People who help their organizations determine the right things to deliver can have a variety of job titles and can fill a variety of roles. The rise of agile approaches in general and Scrum in particular added another role to the list – Product Owner. As with everything else related to agile, the nature of the Product Owner role, and whether it is needed at all, depends a great deal on context. As teams discover this, it leads to some common questions:
- What do Product Owners Really Do?
- Where in the organization do they fit?
- Do we even need Product Owners?
In the series of posts starting with this one I’ll take a closer look at the Product Owner role in an attempt to answer those question and hopefully others as well.
Some Background
Scrum and the other agile approaches were originally created by software developers who were looking to solve software development problems.
One problem that they all wanted to resolve was the lack of clear direct on what the right thing was to deliver. Some teams had no direction at all, some teams had conflicting direction, and still other teams would get direction, eventually, but often right after the team had made a decision conflicting with what the stakeholders eventually gave them.
What if, the creators of these approaches might have thought, we could have one person to represent the needs of our customers, knows all the ins and outs of the problem space, and could make decisions that stuck.
What if!
Scrum includes the Product Owner role as it’s version of that ideal person. You can find the most up to date, officially accepted definition of the Product Owner in the Scrum Guide.
The general gist of the description is that the Product Owner exists to provide the one source of truth as far as what the development team should work on. Definitely a nice setup for the development team.
When this role is implemented, people miss out on the nuances of this description, and the information not said.
1) “The product owner is not a committee, but may represent the desires of a committee.” It’s unrealistic to rely on one person to know everything about the problem space, but it is reasonable to rely on one person to make the final decision about what gets done. It comes down to how that one person makes decisions about what the development team works on – hopefully influenced by many others.
2) Nothing at all is said with regards as to how the Product Owner comes up with what the right things are. Those activities are assumed to be easy, or it’s assumed the person in the Product Owner role knows how to do these things. That’s not to say that those things don’t happen, It’s just one of the many things (including engineering practices) that aren’t included in the official Scrum cannon. I suppose you could say that a big assumption in Scrum is that people know how to do the work that they are on the team to do.
No wonder that both business analysts and product managers proclaim that they are not mentioned in agile. Aside from the minor fact that the roles aren’t mentioned (a lot of others aren’t either) what those roles focus on isn’t mentioned either.
What do Product Owners Do?
If you take the perspective of what is the best for the Development team, they make decisions on what the Development Team should do.
I think there’s more involved than that, and I tend to look at there are three large categories of things that product people (product managers, product owners, business analysts) do:
- Focus everyone on Outcome over Output
- Build and Maintain Shared Understanding
- Make Sure Decisions Get Made
Let’s take a closer look at each one of these.
Outcome Over Output
Outcome is basically the change you’re trying to introduce. Think of it as asking, have we satisfied the need? Outputs are the things you produce in order to satisfy that need, or the solution. We want to measure progress and success based on the outcome we’re getting, not the output.
Most teams measure progress based on output rather than outcome, primarily because it’s easier. It’s a lot easier to count the number of story points we’ve delivered. It’s a lot easier to look at velocity. One way you can measure based on outcome is to establish clear, measurable business objectives that you can use to gauge progress and success.
Shared Understanding
Shared understanding answers two questions: Do we all understand the need we’re trying to satisfy, and do we agree about the characteristics a solution should have? The people that should have that shared understanding are those who have the need (usually sponsors and stakeholders) and those who deliver the solution (delivery team).
The act of building a shared understanding in a collaborative fashion is more important than the resulting shared understanding itself. The conversations that occur in this process give the delivery team a clearer understanding of the problems that stakeholders face and identify risks and assumptions that are relevant to an effective solution.
Decision Making
Once you have a shared understanding of what you’re trying to accomplish, the next thing to do is provide guardrails for the decisions that team members make. While the leaders of an organization make key decisions such as whether to create or update a product or not, the members of the team make many decisions on a day to day basis that impact the product. In order to make sure the team makes effective decisions, they need to keep those decisions in line with the shared understanding of the need the product is satisfying.
Where do Product Owners Fit?
The three activities I listed above are all very important and someone needs to do them. The tricky thing always seems to come down to is who. And that depends on a lot of different factors.
Those organizations that decide they need product owners usually end up using one of the following four models, which also happens to involve the other product related titles – Product Managers and Business Analysts.
- Product Manager is the Product Owner
- Product Manager and Product Owner
- Product Manager and Business Analyst
- Product Manager, Product Owner, and Business Analyst.
Future posts in this series investigate each of these models in more detail.
Do we need Product Owners?
I think the easiest way to answer this question (aside from saying it depends) is to say that the activity of product ownership needs to happen, but you don’t necessarily need a person with the title of product owner. You’re more likely to see people with a title of something else (Product Manager, Business Analyst, or a whole host of business related titles) who filling the role of product owner. I explore the difference between product owner and product ownership in more detail in a later post.
That said, you do tend to see an increasing number of job ads for Product Owners.
What say you?
What has your experience been? Do you fill a product owner role? What is your actual title? Do you fit into one of the four models shown above or do you fit into another? Share your experiences in the comments.