The problem with solutions

When planning a roadmap, it’s common to see descriptions like “Data syncing for automated emails”, “Finance and billing” and “User onboarding”. Sometimes you might see epic user stories like “When I sign-up to the application, I want to see a tutorial, so I can learn how to use the service”. Innocuous descriptions on little yellow cards and gantt charts.

The problem is, these descriptions are packed with assumptions. They assume knowledge, research and planning. Worst of all, they suggest a solution.

Solutions are hard to prioritise

There is little in these examples that can help decide what’s most valuable to users or the business. There’s no simple way to compare the value of one against another. By writing themes as solutions, we are hiding the most useful piece of information. The problem.

Problems are your customer’s struggles.

Instead of “Data syncing for automated emails” we could write, “Our Customers don’t get information about the product when it’s most relevant”. Instead of “Financing and billing” try, “The finance department are manually invoicing our customers and are at risk of making mistakes”. Instead of “user onboarding” we could write, “our new users are unsure how to get started with the service”.

It sounds plain, but this provides more information to make better decisions. The desired customer value is laid bare. There is less risk of ambiguity. Trade-offs are simpler to map and compare. It allows for prioritisation of high-value themes that make a difference to customers and the business. It opens up the possibility for research, ideation, testing and iteration to uncover the best solution.

Sometimes themes on a traditional roadmap are multiple problems tangled together. Separate these problems so they can be evaluated independently. Some problems have dependencies on the outcomes of other problems. Note these dependencies to help with prioritisation. Let the team know about them before they start designing solutions. Without knowledge of a problem’s dependencies, a team might pursue solutions that don’t take the broader picture into consideration.

The moment to choose the best solution is when you have the most information.

It’s uncommon for anything planned more than six weeks in advance to have enough information to make a definitive decision on a solution. A lot can happen in that time. Services and technology evolve. Business priorities and markets shift. People leave and join the team bringing new skills and perspective. New information comes to hand.

Solutions put forward early in the process put up boundaries and set expectations. Problems early in the process are a source of inspiration, opportunity and the catalyst for research. Putting off decisions on solutions as long as reasonable increases the probability of uncovering and executing the best solution for your customers.

A workshop on problems

Here’s an exercise to try. It’s useful and cathartic. Instead of writing descriptions of your themes that suggest a solution, write the problems. Write down all the problems. Everything that is limiting your product and your customers. Don’t get bogged down on why it’s a problem or how it might be solved. Write straight up descriptions of the things that are causing pain or stopping progress.

Don’t forget to write about the things that don’t exist yet in your product. What are your user’s problems? What progress are they trying to make? What adaptions and workarounds are they using? You’ll ideally have observed and spoken to customers and internal stakeholders to identify these problems.

Now get your important decision makers in a room and order the problems. Use research, empathy, risk, experience and your gut to rank them. You can use voting techniques like sticker voting to try to minimise group think. Give a limited number of stickers to each person and build a heat-map of priority. One person is the decision maker and gets a super vote on the most important problems.

Umm…but, aren’t problems, you know…negative?

I know what you’re saying, who wants to present a bunch of problems. First, make sure you prepare everyone and explain what you’re doing. Try some of these phrases, “I am purposely trying to avoid any solutions to allow proper consideration of the problems without bias”. “I see problems as opportunities”. “Problems are a source of innovation and value to our customers”.

If you don’t think your important decision makers can stomach only problems, take the extra step to pair the problem with opportunities. But don’t throw away the problem. An opportunity statement is not nearly as powerful as a problem statement. Opportunities are optional, problems keep people up at night. We want to feel the pain of the problem so we can get a real sense of it’s value.

For example, in addition to “Our Customers don’t get information about the product when it’s most relevant”, add “How might we provide product information to customers when it’s most relevant”. We could pair the problem “The finance department are manually invoicing our customers and are at risk of making mistakes” with, “How might we optimise the billing process to increase efficiency and accuracy”. In addition to “Our new users are unsure how to get started with the service” we could add, “How might we help new users get started with the service”.

You might start to find that a single problem has multiple opportunities. For example, in addition to “…product information to customers when it’s most relevant”, we could write an additional opportunity like “How might we make the delivery of product information to our customers efficient and low touch”.

A roadmap of problems leads your product to better customer centred solutions

Now you have a roadmap of problems to solve and opportunities to make your customers lives better, the product team can do what they do best — solve problems. They aren’t bound by assumptions, pet solutions and first base ideas. They have a benchmark to strive for. The team should be encouraged to research, seek inspiration, empathise, ideate, innovate, prototype, test and iterate. Constrained only with the expectations of lean delivery, they can uncover an ideal solution and deliver real customer value.