PO, PM, same same, but different.

TL;DR

The differences between a Product Owner and A Product Manager role depend on many things: the development framework, the maturity of the business, the organisational structure, and the (right) product people. There isn’t a Holy Grail answer to the question. It’s rather more important to know what’s effective for your particular organisation.

- What’s the main difference between a Product Owner and a Product Manager?

- Which development framework are you using?

- ?

The above conversation doesn’t sound natural, does it? In reality, one would not resist the urge to delve right in based on their own experience or understanding:

- So Product Manager is the title and Product Owner is the job…

But before even finishing, an Agile expert has already rebutted:

- Yes, but when you recruit a Product Owner, what you really want is to have someone to groom the backlog and run planning meetings. A Scrum Master can do that…

Before able to finish either, another rebuttal has landed:

- Are you sure? Scrum Master and Product Owner are completely different roles.

And it goes on.

It’s not rare that you meet someone in the industry who believed getting a Product Owner certificate will help them find a job in product management; or being approached by consulting firms to streamline operations using “Agile method”; or an American coach criticising European product management without proper cultural understanding.

The reasons for both enormous misinformation and strong opinions to coexist on this matter might be rooted in many things:

• The rise (and fall?) of Agile,
• The hasty belief in the “Silicon Valley way” of product management,
• The relentless commercialisation of Product Owner boot camps and Agile training courses,
• The trend of traditional non-software companies gone agile,
• The lucrative deals big consulting firms make to implement frameworks their own consultants have no knowledge of,
• etc.

Gradually, product development teams were blown into a world of concepts and buzzwords, without given the time to grasp even the fundamentals. Since everyone has gone agile, the rest might as well follow suit. So in the end, a dozen more certified Agile experts pop out every day.

If you’re reading this with the serious purpose of seeking the pure and simple difference between PO and PM roles, I’m afraid you won’t find it here. But I can show you what others say about this topic, and ask you a few open questions in the end, to help you form your own views.

In the LinkedIn product management community, there’s never lack of humour around how wrong can PM & PO be interpreted.

Note: I’ve gathered screenshots of valuable inputs from LinkedIn. And considering the debatable nature of the topic, I have anonymised most of the authors. But please let me know if you wish to have your post removed, or rather reveal your identity. Please do get in touch.

Let me tell you a silly joke inspired by a true story. A company’s C-level decided to adopt Agile.

How did they do it?

• Recruited an Agile Coach.
• The Agile Coach got Agile wrong.
• Recruiters wrote wrong PM job descriptions.
• Wrong interviews carried out, and wrong PMs recruited.
• Wrong PMs couldn’t get the expected “Agile result”.
• Everyone decided that Agile is the wrong framework.

Back to PO vs PM, what’s the difference?

It depends.

It depends on the framework: are you using SCRUM, or SAFe, or Kanban? It’s worthy to acknowledge that there are effective mixtures such as Scrum-ban, because no framework is perfect, and no two organisations are the same. Your framework and how your organisation implements it will decide the differences between PM and PO for your organisation.

To brutally simplify it:

• In a SAFe organisation, the PM handles product discovery and PO the product delivery. It’s expected that a PM brings valid problems and ideas to a PO, who shall turn them into working solutions by interfacing a development team. Or if you’d like to speak the language of Double Diamond or Design Thinking, a PM tackles the problem space and PO the solution space. Here, PM and PO coexist to contribute to the product success.
• In a SCRUM organisation, it’s rather expected that one person leads through the product discovery and delivery, with or without the help of a Scrum Master, depending on the organisation. Here, one product person works directly with both the development team and customers. The title PM or PO doesn’t change the nature of the job.

What changes the nature of the job?

It depends.

It depends on the organisation: a start-up, a start-up that achieved product-market-fit (PMF), a corporation, etc.

To over simplify again for story-telling:

• A pre-PMF start-up would thrive to reach their early to mainstream markets, build prototypes, and validate their concepts, which hopefully was based on a burning issue that people will pay money to solve, otherwise here’s another one for you. For example, it took OpenTable 2 years and Udemy 2.5 years to find their PMF. At this stage, the founders might not want separated discovery and delivery, more realistically, might even only want a delivery person who can transform their vision into tangible products — no empowerment, no strategic discussion, just get the velocity up and delivery done. Yes, sadly, there’s no lack of such Product Owners.
• A successful start-up that achieved PMF would likely be driven madly by their VC to scale and boost valuation. Sales and Customer Success are perfectly geared up to generate revenue. Founders work around the clock to win the market and partnerships. There’s now proper marketing as well. Amongst all this, new customers demands and software defects would fly in. It’s not cost-effective for founders to look after their product babies. An empowered Product Manager must come in and structure the process and be ready to build a team.
• A corporation would want to establish their market position by keeping the cash cow well-fed and incubate new ideas to be future-proof. For example, SAP who maintains both the good gold ERP while investing in cloud based SAP HANA. The founders had done their bits to reach the mainstream market; the executives had compiled their PowerPoint slides together to satisfy global shareholders; their company vision and everyday product development perhaps don’t come hand in hand any more. Thus, innovation’s at hand, product vision needed, new strategy awaits, fresh blood welcomed. Personally, I don’t have any information on the development framework that SAP adopts, but I would make a bold assumption that there is a ton of Product Managers and Owners, plus Project Managers, working on a focused but siloed workstreams.

Have you got what you wanted after reading this? Or you’d already like to tell me that I “clearly didn’t read the SCRUM Guide”? To over-simplify for the one last time, look closer at the intention of the job, the title being PM or PO doesn’t matter.