Stakeholder Sworn Statement - When Will We Get There?

Agile development practices have exposed the difficulty in planning when there’s considerable uncertainty. Nevertheless, high-level management often insists that they have adopted agile practices but still want a roadmap. They need a plan first because they can’t confirm the budget without knowing what they will get in return. It’s a natural behaviour. People like to have an idea of where they are going. It gives them peace of mind. That is why every project I’ve ever managed started with a question: When will we get there? 

What is a roadmap? 

Imagine that today is rainy and windy - it would be nice to think about a vacation. You may have already started planning a winter or summer vacation with your family. A trip somewhere nice, with a beach, to relax and have an excellent time.  

It seems natural to look for some information when planning a leisure trip - maybe looking at a map and thinking about how to get to that beautiful place.  

Of course, you can go on the spur of the moment, wondering somewhere along the way. But experience tells us that just jumping into the car with the family and driving off without giving it a second thought is not a good idea.   

Suppose the total driving time is 16 or even 25 hours - that's no small amount of time in the car and you have to wonder: maybe it's too long for a family trip after all? Perhaps you should divide the trip into smaller segments? Or maybe you should have booked a hotel to stay the night on the way? Such questions definitely appear.   

That is precisely what the roadmap helps us with: thinking through such questions. Of course, everything can change. There may be a lot more traffic, and the route may have to be adjusted. But even if it needs changes, you can begin working towards our target with this fundamental concept.  

You can use this concept in your products to define the trip you wish to take. 

What is a Product Roadmap? 

- A roadmap showing how we want to develop a product, typically within 6-12 months  

- Most often coincides with several major product releases and versions  

- Roadmap is the context, and other artifacts complete it 

Roadmap – the context 
  

- Vision – as the general description of the ultimate goal of the product, the vision should offer "continuous guidance" at a very fundamental level. Time horizon: 5 years 
I have already written about it in Creation of IT products – vision, trick and area of focus blogpost 

- Product strategy - describes the approach we have chosen to achieve the product vision. Typically, it is something like a value proposition; that is, the main reason why users and customers may be interested in the product: a description of the problem, the solutions we propose, perfect customer description, revenue sources, and costs. Time horizon: more than 12 months to 2 years, sometimes longer.   

I have already written about it in my post about value proposition. 

Two things related to the product strategy are: 
- The product roadmap - a description of our product's journey, such as most essential ideas that will be implemented with the product. How will our strategy be executed? What are the key benefits of our product? Time horizon: about 12 months 

- Product backlog which contains even more details and also gives you an idea of how the plan is gradually being implemented. Time horizon: Product Backlog covers a working time of about three months. 

Benefits of building a roadmap: 

- continuity of purpose - to get a better understanding of how things might go  

- facilitating stakeholder collaboration - product backlog is too detailed to be useful for stakeholders 

- it can help with prioritization  

- relieving the burden on the product backlog  

- it can help in acquiring budget  

- supporting portfolio management 

Tips on creating the roadmap 

Roman Pichler defined the criteria of success for goal-defining roadmaps on his website.

- at the beginning, focus on Goals, not Features - what needs will be met, what benefits will be obtained (e.g., getting more users)  

- use metrics to assess whether the goal was or was not met (how many users did we get, did we get them from the same segment or a different one, how early after the release of the new version)  

- then take care of the features - e.g. registration, reports, navigation, checkout - product features must fit and support the goal  

- remember about the dates - defined as weeks, months, quarters; be sure to mark any specific deadlines (which, of course, should be realistic);  

- and in the end: names - with the roadmap, having planned releases, you can give them interesting names 

 

Now let's take a moment to look at the dates. There are three ways to deal with them: 

Tips on using the roadmap 

Do the necessary groundwork (Product Discovery)  

Validated Product Strategy is the key. You should look at Product Strategy as a collection of assumptions, identify the main hypotheses, and identify the principal risks (such as the value proposition not being strong enough or not enough people having the problem you want to solve). Then it is beneficial to do user research or user observation.

That validation loop is required during the preparation of the product strategy, before starting work on the roadmap, when you are confident enough that you have the value proposition figured out (that you know the target audience, that you have unique features that will differentiate you from the competition, and that the business objectives are realistic and that there is a way to monetize the proposition)  

Use a roadmap to ease the burden on the Product Backlog  

The product roadmap is a strategic plan that shows how a product should be developed over several product releases. In contrast, a product backlog is a tactical tool that provides details, including epics and user stories that must be implemented to create one or more releases.  

Having an overall plan as the roadmap, we can better choose the main features of the product to be implemented.   

Review the roadmap regularly  

Despite all the work, things change, so, most importantly, review the roadmap regularly. We review product performance, training in the market, what the competition is doing, what's happening internally (what significant changes are being made), any meaningful feedback from users, and the development team's progress. 

Frequency proposed by Roman Pichler 

This allows you to see if the roadmap and strategy are still valid. Is everything on track, or do you need to make any changes?   

Stakeholders can be divided into different categories according to their interests and power. Thus, we have four groups: 

The classification proposed by Roman Pichler 

Those who should be involved in roadmap activities such as creating, checking, and updating - are the Players. Their help extends to the creation of the product. When discussing the scope of the roadmap, the "Highest Paid Person Opinion" wins out. 

So, what is the answer to the question: When will we get there? 

The solution is not to create a detailed plan for your product but rather to signpost the road. Explain the needs that need to be met rather than listing what the product will do. Road mapping is a system for measuring progress, and we can make use of the uncertainties of product development. We know where we want to end up, but we can’t just map it out and start doing it. Products have their functions; they solve problems and fulfil needs. 

 
If you are interested in this topic, I encourage you to read the book by Chris Lukassen: "The Product Samurai". It would also be a good idea to take a look here.