The Product Manager vs. Product Owner

product manager and product owner

Agile product companies have a hard time managing products. The product manager is charged with communicating the voice of the customer — achieving both customer and market success. Meanwhile, agile development teams demand that the product owner must articulate detailed user stories, participate in daily scrum rituals, and answer questions as the customer representative. 

Prior to the moment that paying customers first use the product, a single product manager/product owner model is challenging for any one person to handle. The product lead must simultaneously focus externally and internally. It is hard but advisable.

The product lead is busy externally — formulating a product concept based on interviews and other market research. For internal engineering teams, they must capture the customer requirements as user stories and explain why they are important. And at the same time, the product lead also trains other teams on the core product value proposition and the problems the product solves.

As prototypes are built, it’s time to quickly reclaim external focus — continuing to engage real customers during each subsequent iteration to improve the product and drive adoption.

Being close to customers is fundamental to the success of an early-stage company, as the concept is developed and a winning product is built. And at the same time, the product manager must be the go-to person for engineering.

Yet while everyone rejoices as sales engages prospects and paying customers come on board, juggling the external and internal workload can be overwhelming for even the most seasoned product leaders.

If the product manager continues to spend the majority of their time externally, the development team suffers. Stories aren’t explained in enough detail. Developers wait for answers. Velocity suffers.

Alternately, if the product manager spends too much time being internally focused, the product loses alignment with customers and the market. Client visits are abandoned. Sales enablement materials are few and far between. The product manager does not participate in implementations to find the weak spots.

There comes a point when growing businesses benefit from having two product roles — externally focused product managers and internally focused product owners. And the people are happier too.

When companies achieve a meaningful level of customer success and the engineering team is larger than about 20, many companies split the product role in two. They decide to invest in a market-focused product manager who is externally focused and works on the long-term vision. And they recruit an internally focused product owner who supports the engineering team and manages the software development details.

This split relieves the pain of the overloaded individual. However, it could also introduce overlap and communication challenges that must be addressed in order for the product manager, product owner, and engineering team to be successful.

The good news is that there are a number of ways to address the potential for overlap and ensure the teams work well together.

Making the product manager/product owner relationship great
The following lessons and insights on how to get this relationship right come from my own experience and from pointers I’ve picked up over the years. My team recently decided to address the product management “external versus internal” challenge by hiring product owners to focus internally and allow the product managers to be more externally aligned.

We knew that to be successful, we needed to clearly delineate the respective roles and define how we were going to work together.

The following table is intended to cover the majority of the typical responsibilities of the externally facing product manager and the development-facing product owner.

It is not intended to cover all of the duties of either role, but it should provide a useful reference for how these two teammates work together at our company. And this model can be tailored to other companies.

Role Responsibility
Product manager Tracks the overall market and competitive dynamics.
Product manager Manages the long-term roadmap, involving sales, marketing, implementations, clients, prospects, partners, and other groups. The ideas are expressed as epics.
Product manager Attends iteration demos and some standups.
Product manager Supports other non-technical teams (such as sales, marketing, and channel).
Product owner Leads requirements gathering effort on the epics as needed — consulting with product management, implementations, clients, and other stakeholders.
Product owner Documents story details based on the epics after reviewing with development.
Product owner Attends scrum meetings including standups, retrospectives, and demos.
Product owner Leads backlog grooming to decompose and estimate stories.
Product owner Creates mockups and works with UX on design.
Product owner Answer questions from developers and clarifies requirements.
Product owner Documents the new feature for implementations and release notes.
Both Write acceptance criteria.
Both Demonstrate the latest iterations to customers (pre-release) and gathers feedback.

Our experience has also been that product managers and product owners need to meet at least twice a week to make sure they are on the same page. This allows them to fill in the gaps for each other when needed.

Has this relationship worked in your company?

Do you have experience in an organization with a product manager and product owner who worked especially well together? Or was it a total disaster? Share in the comments below.

This is a guest post by John Peltier. Do you hope to become a great product manager or owner? Want to create brilliant strategy and visual product roadmaps? Start a free 30-day trial of Aha!

