Scrum: The Mythical Product Owner role

Machiel Groeneveld

The Product Owner role in Scrum

In the Lean Software Development method Scrum there are three roles: the Team, the Scrum Master and the Product Owner. In my experience the Product Owner role is by far the most confusing and hardest role to ‘get right’ and provokes the most discussion. Even the mere definition of what this person should do is under debate amongst most Scrum practitioners I’ve talked to. I want to discuss the origins of the Product Owner role and my experience in how (not) to fill this role, especially in companies that don’t do product development.

The mythical Product Owner

I’ve seen many flavors of Product Owners and none of them really worked as they should have. Actually, rumor has it that good Product Owners actually don’t exist. Now that’s something we should be frank about if that’s true. If the Product Owner is a combination of responsibilities that doesn't work in practice, we should find some alternative. First, I'll explain my experience so far.

Definition of the role

Scrum is based on best practices, no one ‘invented’ Scrum by merely theorizing about how the world should work. People like Jeff Sutherland and Ken Schwaber have done projects in the past that were successful and one of the major reasons for their success was the presence of one person who represented all customer interests to the team (later called the Product Owner). Ken Schwaber describes the product owner as ‘one person [that] is responsible for maintaining and sustaining the content and priority of a single Product Backlog’ Jeff Sutherland is more elaborate and lists all responsibilities of the product owner in his online book ‘The Scrum Papers’. Among others he adds the responsibility ‘[...] for the profitability of the product (ROI)’. The direct combination of the ROI and the features of the product are what Product Ownership is all about.

Different flavors

Keeping in mind what the product owner should be according to Scrum, I want to explain the different flavors of Product Owners I’ve come across. Their flavor was mostly defined by the person taking on Product Ownership and their ‘regular’ job.

PO the Product Manager
In product development companies, such as famous Scrum companies like PatientKeeper and Planon, there is usually a role called Product Manager. A Product Manager can be the Product Owner without any issues because they are almost synonymous. Scrum gives the Product Manager a specific way of controlling his product by use of the Product Backlog. The only real issue that I’ve seen is that product managers tend to push down on the teams to deliver, which is considered a bad practice and eventually decreased productivity. Product Manager ‘only’ have to learn empirical management to be good Product Owners.

PO the Project Manager
In most projects I’ve worked in, the project manager does the planning of activities. If he gets the Product Owner role, he usually approaches the backlog from a planning perspective. That means he’ll decide what goes into what sprint based on external dependencies and availability of staff etc. Most project managers are actually not responsible for the profitability of the project or the budget. The PM makes the plan, but the Project Board approves the plan and budget. If the project goes over it’s deadline or budget the Project Board is accountable (if the PM gave ample warnings). The main problem is that work should not flow from managers but directly from stakeholders to developers because a manager is not the customer and usually lacks the business knowledge to make the right decisions. A project manager would actually have to be made accountable for the budget and profitability to be a good Product Owner.

PO the functional/information analyst
For most teams this sounds like the ideal product owner. An information analyst usually has in depth knowledge on what the customer needs. The information analysts I’ve worked with were good at structuring information and conveying it to the developers. Although very good for the productivity, an information analyst is not the same thing as a Product Owner. The analyst usually has ‘feature perspective’: what should the product do. His main competence is getting the requirements and wishes from the (potential) users of the system. If left unmanaged he’ll try to please the customer by implementing everything the customer asks for.
Implementing all requirements sounds good, but few projects have enough resources to do that, that’s why you need to prioritize features. I haven’t seen information analysts do this very well because the budget was not their responsibility. The analyst might work very closely with the product owner to prepare coming Sprints but he doesn’t actually need the Product Owner for that if the Product Backlog is in good shape. In any case an information analyst is a very valuable team member, not a Product Owner.

