The 5 questions I get the most about becoming a product manager
Q&A about becoming a product manager that will help you find great roles, build your skills, and ask the questions you need
A few years back, I realized that the questions I was getting about my path to becoming a leader in product were ringing a similar tune. While I continue to set aside time each week to connect with folks about product management, I also thought it would be helpful to share some of the most common questions and answers here for you all.
These questions range from the why to the how, and you might even find yourself answering them in PM interviews. At the end let me know what else you want to know or get asked a lot about?
What do you find most rewarding and challenging about being a product manager?
I love this question. It simultaneously renders my greatest professional joys and pain points in such vivd color I can almost still smell the paint drying.
I’ll start with the good stuff. Being a product manager is all about solving difficult problems by working with a diverse group of people to create something that makes other people’s lives better. The designers, engineers, UX researchers, and data scientists I work with all love different facets of that drive, but the product manager has the opportunity to orchestrate the dance of it all.
I love watching the elements come together from an early understanding of a challenge through the evolution and testing of different designs to the implementation of those designs in code that still blows my mind. For me, it’s as close to crafting the perfect meal or piece of music as I might get — just the right mix of creativity, precision, execution, artistry, and science.
And doing that all with great people, masters each of their own craft, is a delight all on its own.
But it comes with challenges too.
As a product manager the most difficult thing for me is navigating the delicate moving maze of business interests, user needs, stakeholder priorities, and the many inputs from marketing, sales, design, engineering, customer support and more. Every decision you make has up and downstream impacts on your product from the user experience to dollars earned and everything in between.
You need to be able to ‘speak’ a dozen languages, yet write with one clear and consistent voice. You need to be able to tell stories about your users and your data with equal facility while honing the leadership skills to know when to listen.
The product manager role is not a specialist role but two of their superpowers must be teamwork and communication to align all of the specialized interests they work with.
What is the right level of technical expertise that a Product Manager should have?
There are some places where you won’t get a PM interview without solid coding fundamentals (there are also differences between technical PMs and other types that I won’t go into detail on here). There are others where you’re more likely to walk in and learn a ton on the job.
Regardless of whether you need the skills up front or can build them on the job, technical skills are essential to a PM’s success for a few reasons:
- speak the speak with engineering. You don’t need to necessarily understand the code that engineers work with, but you do need to understand how different software architecture decisions impact current and future product choices for the business and user so you can help advise and prioritize. You need to be able to earn the trust of your engineers and that often means knowing how to ask questions about how something is behaving to help them come up with the best solution and write specifications that are clear enough for them to work with without trying to solve the tasks for them. Better questions come with context, and that means you have to know your APIs from your micro-services, your authorization from your authentication, and your 500s from your 404s. This isn’t meant to scare you away — you can learn the fundamentals fairly easily on your own in a free course, a couple books, or by buying coffee for the folks in engineering boot-camps.
- identify edge cases. The more attuned you are to the limits of different forms of technical solutions, the better off you’ll be at anticipating potential edge cases.
- conduct your own analyses. Sometimes analytic skills are considered separate from technical skills, but where they meet is in statistical programming and an understanding of how web analytics tools are fed data by different channels and applications and the different ways data can be organized. Regardless of whether you have your own data scientists or analysts to work with, having enough knowledge to both wrangle with the data as well as communicate with the data teams is essential.
To boil it down, you should have a basic understanding of:
- front-end and back-end software engineering practices and common architectures,
- data structures, systems, and analysis techniques, and
- software development cycles, including principles of agile, lean, automated testing, and the like.
Bonus points for knowledge and experience in A/B testing, continuous integration, web analytics, SQL and/or another programming language like R/Python to wrangle data you might need.
Your level of understanding across these buckets will grow as you gain experience, work with different tech leads, and do your own learning. But fundamentally, the PM role is a technical role and you should find your level of comfort and enjoyment in it.
How do you balance the needs of the user and business?
This is not a trick question — it is in many ways the essence of product management. What is good for the user is not always good or viable for the business and vice versa. Even the most user-centered companies and orgs have made steps to better define and refine what specifically they mean — just look at the way Amazon has shifted its definition to center its own people.
Back to the question: how do you do this? In my experience there are a few strategies and techniques that work well in this domain:
- Be clear, transparent, and concise with your business goals. Connect your goals to a strong “why,” give space for the team to talk about it and ask questions, and make the case for the goal through strong story telling.
- Identify key outcomes to improve related to those goals. “Get more users” is not a particularly helpful goal without a more specific outcome you want to move the needle on. Whether you select a user segment, specific market, or other dimension will depend on the needs and strategy of your business, but the outcome will give shape to the problem space the product teams are working in.
- Identify user needs to solve that might improve the outcome. At the end of the day you are constantly working with hypotheses about what might work. Focus on the needs that you think will deliver the most user value AND improve the business outcome. Whether you flesh out these options via an Opportunity/Solution Tree, User Journey Map, Business Canvas or other is up to you and the tools you become comfortable with.
What product inspires you?
For many years this used to be an easy answer for me — Spotify’s Discover Weekly remained one of the best sources of new content discovery that almost always felt just right. It’s as though when I booted up my laptop on Monday (although who really “boots up” anything anymore?) my playlist just got me. It was the right balance of genres, instruments, pace, and truly a way to find new musicians to follow. Curious as to how they cracked this puzzle, the more I read about Spotify’s approach the more I was impressed. Their use of both clever AI and a strong intuition for human behavior created a strong self-reinforcing loop that nudged the broader Spotify community of listeners to improve the algorithms, deliver great recommendations, and continually test new changes.
Sadly my impression of the company — and this particular feature — has waned significantly. Their treatment of musicians through low-paying streams, choices on “free speech” that trouble me, and somehow uninspiring recent selections and innovation has led me to look elsewhere for new curation.
But I share the example above because it ticks a lot of the right boxes for a slice of product that truly does inspire me:
- innovative insights into human behavior blended with extraordinary (and extraordinarily subtle) technology,
- a true need and a gap in the market,
- clean UI that just works intuitively.
What does a typical day look like?
I always chuckle inside when someone asks this because the simple truth is that there is no ‘typical’ day. The life of a product manager is a flux of meetings, analysis, decisions, and probably a lot of Slack. But it is a fair question and I typically answer it by categorizing my week across a few buckets:
- 15% Technical Work: A decent chunk of my time went to Scrum rituals, unblocking, clarifying, ticket writing, etc. as a Product Manager working directly with an engineering team. Work with your tech lead to align on definitions for done, expectations for what goes in a ticket and by whom, and how you can use the board together for transparency, clarity of priorities, and more.
- 30% Strategy and Problem Solving: I don’t always get to 30% but I strive for it and block my calendar accordingly. This isn’t a solo activity — I am constantly collaborating with my Design Lead, Tech Lead, UX partners, and Data Science partners to explore how to address challenges, test hypotheses, gather evidence, and explore different options for how to meet needs and goals.
- 15% Stakeholder Engagement: Whether through 1–1s, initiative-level workshops, design reviews, and more, engaging stakeholders to get input, workshop decisions, and more is critical to this role and you need to be highly strategic about it.
- 20% Communications and Collaboration: A significant chunk of my days are in meetings, and frankly most of those meetings are actually useful. Whether I’m a participant in a workshop giving feedback, learning, or asking questions or working through cross-team dependencies we tend to get a lot done in the meetings we have. Regardless of the day or type, most of the meetings require prep (and more if I’m leading them), follow up, and a combination of artifact creation, direct communication, email, slack, etc. that are all part of connection and collaboration.
- 20% Flex: I would ideally really spend most of this time in different forms of user research, analysis, and talking to customers but that just isn’t always realistic every week. Sometimes this chunk extends to quarterly planning, presentations, and other high impact items that happen less frequently. And let’s be honest, sometimes it’s just cleanup — the inbox, the backlog, the help doc you haven’t touched in months.
And that’s it — the five questions I get asked the most and how I’ve evolved to answer them. Let me know what you think in the comments below!
