Product Management- A Complete Definition
A walkthrough of the Product Management role.
The tl;dr version
“For a given universe, a Product Manager aligns all stakeholders towards a set of outcomes, defines dynamic paths to achieve those outcomes, then drives execution along those paths while constantly measuring progress across comprehensive metrics and milestones — all on a foundation of user focus.”
*It took 4 years of full-time Product Management to enhance my understanding of the role from this image to the sentence above it.
The few widely-available definitions
This Venn diagram from Martin Eriksson’s 2011 blog post is one of the most frequently cited definitions on any piece which explores the nature of the Product Management role. It is a simple and effective visualization which accurately depicts the space within which the Product Mangement role operates while extending the diagram to explain a Product Manager’s (PM) role as —
“To discover a product that is valuable, usable and feasible”
These are a few other great articles on defining the PM role;
- Intercom
- Good Product Manager/Bad Product Manager
- This article by Dan Schmidt (Extension of the Venn Diagram)
Why do we need a comprehensive definition?
“So, What exactly does a Product Manager do?”
There is no single answer that encapsulates the breadth and diversity of PM roles across the global tech industry. The lack of a widespread understanding of the role contributes to unclear expectations being set for Product teams. It is a significant entry barrier for folks with great potential for a Product Management role — understanding the role usually helps incoming PMs structure their interviews in a more coherent fashion.
My take on the question — “So, what exactly does a Product Manager do?” led me to this generic and summarised definition of the role;
“For a given universe, a Product Manager aligns all stakeholders towards a set of outcomes, defines dynamic paths to achieve those outcomes, then drives execution along those paths while constantly measuring progress across comprehensive metrics and milestones — all on a foundation of user focus”
I saw value in distilling the breadth of work onto a single sentence since this approach lent clarity and structure to the definition of a Product Manager.
The given universe
“For a given universe …
This universe is made up of a set of constraints within which a PM must work. Product Management is a “real-world” driven discipline with less space, tolerance or emphasis on ideal yet unrealistic solutions.
It is a ‘given’ universe because, usually, a PM would have severely limited control on defining these constraints — and has to work with what has been ‘given’. Good PMs learn how to push the boundaries of these constraints when they can, but still, get things done even when they can’t push those boundaries towards an ideal setting.
Understanding this universe should be the primary objective for an incoming PM across an interview process, as well as for the first 1–3 months on the role.
These ‘universe defining constraints’ typically consist of ten interlinked contributing factors, in no particular order of relevance —
1- The Industry —
B2B, B2C, SaaS, E-commerce, Ride-hailing, FinTech, etc.— each has a distinctive set of business fundamentals and user behaviors/needs that a PM must get up to speed on. To think outside the box, a PM must first understand what is already inside the box.
2- The Problems/Opportunities: The organization’s strategy & priorities —
This defines the current set of specific problems that the organization (or the specific product team) is attempting to solve or the opportunity set that it is attempting to exploit. Good PMs will learn how to influence this constraint and deliver a disproportionate impact. However, this constraint also determines the likelihood of success. A product that tries to tackle a problem that doesn’t really exist, or leverages a solution that doesn’t make sense — will cease to exist once funding dries up. The same is mostly true for great products that have no concrete ideas around profitability.
3- The Stage/Scale of the organization —
Early-stage start-ups have high horizontal spread in terms of Product Management responsibilities, with less scale. Growth stage start-ups involve building/iterating on scalable products and processes. Big Tech startups involve running a small part of high-scale business flows, while constantly innovating without disrupting regular business processes.
4- The organization’s ‘Product Culture’ —
This defines who a PM effectively reports to, besides their manager. The Product Culture is affected by the organization’s understanding and expectations from a PM role
Product Culture determines the default weight of a PM’s opinion in a room of decision-makers.
Product Culture dictates the ownership a PM would have over their universe. Regardless, a PM will always be on the line in case things go wrong — Just one of the perks of the role.
5- The Competition —
Horizontal competitors have a wide range of offerings across a larger market, with a trade-off on customized or deep solutions. Vertical players have specific tailor-made solutions for a smaller market. PMs focus on both types of competitors.
Good PMs learn what set of dimensions (metrics and user needs) they compete for across the competitor and user landscape.
Eg- A critical skill in competitor landscape analysis is identifying a seemingly disparate product as a competitor the way Netflix considers Fortnite a competitor for a user’s attention.
Another point to note is that crowded markets leave less space for creative, long term products — and tend to push focus towards feature parity with competing products, in which case network effects and capital play a more significant role than product.
6- The Funding (and rarely, Profitability) —
This dictates how far in the future a PM can plan for, with a reasonable amount of confidence. More funding runway fosters alignment for long-term projects. Limited funding forces you to get highly creative, focussed and hacky.
7- The Product Management Vertical —
Typically non-conglomerate organizations would have between 2–5 product verticals that operate with a high degree of independence.
(Eg — ‘Supply chain’, ‘Consumer App/Web’, ‘Customer Experience’ in
E-commerce.)
The PM vertical decides the set of users who exist in the PM’s universe — enabling them to focus on the associated user demographics, needs, and personas.
8- The Product Management Hierarchy —
As a PM transitions along the career ladder, the scope and the impact of the work increases. Typically, whether a PM is an Individual Contributor or a People Manager — is the only difference within Product Management roles. Otherwise, everyone has similar work components across levels — with the scope and importance to the organization’s core business being the differentiating factors in a PM’s universe as they move to more senior roles.
9- The Team —
A PM does close to zero tangible work seen on the final product (No code or pixels — just decisions). PMs merely provide direction to the team they work with. The team is the most critical component of the PM’s universe.
Having a team of smart, motivated and aligned developers, designers and business folks is the only way a PM can truly deliver impact. As a PM, your impact is directly proportional to the competency and the synergy within your team.
Good PMs are invested in helping inspire, hire and retain the best folks for the teams they work with.
10- The Reporting Manager —
PMs do not have people reporting to them. Instead, PMs have ownership of the direction of the work done by the same set of people who do not report to them.
Often times things will get blocked. Process will choke progress. Lethargy will choke delivery. Legacy will choke innovation.
So, when it all goes south despite a PM’s best efforts and intentions, the one person a PM should be able to count on to push the boundaries of their universe — when they can’t anymore — is their reporting manager.
Aligning Stakeholders and Outcomes
… a Product Manager aligns all stakeholders towards a set of outcomes …
The “PM is a mini-CEO” tagline is catchy. This McKinsey report states that Product Management is a new training ground for CEOs. While being true to some extent, definitions that include the term “CEO” tend to create an illusion that PMs have more authority than they actually do.
All stakeholders (Design, Engg, Marketing, C-Suite — and other linked business teams) are as important as the PM in the “Outcomes” component of a PM’s work.
A PM is ultimately accountable for the decisions made for a product. However, a PM does not need to make these decisions on their own or come up with all the creative ideas themselves. Instead, a PM must work as an effective curator of ideas.
“Product sense” — an intuitive understanding of what will work and what won’t— is one of the biggest differentiating factors among PMs.
Good PMs create multiple channels for an influx of ideas and become evangelists of great ideas. They master the art of deriving tangible outcomes from a chaotic sea of inputs, ideas, and opinions — and then drive alignment on these outcomes.
Effort is a vector. The direction is as important as the magnitude. Product Management is essentially about being the direction component of the Effort vector.
Outcomes are a set of measurable and directional goals that a team will work towards. Anything a team chooses to do must contribute to these agreed outcomes. The set of outcomes is dynamic and should have a feedback loop coming in from product analytics, business strategy, and user research — and not reside as a static and permanent constitution. (The only caveat here is that frequently changing outcomes will disorient a team and derail work.)
Outcomes can be from macro-level, Eg- ‘Focus on user growth in new markets’, or micro-level, Eg- ‘Improve the clickthrough rate on search results’, depending on the universe the PM is working within.
Once the outcomes are defined, PMs must focus on communicating these outcomes effectively and provide any reasonable person a convincing answer to the question — “Why does this set represent the outcomes that need to be pursued?”.
A PM cannot decide and impose outcomes unilaterally. This is a good thing. It ensures that a PM is valued only if what they say makes sense. The “lead by influence, not authority” angle is actually a beautiful safeguard that prevents the PM from becoming a single-point-of-failure for a team.
Defining paths
… defines dynamic paths to achieve those outcomes …
Once the outcomes are defined, a PM must then chart out a set of paths to achieve those outcomes. This is where the PM bridges the world of business objectives and user-focussed outcomes — to the world of design and software development. It is this transition layer that incoming PMs need to work on the most to become effective.
These dynamic paths constitute the Product Roadmap. A Roadmap is a living document that shows the current trajectory plan for a team’s work over a certain time period typically across the next 3 to 12 months. A good roadmap contains a mix of new features, bug fixes, new product launches, and existing product iterations. “How to build a roadmap?” is a separate field of thinking altogether. There are many paths that can lead a team to their outcomes. The PM tries their best to find the shortest and most effective paths.
The key guiding principles on roadmap building are
- Alignment of items on the roadmap to outcomes.
- Prioritizing based on some form of an Impact vs Effort matrix.
- Effective stack-ranking (What should the team build next?).
- Transparent communication on each item added and why it is lies where it does on the stack rank.
- Taking inputs from development and design teams on the correct paths to follow.
- Following the “Strong opinions, Weakly held” philosophy. An idea has no owner. Freely merging and twisting ideas to arrive at the correct set of items for the roadmap.
- When things go wrong — Feedback and criticism should be effectively ingested. Good PMs take the hits for their team. They are dynamic and quickly respond to new inputs with the right changes to the roadmap.
A PM should always involve the engineering and design teams in the process of defining the paths. Apart from being a source of great ideas, this provides a sense of ownership to the team which tends to get things done quicker and better.
Driving execution
… and finally drives execution along those paths …
This step comes in once the design and development teams finally start the building process for a product. There are many philosophies that guide this process. Variants of the ‘Agile process’ seem to work for most organizations. It is important to highlight that the end result has to drive the process, and not the other way round. Having excessive amounts of ‘process’ in the execution space is a sure-fire way to demotivate a team.
PMs are required to focus on creating holistic and comprehensive PRDs (Product Requirements Document)- followed by ‘PRD grooming sessions’ with the designers and developers who would work on the product. PMs ensure effective communication and mutual agreement before work starts. They unblock effectively using quick daily meetings or ‘Stand-ups’. They shield the team from noise as they build. Most importantly they ensure the team understands what they are building, and why.
PMs then take a step back and trust the team to work their magic and get things done — providing support when needed.
Measuring progress
… while constantly measuring progress across comprehensive metrics and milestones …
Good PMs measure obsessively, but also understand that what they can measure usually represents a subset of what they would like to measure.
A PM must learn to leverage available tools and processes in an ethical manner — producing enough raw inputs to derive insights that feed into the entire Product Management process across the universe, the outcomes, the paths, and the execution — while preserving a user’s right to their privacy.
A few key points to note on the work here;
- PMs define comprehensive metrics that are relevant and are aligned to the outcomes for their universe.
- PMs also track milestones, which is a metric touching a certain value. Milestones serve as incredibly effective spaces for teams to pause and take pride in the work they are doing. Celebrate milestones quickly and keep moving.
- PMs design products that measure all the metrics they want to measure. This should be baked into every PRD.
- PMs ensure that data is democratized and accessible — with safeguards
- Good PMs constantly swim in their metrics and generate relevant insights. They evangelize and prove the notion that a data-inspired approach leads to great products.
A foundation of user focus
… — all on a foundation of user focus”
Within the breadth of the world that is Product Management, it is easy for a PM to dive so deep into the universe, the outcomes, the paths, the execution, and the metrics — that they may forget the point of it all.
Referencing Martin Eriksson’s 2011 blog post again — PMs need to remember that the point of it all is — “to discover a product that is valuable, usable and feasible”
As a PM, Always remember why you’re doing what you do. Remind your team when they forget. Be the voice of the user within your team and truly care about your users.
Empathy is not a 5-minute task of closing your eyes and pretending you are the user. Empathy is a constant conversation. Always aim to maximize the spheres across which you converse with your product’s users. Everything you use to connect — from a Google analytics report to twitter mentions to an f2f conversation— builds empathy.
For even with capital moats, bleeding-edge tech and disruptive business models in place — great products can only be built on a foundation of genuine and comprehensive empathy.