PO the Release Manager
A somewhat ambiguous term ‘release manager’, but it’s best explained as a coordinating planning and resource manager that plans work to be done and selects team members to do it. He also reports the status of work to stakeholders. In some ways the release manager role sounds a bit like the Product Owner role, they both feed work to the team. However, there were a few issues with this specific release manager as Product Owner. First of all, the release manager only planned work for one ‘type’ of developers (J2EE, C++ or .Net etc.) which means that features had already been split up into work packages for each competence. This makes prioritization an impossible task because the link between the work packages and the actual features were missing. The distance between the business case and stakeholders and the release managers was simply to great to make any real decisions and it wasn’t allowed to drop features to meet the schedule. So these release managers were Product Owner for one reason, we were doing Scrum and we needed someone (anyone?) to fill that role because it was in the Scrum book.

PO the Unit Manager
In one of my projects, a unit manager (manager of a business unit within an IT organization) took on the product owner role an in-house project. The main focus of a business unit manager is his people and because he knew Scrum he had no problem facilitating the team and giving them trust and responsibility. But that’s not the main responsibility of the Product Owner, that’s being accountable for the outcome of the project.
Getting the accountability right in an in-house project is perhaps even harder then when there’s a clear customer-vendor relationship. In this case team members were also stakeholders and the unit manager and stakeholders also wanted to help with development (are you still with me?). The main problem was accountability hadn’t been transfered explicitly to the Product Owner. The executive that controlled the budget had little control over the project and thus we fell into the age old project-trap where the people with the money ask “where is my money going?” The Unit Manager didn't get to spend the money as he saw fit and didn't take over responsibility for the success of the project, which left the Executive as the 'hidden' Product Owner.

The ‘right’ Product Owner

Although I haven't seen the role filled correctly, I do see the need the Product Owner role is intended to fulfill in Agile projects. The big word here is Business Case. The business case describes the benefits of the deliverables of the project, for instance: “If we implement software product x, we’ll save x amount of money per year”. Executives love Business Case driven development and that’s why the Product Owner should steer the project using the business case (perhaps we should call him 'Business Case Owner'?). The reverse is also true, if your Product Owner isn’t accountable for realizing the Business Case, he’s not your real Product Owner. But if you can transfer accountability to the product owner, what kind of competences does the Product Owner need to posses to perform Business Case driven steering?
Business Case Value
He needs to know which features add most value to the business case. If time saving is the main goal of the product, measurable time-saving features are valued higher than (for instance) usability features or product maintenance features.
Financial
He needs to know how much money a feature will cost and how much it will deliver. Having feature set X will increase our market share by Y. He needs to know how much to spend on each feature set and be able to drop or simplify features to match the budget.
Some domain knowledge
The product owner needs some domain knowledge so he can decide on what the stakeholders are talking about. Combining high level knowledge of features coupled with owning the business case is the main benefit of the role.
Time
One often discussed topic is the availability of the Product Owner. If you look at the responsibilities, he doesn’t have to be available full-time. If the product backlog is in good shape and priorities don’t change often the team can refine and implement the backlog items without the Product Owner.

The impossible job?

Now for the big problem: reality. Anyone can describe what a good Product Owner should be and do (I just did), but that doesn’t make it a reality. There is a fundamental problem with the Scrum Product Owner role outside of product development companies: good Product Owners are too rare. Most Scrum experts actually admit that a good Product Owner is a rare phenomenon.
One of the great selling arguments of Scrum is that it’s a lightweight process, some might even call it a process framework. That’s a good thing because that means you can start using Scrum quickly and then fine tune the actual process within the Scrum framework. However, the Product Owner role hinders this easy implementation of the framework. I can’t start up the customer-project feedback cycle immediately because in my experience the demands for the Product Owner role are too high.

Conclusion

I've explained when the Product Owner role didn't work as it should have and also what a good Product Owner should be concerned with to maximize the project effectiveness by focussing on the business value of it's features. I conclude that the role is hard to fill in the right way which makes Scrum hard to kick-start and makes the process feel either broken or too heavy.
Perhaps we need a special ‘non-product-development’ version of Scrum? Or redefine the Product Owner role to fit large organizations so that we can start the process immediately and then gradually move towards the ultimate vision of true collaboration between the business and development.

Comments (17)

  1. Roman Pichler - Reply

    May 27, 2008 at 4:03 pm

    Nice blog entry. Even though the Product Owner's responsibilities are quite diverse, I think we have a common understanding in the Scrum community about the responsibilities of the role. Ken Schwaber has written about the Product Owner role in his book "Agile Project Management with Scrum". I also cover the role in a fair amount of detail in my book "Scrum - Agiles Projektmanagement erfolgreich einsetzen". No doubt, applying the role is challenging. Here are a number of reasons why:

    The first one is that the Product Owner role is a hybrid that requires a breadth of qualifications and knowledge but most organizations tend to encourage specialization of their employees. This situation is worsened by the fact that traditional development processes separate the definition of requirements from their implementation. Customer, product managers and marketers are hence not used to collaborating with development teams. Take a look at standard product management and marketing books: It is shocking how little these books talk about the actual creation of products and the necessary collaboration.

    Secondly, Scrum projects differ a lot. A new product development Scrum project that delivers a commercial product is different to an in-hose IT project that provides a maintenance release or product update. Who is the right Product Owner hence depends on the nature and importance of the project. This will also determine the Product Owner’s actual day-to-ay work, e.g., if and how much the PO has to align with stakeholders such as marketing, sales and service to prepare market introduction.

    The Product Owner does play a key part in Scrum. Scrum would not be Scrum without the Product Owner role filled properly. I know that is a challenge but nobody said it would be easy. Heads up: Toyota has employed their version of a Product Owner role, called the Chief Engineer, successfully for half a decade. And the Chief Engineer’s responsibilities are even greater than the Scrum Product Owner’s.

    Roman Pichler

  2. [...] Xebia blogs about how the Product Owner role should be filled out to get the most out of Scrum (Scrum The Mythical Product Owner role | Xebia Blog), and contrasts that with the reality that is met in most projects, where the product owner is a [...]

  3. Max - Reply

    August 18, 2008 at 8:27 pm

    Hi,
    I have a question regarding the role of a product owner and whether he can intervene and control the R&D development practices.

    For example I have examples where I had problems to convince the PO that switching to subversion from cvs was a good choice, or that choosing a specific automated web framework was the way to go than the other semi-automatic inefficient testing framework the company was using so far.

    However I believe that these are R&D matters and since the company decided to adopt scrum it should be up to the team to decide the specific tools to use and follow development practices that are compliant to agile process.
    From my view point the PO should be worried about the features and requirements and the state of the product in terms of customer and thus market satisfaction.

    Have I misunderstood something in the product owner role and his responsibilities or he can really intervene to R&D and have the final say to whether stuff like test driven development , continuous integration etc should or should not be followed by the team?

    Thanks,
    Max

  4. Erwin van der Koogh - Reply

    August 21, 2008 at 12:36 pm

    That is an interesting question Max. But I think going through the PO is still the way to go. I disagree that the PO is responsible for features and requirements. In my opinion the PO is responsible for creating business value and getting a Return On Investment.
    If you want to undertake for example a major refactoring it should give you a good return on investment and that's what the PO should be focused on.

    So PO needs to shift focus to focus on return on investment and creating business value. And you should prove that your technical idea actually delivers value. Either in decreased support cost, more productivity down the line etc.

  5. [...] Scrum The Mythical Product Owner role | Xebia Blog Explains how he has observed the PO done, and concludes by how it should be done, though there are few who are truly great Product Owners (tags: scrum productowner) [...]

  6. Rich Mironov - Reply

    October 2, 2008 at 7:08 am

    A really good breakdown of PO issues and challenges. As long-time product managers and among the limited set of practicing Agile product managers, we strongly advocate that revenue products (i.e. shipping for money to customers) need a product manager who owns the broad product/market problem...

  7. Niklas Bjørnerstedt - Reply

    January 7, 2010 at 5:08 pm

    Interesting post. I think one possible solution is to hire the product owner (but not from the same company as the team). I have worked in this way on a number of projects and it works surprisingly well. Many people instinctively object to hiring the product owner but I wonder if they would change their mind if they tried it. I have posted some thoughts on the product owner role here: http://www.leanway.no/?p=324

  8. [...] This post has some interesting thoughts on the product owner [...]

  9. Software Release != Agile? « Think about… - Reply

    February 28, 2010 at 2:21 pm

    [...] the stakeholders, and is the one who relays external goals (and priorities) to the team. But, alas, good product owners are hard to find – and release management is not necessarily one of their strengts. Inter-team management is [...]

  10. [...] and is the one who relays exter­nal goals (and pri­or­i­ties) to the team. But, alas, good prod­uct own­ers are hard to find — and release man­age­ment is not nec­es­sar­ily one of their strengts. Inter-team [...]

  11. [...] a lot of debate about what makes a good Product Owner. To me it’s simple. They are the person that cares, the person that is charged with making the [...]

  12. Jonathan Kaufman - Reply

    July 7, 2010 at 7:22 pm

    Good stuff. I agree that this is a tough role to fill (and so does Jeff Patton here http://bit.ly/7ij6e ). I think my PO team falls into that early phase you spoke about, where you find the best match you can and evolve to it over time. I'm posting on the characteristics we are pursuing and practical steps we are taking to try and MAKE our POs into POs ( http://unbreakablepo.com/ ). It'll be a long road.

  13. PM Hut - Reply

    September 9, 2011 at 6:47 am

    Hi Michael,

    I have just published an article on the absence of the product owner, which seems to be a bit contradictory with your post!

    In any case, I would like to republish your post on the product owner under the scrum category on PM Hut. Please either email me or contact me through the "Contact Us" form on the PM Hut website in case you're OK with this.

  14. [...] Scrum: The Mythical Product Owner Role [...]

  15. Emilie Chabbouh - Reply

    October 25, 2011 at 4:40 pm

    Hi ! Very interesting article.

    I came to agile beginning as a coach, but as I was a business analyst in the first years of my career, I have rather played the role of Product Owner, or PO's coach, or PO assistant.

    The difficulty of being a PO is that he has several responsibilities that require various skills.

    Responsibilities :
    The PO is the one to decide what the product must be, after collecting the needs of various stakeholders. And he has to be one (not several), because it delays decision and reduces understanding. But he has also to write acceptance tests to describe the features to the development team in a way they understand, he has to test the product, or at least to approve the developed features...

    Skills :
    Understanding of business stakes
    Collecting requirements, leading user workshops
    Analysis and synthesis
    Communication
    Basic technical notions

    As a matter of fact, the teams I have worked with have appreciated the fact that I'm very result oriented (business aspect of the PO) but that I also can sit down next to a developper and understand what he is doing because I am also a computer engineer. I know I am a rare combination, because, as said above, "most organizations tend to encourage specialization of their employees".

    When a client wants to set up an agile project, I encourage him to choose a PO strongly aware of business stakes (a PO business oriented), available 1 day per week for the team, and a PO assistant, preferably a business analyst with some technical notions and good communication skills, working within the team, 5 days per weeks.
    The PO and the PO assistant both manage the backlog :
    - the PO writes macro user stories and define their priority
    - the PO assistant refines the macro US in US fitting the INVEST criteria
    - the PO assistant writes acceptance tests for US
    - the PO assistant propose to the PO a list of US to present in the next planning game, they discuss together, the PO decides
    - the PO assistant answers the questions of the team during the sprint, makes minor decisions, but refers to the PO when something big is to be decided
    - the PO assistant tests the US as soon as they are done
    - the PO validates (or not) the US presented by the team in the sprint review

    I've found out that this combination is really working in the project I've made. Have you set up such roles in your Scrum Team ? If yes, are you satisfied about it ?

    Emilie

  16. [...] skills and responsibilities to do the job well. I tend to agree. Here is some food for thought:http://blog.xebia.com/2008/05/22/scrum-the-mythical-product-owner-role/Next, someone on your team needs to understand retrospectives in depth. If you don't get what you [...]

Add a Comment