When 2 Become 1: The Roles of Product Manager and Product Owner


By Jennifer Gridley – As we approach Valentine’s Day, some may be enjoying The Spice Girls’ 1996 hit for its romantic message. But since this is the BPMA, we’re thinking about the oft-merged roles of Product Manager (PM) and Product Owner (PO). And we’re not alone.

On January 23rd, Pragmatic Marketing hosted a webinar entitled “Six Ways Product Management’s Role Will Change in 2018.” In case you missed it, a full replay is available here.

During their presentation, Pragmatic Instructor and Product Coach Kirsten Butzow along with Pendo Chief Evangelist Eric Boduch emphasized the need to distinguish the PM role from the PO role. Since the Agile Manifesto first distinguished the roles in 2001, the same person has often been expected to serve as both PM and PO. But Butzow and Boduch posited that the PM and PO functions can rarely be performed by the same person effectively. In summary, here’s how they defined each role:


  • Engages in market-sensing activities to determine the future of the product
  • Communicates the voice of the customer
  • Understands customers, the problems the product solves, why the product is winning or losing, competitive differentiation, etc.
  • Converts market data into requirements for engineering
  • Ultimately responsible for customer and market success


  • A subject matter expert (SME) on the product, providing daily support to engineering
  • Helps engineering to ensure the product meets the market requirements identified by PM
  • Deals with release management, uses requirements to create detailed user stories, participates in scrums, etc.
  • Answers questions from customer representatives
  • Ultimately responsible for successful delivery of product that meets requirements

There are other points of view on how distinct these roles should be. For example, see Melissa Perri’s blog post from June of 2017 entitled “Product Manager vs. Product Owner”. Melissa highlights the risks of POs getting distanced from users and depending entirely on PMs for direction:

“When POs are entirely internal-facing, they] are disconnected from their users and incapable of creating effective solutions for them that really solve their problems, because they do not understand the problems well. The Product Managers are essentially waterfalling down the requirements to them and the teams are not allowed to prove if these are the right things to build or not. No one is doing validation work.”

Perri acknowledges many POs don’t have time to do much else aside from writing user stories, calling this The Build Trap. But, she argues that it is possible for one person to act as PM and PO successfully:

“With a good strategy framework in place and ruthless prioritization around a few key goals, one person can effectively talk to customers, understand their problems, and help to define the solutions with the team.”

Echoing this thought, Butzow and Boduch acknowledged that when PM and PO roles cannot be separated, leaders must carefully allocate their time and set expectations accordingly.

So, do you think that setting the PM and PO roles free is the only way to be?
Let’s talk about it – please comment below!

Jennifer Gridley, MBA is a business strategist, change agent and storyteller who has held a variety of corporate leadership roles, most recently in Product Marketing at athenahealth, Inc.  With 15 years of experience rooted in Investor Relations, she loves helping companies to grow and meaningfully improve product differentiation, customer understanding and go-to-market results.  She currently volunteers with the BPMA and is planning her next career adventure.

8 thoughts on “When 2 Become 1: The Roles of Product Manager and Product Owner

  1. Nailed it! Combining these roles is a train wreck waiting to happen! Back in the days of waterfall, most organizations combined the PM and business analyst role. Same bad result! Not only does each role have a different skill set, the goal of each role is very different. Product managers are like the surrogate department head in a customer organization focused on business goals and metrics while POs are the surrogate user focused on making people better at their job tasks.


    • I agree with you, John Mansour, 100%! In my former PM Role, I was a Sr PM for a very mature product that had 5 scrum teams working on features for release. There was no physical way I could be at 5 scrum meetings and working on each of the features, yet still do the strategic work required of a PM. We tried it for one cycle, failed miserably, then our organization figured out how to partner the PM role with 5 talented Product Owners and get great features to our customers that made them better, happier users of our product. I was sometimes called in to help arbitrate healthy disagreements in scrum teams and to provide insight into which feature would have a more strategic value for our company, but was able to stay out of the day-to-day development questions and issues during the cycles. As a result, the scrum teams were more efficient, got more things done for each release, and everyone had less stress and aggravation because they weren’t waiting on the Product Manager for a decision she shouldn’t have had to make.


    • Thank you Brian, that video is helpful – especially the portion that lays out the components of each role. In your experience, what is the best way for someone to balance both PM and PO responsibilities if all duties must be performed by the same person? Or is it more often the case that other functions perform some of the responsibilities – like Program Management or Product Marketing?


  2. Possible? Yes. A good idea? Not always.

    The trap of the PO is that it is easy to get sucked into the machinations of the process and of the dev teams. If you have six dev teams and you are “supposed” to attend all those scrums everyday (30 min including the “after conversation”), that is a huge chunk of your day. The tactical demands of a PM/PO in that case are to the detriment of the more visionary future thinking part of the PM role. Often in these scenarios you see management pick up that task, which is another challenge and probably another conversation.

    To be fair, it does come down to ruthlessly prioritizing what is important, but I think this whole discussion is more nuanced than a question about should they be the same or different roles. The real answer is that it depends. It depends on things like whether the dev teams are disciplined enough to move forward without constant PO involvement (can I miss a week of scrums?), whether the number of teams is small enough that participation as the PO still leaves time (and energy) to be the PM. Regardless of what direction an organization chooses, there should be a way to measure the effectiveness to ensure that what the company needs from the roles is actually being delivered. That will help decide the answer to this question.


  3. As usual in life nothing is black and white.
    PM and PO support the same side of the medal. It is all about the market as such, the segments we address and the individual customers we serve.
    Their needs and the value add we can provide has to be translated in an excellent product/service design. To provide a suiting solution we need engineering or as we call it in our service organisation capability management.
    Depending on the size of your business and the spread of your business across market segments, countries and regions a combined role of a PM/PO works or it needs to be split out.
    My preference is the e2e responsibility view. Avoid to much of such as called subject matter experts. Very often it is an artificial split. Most of the business we do, can be run thru common sense and pragmatic learning. I’d say the classic 80/20 rule also applies here.
    The more of a process a PM/PO spans compentence wise the more agile he/she can be.
    These are my 5 cents on the discussion. My background is of 25 years business development and product as well as process management with in large global trusts and medium sized cooperations.


  4. The false assumption being made here is that the rest of the team (e.g. developers, UX, etc) do not have the skills to listen to a PM/PO and then write and refine the necessary user stories. If your dev team is made up of individuals that cannot do anything but code, first find individuals that also have customer empathy and at least an appreciation, if not understanding of business constraints.

    The industry wants to define roles in a narrow and specialized way, part of the motivation being the assumption that when you do this, you can easily substitute one PO for another or one dev for another. However, this is not the case – something most organizations will only learn by failure.

    For agile software development to function, you need a self-organizing, cross-functional team that remains stable in it’s composition for a long time, ideally for the life of the product. For agility to happen, you need a stable team of senior devs. If you have such a situation, then you can and should combine the PM and PO role into one. If you don’t have that, then none of these efficiency/responsibility band-aids will get you results.


  5. Brian Lawley’s survey results reflect what I see in the real world. However, our profession doesn’t have to accept that as a best practice. Just look at the number of products that don’t deliver measurable value to their customers and it makes a great case for the 2-headed PM function – PMs own the “where are we going (destination)” and POs own the “how will we get there (turn by turn directions).”


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s