How to become a great Product Owner?
January 10, 2012Of all three Scrum roles, the Product Owner is by far the most misunderstood role. What’s the core responsibility of the Product Owner? The typical answers that come out are
- Product Owner tells the what team what to do
- Product Owner defines the product and the Product Backlog
- Product Owner clarifies the vision
Well, these are all valid activities that the Product Owner needs to carry out. The Product Owner role is associated with creating user stories, providing the team with the acceptance criteria, providing feedback in the review meetings. On top of all this, better Product Owners try to work with the team during the Sprints. But the key aspect of the Product Owner role is often forgotten.
The core responsibility of a Product Owner is to maximize value. If there’s one thing the Product Owner must do, that is to maximize product value.
The Product Owner must focus on maximizing return on investment. This is the end goal. All the activities that Product Owner carries out should lead to maximizing value. Product Owner manages the Product using the product backlog, works with the stakeholders, collaborates with the team, plans, inspects and adapts to meet this goal.
A great Product Owner maximizes return on investment by using value driven development techniques. The Product Owner can maximize value by
- Measuring and maximizing value
- Focussing on higher value features delivery
- Optimizing total cost of ownership
Measuring and maximizing value
What is the return on investment on the features and releases you are building? Do you know much value do your customers put on certain features?
Most importantly how many features do they use? And which are the ones they use? How often?
It is very difficult for the Product Owner to decide about the value delivery if she doesn’t have any measures in place. The Product Owner should know how her customers perceive value. And then she can devise place to maximize it.
Focussing on higher value features delivery
When Apple released first generation iPhone many industry pundits were skeptical. Some dismissed it altogether. It lacked 3G support. Every phone company in the world and their dog had a 3G phone out in market. How could Apple expect to sell a phone which lacked a feature almost all of its competitors had.
But Apple released the highest value feature first. They released a phone and a great web experience. They focussed all their investment on core, high value features instead of playing ‘who’s got the most features’ game. They captured the market with blazing speed and kept adding features. Rest, as they say, is history.
We tend to build too many features into our products, too early on. These plethora of features lead to long development times, very high development costs and even higher maintenance costs. When pressed to develop all the features in the product early on, the Product Owner needs to ask the tough question. What’s the return on these features?
80/20 rule is Product Owner’s best friend. The Product Owner needs to analyze, understand and communicate the highest value features of the product. Product Owner needs to invest heavily in the features which provide customers the highest value. These features need to be built and released early. Releasing high value features early not only enables the Product Owner to get real feedback from customers very early, it also means that the product starts to generate revenue quickly. Revenue starts to pile up as more and more features are built in.
Releasing high value features is one part of the picture. The flip side of the coin is that the Product Owner needs to say no to low value features early in the lifecycle.
The return on investment is usually very high while the team is building and releasing high value features early on. But the return curve starts to flatten as more and more features are added. The Product Owner needs to keep a very close look on the return on investment curve. When the return on new features starts to stall, the Product Owner needs to ask another tough question. Does it make sense to keep adding new features?
The answer to this particular question might not be a simple one. It can vary, depending on industry, maturity of the market segment and the competitor landscape among other things. The Product Owner needs to make a call to either stop investing in the product and start investing in other opportunities. Or the Product Owner might decide to keep investing (though adjusting the investment level) to achieve specific goals to capture more market, hurt the competition or achieve other such goals. This decision need to be a deliberate one.
The Product Owner must have reasons to keep investing, instead of just investing because the ‘plan says so’, or ‘that’s what they are supposed to do’.
Optimizing Total Cost of Ownership
Traditional ways of allocating budgets and forcing people to stay narrowly focussed on costs has meant that people often ignore overall lifecycle costs while making key decisions during a certain ‘phase’.
If you are given certain budget to develop a product and your performance is reviewed on how do you manage the budget, you are forced to make short term decisions to cut costs. These decisions often lead to higher costs down the line e.g. cutting corners while designing and developing a product almost always causes high maintenance costs later.
When the design and quality is compromised, by not writing tests, updating tests, properly refactoring the code or in some other way, this leads to lower quality and higher maintenance and support costs.
A project manager once asked me why Scrum teams should include testers right from the start. He said he could cut the cost by bringing them in once the development team has built sufficient functionality to be tested. To him, it sounded like waste of resources. This a very common misconception.
What he didn’t realize in this particular case was that cost of fixing bugs increases almost exponentially over time. The earlier an issue is caught and fixed, the cheaper it is. Developers who are working on that specific piece of code are probably still working on the parts of code related to that feature, they can fix the bug swiftly, lowering the cost of maintenance. If the same bug is reported a few months down the road, the developer who wrote the code might have moved on to other project, other developer fixing the bug would need to first understand the design, navigate the code and then fix it. It takes way longer. Even the same developer would take more time down the line, because the code is not fresh in her memory.
The Product Owner must realize that by cutting quality, the overall cost has not decreased but the cost has merely been shifted. The product will cost more to maintain and this will affect overall return on investment. Great Product Owner don’t want this to happen.
Learn more about the Product Owner role, Scrum and Agile in one of Scrum Certification Courses.
