Product Owner: what's his job and how does he or she help the team? Teams often run through the motions of Scrum and get very hung up on story points, velocity, committed percentages and as a result, struggle to deliver value. But what I’ll share today unlocks the value of Scrum; this is what Scrum is trying to get to create a series of small but potentially valuable investments - which translates in having an agile business that have a great cope with uncertainty.
See if any of the below problems sound familiar:
Scrum seeks to solve these problems by shrinking feedback loops. As an Agile Product Owner, to maximize the value of your product, you need to decrease your amount of investment by making smaller bets/experiments to take advantage of quick feedback loops.
You also need to make better investment decisions by constantly testing your experiments. If you worked as an Agile Business Analyst before, this will help you make the right decisions.
Step 1: Invest.
What does it mean to invest? When we think of investing, we typically think of things like stocks, hoping to get a better return than cost. Or we can think of things like education, investing in ourselves. Investments happen when there are many things we can pursue, and we have to prioritize and make choices.
Why is that so important? Well, this can vary dramatically since the average run rate of a Scrum Team is $1.6 Million per year. That is an enormous investment in a Scrum team. An agile business and an Agile Product Owner should keep the run rate of a team in mind as they consider what they’re investing in. Is the value produced worth the cost to develop?
So if this is the cost of our team, how do we know that what we are building is worth that level of investment? Hint: you don’t… at least initially. Something that can help with this is to understand what outcomes you are going after and how you will measure progress toward that outcome.
The time to learn metric is another effective tool that can help an Agile Product Owner to understand how big their investment cycle is (check here for more details). This metric measures from the time an idea happens to when you can gather meaningful insights off of it. And obviously, the shorter the better. A quick feedback loop helps an Agile Product Owner to validate ideas/investments. When we understand our Time to Learn cycle, how can we shorten it?
Step 2: Experiment.
To decrease our time to learn, we need to break things down to minor pieces of work. Why is this important? Because it enables quicker feedback loops from the actual customer; everything is just a theory of value until it’s released. A refinement session is an opportune time for an Agile Product Owner to ask themselves and their Agile Development Team questions in the refinement process:
These questions boil down to a two-part question for the Agile Product Owner:
An impressive example of this is the retailer, Nordstrom. They had an idea for how to increase sunglass sales in their stores. So they took one of their teams and placed them in a store for a week to create a solution with their customers. They prototyped and experimented on what they thought would help them reach their outcomes.
The goal is always that we want to make sure our outputs are getting meaningful results on our outcomes. The quicker we can do this and get actual feedback on it, the more effective we become.
The key is identifying experiments related to the most impactful assumptions. See what you want to validate or disprove by building something while keeping the product vision in mind; prioritize which experiment is most important for the team to work on next.
Some effective tools for this include A/B test and these are some examples of how this technique can an Agile Product Owner or even an Agile Business Analyst can apply it:
Step 3: Validate.
Run experiments and ask, does this meet our customers’ demands? Is this helping get measurable results? Are we getting a positive reaction from this? If yes, great, it validates our experiment; let’s keep investing in it. Let’s get this idea to our customers and meet our next highest use cases. If it invalidates the experiment we have to make a tough decision - do we continue to invest in this experiment and try to prove a fresh angle? OR perhaps we change our investment to something else that we’re more confident in? This is the tough art of Product Ownership.
But how does Agile Product Owner/Agile Business Analyst know what feedback to trust? Or perhaps what feedback is more valuable?
How often are you checking the value of something after they release it?
But don’t take my word for it! A PO I was working with at a client put this into practice.
If you want the unique advantage for Product Ownership, you can do this too!
You cannot afford in our digitalisation world not to be agile and just doing agile. An Agile Product Owner usually is the person that contribute to the success of the agile business into the same way that an Agile Development team is doing it!
Some (final) thoughts
This article is part of a bigger topic called: