Why the PM and the PO should be the same person

There is a long running discussion on whether the product manager (PM) and the product owner (PO) should be the same person, or two different persons.

In this article I'll share my perspective on this debate, I'll try to take the viewpoint of both sides, and articulate a case for why the PM and the PO should be the same person, and then give some pointers on how to make that work.

This perspective is based partly on learnings from the more 300 interviews with product people (both "product managers" and "product owners") that was the foundation of my book Epic Alignment, and partly on thinking by some of my favorite product thinkers (specifically: Marty Cagan, Melissa Perri, Teresa Torres, Jeff Patton).

The two schools of PM vs PO

Initially, trying not to put down any value judgement, I'd like to clarify the stance of the two schools.

The one-person school

PM is a title that a person has. The job description of the person is to manage a certain product or area of a product, and their goal is to make that product successful.

PO is a role on a Scrum team. In the Scrum methodology, there is role called "product owner". The role of the PO in Scrum is essentially to manage the backlog. The PO is responsible for prioritizing the backlog and for that tickets in the backlog (e.g. user stories, bugs, improvements) are detailed to the point where they can be developed by the team.

The PM should be the PO. The one-person school believes that the PM and the PO should be the same person, i.e., that it is the PM that should have the PO role on the team.

The two-person school

PM and PO are two different job titles. The PM is customer-facing, and the PO is team-facing. The interface between the two is that the PM hands over high-level requirements that the PO then turns into user stories and details them together with the team.

The SAFe framework is maybe the most known proponent of this school. Here is their definition of the two titles:

Where the urge to split the responsibilities into two people comes from

Many different activities to pursue

For a PM that also has responsibility for working with the team to detail what to build, there is indeed a lot of things to do.

McKinsey have done a study of how PMs split their time, across different activities:

It is clear that there are indeed many different activities that they are expected to do, and that it is hard to make time to do them all, not to speak of learning all the wide array of product management skills required.

A messy, iterative process with many artefacts and stakeholders

The product management process can be said to consist of the steps Strategy, Prioritization, Discovery, Refinement, Development, and Iteration (when I refer to Delivery, I mean the combination of Refinement and Development).

Across this process, the PM must handle many different artifacts that live in different and disparate tools, and they have to involve different team members and stakeholders that have different perspectives and preferred ways to interact.

All-in-all, this means that the many different activities described earlier have to be performed within a messy process.

The urgent pull to detail things for the team to build

When there is not enough time to do what you have to do, there is a tendency for the most urgent thing pull the hardest, even at the expense of things that might actually be more important. This is a tendency that causes big problems for PMs.

There will always be a sense that the PM needs to make sure to spend time to detail things for the team to develop. After all, if the team would "run idle", that would be a huge cost.

Because of this, many PMs that are stressed out by the many different activities they have to do and the messiness of their process, turn to focus on solving the urgent problem of detailing things for the team to build.

Under-investing in important strategy and discovery work

PMs risk of spending almost all of their time on preparing delivery, refining things to build.

If they do this, it means they have very little time to spend on the important work of strategy and discovery, which means they won't have a clear perspective on how feature outputs link with business impact and customer outcomes.

If the PM does not have an own thought-through perspective on this, it is indeed very hard to resist the pull from stakeholder who requests features.

When this happens, the team turns into a feature factory. Trying to avoid this is what Melissa Perri describes in her aptly named book Escaping the Build Trap.

Delegation as the way to escape urgent busy-work and get important work done

The Eisenhower Matrix is a good framework to illustrate the difference between urgent and important.

It is wholly applicable to the challenge PMs face when trying get out from under urgent work to do refinement of what the team should build, so that they can do the important work of strategy and discovery.

The answer seems clear: Delegate. But the next question is then: Delegate to whom?

The illusory solution of delegating part of the burden from the PM to a PO

It is understandable to want to introduce a new role to which the burden of working with the team to refine the things that are to be developed. And if that is to be done, it makes sense to carve out the PO role on the scrum team to another person.

Afterall, if the work is split among two people, the PM and the PO, then at least someone is working on strategy and discovery.

It must be admitted, that having a PM and a PO is better than just having a PM that is entirely overwhelmed and works only on delivering on the latest request from sales or marketing.

However, the team is then quite far removed from strategy and discovery, and there is no-one who can truly connect strategy and discovery with delivery

The problem with splitting the title and the role into two people

The goal of the PM

The goal of the product manager is to maximize business impact and customer outcomes with a minimal amount of developed feature output.

Here is an drawing by Jeff Patton that illustrates this rather well.

Why the PM-PO handover makes reaching the goal harder

To be successful at this, the PM needs to have knowledge across and be able to connect strategy, discovery, and delivery. If the thinking on what feature outputs to build is handed over to another person, e.g. with the role of PO, then there will be a handover to that person.

