Product Management 101: #11 Problem-Focused Product Roadmaps

Problem-focused Product Roadmaps to focus on Product Innovation

“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.
• 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.
• 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.

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.

Read the full article here:

#productmanagement ?#productmanager ?#product101 ?#businessagility ?#productstrategy ?#productdiscovery ?#agile ??#agileproductmanagement ??#leanstartup ??#leanux ??#productgoal ?#productowner ?#productvision ?#scrum

Subscribe to?https://lnkd.in/eqga-DuZ ?for more product-related content.