Agile DevelopmentCultureDevelopmentManifestoOrganizationProcessProduct MarketingRequirementsSaeedScrum

A new (and better) definition for Product Owner

by Saeed Khan

Last week’s post entitled “The Scrum Title ‘Product Owner’ must die!”  on changes to the Scrum “Product Owner” title and responsibilities drew a lot of comments and feedback. Some agreed, some disagreed, but clearly there is much room for improvement in how that role is defined and implemented.

And thus the genesis of this post. It’s time to provide a better, more applicable and less convoluted description of the “Product Owner” role so that companies who are implementing Scrum can do so with far less confusion and tumult in their organizations.

One reader, Rohan, left a great comment that is worth repeating and discussing.

Given that the role of Product Owner is a requirement in Scrum, and given that the name “Product Owner” is well established there, I think that “must die” is admirable but futile. I think we have a much better chance of success if we focus on educating people that Product Owner is a role, not a job title, to be filled by someone with a real job title like (in many/most cases) Technical Product Manager. Then the existence of the term “Product Owner” can be limited to members of the Scrum team, and the rest of the world can be spared. That is, I don’t think we can kill the term, but we can quarantine it.

Well said Rohan.  I must say that the “must die!” title of the previous post had a lot to do with having a provocative title to draw readers. I think it worked. 🙂 And while it’s true that it would be difficult to displace the name “Product Owner”, it doesn’t hurt to get people thinking about it. But I have to agree that quarantining it is much more likely to happen. So, let’s get started.

The problems with the current definition

To review, I saw two problems with the “Product Owner” title and description. In short they were the title and the description.  But seriously…

  1. The name “Product Owner” and particularly the word “Owner” causes confusion when Scrum in implemented. Does anyone actually “own” the product? And if so, is that person (most likely someone very senior) going to spend time with the Scrum team, in daily standups etc.? No.The name derives from the Engineering-out view of the company. i.e. Engineers want “one throat to choke” when it comes to business requirements and ensuring their work aligned with “the business” side of the house. i.e. from their perspective, that person is the owner of the product, regardless of whether that is the case in the company at large.
  2. The responsibilities of the “Product Owner” (as defined by Scrum and it’s advocates) are a convolution of business and technical, strategic and tactical responsibilities, that in reality are never seen in a single individual role. There needs to be a distinction made between what the “Product Owner” actually does and what he/she represents.

BTW, in researching what others had written on this topic, I came across this series of posts by Luke Hohmann on why prioritizing backlog by ROI doesn’t make sense. Luke is no outsider when it comes to Agile and Scrum and this series of articles is worth reading.

Constraints for a new defintion

So, back to the topic at hand. Given the issues with the Product Owner definition, how can it be changed to be better and more clearly defined and applied within environments? Let’s look at some of the constraints that the definition must fit into.

  1. It must cover both internal IT projects and commercial products, and also be relevant to applications built for specific customers by consultants.
  2. It must focus on the need for ongoing business input into the development process
  3. It doesn’t define a new role that duplicates existing roles.
  4. It must adhere to the Scrum requirement of a “single throat to choke”
  5. It must be a job that can actually be done by one person. No superheroes required

The new (and better) defintion

Given these criteria, here’s a proposed NEW and (IMHO) better definition of Product Owner. To compare and contrast, read the Jeff Sutherland definition in my previous article.

1. It’s a Role not a Title
The “Product Owner” is a role (and not a title) aimed at addressing a key problem that has historically plagued software development projects: that being the gap between business priorities and the work executed by software development teams. The result of this problem is a long history of projects and products that did not meet customer or market needs and that were either delayed or required extensive additional work to meet requirements.

2. Primary interface to the Scrum Team
The “Product Owner” is the primary interface of the business with the Scrum Team, and is responsible for ensuring a prioritized backlog is maintained so that each successive Sprint can be planned clearly and efficiently.

3. Actively addresses ambiguity and change
Given that requirements can be open to interpretation, and business priorities can change over the course of a project, it is imperative that a representative of the business be actively engaged — ideally on a daily basis — with the Scrum team to ensure development decisions stay aligned with business needs, and any issues that arise are addressed as quickly as possible.

4. Different titles can be “Product Owner”
For internal IT projects, the “Product Owner” may be represented by a Business or IT Analyst or even a direct End-User representative. For products targeted at wider markets, the “Product Owner” may be part of the Product Management team – e.g. a Product Manager or Technical Product Manager. And for consulting projects, it’s likely that the “Product Owner” is a direct representative of the end customer and not a proxy for them.

5. Is most likely NOT the sole business decision maker
It is understood that the “Product Owner” represents the business needs to the Scrum team but may not be the sole decision maker in the business priorities. i.e. While they interface with the Scrum team on one side, they will be interfacing with other parts of the business, or in fact directly with the end customer.