This handover will lead to a weaker connection between the thinking of business impact and customer outcomes on the one hand, and feature outputs on the other hand. This puts the part about minimizing feature outputs in jeopardy.

When PM and PO is split, opportunities to minimize feature outputs can be missed in two ways. First, it is less likely that a PO will cut down functionality looks relevant but won't actually drive value. Second, it is also less likely that a PM will pick up on a technical solution that could solve a problem with very little development effort by the team.

The compoud effects of missed opportunities like these amount to a strong reason why the PM and the PO really should be the same person.

Example of how the handover can be problematic

To illustrate the above, let's take an example.

Customers have been asking to be able to log in with Google accounts. Let's say there are two ways to solve this:

A. Add Google account credentials to account with password

B. Allow either Google or password accounts

The main difference is that with solution B, it will not be possible for existing users that crated their account with a password to start using their Google accounts to log in. Thus, solution A is the best from a customer perspective.

But let's say A is significantly more time consuming than B. Let's also say that the reason why this feature was requested was to drive the business impact of increasing signup conversion. For that B is just as good. Given that B is much faster to do, the ratio of customer outcome to feature output is much higher with B.

But, unless all this information is properly conveyed in the handover between PM and PO it is not certain that the PO will chose to go with B. Without talking with the team the PM won't know enough about the technical details to realize that B much faster to build than A. If the engineer is in the customer meeting, or if the PM has a deep technical perspective, it is likely that B will be chosen. However if the PO has the discussions with the developers, which are then one further step removed, it is more likely that A will be chosen.

In this case, and in cases like this, teams where the PM is also the PO will be much more effective.

How to make it work with one person as both PM and PO

Delegating to the team instead of to a PO is only part of the solution

Let's come back to the Eisenhower Matrix. PMs are being pulled into spending most of all their time on refinement, as it is always urgent to detail what to develop for the upcoming sprint. The matrix indicates that the PM should try to delegate all or part of this work.

The two-person school concludes that this should be delegated to a new person that takes over the PO role. To the one-person school, however, only part of the solution involves delegation to the team.

Sharing part of the work with the team is an important part of making it work, and to some extent it can save time, especially if done right. But there are several more practices to get right, not least taking the time to beyond the PO role, no matter what.

Make time for strategy and discovery work, timebox if necessary

One important driver of success when being a PM that also has the PO role is just carving out the time to work with strategy and discovery, regardless of whether you feel like that time exists. Not doing the work of linking feature output properly to business impact and customer outcomes is simply not an option.

If it is not clear to you how your work links up with overall company strategy, or what exactly the business impact your work is meant to have, or what customer outcomes should drive this, you need to make sure it is. Opportunity Solution Trees are a great artefact for structuring the thinking around this and communicating it with your leadership. To move from being a feature factory to actually leading the product development, you need to gain autonomy by building trust in that you can work with these concepts.

If you feel like you never get the time, a way that will make it happen even if it is tough is to place a timebox in your calendar for this type of work every week, and then stick to it.

A quick way to get up to speed with this is to create draft strategy documents such as business model canvas and value propositions based on a template and then engage with leadership in a discussion about them.

To make sure that the features you develop actually helps drive customer outcomes, it is important to get a good product discovery process running with your team.

Involve the team in both discovery and refinement

To give the team the level of insight needed to be helpful in refinement, they will also need to be involved in discovery. Teresa Torres writes about how to make this happen in her book Continuous Discovery Habits.

Get habit of talking to your customers together with the team. Conduct at least weekly interviews with the full product trio present (PM, tech lead, and design lead).

Work together with the product trio to codify the understanding of customer problems (e.g. by creating experience maps and opportunity trees).

Work with team and stakeholders to first generate a surplus of solutions to select from and then to combine them into a few solutions for which assumptions are identified and then tested.

Work with user stories, and take responsibility for "confirmation"-part

User stories enable better collaboration, as all team members and stakeholders can relate to a story form a user, and the three Cs framework can help to illustrate the difference between when the PM is also the PO vs when not. The three Cs of user stories illustrate the work needed to be completed in refinement - card (the story itself), conversation (all that is said relating to that story), and confirmation (the agreed criteria for when the story has been delivered).

When the role of PM and PO is split among two people, it is common that the PM interface between them occurs primarily at the card level, or the stories themselves. This risks leading to the problem described above, where the PO does not have enough business and customer context, and so does not set the appropriate bar for the confirmation level, e.g., writes unnecessarily demanding but ultimately non-value-adding acceptance criteria or perhaps misses an important criteria.

When the PM also has the PM role, the trick is to be very involved in the card and the confirmation levels, but delegate and leverage the insights from the team in the conversation that happens between the two. The PM should then adapt what user stories and acceptance criteria to go for based on how much effort they require for the team to complete.

Remove time sinks by working more effectively with documents

