So you're a Product Owner. The Value Maximizer. How do you do that?
The basic idea is simple. You create value for customers and users, then capture some of that value for yourself, or your company.
We phrase this as creating customer or user outcomes with your product, which then leads to company impacts.
As simple as the basic idea is, apparently putting it into practice is awfully hard. We believe it is the next frontier for more agility, and many more things. Therefore, we work really hard with Product Owners to make it more practical and applicable.
Yes, there are many things in the way:
- Your Scrum team might be building a component of a larger product, so you have no visibility into what the product actually does, and how the product achieves the outcomes for the users or customers
- Your Scrum team might just be handed solutions to implement, instead of problems to solve
- Your Scrum team might not deliver frequently enough to gauge what is going on in the field with the product
- Etc etc
Fortunately, many organizations are realizing the benefits of being more product-led, instead of project-led. They are taking steps to remove some of these obstacles, so it becomes much easier to keep value front and center for everything you do.
Even though many teams don't have the context that will allow you to take being a value maximizer to its logical conclusion, what can you do as a Product Owner?
What value does your product deliver?
What you're building is always aiming to deliver some User Outcomes or Company Impacts, otherwise the product would not exist. Value can mean many different things to many different people.
For your context, for your product, you have to figure out what the outcomes and impacts are that you're after. That can range from the very practical (e.g. speed) to the highly emotional (e.g. a feeling of belonging). An excellent source of inspiration for naming the outcomes and impacts you are after, is Bains Value Pyramid. Make sure you identify them.
We found in practice, that the more you are removed from the customers and users as a team (e.g. a backend services team), the harder it becomes to think in terms of outcomes and impacts. They are still there though. It might be about speed, cost-efficiency, ease of use, reliability, security. All highly desirable outcomes in many situations.
Where do you express that value?
Vision
The best Product Visions describe the outcomes and/or impacts the product aims to achieve. How will your product benefit the customer? How will your product impact the company? These are excellent questions to answer in a Product Vision.
Roman Pichler's Product Vision Board has areas for both.
Be aware that if your team is part of multiple value streams, your vision is only a part of the picture that determines the order in your Product Backlog. The visions of these other value streams, and the relative importance of each determine it to a large extent. Be sure to create a vision that limits itself to the scope of what your team is building, and engage with others in other value streams to come to a Product Backlog order.
Product Goal
The best Product Goals describe a change in customer or user behaviour, through achieving some outcome. Ideally, the Product Goal is described as a Hypothesis, to be validated. The Goal Oriented Product Roadmap from Roman Pichler lets you define Product Goals in this way.
Product Backlog
Your Product Backlog contains everything you envision you'll do to the product. Often, the Product Backlog items contain pieces of functionality that your team will build. If you want to become more value-driven, you can modify these product backlog items so they contain some more data. After all we want the functionality to have some outcome or impact right? So what we add is the expected outcome or impact from the functionality (eg 10% faster, 60% more usage, 20% less outage) An excellent way to do this is via the use of Test Cards from Strategyzer.
Now here is where it really gets interesting. A lot of product backlogs don't contain actual product. Product as in features and functionality that is being developed. They contain components and or activities. In which case you need look at a higher level to be able to identify outcomes and impacts. Plus see if can make your product backlog better, in terms of containing actual pieces of functionality
Metrics
Please note that the Scrum notion of Done doesn't mean you're Done as a Product Owner. The Scrum notion of Done just means the output has been produced. It doesn't require the outcome or impact to have been achieved. We think as a Product Owner you're done when the desired outcome or impact has been achieved. That means you need to be able to establish whether that's the case. You need to find metrics that indicate whether an outcome or impact has been achieved.
How much faster, how much easier, how much more connected, how much cheaper, etc, etc.
You can do it
From a Scrum perspective, no area has evolved more over the past decade than the area of Product Ownership. Shifting the attention to the value side of the equation, and keeping that front and center, is key to any future excellence in product development. No matter how far away from the customer you are removed, no matter how much of a project-led organization you're still in, there is something you can try.
It will make things better, because if it's more about fulfilling customers and users needs, through which we get some great results for the company, how can that possibly make things worse?