What Problem Does It Solve?
Every technology exists for one problem, and the question that cuts through its feature list is which. Ask it of the tool, then ask whether your system has that problem — and if the two do not match, no amount of the tool's other virtues makes it the right choice.
The situation, the reflex, and why it stalls
Every lesson starts where being stuck starts: someone has a problem, and the first move that comes to mind feels like progress.
Someone proposes a technology and lists its advantages. What single question tells you whether any of those advantages apply to your system?
A colleague proposes moving the store's product search to a dedicated search engine. The pitch is convincing: relevance ranking, typo tolerance, facets, fast. The store's search today is "filter products by name" against the database, and the founder has never complained about it. You cannot say what is wrong with the proposal, and you also cannot say what problem it would fix.
Evaluate the technology on its merits. Is it mature, is it fast, is it well documented, does the team like it. All of those can be answered, and answering them feels like due diligence — and none of them is about the store.
The evaluation concludes that the search engine is excellent, which it is, and the store adopts an excellent solution to a problem it has not been shown to have. The operating cost arrives immediately; the benefit arrives only if the problem was real.
- The evaluation concludes that the search engine is excellent, which it is, and the store adopts an excellent solution to a problem it has not been shown to have. The operating cost arrives immediately; the benefit arrives only if the problem was real.
- Because the question was "is it good?" rather than "what is it for?", the same evaluation would approve almost any well-made tool, and the architecture fills with well-made tools whose problems the store does not have.
- The proposal cannot be argued with on its own terms — every advantage listed is true — so the disagreement becomes about taste or about the colleague, instead of about whether the store's customers cannot find products.
- The real search problems the store does have — that the product name filter is case-sensitive, and that a search for "shoes" misses "trainers" — are never named, because the conversation was about the tool rather than the problem.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Ask, of the technology, the one question its authors would answer first: what problem does this exist to solve? Every mature tool has a one-sentence answer — a search engine exists to rank documents by relevance to a query over text too large or too fuzzy for exact matching. Write that sentence down in the authors' words.
- Ask, of your system, whether it has that problem, in terms of observed behaviour: which user, doing what, currently fails or suffers. "Customers search for shoes and see nothing because the product is called trainers" is a problem; "search could be better" is not. If no observed problem matches the tool's sentence, the tool's other virtues are irrelevant to this decision.
- If the problems do match, ask whether the simplest change to what you already have would solve the observed problem — a case-insensitive match, a synonym list, a database text index — before evaluating the new tool at all. The tool is justified when the simpler thing cannot meet the requirement, not when the tool would also meet it.
- Make "don't over-engineer" falsifiable: a component is over-engineering when it solves a problem the system has not been observed to have. Under that definition the search engine is over-engineering today and may not be next quarter, and the thing to track is the observation, not the opinion.
From the proposal to the requirement
The why ladder is the instrument for this lesson. A proposal is a claim at the top; each "why" descends toward the requirement; the bottom rung is what was actually needed, and it is usually smaller than the claim. The device also names the case where the claim was right, because the question is not "is the tool bad" but "what is it for".
Notice that the descent is about the store at every rung. The tool's features never appear; they cannot, because the ladder asks about need and the features are about capability.
“The store needs a dedicated search engine for product search.”
- ↓Why do we need a search engine? Because product search is bad.
- ↓Why is it bad — what does a customer do that fails? Searching "Shoes" returns nothing, and searching "shoes" misses products named "trainers".
- ↓Why does that happen? The filter is an exact, case-sensitive match on the name column, and there is no notion of synonyms.
- ↓Why is that the requirement rather than relevance ranking? Because no customer has been seen to fail on ranking; the observed failures are case and vocabulary, and the catalogue is small enough that every match can be shown.
the claim was right when The catalogue grows to where showing every match is useless and ranking decides what a customer sees; or searches with misspellings are observed to fail at a rate that matters; or descriptions must be searched and the database's text search is measured to be too slow. Any of those is an observation, and the search engine is the right answer to it.
Two evaluations of the same proposal
The pair below is the proposal evaluated on the tool's merits and evaluated on the store's problem. The first is not careless — it is what most technology evaluations look like. It is simply about the wrong subject.
Mature, well documented, fast, typo-tolerant, faceted, widely used, the team is keen. Verdict: adopt. Every statement is true.
Purpose: relevance over fuzzy text. Observed problem: case-sensitivity and one synonym gap. Simplest fix meets the observed problem. Gap the tool would fill: none observed yet. Verdict: fix the filter, log empty searches, revisit on evidence.
The merits describe what the tool can do for anyone; only the second evaluation describes what it would do for this store. A decision made on merits is a decision that any good tool would win, which means it is not a decision about the store at all.
When purpose and problem drift apart
The question is worth asking again after adoption, because problems change and tools stay. Each row is a way the match between a tool's purpose and the system's problem goes wrong over time, and the response is always to re-ask the question rather than to defend the tool.
| Trigger | Symptom | Cause | Response |
|---|---|---|---|
| A tool is adopted on its merits | Operating cost with no measurable benefit; nobody can say what would break if it were removed | No observed problem was named at adoption. | Name the problem now. If there is none, plan the removal (The Complexity Ledger). |
| The simple fix is extended repeatedly | A synonym table with a stemmer, a ranker and a cache — a worse search engine | The observation that would justify the tool arrived and was not honoured. | Re-read the decision record; the reversal condition was written for this. |
| The problem changes | A tool that solved last year's problem is in the way of this year's | The current system is assumed to be justified by existing. | Ask what problem the current component solves, and whether the system still has it. |
| The purpose question is used as a veto | Proposals stop; problems the questioner cannot see go unsolved | The question was asked rhetorically rather than to be answered. | Ask it with the expectation of an answer, and go and look at the logs when the answer is "I think customers are struggling". |
How to do it
Most important first.
- Find the tool's one-sentence purpose on its own site — the sentence before the feature list — and write it down verbatim (Researching an Unknown Technology).
- Write the observed problem in your system as user, action, failure. If you cannot name a user and a failure, write "no observed problem" and stop; the proposal is filed with the requirement that would revive it.
- Climb the why ladder from the proposal to the requirement: "we need a search engine" → why → "search misses products" → why → "the name filter is exact and case-sensitive". The bottom rung is the real requirement (The Why Ladder).
- Name the simplest change to the existing system that meets the bottom rung, and say what it cannot do. That gap, if any, is the only argument for the tool.
- Write the decision with the observation that would reverse it: "name filter with case-insensitivity and a synonym table; revisit when a measured share of searches return nothing" (The Decision Journal).
Worked on a concrete problem
The move has to produce something. This is what it produced.
- The search engine's purpose: rank documents by relevance to free-text queries, with tolerance for typos and vocabulary mismatch, over corpora where exact matching fails. The store's observed problem, once someone looked at the logs: searches for "shoes" return nothing because the products are called "trainers", and searches with a capital letter return nothing at all. Both are real. Both are also fixed by a case-insensitive match and a synonym table in the existing database, which is an afternoon and no new component. The gap the tool would fill — typo tolerance, relevance ranking across descriptions — is not in the observed problems. Decision: fix the filter; revisit when searches with no results are measured, not felt.
- The same question for the analytics dashboard's proposed "streaming pipeline": the tool exists to process unbounded event streams with low latency. The dashboard's observed problem: the nightly report is late on Mondays because the weekend batch is large. Purposes do not match — the problem is a slow batch, not a need for streaming — and the simpler thing is splitting the batch or indexing the query it runs (The Simplest Thing That Could Work).
- A case where the purposes match: the chat app proposes a realtime transport because "polling is wasteful". The tool exists to push messages to connected clients without the client asking. Observed problem: messages appear seconds late and the server logs show most polls returning nothing. The purpose matches the observation; the simpler thing — longer polling intervals — makes the latency worse. The tool is justified, and the justification is written down as the observation, not the slogan (Choosing a Real-Time Transport).
How you know it worked
What now exists that did not before, and what question you can now ask.
- You can state the tool's purpose in one sentence that its authors would recognise.
- You can name a user, an action and a failure in your system — or you have written "no observed problem".
- The simplest change to the existing system has been named and its limit stated.
- The decision carries the observation that would reverse it.
The questions you can now ask
The field this whole domain exists for. After this lesson, these are the questions to put to an unfamiliar problem.
- ?What is the one problem this technology's authors say it exists to solve?
- ?Which user of my system, doing what, currently fails or suffers in a way that matches that sentence?
- ?What is the simplest change to what I already have that would fix the observed problem, and what can it not do?
- ?What observation would make this tool justified next quarter, and am I collecting it?
- ?What problem does the thing I already have solve, and is it still that problem?
What can go wrong
- The purpose question becomes a veto: every proposal is met with "what problem does it solve?" in a tone that means "none", and the team stops proposing. The question is meant to be answered, and sometimes the answer is a real problem the questioner had not seen.
- The observed problem is required to be measured before anything is done, in a system with no measurement. The first step is then to observe — a log of searches with zero results — not to refuse until the observation exists.
- The simplest thing is chosen and then extended until it becomes a worse version of the tool: the synonym table grows a stemmer, then a ranker. The observation that would reverse the decision was written down for exactly this moment; honour it.
- The question is applied to the tool but not to the current system, which is assumed to be justified by existing. "What problem does our current search solve?" is also worth asking.
- Requiring an observed problem before adopting a tool means the tool arrives after the problem has been felt by customers, not before. On problems that are certain to arrive, that is a cost worth naming.
- The simplest change to the existing system is often less pleasant to work with than the tool would have been, and the team pays that daily.
- The purpose question is quick and the observation it demands may not be; a system with no logging cannot answer "how many searches return nothing" without first building the logging.
- "So the answer is always to fix the existing thing." The answer is always to name the problem first. When the problem matches the tool's purpose and the existing thing cannot meet it, the tool is right, and the question got you there faster than the feature list would have.
- "Advantages that are not the tool's core purpose do not count." They count once the core purpose matches. A search engine's facets are a fine reason to prefer it over another search engine; they are not a reason to add a search engine.
- "Observed means measured with numbers." Observed means someone saw a user fail. A support ticket is an observation; a log is a better one; "I think search is weak" is neither.
Where this applies
Problem-solving advice is stated as universal far more often than it is. These labels say what each method is specific to — and where CONTESTED appears, the note gives the strongest form of the opposing view.
- GENERALThe purpose-then-problem question applies to any component, library, pattern or process — including ones proposed by this domain. A decomposition, a canvas or a why ladder also has to solve an observed problem to be worth doing.
- STAGE-SPECIFICOn a greenfield system, some problems are certain enough to be adopted for before they are observed — a payment provider, authentication. The move then becomes stating the certain problem rather than waiting to observe it; in an existing system, the observation is usually available and should be demanded.
- ILLUSTRATIVEThe search engine proposal, the shoes-and-trainers finding and the dashboard's batch are invented to show the shape of the question; the search engine's purpose as stated is the generic one, not any product's marketing.
Where the depth lives
This domain asks the question and hands the answer off by name.
- — The manifesto at /manifesto/delegating: a search engine delegates ranking; deciding what "relevant" means for this store stays yours, and that decision is the requirement the ladder is looking for.