We looked at the study by McKinsey about where PMs spend their time earlier. One thing that stands out in the study is that PMs spend more than half of their time on writing and maintaining these different kinds of documents and collaborating with internal stakeholders. Earlier we also looked at the messy process PMs have to work with, including many different documents and tools to update and copy-past between as they collaborate with team and stakeholders.

As we put these two insights together, it becomes clear, that an improvement in the way that PMs can work with and collaborate around product requirements documents (PRDs), as well as other documents, has an enormous potential to free up time. This was also the main topic of my book "Epic Alignment - How the Best Product Managers Work with Feature Documents"

One of the core tenets of the book is that by adopting a few behaviours it is possible to work with a single source of truth, thereby making huge time savings.

Some of the behaviours that we have seen enable PMs to get working with a single source of truth to work in practice include:

• Making documents at the epic level, and letting the document live and evolve from early idea and into development
• Using a template to guide and harmonize the way the team works, and to make it easier for stakeholders to find their way
• Basing the work in the document on user stories, and let the stories in the document evolve as well, from stub stories, onto user story mapping, and then adding more details and then acceptance criteria as work progresses.
• Using an outliner to be able to quickly capture and structure the relevant details while still being able to collapse and get an overview to avoid cognitive overload
• For content that does not fit in the document, to pull it in and embed in document or refer to it in a clear way
• Work with decisions as explicit questions in the document, to be able to involve the relevant people, keep track of what is left to decide, and to capture the rationale for decisions

Most of these behaviours are possible to adopt almost regardless of tool stack, but having the right tool for the job can indeed be very helpful.

Delibr was built with this in mind, to help PMs rise above the daily grind by super-charging their efficiency in refinement and thereby getting time to work on strategy and discovery. Don't hesitate to get in contact with us if this sounds interesting.

Limit the amount of parallel work in progress

Even with a great process for each feature being built, running too many such processes in parallel will remove focus be a reduce team effectiveness.

Work is always more productive when it can be done on one or a few things at a time than if it has to happen on many things in parallel. Referring back to the messy process above, it is easier to manage the messy process for a PM that is deeply involved in 2-3 epics at the same time, than for a PM that works 5-10 epics at different stages of discovery and refinement.

This becomes even more important when the PM also has the PO role. It is difficult enough when the PM works on one part of the process and then hands over to the PO and the team that works on another part of the process. But, when the idea is to involve the development team, or at least a product trio, it becomes even harder to handle the discovery and refinement of many epics simultaneously.

However, bringing the team into discovery and refinement brings two changes. It make it more difficult to it work with many epics simultaneously, but it also makes it easier to reduce the cycle time from discovery to refinement and on to delivery. This also makes it more feasible to work with fewer epics at the same time.

Move towards a role with actual end-to-end responsibility

Another important enabler for having PMs that are also POs is how to define roles and divide areas of responsibility among PMs.

It is always important to give a PM a distinct area to work on, with end-to-end responsibility. Having a end-to-end responsibility for a suitably defined area is more or less a pre-requisite for being able to work towards business impact and customer outcomes. As an example, if the PM's area of responsibility is to improve the back-end for a certain area of the product, it becomes much harder to take that kind of responsibility.

This is true regardless of whether PM and PO is one or two people. However, this means that if you currently have a PM and 3 POs, you cannot just change and have 3 or 4 PMs, you also need to be mindful of splitting the areas of responsibility so that each PM can see a clear link to strategy and work across both discovery and delivery.

For more insights into how to get this right, I can highly recommend Marty Cagan's book Empowered, where he digs deeper into this topic under the chapter about Team Typology.

The one-person PM-and-PO is better for both product and team

There are ample rewards if you can get this right, both better results for the product and more fun and personal development for team.

As we have covered above, the promise of getting it to work in a context where the PM is also the PO is that the product will become better. This is because the PM will be able to actually bridge strategy and discovery with delivery. By making this bridge work, the PM will be able to truly link how feature outputs drive business impact and customer outcomes, and that is what product management is all about.

Not not only that, everyone involved will have a much more rewarding experience.

• First, when the development team gets to engage with actually solving problems for customers rather than just writing code according to a specification, their jobs become much more rewarding and personally developing as well.
• Second, there is no beating around the bush, the pure PO role risks being boring. This as there is not connection to the users. As a consequence, pure POs are likely to either have great people who churn or less inspired people who lack of other options stay on.
• Third, the PM-and-PO role is more rewarding and developing. The real challenge lies in working with both sides of the outcomes/output ration, to actually be part of crafting the solutions.
• Also, Taking this end-to-end responsibility within a smaller area is also a better preparation for becoming a product leader than working with only one side of the equation within a bigger area, even if there would potentially be PO subordinates. Grappling with real challenges is what develops you into a product leader, and unless you have done the work, it is much harder to coach other people in doing it.

So, if you want to develop great products and build great teams that can then go on to improve those products even further, don't hesitate: Try to affect a move to one-person PM-and-PO roles.

‍

‍