I’m a big fan of problems.
Innovation efforts often focus on ideas. They’re exciting, right? Wouldn’t it be amazing to create this widget or that service? We can sketch ideas, embellish them, prototype them. We can make compelling presentations that convince holders of purse strings to fund them — and, in the process, convince ourselves.
Over the years I’ve come to persuade teams to keep their work in the problem domain as long as possible. Among other things:
- It turns out to be easier to do useful brainstorming on problems than on ideas
- Problems are readily recognised and understood by end users
- Getting buy-in to solve a problem rather than deliver a solution allows you to stay flexible about how to do it
When we think about the long-term evolution of products and services, we often talk about a product roadmap. Typically, these are really feature roadmaps — what things to build in which order.
A greater focus on problems has its place here too. I came across this article from Lookback that describes the idea of a “problem roadmap”. The article acknowledges work by Melissa Perri, who recently posted a thoughtful approach to product roadmaps in her article Effective Product Roadmaps, from which this picture comes.
