How to Define Customer Problems That Tell You What to Build in B2B SaaS
The test for a precise problem definition? You can evaluate any alternative solution against it. Most definitions fail because they lack 10 foundational elements of every customer problem.
💡 This is article #4 in a series on Deductive Innovation, a systematic approach to B2B SaaS product discovery. To get the most value, start with the intro article #1, continue to part #2, then part #3.
Companies spend millions developing products based on insufficient definitions of customer problems. The result is speculation and guesswork about what to build.
One enterprise software company I recently spoke with had spent 18 months building a product no customer ultimately wanted to buy. They never really understood the problems the product was meant to solve.
This article introduces a precise test for whether you understand a customer problem well enough, identifies the most common mistakes in problem definitions, and lays out 10 foundational elements that every customer problem contains. These elements are necessary to evaluate solutions analytically before building anything.
First, let’s review what we discovered about customer problems in the previous article. Skip this if everything is already fresh in your mind.
Recap: the principles behind customer problems
We are seeking the correct answer to a deceptively simple question:
What is a “customer problem” to which a software product is a “solution” – in principle?
The answer gives us something that very few product development approaches offer: the ability to systematically construct optimal solutions to any customer problem of a B2B SaaS product.
Last time we examined three situations where people needed to boil water for tea:
A) Alice’s evening ritual: Winding down at home
Alice is at home, exhausted after a long day, and getting ready to go to bed soon. To relax, she enjoys having a cup of tea.
B) Bob’s wilderness challenge: Hydration on the hike
Bob is trekking in the wilderness. A cup of tea would help keep him warm and safely hydrated, as boiling the water makes it sterile.
C) Carol’s family adventure: Forest fun with the kids
Carol is on an outing with her children in a forest on a Sunday afternoon. Her goal is to provide exciting and educational experiences for them.
From analysing these situations and their best solutions (electric kettle for Alice, Trangia stove for Bob, campfire for Carol), we discovered universal principles for all customer problems:
A customer problem describes a specific example of a situation where a particular customer is
A customer problem exists independently of any solutions
A customer problem has multiple potential solutions
We can objectively evaluate and compare solutions against a specific customer problem
With these principles established, the next question becomes: what elements must we understand about any customer problem to make such evaluation possible?
The non-negotiable test for understanding any customer problem
Every solution exists to enable a customer to solve their problem: to use it in their specific situation by taking some sequence of actions to reach a good end-result.
To evaluate a solution, we must analyse two aspects:
Value of the best possible end-result the solution enables the customer to reach
Quality of the process that the solution requires the customer to go through to reach that end-result
Real customer problems always occur for a specific person in particular circumstances. Many elements of the situation affect the end-result they can reach and the actions they need to take. To evaluate alternative solutions, we must know what those elements are.
This gives us our key criterion for the elements of customer problems:
We must be able to evaluate any alternative solution to the same customer problem.
This is our non-negotiable test for how well we must understand customer problems.
To evaluate any solution, we must:
Have the ability to put ourselves in the place of the specific customer in the specific situation
Know exactly how the solution works from the customer’s perspective in that situation
Find out the sequence of actions that the solution requires the customer to take to reach the best end-result
Evaluating a new solution idea requires first defining it at a level of detail where it’s possible to construct the required sequence of actions. Until then, an idea is merely vague speculation: appealing in concept but completely untested against reality.
Common mistakes in problem definitions
The most fundamental mistake I see companies making is describing a customer problem in terms of solutions:
either as solutions customers ask for, or
as problems in existing solutions.
Note that while the descriptions might be called customer needs, user stories, epics, use cases, jobs or user goals, they are nevertheless attempts to describe a customer problem to which a solution is a solution.
Even when companies avoid this mistake, their problem descriptions still usually fail our non-negotiable test. Typical description look like these:
“Boil water to make tea”
“As a user, I want to boil water so that I can make tea”
“Increase liquid temperature from A to B”
“Bob is a sporty guy who enjoys spending time in nature.”
Simplistic or generic problem statements like these do not enable evaluating and comparing alternative solutions analytically and objectively.
They cannot differentiate between a vast array of different kinds of situations, such as Alice’s, Bob’s and Carol’s, for which different solutions would actually be best.
Qualities of a person that don’t affect the evaluation are not elements of a customer problem. Imagine putting Bob in Alice’s situation. No matter how “sporty” and “nature-loving” Bob is, he would boil his water using an electric kettle, just like Alice. He wouldn’t go out to make a campfire.
If we can’t compare alternative solutions, we can’t know what the optimal solution would be. This prevents us from innovating new, radically better solutions systematically and consistently, which is the ultimate goal of Deductive Innovation.
“A solution can only be as good as your understanding of the problem.”
—Paul Adams, Chief Product Officer of Intercom
Without properly understanding customer problems, we lack a yardstick for comparing alternatives. This vacuum leads to decisions based on the loudest voice, the most popular opinion, or the HiPPO (highest paid person’s opinion).
So, what does the right kind of description of a customer problem include?
10 essential elements of customer problems
The specific situations of Alice, Bob and Carol provide a basic demonstration of what customer problems must contain.
Below I have listed 10 foundational elements of customer problems. They are present in every customer problem, even simple everyday ones like our tea examples (though often implicitly, as we’ll see in a moment). B2B software problems typically require additional elements beyond these 10, which I will cover in a future article. But these are the starting point.
In some way, they all affect:
The sequence of actions a customer necessarily has to perform with the solution
The best end-result the solution enables them to reach
Consequently, they affect what the best overall solution is in each situation.
Protagonist: Who has the problem?
A person at home, a hiker, a mother with children
Goal: What are they trying to get done?
Boil water to make tea
Motive: Why are they doing it?
Calm down at night, keep warm and hydrated in the wilderness, provide exciting experiences for children
End-result (“benefit”): What end-result are they trying to achieve? The end-result is the “benefit” the customer gets from solving their problem.
Hot water that is suitable for making tea
Timing: What initiates the situation and when?
Getting ready for bed, satisfying thirst during the hike, fun weekend outing
Location: In what physical or organisational setting does this occur?
Home, wilderness, forest
Resources: What resources and information are available in the situation and what do they cost?
Electricity at home, Trangia fuel, dry wood and a spot for the campfire
Causalities and dependencies: What forces and natural causal relationships affect and constrain the series of actions necessary to reach the end-result?
One must obtain the water before boiling it; the water must be placed in a container to boil it; certain containers can be damaged by boiling water, fire or microwaves
Criteria for the end-result (“benefit”): How does the customer measure and evaluate the end-result in the situation?
Water is boiling hot and evenly heated, suitable for making tea
The criteria for a good end-result are very specific to the situation
Criteria for the process (“cost”): How does the customer measure and evaluate the process of reaching the end-result? The process of using the solution is the “cost” to reach the end-result; but in consumer products, the process itself can also be a “benefit”, like in Carol’s case.
Convenience, saving electricity, effort, speed, safety
The usual criteria for the process are minimising time, effort and risk
Notice again that all these elements are solution-independent, which is our foundational requirement for what a customer problem is.
How much detail you need to document
You might wonder: “Do I really need to document all those 10 elements for every customer problem?”
For familiar situations, a vivid 1-2 sentence description often suffices. Take our tea examples:
Alice is at home, exhausted after a long day, getting ready for bed soon.
Bob is trekking in the wilderness, needing warm hydration.
Carol is on an outing with her children in a forest for an exciting and educational experience.
Despite lacking many of those 10 elements explicitly, such short descriptions work because:
They describe real people in real situations
The context is familiar to everyone
Common sense fills in most details
But watch out for important hidden details. Even in seemingly simple situations, small variations can demand completely different solutions. Consider this twist: Alice prefers green tea, which contains less caffeine and requires water at about 80°C, not boiling. Suddenly none of the solutions we evaluated are optimal for her situation.
For B2B software, brief descriptions rarely suffice:
Domain complexity requires explicit detail. The elements of customer problems in drug development, reinsurance, or operating a nuclear plant are not self-evident or obvious.
Product developers are not familiar with the domain. Facts about customer problems must be documented for shared understanding.
Business situations often include multiple people in different roles with different goals, which add layers of complexity to customer problems.
For a solution that is used to process complex large data sets, the description of a specific situation must include an example of a realistic data set.
Describing customer problems for software, and B2B software in particular, involves some further considerations beyond these 10 basic elements. We will get to those in a later article.
Why these elements matter for B2B products
These 10 elements do more than describe a situation. Once you know them, several things become possible.
You stop speculating about what to build, because every element of your product addresses a specific, validated aspect of your customers’ real-life problem.
You can evaluate potential solutions objectively before developing them. Instead of building and testing with customers to find out if something works, you can reason through how each solution would perform in the situation, step by step.
You can identify which underlying problems are actually common across customers, irrespective of the solutions customers are asking for. This is what enables building scalable products rather than custom solutions.
And you gain a stable, long-term basis for your product strategy. Customer problems change slowly; feature requests change with every conversation. Building on the former gives you a foundation that competitors who chase the latter cannot match.
Applying these principles to complex B2B software products
The principles we have explored using the tea example already apply directly to software. But B2B software products bring additional complexity and require understanding a few more elements. Specifically:
Multiple stakeholders with potentially competing needs
Complex business processes
Enterprise-scale implications
Industry-specific regulations and constraints
The need for scalable products that solve common customer problems across different organisations
What’s next
In the upcoming articles, I will show how the discovery method of Deductive Innovation, Deductive Discovery, addresses these complexities. You will learn how to systematically uncover customer problems in enterprise environments, and why this is possible even when many seasoned industry experts believe it isn’t.
Subscribe now to get the next article when it comes out.