John Peltier applies product and marketing spidey senses and user-centered design to solve business problems experienced by real users and buyers. His areas of concentration include B2B software, compliance, and healthcare. He has more than a passing interest in personal branding. John resides in Atlanta with his lovely wife, Phay. Follow John @johnpeltier


  1. John Gilmore

    Interesting post. I’m currently the product owner, but with more and more potential customers and a lot of sales training required, I’m spending more and more time away from my team. My internally focussed duties are feeling the strain, since the team doesn’t always have me present. I was away for the past two release testing cycles and that added some strain. They’ve suggested splitting this role and I was worried that that would make us much slower. It’s good to see that this has been tried before.

  2. John Johnson

    I’ve found that the PM and PO split highly depends at which stage a company is in.

    Do you have multiple products? multiple product verticals? multiple enterprise customers?

    If not, it doesn’t make sense to split these roles as the Product Owner tends to become highly disempowered and unable to make decisions. PO’s then simply act as a liason between the team and the decision-maker.

    I’ve also seen in organizations that have Product Management (which we hope are most!), the Product Manager is the one who should wear the Product Owner hat or title, rather than going down the path of SAFe or other frameworks such as it.

  3. Can Hüzmeli

    I don’t think this strict distinction between a product manager and product owner would work. Product owner should the single owner of the backlog. Product owner decides on the prioritization and what needs to get done. He is the one who should communicate with all the stakeholders too. The definition given in the article is against the definition of a product owner. If there is a worry about spending to much time with external stakeholders, the head of products (or chief product owner) can take this responsibility. If the product owner stops communicating with customers and stakeholders, he will become a proxy product owner who is only responsible to articulate what product manager decides what needs to get into backlog.

  4. Bart Mastenbroek

    You seem to put a lot of emphasis on the tasks and responsibilities. I recently attended a Product Owner training that moves the onus to collaboration with the whole development team. The interpretation that the PO must write the user stories is faulty, and results in finger pointing as opposed to collaboration. The PO is responsible for the backlog, but anyone can be asked to help, and in my experience is this is necessary.

  5. Graham Libaert

    This approach works well within our organisation, as our portfolio is relatively immature, there is much feedback we need to gain from our customers and the market and the product is aligned to more than one industry vertical. If we had one vertical and a more mature product then I would only see the need for a product owner in this scenario. The distinctions for me really highlight well where each role should be focussing their energy to bring the most value to the product, there will always be overlap in a collaborative approach however if my PM spent more time refining the backlog and my PO was spending a lot of time with the sales team it would cause a concern.

  6. Russell

    There is a mistake.
    “Meanwhile, agile development teams demand that the product owner must articulate detailed user stories, participate in daily scrum rituals”
    Product owner is not allowed to attend daily standup meetings

    1. Nathanael Coyne

      Product owner absolutely can attend daily stand-up meetings, the “rule” is really about not having observers/lurkers – if you attend, you participate.

    2. TC

      Product Owner most certainly needs to be part of the Scrum ceremonies. Collaborative self managing teams in a Scrum shop should always consist of a PO an SM and the Team that is made up of QA and BA/TA roles. This has been a core belief in Scrum for as long as I have been working in software development (1998). Mike Cohn and Ken Schwaber (one of the originators of the Scrum process) have taught this for as long as I can remember.

      “The product owner role requires an individual with certain skills and traits, including availability, business savvy and communication skills. First, the Scrum product owner needs to be available to his or her team. The best product owners show commitment by doing whatever is necessary to build the best product possible – and that means being actively engaged with their teams.” – From Mountain Goat Software

  7. David Novick

    I just came upon this. I am not in complete disagreement with this approach but lets be clear about what a Product Owner is and does. There is ONE product owner who is the KEY stakeholder and visionary in the product… period… end… full stop. If you follow the example in LeSS (Large Scale Scrum) there is a concept of a Product Owner with Associate Product Owners underneath and while the Product Owner may coordinate the entire product vision, each Associate Product Owner owns the vertical slice that is unique to his/her feature team(s) and negotiates his/her priorities with his/her peers to aid in that overall coordination of the product.

    From Michael James’ “Scrum Reference Card”
    “Product Owner

    * Single person responsible for maximizing the return on investment (ROI) of the development effort
    * Responsible for product vision
    * Constantly re-prioritizes the Product Backlog, adjusting any long term expectations such as release plans
    * Final arbiter of requirements questions
    * Decides whether to ship
    * Decides whether to continue development
    * Considers stakeholder interests
    * May contribute as a team member (my addition: note s/he MAY contribute as a team member but is not required to do so)”

    “Daily Scrum and Sprint Execution

    Every day at the same time and place, the Scrum Development Team members spend a total of 15 minutes reporting to each other. Each team member summarizes what he did the previous day, what he will do today, and what impediments he faces. ”

    The PO is NOT mandatory in the Daily Scrum… in fact, the PO should look at development as the “sausage being made” and should “trust” that his/her devs will complete their commitment and the PO should then focus on upcoming things, be available for clarifications, and wait until the end of the sprint for the Demo)

    Further, it is not unheard of for a team to have a business analyst which works more tactically and negotiates the stories with the Devs based upon the priority the PO sets and as his/her proxy. We have that set up now on 3 of my feature teams that comprise one overall product.

    But, I want to make clear that Product Owner in the context of this article and under the guidelines of the Scrum Reference Card and LeSS (Large Scale Agile) owns all these responsibilities and can choose to delegate some of them to his/her business analyst as need be. Going beyond Scrum, I do not find a clear delineation between these two roles as constructive. It sets up a brand new waterfall within the product organization. Our PO negotiates the delegation of responsibilities to his BA, together. But, at the end of the day, the PO owns all of it.

    1. Adam

      David Novick, it sounds as if you are allowing ego to get in the way of the ultimate objective of the team. I have worked with Product Owners that also believed that they did not need to participate in the “sausage being made”, but were somehow consistently available to take full credit for the success of the team.

      If you are not involved with the development of a product, you have no right to claim the role of Product Owner. You are an executive or a salesperson, full stop. It sounds as if are underpaying a Business Analyst to me.

  8. Robert McComiskie

    It sounds to me like there are many different interpretations of the Product Owner role here. Each is correct as perceived by the writer but some are at cross purposes with other writers. If I look at the infinitely variable list of tasks to be accomplished by ‘Product Management,’ let’s just say that the PM and the PO must come to an agreement about which tasks are owned by each or both. Whether those tasks are outward or inward facing depends on the organization and the stage of the product life cycle.

  9. Joe driver

    I’m researching the PM vs PO to understand the agile mindset better, what this does show is that no one understands fully or can explain what agile means in the workplace. It’s an interesting place!!!

    1. Amber

      there is a really good post on specifically this that can be distilled down into 1 sentence:
      “Product Owner is a role title; Product management is the job”

      I really like this because it takes the split out of the equation. A goo PO or PM can be as tactical or as strategic as the organisation requires… but the work is essentially the same and still very dependent on the context the team/product are in.

  10. Mike

    It’s funny, I’ve been working as a Product Manager for about 10 years now and my current position is the first to introduce me to the Product Owners vs. Product Manager split. I’ve always just done both and I think you’ll find that’s the case in both small and mid-sized companies.

    While it’s a lot of work, I personally prefer having to handle both aspects. If you only live in the external facing world, I think you’d tend to set roadmap goals that were not truly achievable, whereas if you live only in the scrum meetings and were constantly head down with development and QA, you might start to only build what was technically expedient.

    I think that having a balance of both is ideal … if you can manage it.

  11. Cassis Mortimer

    I think that Aha! has found a way to create some sort of importance for the Product Manager to help create a niche and in turn boost sales for its SaaS product. Kudos at the attempt.

    But most project teams have PO, PM, SA (Solution Architects), BAs (who carry out writing of user stories – what is described here as a PO role, whilst POs act as described Product Managers), Devs, QAs. Effectively the model is simple. Please don’t change things around Aha! By the way, I love the original 80s band A-ha!, who produced the hit song ‘Take On Me’

  12. Yanita Diamandieva

    My experience echoes the definition of the PM & PO roles here. Not many companies have a clear definition for these roles and the difference (the specific responsibilities of the two) simply because their works have not got into such depth. As a result we find differences in the job specs of PO and PM jobs at the market. There is a blurred line between the two, and the responsibility list varies. Very often the two are mistaken – my most recent experience in a company – I was 90% PO while my title was clearly saying Product Manager.

    At small companies (Startups, SMEs) it is common to have one and the same person driving the PM & PO responsibilities for the definition of the product. You achieve 1) more focused approach and short-term strategy for your product/service (having one visioner defining the roadmap) and 2) it is more cost efficient and accomplishing given the scale of work, responsibilities and engagements (external, as well as internal with the team).

    Big companies need more product managers and product owners. It is true that you need someone to communicate internally to the team the Whats and Whys, while at the same time you need someone who manages the organisation’s links with the outside world (customers, users, markets).

    Often you find roles called either PM or PO which, in essence, cover both set of responsibilities without acknowledging the fact these should be two separate – my experience in Company X. You can come across PMs who do not communicate externally at all, or POs who do not work as closely as they should with their team(s). Often it is concluded for these people that they are not good in what they are doing. Often truth is, that the role is not clearly defined due to organisational dis-focus, culture, or not enough internal expertise to acknowledge the need for a split. Also, let’s face it, you cannot do it all alone when it comes to more matured product/service. There are companies that recognise the challenge and split the two roles (as defined above). Other organisations might not have matured to the extend where such need is recognised. Also, organisations might not even get to such need, or might not want to risk losing the link between the two roles.

    A side comment: Whether service or a product – I recommend for both to have a dedicated Researcher. In some organisations this this tough job is given to the PM/PO, in addition to the long list of responsibilities they already have. In Company Y, for example, the team had a dedicated Researcher per service/product. This was another full or part-time job. These guys are experts in the field of research and as important as every member of a team (developers, UX/UI designer, service/product manager). They know 1) how to do research (approaches/methods), 2) how to ask the right questions to get to the problem/need, 3) how to perform qualitative and quantitative analysis and 4) how to communicate internally the findings. PO/PM do not have the capacity to get to this level of research, still, they can use this valuable information make decisions based on facts and use facts and figures to justify these internally.

    There are number of models you can apply to your ‘machine’ to meet the needs and problems of your current organisation, as well as the vision of where you want it to be in few years from now. Start from the need/problem of the organisation, nail, scale it and iterate constantly to improve on it.

    1. Natalia

      Your comment highlights a few issues and challenges I agree with and have experienced as well:
      – There is no silver bullet in either merging product leadership into one role, or in splitting and allowing external vs. internal focus

      -Even if an organization clearly defines both roles, there is no guarantee that the split will work well due to the simple fact that the tiles themselves are still so unavoidably similar and overlapping that no matter how clearly you draw the boundaries, they still will be crossed.

      (If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck)

      – Again because the roles are so similar, you may find product owner that that are doing both ends (external and internal facing) and undermine Product Manager authority, not necessarily intentionally, but due to natural inclination to validate assumptions with end users. Those POs will likely also be dissatisfied due to inability to make decisions. On the other hand, you may find Product Managers involved too much in development process, undermining the role of the product owner…again, not necessarily intentionally, but out of desire to validate or to be in control.

      In my view, the internal and external roles/focus creates more issues than solves problems, the main issue being the disconnect between the dev team (lead by Product Owner) and the end user (represented by Product Manager)

  13. DomH

    I’d like to give my take on the matter as well: I work in a company with the split between a PM and PO (me). In the beginning the perception especially in the team, the CTO and all of engineering was quite the same: the PO is the “delivery boy” of product management. So the PM sets the route and expects delivery by the PO. The PM held all responsibility and all strategic decisions were made by him. The PO was expected to merely deliver solutions.
    Now, after a while of working together it has shifted for the PO role to be way more strategical, and way less tactical. We empowered the team to actually take more ownership over the product, so the PO can be a lot more customer-facing. In a large B2B company this means actually understanding the larger strategic goals of the customer, and the problems he has to overcome to achieve his goals (for example “business transformation”) and understand how we can support him in his journey. The PM on the other hand now concentrates on company strategy, market needs, GTM strategies etc.
    So now the role isn’t spit vertically anymore (i.e. not a hierarchy) but we’re on the same level with different focuses (PO: customer value) and PM (business and market). Together we define the strategy of the product and sell it to C-level.
    But team empowerment is the key to this actually working. Then it also becomes scalable for more teams. I think one of the biggest mistakes is that very often POs are actual glorified team leads and basically solution owners. So instead of defining the problem (requirement) they define the solution. And this degrades the product team (including UX/UI)to a mere “delivery” team. “Tell me the specs, we’ll implement it”. I think that’s the old way, we should move on from that.


Leave a Reply

Your email address will not be published. Required fields are marked *