Fix your prioritization problems with a lean roadmap

Have you ever thought about how the implicit assumptions you make in a timeline roadmap could impede your prioritization of the real problems that need to be solved?

Before I started to use a lean roadmap format, I found that every month, like clockwork, I would push forward items on the roadmap and rearrange the order. Here was a roadmap that should be showing what order and when we would deliver things – except it changed constantly. 

The reason my roadmaps changed so much was that we would release something, gather feedback and then realize that our assumptions were wrong. Those same assumptions underpinned our prioritization and consequently the Gantt roadmap. The constant change made a nonsense of our timeline roadmap.

As my experience shows, if product roadmaps are to work and be useful to organisations they need to embrace uncertainty and assume change. 

The trouble with timeline roadmaps

Timeline roadmaps, or Gantt charts, assume that you know what you need to do first, second, and so on, from a list of features that you want to build. But in reality, product managers usually have a backlog of features and no real sense of the order to build them.

What’s more, the prioritization algorithms and frameworks that allow product managers to give order to their backlog – RICE, Weighted Scoring and the like – all share the fundamental assumption that there is an absolute order of delivery (or importance) between the different features. 

The assumption is necessary to ensure that timeline/Gantt roadmaps are usable. They need an order of features to build that doesn’t change with time. Timeline roadmaps only work with the assumption that priorities are absolute and don’t change over time.

But priorities change. They change with markets, as products evolve, and as users evolve. The dynamics of user needs, desires and market forces mean that there cannot be an unchanging order for building features.

A timeline roadmap/Gantt chart isn’t really a roadmap, just a list of features that need to be built.

Embrace uncertainty with a lean roadmap

A lean roadmap embraces uncertainty and assumes that things will change. It’s not about features, rather problems that you can solve. 

With a lean roadmap you still have to choose the order of which problems to tackle and when. You can use frameworks like RICE or Weighted Scoring with a lean roadmap, but neither are ideal. This is because both assume an absolute order, whereas you are prioritizing relative to the other, strategic, problems.

It’s better to prioritize by looking at how the problems support the product and company strategy through achieving the objectives. Then you can look at how that works with the market and product feedback about the problems. Have a look at this post, Putting it all Together – Creating a Lean Objective-Based Product Roadmap for more detail.

Summary

The style of roadmap you use determines your approach to prioritization, but you should beware the fundamental flaw of assuming that an unvarying, absolute order exists with a timeline roadmap. In reality most product managers inherently recognize this in all the tweaking and eventual manual re-ordering of priorities that they do. Ultimately, you can’t really fix that fundamental flaw by tweaking. Lean roadmap and native prioritization approaches are better suited to the reality of product management.

Read more: Feature prioritization principles in Product Management