Many software companies have a product roadmap, with a list of features they’re planning to build, one after the other. While useful, it may also lead to lots of unnecessary features, a bloated product, and slow actual progress.
What we’ve instead switched to is a “problem roadmap”, which lists the most pressing needs our customers have. It purposefully excludes potential solutions to the problems. Instead it simply helps our whole company agree upon the problems at hand, and makes it easier to talk about them.
The problem roadmap gives us the flexibility and creativity to come up with the best solutions for each problem — and to see whether our solutions can be validated quickly, before we work on them.
Separating problem and solutions
A classic product roadmap can be confusing, because it doesn’t clearly separate problems from solutions. Plus, it seems to assume that the next item on the list will fix whatever problem it’s meant to address (if any). But we’ve found that there are often many ways of solving a problem, and we don’t know in advance which one’s the best. Many times features aren’t even the best answer. What if we instead should explain current features better, improve the navigation, tweak the copy, or remove existing features?
This is where a problem roadmap helps by separating problems from potential solutions. It creates clarity, because once you’ve agreed what the problem really is, it is much simpler to come together to discuss what the best solution to this particular problem might be.
With a classic product roadmap, we found ourselves celebrating when we deployed new features. But customers don’t care about shipped features, they care about solved problems. So with the problem roadmap, an item remains on the list until it is truly solved for customers. That’s when we celebrate.
Because what if the feature we spent way too long to build didn’t make a difference at all? That’s not “done”. That’s not worthy of our celebration.
Discipline helps you find the problems…
Anyone can throw a feature onto a backlog. But it’s very hard to come up with a list of accurately prioritized customer problems. It requires diligent UX research, lots of listening, open-ended questions (like The 5 Whys), analyzing of metrics and monitoring. Like in most UX research, you need to consciously remove your biases and start listening with an open mind — what’s really the most important challenge for customers, and what’s the underlying issue? What’s an actual pain point vs a nice-to-have?
… and creativity helps you find the best solution
With the problem roadmap at hand, it’s time to get creative. This is where you use intuition, skill and diversity of perspectives to come up with a list of least effort, highest impact solutions. Which solutions will drive the biggest improvement in the customer behavior metric related to the problem at hand? And which solution is easiest to verify and test?
At this stage, our teams get together to debate for hours about which solution is the smallest, introduces least technical debt, will really work, etc. And since we don’t know whether our proposed solutions will really solve the problem, we call them “experiments”. More on this process in an upcoming post.
Credits:
- We came up with this idea after reading Dan Olsen’s separation of “problem space” from “solution space”, as well as hearing Jeff Gothelf tell us about “a backlog of hypotheses instead of features”. The combination of the two became the problem roadmap.
- We’ve since also found an excellent post by Melissa Perri called “Rethinking the Product Roadmap” which outlines a very similar idea.
Share this post:
