# Known vs unknown operational problems: how to tell them apart > A known operational problem already has a number attached — a backlog, a cycle time, an error rate — and the task is finding its root cause. An unknown problem has no measurement yet and shows up as a feeling that something is wrong. Telling them apart decides whether the first step is analysis or instrumentation. Question: How do I tell whether an operational problem is known or unknown? Canonical: https://avidproblemsolvers.com/answers/known-vs-unknown Updated: 2026-10-18 Publisher: Avid Problem Solvers (https://avidproblemsolvers.com/) ## What makes a problem "known"? A problem is known when it can be stated with a number and the number is trusted. "Claims take eleven days to settle." "Our dispatch backlog is four hundred orders every Monday." "First-contact resolution dropped to sixty percent." Somebody named it, it is probably on a dashboard, and people argue about why it has not moved rather than about whether it exists. Known problems are not easy problems. They are often the ones that have survived several attempts to fix them. But they have a clear starting point: the metric exists, so the work is to find where in the process the variation enters and remove the cause. ## What makes a problem "unknown"? An unknown problem has no measurement attached. It appears as a symptom without a figure: margins that feel thinner than they should, a team that seems busy all the time without output rising, customers who leave without saying why. People describe it with words like *feels*, *seems* and *somehow*. Unknown problems are frequently the more expensive ones, because nobody owns them. There is no metric to assign, so there is no target, so there is no project. They persist precisely because they cannot be pointed at. ## Is there a middle case? Yes, and it is the most common shape in mature operations: **a known symptom with an unknown cause**. The effect is measured precisely — churn is up, cost per transaction has risen — but none of the existing data explains it. The dashboard is right and the diagnosis is missing. This case is easy to misread as a known problem, because there is a number. The test is whether the available data can actually explain the number. If every breakdown of the metric leaves the change unexplained, the cause sits outside what is measured, and the work looks more like an unknown problem than a known one. ## How do you tell which one you have? Write the problem down in one sentence and examine the sentence: - **Does it contain a measurable quantity?** A count, a duration, a rate, a cost or a percentage. - **Does it contain uncertainty language?** "We can't tell why", "nobody knows", "it seems", "it feels". A sentence with a number and no uncertainty describes a known problem. A sentence with uncertainty and no number describes an unknown one. A sentence with both describes a known symptom with an unknown cause. A sentence with neither — "our operations need improving" — is not yet a problem statement at all; it cannot be tested, and the first move is to turn it into something with a number attached. This is the same reading the problem probe on the [Avid Problem Solvers home page](/) applies to whatever you type into it. ## Why does the distinction matter? Because the first step is different for each, and starting with the wrong one wastes weeks. For a **known problem**, the first step is analysis: segment the metric, map the process, and isolate where the variation enters. Lean Six Sigma's root-cause tools were built for exactly this situation. For an **unknown problem**, the first step is instrumentation: decide what quantity would prove the problem exists, and start measuring it. Analysis before measurement produces opinions, not findings. The practical method for this is described in [How to find an operational bottleneck you cannot measure](/answers/unmeasured-bottleneck). For a **known symptom with an unknown cause**, the first step is to widen the data: bring in sources the original metric never used — free-text notes, system logs, timing data from adjacent processes — and look for what correlates with the change. This is where AI-assisted pattern detection earns its place, as discussed in [Does Lean Six Sigma still work when AI handles the data analysis](/answers/lean-six-sigma-ai). ## What goes wrong when the type is misread? Treating an unknown problem as known produces a confident project aimed at the wrong metric. Teams optimise the number they have, it improves, and the underlying problem is untouched. Treating a known problem as unknown produces endless discovery. The number was there all along; what was missing was the discipline to trace it. Treating a known symptom as a fully known problem is the most expensive mistake, because the existing data has already been exhausted. Re-analysing it more carefully will produce the same unexplained result. ## What should you bring to a first conversation? Bring the one-sentence statement and whatever number you have, even if you distrust it. Saying which of the four shapes you think it is — and why — will shorten the diagnosis considerably. [How to prepare for a consulting session so it is not wasted](/answers/prepare-for-consultation) covers the rest. ## Related answers - [How to find an operational bottleneck you cannot measure](https://avidproblemsolvers.com/answers/unmeasured-bottleneck) - [How to prepare for a consulting session so it is not wasted](https://avidproblemsolvers.com/answers/prepare-for-consultation) - [Does Lean Six Sigma still work when AI handles the data analysis](https://avidproblemsolvers.com/answers/lean-six-sigma-ai) --- If this is the shape of your problem, one hour is usually enough to find the first move. One hour, $1,199 flat: https://avidproblemsolvers.com/#book