Startups are experimental and chaotic. This culture of risk is also what creates the potential for disruption. It's the reason that 80% of new businesses fail and why the biggest success stories often come from such unexpected places.

In the early days, most startups avoid formal processes. They're seen as an unnecessary stifling of creativity. But an absence of process can lead to a lot of running in circles, aimless debate, inefficient learning and poor allocation of resources. So how can startups organize themselves effectively while remaining agile and open-minded? The answer is a problem-focused roadmap. But first, let's look at the other type of roadmaps companies use and why they don't work well for startups.

Output-Focused Roadmap

An output-focused roadmap contains a list of features (outputs) placed along a timeline (example below). It tells everyone what will be built when so that the team stays aligned and organised. But an output focused roadmap doesn't communicate why that feature is being built, why the order of development was selected and what the end result is intended to accomplish.

Focusing on building features creates a feature-obsessed culture, moving the focus away from what matters most—the customer. This gets compounded if the organisation's incentives reward shipping new features. In these circumstances, product teams tend to overlook the problems they are solving in favour of meeting deadlines and patting themselves on the back for remaining on schedule. There is little accountability for solving customer problems because their incentives don't encourage this behaviour.

You can diagnose an output-focused roadmap if it looks like a list of features to be built and if performance indicators are focused on shipping product in order to meet deadlines. For example, build an infinite scroll newsfeed by July 1st 2021 is an output-focused development sprint.

Outcome-Focused Roadmap

The idea that output-focused roadmaps are flawed has gradually been accepted in recent years. Instead, companies are moving to outcome-focused roadmaps which, as the name implies, focus on achieving an outcome separate from building a specific feature. The features being built are a means to achieve an end and not the end itself. Companies that use Objectives & Key Results (OKRs) as performance indicators are generally outcome-focused. You can identify an outcome-focused roadmap when performance indicators are linked to measurable outcomes, for example, increase the amount of time on the app by 25%.

Outcome-focused roadmaps are more flexible on how the feature should be built. It allows for whatever experimentation and iteration is needed to reach the end goal. It keeps the team focused on the outcome and not simply the output.

While outcome-focused roadmaps are a step better than output-focused roadmaps, the product team is still ultimately prioritising internal goals and attention isn't on the customer. Yes, the customer is accounted for, but how long does the customer stay top of mind weeks into striving towards your goal? Through trial, tribulation and iteration, the voice of the customer is easily lost in the chaos. This is a recipe for disaster for startups that are still trying to find product-market fit.

Problem-Focused Roadmap

Problem-focused roadmaps are centred around solving the customer's most urgent problems. Why is this so important? 80% of new companies fail and the number one reason is that nobody wants the product. The reason nobody wants these products is that they aren't solving a genuinely painful problem. No problem = no business. Every successful company is solving an important problem, even if that isn't immediately obvious from the outside.

Similarly to the outcome-focused roadmap, problem-focused roadmaps are flexible about which features should be built but instead of inwardly focused goals, product-focused roadmaps are designed around customers problems.

Planning a problem-focused roadmap starts with a simple question, What are our customers' biggest problems? To build a problem-focused roadmap, you must understand the pains that your customers are most urgently trying to solve within your area of interest. It's not enough to have a list of problems; you need to understand which problems are most important to them.

How to Build a Problem-Focused Roadmap

Finding the most urgent problems

I can already hear you ask, How do I know which problems are most important? This is where a lot of people go wrong. Their inability to robustly answer this question is one of the main reasons why people often compromise for a less customer-centric option than the problem-focused roadmaps. Even after conducting weeks of customer interviews, it's difficult to know which problems take priority for customers. This is where Customer Problem Stack Ranking (CPSR) comes in.

CPSR involves customers ranking their problems by importance. This shows you what really matters to them and which problems have the largest impact and therefore should be solved first. Only talking to customers about the specific problem you are solving is a recipe for disaster. You won't know if this problem ranks highly compared to the various other problems they face. Focusing on one problem can make a mild inconvenience appear to be a "hair on fire problem" and lead to building a product with no demand.

You can implement Customer Problem Stack Ranking manually in your user interviews or use a purpose-built tool like OpinionX. Using OpinionX will allow you to engage your target users at scale and measure how important your problem really is. You will be left with a list of problems in order of importance like in the example below.

(Note: Interested in building a problem-focused roadmap? Use our solution, OpinionX, to understand what problems you should be solving. Try it for free!)

Mapping problems to your roadmap

Once you have stack ranked these problems, you can begin planning your problem-focused roadmap. The process is pretty simple; aim to solve the most urgent problems first. Of course, you will need to consider other factors, like the number of target customers this problem affects (Reach), how much a solution to this problem impacts each of those customers (Impact → as informed by your CPSR), how confident you are that this problem can be solved with the skillset and resources on hand (Confidence), and the overall effort it will take (Effort). These four factors together make up the RICE Scoring method, a popular prioritization method used in product management. But at minimum stack ranking customer problems will place you firmly in the reality of what your customers really need.

Once you decide which problems are worth solving, you can put them on your roadmap. You don't need to know which features to build just yet. This will come at a later stage as you brainstorm ideas, experiment and iterate. Instead, your roadmap will look like a list of problems along a timeline. For example, in January you focus on customer mistrust and in February you focus on the problem of long waiting times.

Each problem on your roadmap will have multiple possible solutions. Map out each of these solutions and then select which features need to be built to make the solution possible. Now you have a roadmap that is focused on solving the customers biggest problems. Remember, no matter what complications emerge during the building process, you remain focused on solving the customer problem. Experiment with different strategies and see what works.

For example, SproutPlans (a startup building a personal finance app) used OpinionX to stack rank customers problems to understand which pain points their target customers were most eager to solve. The stack ranked data made it very clear that their target customers find it difficult to trust the advice given on personal finance apps. This is a major barrier to entry.

This is an example of a problem that could take priority on a company's roadmap. Dedicating a couple of weeks towards solving a trust problem could prove invaluable in the long term. Of course, there are multiple potential solutions to this problem. For example, they could decide to increase security on the application, hire more qualified advisors or improve the transparency of in-app communications. As you can see in the image below, these potential solutions can then be broken down into individual features within this problem sprint. As a result, the product team has a number of options for how they might solve any one problem. They can be flexible, experiment, conduct research and iterate until they meet the goal of solving the problem. This way the team stays super focused on what really matters — customer problems.

Each quarter you can ask customers to prioritise their problems again through another stack rank. You can see if the problem you attempted to solve remains a big problem or if it has reduced in importance. The goal is to keep knocking the biggest problems off the top of the stack rank; solving big problems leads to big business.

Design your own problem-focused roadmap

The best place to start is by setting up a free Customer Problem Stack Ranking survey. I jump on calls with startups all the time to help them design and interpret their CPSR surveys, so grab a free 30-minute slot if you'd like to discuss your goals together!

Startups should have a Problem-Focused Roadmap