The PO nonsense: Product Manager vs Product Owner

I can’t tell you how many times I’ve been asked to describe the difference between a PM and a PO. I’ve been asked this question in interviews by executives who had really no idea what the fuss was all about, in the workplace on a weekly basis, even once in the subway. What’s funny, is that seemingly everyone has a distinct definition for themselves which in no way is aligned with the spirit with which these two, shall we say, roles were actually invented for. This wide array of arbitrary and mostly made-up definitions, besides being a little bit annoying, is a reminder that we, product managers, should have done a better job describing our tribe.

On to business. So who IS this product owner person?

Answer: the Product Manager him/herself. There. They are the same person — though that doesn’t mean they are the same role. The Product Owner is a subset of a Product Manager’s responsibilities- specifically, those concerning the leadership of an Agile team. To put it in other words, Product Manager is the job title; Product Owner is a set of responsibilities.

You might be surprised about these two roles merging on a single person, or that PO is NOT a job title. After all, we have all seen job applications where the companies specifically ask for a PO rather than a PM; We have read profiles on LinkedIn with the job title PO rather than a PM. They couldn’t all be wrong — or could they?

Actually, they are wrong. All of them. This is not just coming from me, almost every worthy product textbook says the same. Marty Cagan and Melissa Perri specifically point this out in inspired and escaping the build trap. But to understand why this distinction is wrong, we must dig a little bit deeper into how a product is born and the dynamics of the team that builds it.

Product Managers: Masters of war on two fronts

At almost any point in time, a product manager is juggling two very different tasks: Product Discovery and Product Delivery. We need to find out what the customer needs (discovery) and we need to build a solution for that specific customer need (delivery). Discovery work is essentially hypothesizing, designing tests, experimenting and analysis; Delivery work is mostly documenting, going through edge cases, meetings, prioritizing, communicating and coffee breaks.

Product Discovery

In the discovery phase, the product manager and the product designer, sometimes accompanied by one or two developers, go through brutal episodes of exploration which is basically about finding out what’s wrong with the product, in what ways it could be improved to meet customer demands and is there any new technology we could use to advance our product and so on.

After figuring out a worthy problem the inspection phase begins: How could we solve the problem? Is method A better than method B? Which one has a lower time to money? which one delivers a higher value? how could we tell if we have solved the problem? What could we expect in the long-run?

Moving on, we come up to the challenge phase. We have identified a good problem and a few possible solutions — In what ways could these solutions not work for us? How can we test them? What could go wrong with other aspects of our product if we chase this particular solution?

Product Discovery ends with a clearly stated customer problem and a thoroughly tested solution. The PO role is non-existent in this stage.

Product Delivery

When the problem and the solution are clearly known, it’s time to build the solution and ship it to the customers. This is something the developers will do, but it’s not as simple as showing a design to them and asking them to start on it. Here, a PM must clearly communicate and manage what is to be built and when, in what order — Enter the PO role. The official Scrum Guide lists the following as the primary responsibilities of the PO role:

Developing and explicitly communicating the Product Goal;

Creating and clearly communicating Product Backlog items;

Ordering Product Backlog items;

Ensuring that the Product Backlog is transparent, visible and understood.

As it can be seen, the PO role is mostly a communicator, documenter and prioritizer- It is closer to project management and there’s less creativity and more frameworks and structural approaches.

Before the lean movement took over digital product development, the PM role had less to do with what is to built and more to do with how it is built. That is to say, Product Managers were more product owners than visionaries with the customer in mind — they would simply build what the business told them to build. PMs in those days would still derive requirements, but they were effectively just backlog managers. The lean movement changed that — Now it was up to the PM to decide what was to be built.

Sadly, many companies still haven’t implemented a lean mindset in their product development plan and still cling to the proud tradition of the waterfall approach. For such companies, talking of a PM is obsolete. They need a project manager.

All in ALL…

Personally, I believe what constitutes a great PM is discovery work, not delivery work. Don’t get me wrong — it is very important to deliver to the customer and a PM must be skilled in that area. But it is more important to deliver the right thing to the customer.