The questions that must be answered
Problem Phase is structured around six fundamental questions. They're not a questionnaire to fill out — they're directions of investigation. Each one opens a different angle on the problem, and together they compose a picture complete enough to produce a quality Problem Statement.
1. What is the real problem, not the symptom?
This is the most important question and the hardest one. What you're told first is almost always a symptom. "We need a dashboard" is a symptom. "We have no visibility into inventory and lose sales when we run out of stock" is the problem. The difference seems subtle but it determines the entire solution.
There's a distinction that helps: the symptom is what you see. The problem is the gap between reality and what should be happening. "The team takes a week to do reports" is a symptom. The gap is: "Business decisions are made with a week's delay on real data, and by that time the situation has already changed."
Repeatedly ask "and why is that a problem?" Use the 5 Whys technique. Don't stop at the first answer. When the person says "because it's always been like that" or "because the system doesn't allow it," you're close to the root cause.
2. Who does it affect and how do they experience it?
A problem doesn't exist in the abstract. It exists in the experience of specific people. You need to understand who lives it, how they experience it in their daily routine, what emotions it generates, and how it impacts their work or life.
But there's a nuance that many teams overlook: not all affected people experience it the same way, and not all matter equally for the problem definition. The store manager who loses sales due to stockouts lives the problem one way. The warehouse manager who receives constant complaints lives it another. The customer who finds an empty shelf lives it a third. The Problem Statement needs to integrate these perspectives, not choose one and discard the rest.
Ask for concrete stories: "Tell me about the last time this happened to you. What did you do? How did you feel?" Stories contain details that generic answers don't reveal. Emotions are data. A user who says "it makes me angry" is giving you information about the problem's intensity that no metric captures.
3. What causes it?
Understanding the causes is critical to avoid solving a symptom. Causes can be multiple, interconnected, and operate at different levels: personal, process, system, organizational.
Map causes in layers. Distinguish between root causes and contributing causes. An Ishikawa diagram or causal map can help visualize the structure of the problem. The root cause is the one that, if eliminated, makes the problem disappear. Contributing causes are those that aggravate it but don't generate it.
4. What has already been tried and why didn't it work?
This question is a gold mine of information. Previous failed attempts tell you what doesn't work, what constraints exist, and frequently, what part of the problem the user already understands better than you.
Don't judge previous attempts. Explore what part worked, what part didn't, and why. Partial solutions often contain the seed of the real solution. Ask: "What workaround have you created? What part of that workaround works well?" Those answers reveal invisible constraints that no technical analysis would show.
5. What is the cost of not solving it?
The cost of the problem is what justifies solving it. If you can't quantify — in time, money, lost opportunity, emotional wear, or risk — the impact of not solving the problem, you don't have a business case. You have a hypothesis.
But there's a point here that many teams avoid because it's uncomfortable: the cost of not solving the problem is also the most honest criterion for deciding whether it's worth solving. Not all problems justify a solution. A rigorous discovery can legitimately conclude that the problem exists but its cost doesn't justify the investment. That's not a discovery failure. It's its most valuable outcome: avoiding building something that doesn't make economic sense.
Quantify whenever possible. "It costs me 3 hours per week" is better than "it costs me a lot of time." Concrete numbers anchor the conversation and facilitate subsequent prioritization. When direct quantification isn't possible, use proxies: "How many times per month does it happen? How much time do you lose each time? How many people are affected?"
6. When does it occur, how often, in what context?
The temporal and situational context of the problem reveals patterns that don't appear in a static description. A problem that occurs every day is different from one that occurs once a month. A problem that appears only under pressure suggests different causes than one that is constant.
Look for triggers and conditions. "When does this problem appear? Are there days or moments when it's worse? Is there something that triggers it?" Contextual patterns frequently reveal the root cause more effectively than direct questions about causes.