6. Must be technical enough to deal directly with the Scrum team
Given the technical nature of software development, the “Product Owner” should have a sufficient technical background to engage with the Scrum team when technical issues arise that impact delivery of business requirements. This does not mean the “Product Owner” has to be as technical as a Developer, but sufficiently knowledgeable to fulfill the bridging role between the business and technical sides of the project.

7. Not necessarily the ” single throat to choke” from a Scrum team viewpoint
While the Scrum team views the “Product Owner” as THE  representative of the “customer”  — singular or multiple — and their requirements, this cannot be universally true. While it *may* work for a given project for a particular (singular) customer, when it comes to software products targeted at market segments, the “Product Owner” may not have full authority for all decisions needed to be made and thus the Scrum team must be aware that some issues will need to be escalated up the chain to more senior people in the Product Management or Executive team.

So there you have it. While not as short as I would have liked, the above definition meets the constraints set out earlier in the post. It’s clear to me. What do you think? Does it address the “traditional” problems with the “Product Owner” role? Does it create any new ones?


Tweet this: A new (and better) definition of Product Owner http://wp.me/pXBON-2y8 #scrum #agile #prodmgmt

  1. Geoffrey Anderson

    I read last week’s post, and the above, and I am a little saddened. Not by the content, but the state of PM and agile that seems to be pervasive.

    Some great points, and I get the ambiguity on the role and responsibility, the confusion, and how a title may be a little off. However, I can’t seem to get as worked up about it as this all seems to imply.

    As you rightly mention, the Product Owner is a role. It is not a title, and in fact, as you mention, there are many business functional titles that might be able to fulfill this role.

    However, in my experience, the role, particularly for a larger project/dev team, is pretty near a full time job, so unless you can dedicate a Business Analyst, or a Technical Product Manager (I like that title less, by the way) to the role, the development team will be left wanting. I have tried offloading to a product specialist (really a lite Technical Product Manager), and that went poorly. While on paper, there should be ample time to do both roles, it just doesn’t work well.

    I currently play both the Product Manager role, and the Product Owner role (as well as doing about 60% of the product marketing function, but that is a different discussion) for my product line ($60M, 5 products, and many optional modules in enterprise SW). If I could find someone to offload the PO role, I would love to, but to truly be effective, as you mention, you need to have some market smarts (to understand what customers really want), how to write stories, how to define success, and enough technical knowledge to play ball with the dev team. That is a hard set of requirements to fill, and perhaps the fact that there is so much angst is in the fact that this really describes a highly engaged, business and technology savvy product manager.

    For the record, I have never seen a BA with enough skills to pull this off (the PO role). The market perspective, the business justifications, yes, but the technology, and the customer connection, nope. They may exist, but I have not run across any of them.

    How about running a Product Management Survey to find out how many scrum adherents have a dedicated PO, a shared resource (and what type of title they share with) and look for comments on its success ratio.

    I know that I sacrifice important product management tasks when I need to focus on the PO items, and that it curtails my ability to travel as needed.

    1. Saeed


      Thanks for the detailed comment. Let’s remember the 3 contexts in mind (internal IT, external product, custom application) as we discuss this topic. My focus is on the second one — i.e. external product — which is where most of the issues arise.

      WRT internal IT, some BAs can be POs, some can’t. It’s really up to the company to find the right person. I didn’t want to dictate either way, but simply point out some possibilities and distinguish between the 3 contexts and titles that could take on the PO role. And just to be clear, I’m not advocating a BA as a PO for a market focused product.

      I do agree that the role can be a full time job, and there is nothing wrong with that IF that is justified. I have seen Dev Teams (unnecessarily) soak up a TPMs entire schedule in design reviews, bug reviews, standup meetings, retrospectives etc. until the TPM got a backbone and pushed back. It seems some Scrum teams feel that Scrum entitles them to stop thinking for themselves and push ALL decisions onto the “Product Owner”.

      But whether full time or not, staffing appropriately — both headcount and skillset/background — is key. In one company I worked at, when the Dev team decided they were going Agile and wanted to have a “Product Owner” from Product Management colocate full time with the Dev team, my first comment to the VP Eng. was give me one of your headcount and I’ll see what I can do. He agreed. My second comment was, colocation is not necessary. Do you want a PM who is simply just another member of the Dev team, or do you want someone who understands the market etc? I got both my requests.

      And I’d say that for any small company who is adopting Scrum, if it’s such a critical role, then create a dedicated headcount for the PO role, don’t just heap it onto the (already overburdend) PM. It’s a recipe for failure.

      WRT your poor experience with a TPM, I can only say that I’ve had the exact opposite experience. Find the right person and define the role properly and it can work VERY well. It did in my case. That TPM (a former software engineer) is now a Dir. PM at a software company.

      Finally, I want to emphasize that the PO does not work alone. Perhaps from the Engineering point of view, he/she is their single “throat to choke”, but I’ve never looked at it that way. If the PO is a member of the PM team, then they have the knowledge, backing and guidance of the PM org (even if it is a small org) to draw upon. I worked very closely with a TPM/PO who reported to me, and when he couldn’t address the needs of the Scrum team, it got escalated to me, either by him, the Project Manager or the Dev Manager. We’d figure issues out together and move forward.

      In the end, isn’t that what Scrum is all about? i.e. Self organizing teams, getting the job done, people over process etc.?


      1. Geoff Anderson


        Thanks for the great response. Certainly illuminating.

        I am thinking that your definition of a business analyst is different from mine. Typically, I see them as ‘numbers’ heads, diving through CRM, order data, sales funnels, leads, forecasting, margin reports, costing and other factors to help us define our segments, and market opportunities. At least that is what we call them. Of course, I come from a realm of hardware/software where these are important metrics. As such, they are a lot closer to a Product Marketing Manager (with little direct product/tech experience) but lacking the “instinct” for the market. They are bean counters and pivot table mavens, and thus poorly suited for a PO role.

        Where I am at now, they tried to push a mid level developer into the TPM role, which I kiboshed. I really didn’t need their fox in the hen house. Additionally, when he interviewed for the position, he viewed it as a way to reduce his work load. I still marvel at that comment. The problem is that I am in a small market, and the pool of talent is not deep enough. I did find two people from our support organization. So far the result is mixed, one is taking to it like fish in water, but one requires a lot of direct supervision, and constant monitoring to keep him on task.

        One thing that is certain, unless I can get the PO position operating more or less autonomously, I will be constantly badgered with tactical flak impairing my ability to do my real job.

        Thanks for the insightful posts and the commentary. You are right, Scrum is about self organizing teams and getting it done.

        (Perhaps you can write a post on classic project managers trying to box in the scrum process and the deficiencies of the round peg in the square hole. Some of them can’t unplug from the rigor of project management 🙂 )

  2. Sunil Roy

    Thanks Saeed, for this great article.

    While on one side, I agree with a lot of your points in the “better definition”, I wish to add that retaining the role name as “Product Owner” is helpful, due to following reasons.
    And of course, I agree that it is a ROLE, not a title.

    1) Sometimes, the POs have been found to NOT get involved in the day to day matters of the product development, where the team needs him/her for clarifications, on what is fine and what is not for him. The team may need additional info to proceed in many cases. The team may need interim feed backs, to make sure they are on the right track.
    Instead of helping the team in all these areas, he may happily show up only during the review, ending up blaming the team for incorrect development or not taking care of the finer details as he would have *liked them to*.

    I think the initial gurus may have used this role name due to this problem.

    2) Also, the PO feels proud that he OWNS the product, and feels responsible for it.

    3) This role name helps the PO to feel empowered to make the necessary decisions. This is especially necessary when the PO is new to the team or he is an external customer or the PO does not have management skills and feels intimidated by strong personalities in the team.
    The role name also tells the team who is in charge of the priorities.

    4) The role name also sends a clear signal to the management that the PO should not be burdened with other responsibilities, since he needs to ensure that he the team gets the required guidance from time to time.

    Saeed and Everyone else…Requesting your inputs on my views.
    Thank you Saeed and others for discussing this important point.

    … Sunil Roy

    1. Saeed


      Thanks for the detailed comment. I will stick to my position 🙂 on the “Product Owner”. I think that in each of the points you make there is a strong counterpoint that can be made.

      e.g. for #2, the PO doesn’t “OWN” the product, though that is how the Agilists perceive him/her from their perspective. It’s akin to a diner in a restaurant thinking the waiter/waitress is the “restaurant owner” because the waiter/waitress is their interface to everything the restaurant does.

      In actuality the waiter/waitress is the “Experience Owner” for the diner, but doesn’t need that title to feel responsible.

      I can comment on the other points if you like but as I said, I’ll stay with my original points on this. 😉


      1. Sunil Roy

        Thanks Saeed for commenting on my note.

        So, while I agee that there can be counter points, I feel that a PO’s role is not as simple as say a waiter.
        The waiter passes the order to the kitchen and gets the dishes back. He is Not INVOLVED in the manufacturing part, whereas the PO is very much involved in it on a regular basis.

        That is why, the role name should indicate a sense of responsibility and pride (# 2) and some empowerment (#3), even though it is well known that for many cost related and organization related decisions, there are more senior members in the hierarchy that help the PO.

        And, realistically, when we say that the PO has to take care of the cost, it really means that he should think of the efforts vs. the value delivered, and the priority of the value being delivered. For thinking of cost to the customer in terms of money, there would generally be a Product Manager or Lead Product owner, who interfaces with the customers rather than with the team.
        So, generally the assumption is that given the management support that the PO needs, he has a big responsibility to take on.

        Also, the priority is generally based on a combination of “Business Value” and the “Greatest Risks to get away with”. So, the point (mentioned somewhere in theses blogs) that the Business value alone is a fuzzy benchmark for Prioritization is valid, because the priority should not be based only on Business value.

        … Sunil Roy

  3. Bill

    How about we retire the “single throat to choke” phrase from any conversations about creative and healthy software development practices?

Leave a Reply

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