7 Tips to Create a Product Roadmap from the Backlog

the Product Roadmap


I think you will agree with me when I tell you…

 

A product roadmap is essential to explain your product strategy to your stakeholders.

 

Nevertheless, it is not that easy for new product owners to create a product roadmap from the backlog.

 

When I started as a product owner, I had the same problem. First of all, I didn't understand the value of a roadmap. Second, I wasn't able to create one out of a huge backlog.


In my first year, I learned how to create a product roadmap from the backlog. For sure, it took me some time to solve the roadmap riddle but today I am able to help my colleagues if they struggle to create a product roadmap from the backlog. 


In this blog post, I summarized 7 essential tips which will help you to clean the dust from your backlog and come up with a great roadmap. So check it out!

1

Tip #1: Change is permanent

My most important learning was to accept that change is permanent. It even applies to a long-term roadmap.


When I started as a product owner, my relationship to roadmaps wasn't good. We were doing Scrum and focused on our sprint plans. I didn't see a need in creating a roadmap as our priorities anyway changed between two sprints.


This didn't work well with my stakeholders as they request to provide them a roadmap with clear commitments.


At on point, I just accepted the fact that it is natural that our priorities change. I challenged myself by creating a roadmap, knowing that it will change.


In fact, this helped me to make the priorities of my stakeholders transparent. In addition, your team will work more effectively as the roadmap provides them with a clear direction.

2

Tip #2: Clean up your backlog

Simplicity - the art of maximizing the amount of work not done - is essential. - Agile Manifesto

Sometimes doing less is the better solution. In my case, I got overwhelmed by a huge backlog. Including overall 150 user stories, I was not able to create a product roadmap from the backlog. 

For sure it took some time to handle this and one of the most important things was to reject some of those stories.


Therefore, I want to outline some cases where you should think about rejecting the story:


  • The person who requested the user story left the organization.
  • The user story is already 2 - 3 years old. 
  • The story is an unspecific improvement story, like "refactor the GUI".

In all these cases, it is totally okay to question the business value of the user story.


In my opinion, you shouldn't worry about offending somebody by rejecting a user story. If somebody complains that you declined their user story, it is already a good indication that there might be a business value.


3

Tip #3: Clarify your product vision

The disadvantage of focusing on features too much, is that there are always too many features that would add value, therefore creating a lack of focus on the vision and goals. - Robbin Schurrmann

A product vision is more than a fancy slogan. It provides you the right direction for your product. 


One tool for this is the Product Vision Board by Roman Pichler. With the help of this template, you can work on your product vision step by step. Filling out the product vision board challenges you to think about your customers and their needs. Furthermore, you need to describe how your product satisfies the needs and your business model (or business goals).


Hint: If you are struggling to fill out the board, you can also start documenting the current state of your product. Afterwards, you will feel much more comfortable about adding your vision.


Check out this example for some inspiration:

After defining your product vision, creating a product roadmap will feel much easier. Define the steps to achieve your vision and consider your backlog items.

4

Tip #4: Cluster the user stories

If you are dealing with a huge amount of user stories, creating clusters of user stories can help you to reduce the complexity. 


Either you can group the items according to the affected features or assign them to a specific customer segment. 


Afterwards, you can try to identify one or more key stakeholders or users. Talking to them will help you to raise your understanding about their needs. 


Another way to visualize the value of user stories is the Kano model: 

The Kano model helps you to categorize user stories in excitement, performance, and basic features. I always try to keep in mind:


  • One excitement feature can make your customers buy your product.
  • Performance features differentiate yourself from your competitors
  • Missing basic features can be a show stopper (but don't have to). 


Any of these clusters could be reasonable milestones for your product roadmap.

5

Tip #5: Define your release schedule

Defining a "strict" release schedule can give you a great basis for creating a roadmap. If you know when you will release your product, the basis for your roadmap is ready.


In the following infographic, I summarized how detailed I am planning in relation to the time.

Infographics - How to create a release plan

6

Tip #6: Don't prioritize, rank it!

In my discussion with different stakeholders and key users I recognized one flaw in the communication with my stakeholders:


Stakeholders often give a high priority to multiple things.


I am 100 percent sure you will end up in the situation where your stakeholders will request multiple things at the same time. If you ask them for a priority they will tell you 2 - 3 tasks that are the "high priority tasks".


One trick I learned about this to ask for a ranks instead of priorities. 


If you want to get shit done, multi-tasking isn't a good idea.


The problem is that people tend to prioritize in three levels: High, medium and low priority. Instead, a ranking defines a clear sequence.


If you want to read more about helping your stakeholders to rank their requests, check out my blog post about Where agile estimation fails: Involving stakeholders to prioritize user stories.

7

Tip #7: Get feedback about your roadmap

Last but not least, getting feedback about your roadmap is essential. The point is: If you are dealing with many stakeholders there isn't a perfect roadmap. Instead, the roadmap facilitates the discussion about your product strategy.


If you are struggling to create a product roadmap from the backlog, it is important that you realize that having no roadmap is no alternative. 


Ask your colleagues, team members and stakeholders for feedback.

Are you just starting as a product owner? 

I can also recommend you to read the article Tips for starting Product Owners by Robbin Schuurmann, which inspired me to write this post.

And if you liked this post, you should check out the other post on my blog. For example, there is one about 8 skills every software engineer needs in a Scrum team.

Click Here to Leave a Comment Below 0 comments

Leave a Reply: