Have you heard? My new book Continuous Discovery Habits is now available. Get the product trio's guide to a structured and sustainable approach to continuous discovery. For this month’s Product Talk post, I recorded a video where I consider the difference between product managers and product owners. You can watch the video or read an edited version of the transcript below.
I want to talk about product managers and product owners.
This is a topic that’s come up quite a bit for me in the last few weeks. I’ve had several companies ask me if they should be hiring product managers or product owners. Do they need both?
And so I want to talk a little bit about these two roles, the differences, and what they mean in terms of where you are on your own journey toward a continuous discovery process.
For those of you who aren’t familiar with my background, I work as a product discovery coach. I teach teams all over the world a structured and sustainable approach to continuous discovery. And this post is really going to build on what I’ve seen from working with teams in all different places that are striving toward a more continuous discovery practice.
Traditional Product Management: Gathering Requirements from Stakeholders
The traditional approach to product management reflects how many teams still work today.
Let’s start at the beginning. This is what I often refer to as “traditional product management.” It’s where product management was grounded for many, many decades. We still see most companies rooted in this model in one way, shape, or form.
In a traditional company, a product manager sits in the middle between business stakeholders and the engineering team.
Now typically the product manager is working with business stakeholders to gather requirements. So in this model, the business stakeholders are making decisions about what to build. The product manager is working with them to turn those decisions into viable software.
And then the product manager turns around, writes typically long requirements documents, and then hands that off to the rest of the team. This is often what we call a traditional waterfall model. The product manager gathers requirements, documents them, a designer creates a design based on those requirements, and the engineers build software based on those requirements.
The reason why this is considered the old way of working—even though many of you may still work this way—is because we see a lot of challenges in this model.
Marty Cagan often uses this analogy of mercenary teams versus missionary teams. He argues that we want our teams of engineers to be missionaries. So let’s talk about the difference.
A mercenary team is one that is really an order-taker. They’re being told to build something specific and they’re just building exactly what they were asked to build, whereas a missionary team has been tasked with a mission. There’s an objective they’re trying to reach, and they join the team, buy into the mission, and deliver higher quality software.
A mercenary team is one that is really an order-taker. They’re just building exactly what they were asked to build, whereas a missionary team has been tasked with a mission. – Tweet This
Every business wants high-quality software. So our goal is to strive for missionary teams.
Now this traditional model, unfortunately, really encourages mercenary teams. And the reason why is that the requirements are coming from business stakeholders.
There’s nothing wrong with business stakeholders sharing what they think the business needs. In fact, that’s their job.
But when we let business stakeholders define software requirements, we’re letting the people furthest away from the technology decide what to build. And they don’t always have the requisite knowledge to write good product requirements.
When we let business stakeholders define software requirements, we’re letting the people furthest away from the technology decide what to build. – Tweet This
When the engineers are building something and they realize it wasn’t designed quite right, they’re too far away from the business stakeholders and the real needs.
And they’ve been trained to just be mercenaries, so they just build what they’re told, even if they know it’s not going to be good.
We don’t want that. We want our engineers to be engaged in the process and giving us feedback because they’re the closest to the technology and they know what’s possible.
The Scrum Method: Giving Voice to the Customer
In the late ‘90s and early 2000s, we saw the adoption of a method that’s often associated with agile but actually predates it—Scrum.
The Scrum approach introduces a product owner as a liaison between customers and engineers.
In the Scrum model, we’re particularly trying to solve a couple of these problems. Scrum labeled that middle go-between role as the “product owner.” So that’s where that term comes from.
You can see in this diagram, the product owner is still gathering requirements, but in scrum, the product owner is really meant to be the voice of the customer. They’re gathering requirements from the customer.
They’re still writing requirements, but they’re working in much smaller iterations. Instead of writing a long product requirements document that might represent months of work, they’re typically writing user stories and working in one or two week increments, often called a sprint.
We get a few benefits with Scrum right away. Writing shorter requirements and working in faster iterations means that we can get feedback from customers more often—at least in theory. Unfortunately, I’ve met plenty of Scrum teams that don’t get feedback from customers after each sprint.
Scrum is based on the idea that if we work in smaller increments, we can get feedback from customers more often and course correct as needed.
Scrum is based on the idea that if we work in smaller increments, we can get feedback from customers more often and course correct as needed. – Tweet This
But in this model, the product owner is still just gathering requirements. This means the customer is deciding what to build.
Sometimes the customer is those very same business stakeholders. If we’re building internal tools, business stakeholders are still making the decisions about what to build. Sometimes the customers are end users. But in either case, it’s not necessarily true that our stakeholders or our customers are the experts on what’s possible with technology.
It’s not necessarily true that our stakeholders or our customers are the experts on what’s possible with technology. – Tweet This
In this situation, the engineering team is still pretty far removed from the decisions about what to build. So we’re not turning them into missionaries. They’re still mercenaries and we’re still not going to get that high quality we’re looking for.
Project-Based Discovery: Product Trios Co-Create with Customers
A number of teams have pushed the envelope even further, especially in the last 15 years. And they’re moving to a trio-based model of discovery.
In project-based discovery, the product trio is involved in co-creating with customers, but still writes product requirements for the engineering team. This moves engineers further from the discovery process.
When we use the term “discovery,” we’re just talking about who makes the decisions about what to build. In this case, the product manager or product owner joins with a product designer and a software engineer into a product trio to co-create solutions with customers.
In this situation—what I refer to as “project-based discovery”—the product trio is iterating with customers, but they’re still writing requirements and handing them off to the team. They’re still trying to take a complex product or service and translate it into requirements with engineers.
Most of the engineers are still removed from the discovery process. So we’re not solving all of the problems. But in this model, we are seeing that customers are much more involved in the process. Our product trio is no longer gathering requirements. They’re bringing their technology expertise and working with customers to iterate on their ideas. Customers are bringing the knowledge of their context. The product trio is bringing the knowledge of technology and they’re co-creating better solutions. So that’s great. The left-hand side on this map looks really good.
The challenge we run into with project-based discovery is sometimes this team on the left can move really fast and they’re just loading the team on the right with a ton of requirements and the team on the right can’t keep up.
Other times, we see the opposite happen, where discovery is taking a long time. It’s hard to get the prototype just right. We’re not exactly sure what to build. And the team on the right is sitting, waiting for more work.
When these cadences get out of sync, companies start to wonder whether they should have a product discovery team and a product delivery team. If discovery’s too slow, maybe we have many discovery teams and one delivery team. If delivery is too slow, maybe we have one discovery team and lots of delivery teams. And so we start to think about separating these roles.
The problem when we do that is we’re starting to reintroduce these handoffs that we saw in that more traditional product management model, which we don’t want to do. We actually want to bring the engineering team closer to the discovery, not further away.
We want to bring the engineering team closer to the discovery, not further away. – Tweet This
The other problem with this model where the trio is doing discovery together and they’re writing requirements and handing them off to the engineering team is the product manager often gets overwhelmed. They spent a ton of time co-creating with customers, but they’re still being asked to write these really detailed requirements. So they’re also spending a ton of time in delivery. They’re grooming backlogs. They’re going to all the sprint ceremonies. They have to be available to answer all the engineers’ questions. And it becomes too much work for one person.
This is typically where a company thinks, let’s add a product owner to the mix.
Project-Based Discovery with Product Owners: Pushing Engineers Further Away
Project-based discovery with product owners introduces a new person to the workflow, adds further distance between engineers and discovery, and creates a job that isn’t very interesting.
In this model, the product manager works with the trio and they do all the discovery work co-creating with customers. They hand off all their discovery learnings to the product owner, and the product owner translates that into product requirements that then go to the engineering team.
What did we do here?
First of all, we introduced a handoff. The product trio is now handing off a bunch of work to the product owner.
We also just added a step where we’re further removing the engineers from the discovery process, which we don’t want to do because we’re making them mercenaries and not missionaries.
And the other thing that we did is create a pretty crummy job. If I’m that product owner and I don’t get to engage with customers, I don’t get to make any decisions about what to build. All I’m doing is essentially being an assembly line worker. I’m taking input from the trio, translating it to requirements, and handing it off to the team. That’s not a very fun job.
You’re going to see a high turnover. You’re going to see apathetic employees, and you’re going to see your junior people grow out of this role pretty quickly. Good people are not going to tolerate this role for more than a few months.
So this is not the way to solve this problem.
What you want to do instead is to move from a project-based discovery model toward a more continuous discovery model.
When your product manager is overwhelmed, you don’t need to add a product owner. You need to move from a project-based discovery model toward a more continuous discovery model. – Tweet This
Continuous Discovery: Bringing Engineers Closer to Discovery
In continuous discovery, the engineers are as close to discovery as possible, which increases their likelihood of becoming missionaries.
In continuous discovery, the product trio is still co-creating with customers, iterating through prototypes, running experiments, and doing interviews. Their goal in co-creating with customers is taking the customer’s knowledge about their own context and combining it with the product trio’s knowledge of what’s possible with technology and co-creating the best solution given both groups’ knowledge.
You can see in this model that the engineers aren’t positioned off to the right. We actually want to bring them as close to the discovery work as possible. That means when they’re available and they have time, they should be coming to our interviews. They should be part of our experiment designs. They should be helping us with prototypes. And of course, they still need to do the delivery work, and we need a way to communicate what we’re building and why—not just “Here are some requirements. Go be a mercenary for us.”
In this model, we’re using the same prototypes that we’re using with our customers to communicate requirements to our engineering team. When we communicate requirements with prototypes instead of requirements documents or user stories, we’re able to communicate complexity much more easily.
We’re also going to use the same types of artifacts that we used in discovery to synthesize what we’re learning—opportunity solution trees, customer journey maps, interview snapshots—to communicate with our engineers why we’re building what we’re building.
When we take this approach, we’re not writing anything new. We’re taking the same things that we were creating to do our discovery work to communicate our discovery work. So that product manager isn’t getting overloaded doing two jobs.
Plus, we’re giving our engineers the context they need to answer their own questions, to make better decisions about how to implement something, how to design the data model.
They have the same context the product trio has. So they’re now empowered to be missionary teams.
If you’re finding that your company is starting to slip down this slope of looking at, “Hey, maybe we need product managers and product owners, we’re not really sure if you’re a product manager or a product owner,” hopefully these different models will help you start to put it into context.
The vast majority of times when a company feels like they need both roles, it’s usually because they’re still stuck in this project-based discovery model, where they have one foot in the old waterfall, traditional product management model, and one foot in this more customer-centric discovery model. And because they’re trying to do both jobs, it’s just slowing them down.
The vast majority of times when a company feels like they need both a product manager and product owner it’s because they’re still stuck in the project-based discovery model. – Tweet This
I really encourage teams and companies to step that foot out of the traditional model and step fully into a continuous discovery model.
I would love to hear your feedback on this. Feel free to comment on YouTube or reach out on Twitter to share your thoughts and experiences.
