Product manager is a problematic misnomer đź«Ł
When I first started out as a product manager, I was perplexed by how different every PM approached the role. What was the right way? It took me a while to realize there’s isn’t one. Where you work, the culture, division of responsibilities between roles, the influence of your org/leadership, industry, stage and your background experience/education shapes how you approach the role. Below is how I see my role. It’s not how everyone sees PM and that’s totally fine with me.
When I’m asked “what is a product manager?” or “how do you define product management?” I may start by saying I think that product manager is a problematic misnomer. To me, it doesn’t actually reflect my role on the team because
- I don’t design, engineer, handle all support or perform all of the analysis/research on the product
- I don’t come up with every product idea
- I don’t make every product decision or determine prioritization for every aspect of the product
- I don’t do all of the product communication with users, press, execs, or the company
- I don’t do all the product planning and goal setting alone
- I don’t manage all of the people working on the product
That’s not to say I don’t contribute, fill in for these roles or take the lead on some responsibilities. Just that when I have the right folks in the roles, I want to support them in doing their best work and getting out of the way.
More often than we’d like to admit, the title and reputation associated with “product manager” can also create unnecessary friction with other functions (esp. design and engineering) who do more of the work to build the product. Whether you’re slinging code, chiseling out designs, interrogating users, or mining the depths of ye olde data mines, I want everyone across the team to feel an extreme sense of ownership over the product and empathy for the user – regardless of their role.
This is especially true at early-stage companies. Everyone at an early-stage company is self-selected to be more entrepreneurial, creative, and passionate about the product. It’s to my advantage if you care deeply about the user, and have ideas and opinions about the product. I don’t want apathetic waterfall executors on my team. I want product thinkers and I believe that means empowering every role to be product.
What are PMs?
PMs are outcome managers. We manage an outcome for users and the business.
An outcome isn’t a product, KPI or metric. It’s not a vision or mission – though it’s closer to it. An Ads PM’s outcome may be as grand as “build a sustainable revenue-generating business” or as focused as “build the best in-app shopping experience.” One of my outcomes was “make Astra the fastest company to develop, test and launch rockets.” How we did it involved software, but it could have easily been about hardware or process.
"Outcomes are the point of building products."
How an outcome is measured, what products are built, or what tactics/strategies are employed to achieve it aren’t the point. They’re different means of accomplishing the outcome.
PMs should not blindly be committed to any one solution, problem, product, tactic, strategy, roadmap, or KPI. We should constantly pull up and evaluate whether what we’re doing is the most efficient way to realize the outcome with the latest information we have. We should invest, evaluate and kill products depending on how they help the outcome. This outcome objectivity sets our role apart and gives us a unique responsibility. Outcomes are the point of building products.
* Most importantly, we’d finally create some distance between acronyms for product, program, and project managers.
What are PMs responsible for?
I see myself as responsible for defining, aligning, and refining how we accomplish the outcome.
"Defining requires understanding a lot of people’s perspectives (often siloed and conflicting) without acting on everyone’s perspectives. "
My first responsibility is to define why we should be taking on a specific market, user, problem, or product and why now. It takes in-depth research, broad evaluation, open exploration, and earnest collaboration to define. PMs are first movers in defining but don’t do it alone. Defining requires understanding a lot of people’s perspectives (often siloed and conflicting) without acting on everyone’s perspectives.
Ideally, what is also being defined is a set of guiding product principles that help the team evaluate information and navigate trade-offs. This way any individual member of the team can reason with the same principles and hopefully make faster decisions through decentralizing – while maintaining consistency and quality. When the whole team has a shared understanding of user problems and product principles, it makes prioritization, trade-offs, and alignment a lot easier.
My second responsibility is to align the team and execs with the strategy, roadmap, and product development plan (whatever it may be) we’ve crafted to advance the outcome. I have to be able to bring the team and execs along in a compelling way. Not everyone is persuaded by the same information or argument.
One of the best ways to persuade is to listen to the team and incorporate their experience and insight (data for some, qual for others, validated research, proof of concept, etc) into the plans. Often you’ll find new ideas or information that will strengthen your plans by forcing you to refine them.
My third responsibility is to refine the strategy, roadmap, or product development by incorporating reasoned ideas and new insights to achieve the outcome. Refinement comes with insight and learning. These should be documented and rolled forward to lead to better outcomes.
For ideas we’re not incorporating, I also have to help the team understand why not or why not now. These are tough conversations but they help strengthen our shared understanding and principles.