Three great ways to build and maintain agile product roadmaps -

Three great ways to build and maintain agile product roadmaps

By Georg Fasching | agile practice

Sep 26

Learn the easiest and most effective way to use roadmaps in agile product management with scrum.

Tip 1: Spare yourself the details

Your product roadmap must focus on key bits of information that are crucial to your product lifecycle. Your roadmap will constantly evolve so avoid overloading it with details. Instead, focus on adding information around three key areas:

  • Purpose
    • What’s the purpose of this particular milestone? What’s the reason for releasing this particular value?
  • Value
    • What value you’re looking to create for your user, customer, prospect and organisation?
  • Metrics
    • What change in your metrics or key performance indicators (KPIs) are you looking to achieve by doing this?

As an example, your goal or purpose might be to increase customer acquisition. The value will be realised through features that solve these pain points. This will e.g. increase customer acquisition by a number, measured by the metrics you’ve put in place.

Tip 2: Be sure of uncertainty

People often make wild assumptions about the future and act as confidently about tomorrow as they are about today. But to build a more realistic roadmap, you’ll need to be comfortable with being less confident the further ahead you plan. This is because, naturally, the further into the future you plan, the less certain you can be about what will happen due to unknown forces and external factors.

One way to express this uncertainty, while still building a promising roadmap, is to assign each milestone a low, medium or high level of confidence.

Another way is to increase your time estimates for execution at key intervals along the roadmap. For example, you estimate your first milestone will be met in one month, your second will be met six weeks after that, your third in another two months later and so on. The further into the future you go, the larger the target time frames for realising the value.

“Your roadmap is not a plan that is signed in blood and must be followed unquestionably–its a tool for communication”

Tip 3: Know your roadmap from your contract

It’s important to know what your roadmap is for and how it can help your agile scrum team. Equally important is knowing what it’s not. The roadmap is not a binding contract that must be signed in blood and seen through unquestionably until the end. It’s actually a tool for greater communication that:

    • Reminds you and your team of the bigger picture
    • Keeps you aligned and in sync as you progress and update it (and you will update it)
  • Helps to keep stakeholders in the loop, give them a good idea of the key milestones and maintain healthy expectations

If used correctly, the product roadmap can give clarity on the outlook, the timeframes and the value your team are constantly creating throughout the entire product lifecycle.

I hope the video and tips above help you to understand what’s involved in creating, maintaining and using a product roadmap in agile scrum. By taking these tips into consideration you can help to align teams and stakeholders across a common journey towards the product vision and unlock even more value for the end user and the organisation.

If you have any questions or topics you’d like me to cover, leave a comment below or send me a message through my website. Thanks for reading. See you next time!


Here is the full transcript:

– Hello, Georg Fasching here, helping you unlock your team’s genius.

In this video I am focusing on product roadmaps, a very important tool indeed when it comes to agile project management with Scrum.

And this is another video in the series Power of Three where I’m spending three minutes sharing my top three tips and suggestions on any particular subject.

So let’s get to it and put three minutes on the clock, starting now.

So when it comes to product roadmaps that you use in agile working the first thing to remember is that you want to focus on a few key bits and not overload the roadmap with too much detail.

It is important that you focus on the purpose, value and metric goals when it comes to any particular milestone that you have on the product roadmap.

What is the purpose of that particular milestone and the reason for releasing this chunk of value?

What is the actual value that you’re looking to create for the user, for the customer and the organisation in turn, and what is the targeted shift in product metrics or product key performance indicators that you are looking to achieve by doing this particular milestone.

So for example it might be, the goal might be to focus on the customer acquisition and the value that you are releasing to the user is
the inserted features which will help solve these sorts of pain points and therefore the organisation will benefit from it in this in that way, and you’re looking to increase the customer acquisition or user adoption by x percent or x many users. So that could be a very brief example.

The second thing to bare in mind is that you want to convey a decreasing level of confidence the further you go out on your roadmap
because of course there is more and more uncertainty the further you go out into the future, and there are a number of ways that you can do that.

The most common one is to perhaps look at a low, medium or high level of confidence and of course the closer you are to it, the higher would be your confidence.

Much better to some extent though is to actually reflect the anticipated, or the confidence that you have, and the level of uncertainty
that still remains based on time frames. So the milestone that you are currently working on, you can be quite certain and have that down to maybe a month, next milestone further out, maybe one calendar month, and the further out you go, the bigger the targets time frames for releasing that chunk of value, that milestone on your roadmap would be.

The last, but very much not least thing, and most important thing is probably to bare in mind what the roadmap actually is. The product
roadmap is a communication tool, it is not a contract, it is not a plan that is signed in blood and must executed on exactly as it is.

It is a tool that you can use for communication, firstly with your team as you’re creating the room of an ongoing as you update the roadmap, but also with the stakeholders.

It is a very good way for you to actually have that conversation with them, take the information into account, give them an
outline of the key milestones that you’re taking, that you can currently foresee in order to, that are helping
you to realise the vision that you have aligned on together with the stakeholders and with that you can ensure that they are very clear on what the outlook is and roughly what the time frames will be, the value that you are returning for them, that you’re creating for them and use it this way.

And with that our three minutes are up, once again thank you very much for your time and energy, I do hope that you found this useful. Please like, share and subscribe, in that case. Also feel free to share any thoughts or comments or questions that you have in the comments
below, and I wish you all the best for your practice with your team, and until the next video, thank you very much and goodbye.

Follow

About the Author

An agilist since 2010 and in product management since the 90s, Georg Fasching helps digital creative agencies delight their clients, fulfil their people, and improve their prosperity.

  • […] should be had as early as possible and it’s important to make sure the agreed level of fidelity aligns with your current position in the product lifecycle. Ask them […]

  • >