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.

Tags: Agile, business case, product owner, Scrum
Filed under Scrum | 8 Comments »