Product Owner vs. Product Manager
The following question was asked this morning in the Product Hive Slack Team:
What is the difference between a product owner and a product manager? Is there a difference at all?
I’ve answered this question many times before, but today, I took a different approach and thought I’d share my response here.
Many, hearing the title for the first time, assume it’s something new. Some organizations use the title interchangably with Product Manager, adding to the confusion. Some, note the difference between the two roles, but assign the responsibilities t0 a single individual. Other teams, that are entirely Engineering-driven, don’t even have Product Managers.
Several answers were offered, mostly along the theme of a Product Owner being more tactical and involved with day-to-day management and communication with developers, and Product Managers being more focused on the business, customer, and market. This is good and close, but misses the principle motivational difference, which illustrates the weakness in the entire framework around which Product Owner is built.
Yes, I’m proposing that the role of Product Owner shouldn’t even exist.
Product Owner is not a new role; it’s existed for almost two decades now and is part of the Scrum Agile Software Development Framework. Product Owners generally only exist within Engineering organizations fully utilizing this framework. And, generally, only those that are large enough to justify the head-count; meaning, you don’t often see them at startups. They usually show up as organizations get bigger and start to slow down. This should be a major red flag.
What’s important to understand is that Product Owner is a product delivery role. Product Managers, on the other hand, are responsible for product discovery.
Product Delivery is focused on shipping. It’s purpose is to build product and ship fast. The Agile Framework is a major step forward from how things were done before, but it doesn’t answer the question of whether we’re building the right thing. Specifically, it’s time to call bunk on Scrum. It’s better than monolithic epics, but it’s just mini waterfalls. It’s certainly helped increase output, but what’s the point of moving fast if you have no idea if you’re even headed in the right direction?
Product Managers are responsible for deciding what to build. The proper way to do this is through product discovery, which is the process of determining if you’re solving the right problems for customers. Product Discovery is learning that drives towards a desired outcome. Initiatives emerge from a deep understanding of the customer and are iteratively tested.
Most products and companies start with a clear problem they are trying to solve, but pressure from the market, executives, boards, and investors, cause them to optimize around process instead of learning, and lose this focus. They slip, catastrophically, from outcomes to output as they begin to scale, forgetting what they are are truly in the business for.
What is the proper approach then? Whatever focuses you on outcomes and learning instead of output and shipping.
If your process is complicated enough that you need a Product Owner and a Scrum Master, then your process is too complicated. Most roadmaps are not only a waste of time, but are toxic. They exist to support old, siloed processes built to deliver output instead of outcomes. These frameworks and methodologies compensate and incentivize teams to ship features instead of to learn. You don’t need a Product Owner and a Scrum Master if your roadmap isn’t longer than 4–6 weeks and a roadmap longer than 4–6 weeks “is based on assumptions” and, as Jeff Gothelf says, “is a complete fabrication.”
Instead, you should have small, autonomous, collocated, cross-functional teams, that, with specific areas of expertise, are all responsible for discovery, building, and delivering entirely on their own. These teams should be comprised of a Product Manager, a Product Designer (or UX Designer), an Engineering Lead, and 4–5 Product Engineers. With small teams such as this, you need little official process.
Techniques such as Continuous Discovery, Continuos Delivery, DevOps, OKRs, Hypothesis-based Experiments, Jobs Theory, and Sense & Respond focus and motivate teams correctly and produce effective results.
Again, from Jeff Gothelf:
Our goal is not to create a deliverable, it’s to change something in the world — to create an outcome. We start with assumptions instead of requirements. We create and test hypotheses. We measure to see whether we’ve achieved our desired outcomes.
This is the role of a Product Manager. This is how companies succeed and delivery products with powerful and lasting value.
When I’m asked for a roadmap, I explain why we don’t plan out in detail farther than 4–6 weeks and then move to discussing our strategic plan, which includes our current experiments, which support our quarterly OKRs, which support our strategic themes, which support our company mission. A strategic plan can provide a year’s worth of vision, but it’s just a vision, not a set of deliverables.
Ed Catmull, CEO of Pixar, says it so well in his book Creativity, Inc.:
I believe the best managers acknowledge and make room for what they do not know — not just because humility is a virtue but because until one adopts that mindset, the most striking breakthroughs cannot occur. I believe that managers must loosen the controls, not tighten them. They must accept risk; they must trust the people they work with and strive to clear the path for them; and always, they must pay attention to and engage with anything that creates fear. Moreover, successful leaders embrace the reality that their models may be wrong or incomplete. Only when we admit what we don’t know can we ever hope to learn it.
If you’re not a member of Product Hive, by-the-way, you’re missing out. It is a community of product managers, strategists, and designers in Utah and is one of the most active and vibrant I’m aware of. The group currently has over 2,300 members, runs multiple in-person events each month, and has almost 800 individuals actively participating in their Slack Team.