A quick note for the new subscribers: I just started doing a bi-weekly series on my notes on technology product management (this is what I do for a living). As I write to learn, you’ll notice posts on the topics I spend most of my time thinking about on weekends. Thus, it is technology/product management on Sundays and parenting on Saturdays. :)
We kicked this series off with an attempt at answering the the most common question about problem management – “What is the day in the life of?” In doing so, we looked at the 4 core skills of an individual contributor Product Manager – problem finding, problem solving, selling, and building effective teams.
Today, we’ll tackle the other common question – “What does a product manager actually do?” As with the last post, this is focused on the individual contributor Product Manager vs. a manager/leader of product managers. We’ll build up to the latter later in the series.
So, what does a product manager do?: A product manager brings a team of cross functional stakeholders together to build a product that is valuable, usable, feasible.
This definition builds on Marty Cagan’s articulation of product management by explicitly calling out the role of the product manager in bringing a team together. I’m aware that there is definition out there that explains what the product manager does by describing a person who spends time at the intersection of technology, design, and user experience. While there are many problems with that definition, the most important is that it is output focused vs. outcome focused. The outcome that matters is a product that is valuable, usable, and feasible.
Inevitably, this discussion on what a product manager does takes us back to the 4 core skills of a product manager. Each of the 4 contributes to our definition –
1. Bringing together a team of cross functional stakeholders effectively requires us to build effective teams.
2. Building a product that is valuable requires problem finding and selling.
3. And, solving for usability and feasibility requires plenty of problem solving supported by selling.
Who are these cross functional stakeholders?: The typical list of functions a product manager works with is proportional to the size of the company and is dependent on the type of product. In smaller companies, multiple members of the team likely wear more than one hat. And, B2B products, for example, tend to have more cross functional involvement due to the concerted go-to-market efforts required. All that said, a list of the stakeholders who combine to become the product team would look something like this –
I have a long list of cross functional stakeholders listed in the “value” part because that is most challenging part of product management. Getting the “value” part right means finding that ever elusive product-market fit.
At this point, it is important to understand why a lot of the writing around product management tends to focus on the process of building products that are usable and feasible. That is a function of the fact that a large number of product managers are working on established products that have already found product-market fit – i.e., the survivors.
In such situations, building effective teams and problem solving through usability and feasibility issues tend to be the skills in demand. Established products do still go through the process of problem definition – every new feature still needs a problem statement and hypothesis. But, it is much easier to do this when you’re building on a successful product.
If, however, you’re tasked to build something new for an existing audience or target a new audience altogether, problem definition becomes the single most important skill (the ability to sell comes second). If you’re not building something that is of value to customers/users and that fits within the company’s strategic vision, the most beautifully designed/engineered product is useless.
What exactly is good problem definition?: Since I’ve spent a lot of time in both posts on the importance of good problem definition, I’d like to do a quick outline of what “good” looks like (detailed version to follow in another post). The two key steps in defining a problem well are generating a good problem statement and hypothesis.
Problem statement – Good problem statements clearly articulate i) the audience, ii) their unsolved need, and iii) the importance of meeting that need.
Hypothesis – A good hypothesis is a proposal for meeting the audience’s need articulated in the problem statement that can be validated/tested through experimentation or analysis of existing data. A hypothesis generally takes the form of a collection of assumptions that can be tested.
Getting the problem statement and hypothesis right are the first and most important steps of the product creation process.
Conclusion and a preview: This post was focused on defining what an IC Product Manager does – bringing a team of cross functional stakeholders together to build a product that is valuable, usable, feasible. As we explored this, we touched on cross functional stakeholders and problem definition. Understanding how to craft a good problem statement and hypothesis helps explain why product creation is less about “minimum viable products” and more about “riskiest assumption tests” – an idea we’ll spend time on in future posts.
At this point, it is also worth taking a step back and asking why we didn’t begin this series with this post. Why not start with what product managers do and then follow it up with the skills required for the job? I think that flow gets to what is generally broken about hiring and PM hiring is no exception. Most hiring focuses on past experiences over skills and, thus, inadvertently prioritizes intercept over slope. There’s an opportunity in there for all of us – for those who are looking to hire great teammates and for those who are seeking to move into product management.
More to come on all of this.