Problem-focused Product Roadmaps to focus on Product Innovation
By: Sebastian Straube
Tags: Discovery, Product Management, Delivery, Roadmaps, Agile

Drawbacks from “classic” product roadmaps

“I’ve seen unrealistic roadmaps destroy teams and good products time and time again. Many problems could be solved if we stop considering Product Roadmaps to be a Gantt Chart rather than a high-level guide, but the way we make traditional product roadmaps prevent teams from being innovative and successful.” (Melissa Perri)

There are several reasons why product roadmaps can have a negative impact on product success:

Estimations are arbitrary: It’s nearly impossible to estimate large chunks of work without planning out and thinking through the features, which we do not do when we plan roadmaps so far in advance.

It’s nearly impossible to estimate large chunks of work without planning out and thinking through the features, which we do not do when we plan roadmaps so far in advance. No time for research and validation factored in: When companies estimate how long a product will take they usually do not account for research and validation but only for wireframing, design, etc. So we end up building products that do not solve customers’ problems.

When companies estimate how long a product will take they usually do not account for research and validation but only for wireframing, design, etc. So we end up building products that do not solve customers’ problems. No room for change: 100% of estimated capacity is allocated across the upcoming months and leaves no room to incorporate learnings from customer feedback and market dynamics.

100% of estimated capacity is allocated across the upcoming months and leaves no room to incorporate learnings from customer feedback and market dynamics. Not problem-focused: Usually product roadmaps focus on solutions and neglect the point that features are built to solve problems for our customers. In order to build the right things we need to deeply understand our customer’s problems.

Usually product roadmaps focus on solutions and neglect the point that features are built to solve problems for our customers. In order to build the right things we need to deeply understand our customer’s problems. Output-driven: Often roadmaps become a feature wishlist from different stakeholders and do not focus on desired outcomes.

Time to rethink roadmaps — Separating problems and solutions

A classic product roadmap usually does not separate problems from solutions. Instead it assumes that the next feature on the list will fix whatever problem it is meant to address. As we know there is not only one way of solving a problem but many… Sometimes the best solution might also be to NOT build a new feature but tweak an existing one or even remove an existing feature.

A Problem-Focused Product Roadmap separates problems from potential solutions. It can be planned over any time period, depending on what is suitable in your business context. A quarter usually gives adequate time to work through the two phases: Discovery and Delivery.

Each cross-functional team works on a problem to be solved during the time frame. The problem is manifested in form of an OKR (Objective & Key Results). One or more OKRs can be defined for each quarter and per team. Their goal is to the solve the problem and deliver on the planned Key Results.

During the Discovery phase, the teams are focusing on customer research and validating that the problem exists. They will build prototypes, execute user experience labs, conduct A/B tests and so on. All known discovery methods & tools are welcome here. When the teams have gained enough knowledge, they can transfer this to the Delivery Backlog and start building the features as MVPs (Minimum Viable Product) or MMPs (Minimum Marketable Product) in the Delivery phase.

In the Delivery phase, teams focus on minimum solutions to solve the most important customer problems. Teams should release frequently to receive fast customer feedback. Learnings from that feedback flow back into the Strategic Themes and the Discovery Backlog. This is a continuous feedback & learning cycle.

It is very important to keep options on the roadmap and let Discovery drive the decisions on the features built.