Getting the product roadmap prioritisation right is a common challenge.
We should address which items first? We can delay which ones? This article answers these questions and helps you prioritise your product roadmap.
Do you have the product strategy in place. You should be able to articulate why users would want to use your product and why it is worthwhile for your company to invest in it. You should have valid answers to the following questions:
If you haven’t nailed the answers, then do not continue the road mapping effort. Instead, carry out the product discovery and strategizing work. Otherwise, the Agile Product Owner can build the roadmap on false assumptions. Getting the prioritisation right will then be virtually impossible. More than that can sneak in agile technical debt that the team should focus on and maybe this agile technical debt need not to be there in the first place!
To prioritise the product roadmap, consider in which life cycle stage your product is. As long as it hasn’t reached maturity, a product has to move forward: initially to get to launch, then to reach product-market fit, and finally to sustain growth.
At these life cycle stages, your product roadmap should tell a convincing story about the likely development of your product - should describe the journey you want to take it on to create the desired value for the users and business.
Is the duty of an Agile Product Owner to assure that the entire team is making the “buy in” for this product roadmap - because the agile technical debt can have a big impact on it. To get the prioritisation right, take the following steps:
For a brand-new product, this might mean that you start with user acquisition followed by activation, retention, and finally revenue generation, depending on your product’s underlying business model. For a product in the growth stage, you might find that you first have to remove agile technical debt before you can enhance the user experience and increase conversion.
If there are items on the product roadmap prior to the prioritisation, then check if they help you reach any of the newly created goals. If that’s the case, then assign them to the aim. Otherwise, either discard the item or investigate if changing the goals to accommodate the items would be beneficial.
A cost-benefit analysis might help you with this.
Whatever you do, make sure that your roadmap tells a cohesive, meaningful story that communicates how the product will create value for your clients and for the entire Agile team.
Once your product has entered the maturity stage, you rarely want to take it on another big journey, unless you extend its life cycle. Instead, you stay where you are, protect your product’s position, and maximise the return it generates.
There are often smaller, unconnected goals that the Agile Product Owner need to address, like:
But these objectives often lack clear connections, and they don’t form a logical sequence or narrative.
Faced with such a challenge, I recommend using cost of delay to get the prioritisation right. To put it simple, ask yourself how big the loss or severe the disadvantage is likely to be when you delay each item.
For example, if you are unsure whether you should first enhance the user experience to sustain engagement or fix bugs to prevent churn, then identify the impact of delaying each goal.
Once you’ve determined the cost of postponing the items, address the one with the biggest cost of delay first, then the item with the second biggest cost, and so forth. This should give you the right prioritisation.
The two approaches described above assume that the user and business needs together with the product’s life cycle stage determine the prioritisation of your product roadmap—not the HIPPO, the highest-paid person’s opinion.
I am an enormous fun of working collaboratively on product roadmap. Do actively involve the key stakeholders and Agile development team members, encourage people to share their ideas and concerns, attentively listen to them, and build shared agreement, as much as possible.
But if they face you with individuals requesting or even demanding that their interests must be address immediately, then do not give in. Don’t appease them and don’t avoid a tough conversation. This is a very simple way for the agile technical debt to sneak in and the team should address this but especially by the Agile Product Owner.
Instead, patiently listen to them and thank them for telling you about their idea. Then invite them to the next workshop for tickling the product roadmap so they can share their request with the other stakeholders and jointly decide if you can address it. And if the matter is urgent, get everyone together as soon as possible.
An Agile Product Owner means making tough choices, and prioritisation entails saying no.
This is an important part of our job, whether we like it or not.
Some (final) thoughts
This article is part of a bigger topic called: