Identifying the Real Problem

Early in a scoping effort, you will usually receive a description of what is going wrong. It may come from a sales conversation, a written brief, or a meeting with a manager. It sounds specific and authoritative, so the natural move is to treat it as the job definition and start designing around it. This is the misconception this article addresses: the belief that a problem as stated is the problem the customer actually has.

When someone explains a problem to you, their words feel like the problem itself. A customer says what is wrong, you write it down, and the rest of the process is built around that sentence. The source material argues that this sentence is often a poor guide to what actually needs fixing. Sales conversations almost always produce a stated problem that is not quite the real one. The word almost matters: it tells you this gap is the normal case, not an occasional accident.

The distinction matters because of how a good sales process uses each object. It treats the stated problem as evidence about the real problem, not as a replacement for it. If you build a solution directly from the sentence a customer spoke, you have assumed that the sentence and the work are the same thing. The comparison below shows how the two differ in where they come from, how they are worded, and what each one asks you to fix.

The stated problem is rarely invented on purpose. It usually forms as the problem passes through several people, and each one shapes it a little. Describing a problem is not a neutral act. Each person who speaks about it passes it through their own position, their incentives, and their expectations about what a solution could look like. The result is usually useful but incomplete. Three pressures account for most of the drift, and they can operate separately or together.

Follow a single problem as it passes through these pressures. The pipeline below is a mental model, not a literal process: the real problem sits in the daily work, and each pressure transforms it on the way to being spoken aloud. The three sub-sections that follow describe each pressure in turn.

The scenario below is an original illustration written to show how the two kinds of problem can diverge. It is not drawn from the source, so treat the specific details as invented teaching material that follows the source's principles. Watch how the problem changes wording at each step.

The source observes that people often speak in the language of the executive summary rather than the language of the workflow. An executive summary compresses a process into outcomes, categories, and conclusions. A workflow is made of concrete actions, handoffs, files, and repeated steps. The same problem sounds very different in each register. The phrase 'reporting is too slow' is an outcome. The phrase 'analysts re-key totals from two exports into a shared sheet every month' is a workflow.

This difference works as a diagnostic signal. When a description uses broad outcome words, the real problem is probably still hidden inside the process. When the description names specific steps, people, and tools, the stated problem is probably closer to the work. A practical habit follows: when you hear summary language, ask the person to describe what happens on an ordinary day, step by step.

The source is direct about where the real problem can be found: it is visible only at the level of the workflow. A workflow is the sequence of actions people actually perform to get their work done, including the workarounds, handoffs, and waiting that rarely appear in a summary. Headquarters cannot see this level, and neither can the customer's own leadership, though often for different reasons. Both see the problem at a distance, through reports and outcomes.

Verification means observing the people whose work the system will change and comparing what you see with the stated problem. This is why proximity matters. The forward-deployed engineer works at the customer's site rather than at headquarters, and the source treats that proximity as the way the real problem becomes visible, not as a courtesy. The flowchart below shows the check a designer should run before a solution is designed. If the observed workflow does not match the statement, the statement is revised and the workflow is observed again.