Restating the Problem
Say the problem back in your own words — to the requester, to a colleague, to the page — before solving it. The restatement is where misunderstandings surface, and it is the cheapest experiment in the domain.
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.
You think you understand the problem. How do you find out whether you do, before the cost of being wrong is a week of code?
The support lead asks for "a way to see which orders are stuck". You nod; it seems obvious — orders that have not shipped. You are halfway through a query on shipping dates when you wonder whether "stuck" means something else to her.
Solve the version you understood. Asking "what do you mean by stuck?" feels like admitting you did not follow, and the version you understood is concrete enough to build. If it is wrong, she will say so when she sees it.
She will say so when she sees it — after the query, the page and the deployment. The correction that could have taken one sentence now costs the work built on the misunderstanding.
- She will say so when she sees it — after the query, the page and the deployment. The correction that could have taken one sentence now costs the work built on the misunderstanding.
- "Stuck" turns out to mean "paid but not yet acknowledged by the warehouse", a state your query does not distinguish from "shipped late". The page shows the wrong orders confidently, and confidence in a wrong tool is worse than no tool.
- The misunderstanding compounds. The next request builds on the first — "and let me mark them as chased" — and now two features encode a definition of stuck that nobody agreed to.
- You learn nothing about how the support team thinks, which was the most valuable thing the request could have taught you, because the request was never discussed.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Before solving, restate the problem in your own words and check the restatement with whoever gave it to you. Not "so you want a stuck-orders page" — that is their words back — but "you want to see orders where money has arrived and nothing has happened since, so you can chase the warehouse". A restatement that changes the words is a test; one that repeats them is not.
- Make the restatement concrete enough to be wrong. Include an example: "so an order paid yesterday with no warehouse acknowledgement would show, but one that shipped late would not?" The example forces a yes or a no, and the no is the whole value of the exercise.
- Restate at three audiences. To the requester, to catch misunderstanding of intent. To a colleague, to catch misunderstanding of the system — they may know the warehouse acknowledgement is unreliable. To the page, in writing, because the act of writing exposes the gap you would have talked past (Explain It Back).
- Treat a restatement that survives all three as the frame, and one that fails as a gift: it failed in a sentence instead of a sprint, and the correction is now part of the requirement.
A restatement that can be wrong
The text below is the restatement as written before the conversation, with its example, and then the version after the two corrections. The differences are the requirement. Notice that the first version was a reasonable reading of the request, which is exactly why it needed checking.
1BEFORE (my reading)2 "Stuck" = paid, not yet acknowledged by the warehouse within a working day.3 Included: order paid yesterday, no acknowledgement.4 Excluded: order acknowledged and shipped, but late.5 6CORRECTIONS7 Support lead: also "acknowledged, then nothing for days" — a second state.8 Colleague: acknowledgement webhook fails silently sometimes —9 "no acknowledgement" may mean "shipped fine, message lost".10 11AFTER (agreed)12 Two states, shown separately:13 A. paid, no acknowledgement within a working day14 (flag: acknowledgement may be missing, not the order)15 B. acknowledged, no shipment event for several days16 Excluded: shipped late — that is a different report.The before version would have been built confidently and would have been wrong in two ways. Both corrections took one sentence each.
The restatement as a question ladder
A restatement is a question asked of the requester, and it can be vague, better or best like any other. The best form carries an example that forces a yes or no; the vague form cannot be answered with either.
why The best form names a state, an example in and an example out, and the purpose. The requester can say "yes, and also…" or "no, because…" — either answer is a requirement. The vague form gets a nod, which is worth nothing.
How restatements fail, and what each failure means
A restatement that fails is the move succeeding. The table lists the kinds of failure, what each reveals, and what to do with it. The last row is the case where the restatement itself was the problem.
| Trigger | Symptom | Cause | Response |
|---|---|---|---|
| Requester says "yes, and also…" | A second case appears that the request did not mention. | The request named the common case; the requester's model had more. | Add the case to the requirement with its own example; ask whether there is a third (Missing Requirements). |
| Requester says "no, because…" | Your reading was a different problem. | A word meant something specific to them and something general to you. | Take their example as the definition; restate again with it. |
| Colleague adds a constraint | The data you planned to use is unreliable, or the state you named is not recorded. | System knowledge the requester could not have had. | Add the constraint to the requirement; it usually changes the design more than the request did. |
| Requester says "yes" too quickly | Nod without engagement. | The restatement had no example, or repeated their words. | Restate with a concrete in-and-out example and wait. |
| Requester cannot answer | "I'm not sure what I mean." | The request was a symptom of a problem they have not framed either. | Step back to the goal: what were they trying to do when they hit this? (What Am I Actually Trying to Achieve?) |
How to do it
Most important first.
- After any request, say "let me check I have this" and restate it with different words and one concrete example. Wait for the correction; there is usually one.
- Write the restatement down as the first line of the ticket or the notebook entry, with the example, so the agreed meaning is recorded and not just remembered (The Engineering Notebook).
- Restate to someone who knows the system but not the request. Their questions — "which acknowledgement?" — are the system-level misunderstandings the requester could not catch.
- When the restatement fails, do not defend the original understanding; ask what the example should have been. The requester's example is the requirement (Example-Driven Thinking).
- Restate again when the problem changes shape mid-build. The first restatement was true of the first version of the request.
Worked on a concrete problem
The move has to produce something. This is what it produced.
- "A way to see which orders are stuck." Restated: "orders where payment has arrived and the warehouse has not acknowledged them within a working day, so you can chase the warehouse — an order that shipped late would not count." Support lead: "yes, but also ones the warehouse acknowledged and then nothing for three days — those are the ones I lose." Two states, not one, and the second was invisible in the original request. The query changed before it was written.
- The colleague restatement. "So I am going to find orders with a payment and no warehouse acknowledgement." Colleague: "the acknowledgement is a webhook that fails silently about a tenth of the time — you will show orders as stuck that shipped fine." The requirement gained a line — "flag acknowledgement-missing separately from not-yet-shipped" — from one sentence to someone who had never seen the request.
- The AI assistant version. Request: "make the assistant answer HR questions." Restated: "when an employee asks about leave, pay or policy, the assistant answers from the HR wiki and cites the page — and when the wiki does not cover it, it says so rather than guessing." Requester: "yes — and it must never quote salary bands, even though they are on the wiki." The restatement surfaced a hard exclusion that no amount of building would have.
How you know it worked
What now exists that did not before, and what question you can now ask.
- The restatement uses different words from the request and contains a concrete example, and the requester has said yes or corrected it.
- At least one thing you believed about the request has changed as a result — a second state, an exclusion, an unreliable input.
- The agreed meaning is written at the top of the work, not held in memory.
- A colleague who knows the system has heard the restatement and either nodded or added a constraint.
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.
- ?Can I say this problem back in different words, with a concrete example that would be included and one that would not?
- ?Who could tell me my restatement is wrong — the requester, a colleague who knows the system — and have I asked them?
- ?What did the restatement change about the requirement, and is that written down?
- ?Has the problem changed shape since I last restated it?
What can go wrong
- The restatement is the request repeated. "So you want to see stuck orders?" cannot be corrected because it contains nothing to correct. Change the words, add an example.
- The restatement becomes an interrogation. Five rounds of "so what you really mean is" exhausts the requester and teaches them to send requests through someone else. One good restatement with an example is usually enough.
- The restatement is done and then ignored. The correction is heard, and the query built anyway on the original understanding, because it was already half-written.
- Restating problems that were stated precisely. A ticket with an example and an expected result is already a restatement; asking the reporter to confirm it wastes their time and your credibility.
- Restating costs a conversation, and some requesters experience it as friction: they said what they wanted, why are you saying it again?
- A restatement with an example commits you to a definition, and definitions get argued about — the argument you are having now is one you would otherwise have had after building.
- The colleague restatement takes their time as well as yours, and on a small change the constraint they would have added is not worth the interruption.
- "Restating is for when I am confused." It is most valuable when you are confident, because confident misunderstandings are the ones that get built. The confused engineer asks anyway; the confident one needs the habit.
- "The requester should have been clearer." They were as clear as their own model allowed. "Stuck" was one word to them because they see the warehouse flow every day; the restatement is how their model reaches you.
- "A written spec makes restating unnecessary." A spec is one restatement, by one author, unchecked. Reading it back with an example still finds the gaps, because the spec author had a model too.
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.
- GENERALAny request from any source can be restated with an example; the audiences change — a caller, a product owner, a ticket reporter — and the move does not.
- TEAM-SPECIFICOn a team with a shared vocabulary and long history, most restatements confirm; the move is still worth one sentence. With a new stakeholder, a new domain or a new team, restatements fail often, and the move should be a reflex until the vocabulary is shared.
- ILLUSTRATIVEThe support lead, the warehouse acknowledgement failure rate and the salary-band exclusion are invented to show what a restatement can surface; no real operation is described.
Where the depth lives
This domain asks the question and hands the answer off by name.
- — The manifesto's /manifesto/review page applies the same discipline to an LLM's answer: explain it back before accepting it. Restating a request is the same move, one step earlier.