Questions That Reduce Uncertainty
Among all the questions you could ask, the one worth asking next is the one whose answer removes the most uncertainty per hour spent — and a question is an experiment, with a cost, an expected answer, and a decision that depends on it.
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 have many open questions and limited time — which one do you ask next, and how do you know it was worth asking?
The unknowns board for the store has a dozen sharpened questions on it and each one is a legitimate afternoon. You start at the top because it is the top. Three afternoons later you know a great deal about image storage and nothing about whether the payment design is right, and the payment design is what everything else depends on.
Answer them in order, or answer the ones you know how to answer. Both feel productive: the board gets shorter, and a shorter board looks like less uncertainty.
The board shrinks from the easy end. Questions whose answers change nothing get answered first because they are pleasant, and the question whose answer could invalidate the design waits — until it is on the critical path and there is no time for the answer to be "no".
- The board shrinks from the easy end. Questions whose answers change nothing get answered first because they are pleasant, and the question whose answer could invalidate the design waits — until it is on the critical path and there is no time for the answer to be "no".
- Answers arrive without a use. "Object storage is cheaper than serving images from the server" is now known, and no decision was waiting on it, so it is filed. Knowledge with no pending decision is the most respectable form of wasted time.
- Uncertainty is measured by the length of the list rather than by what the list contains. Eight small answered questions feel like progress; the one unanswered question that could still change the data model is the whole of the remaining risk.
- When the big question is finally asked, it is asked without a prediction, so the answer cannot surprise you and nothing is learned from it beyond the fact itself.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Treat each question as an experiment and ask of it the same three things: what will it cost to answer, what do I expect the answer to be, and what decision changes depending on it? A question with no dependent decision reduces no uncertainty that matters — however interesting — and a question whose answer you can already predict with confidence reduces little.
- Rank by information per hour. The question worth asking next is the one where you are least sure of the answer, the answer would change the most, and finding out is cheap. Uncertain, consequential and cheap beats certain, consequential and expensive — and both beat uncertain, inconsequential and free.
- Write the prediction before asking. The value of an answer is the gap between what you expected and what you got; a question asked without a prediction cannot surprise you, and an answer that could not have surprised you was not worth an afternoon (Prediction Before Execution).
- After the answer, do the thing that depended on it — immediately, while the dependency is fresh. Then re-rank: the answer usually collapses some questions, splits others and creates one or two that did not exist. The board is a living ranking, not a queue.
A question is an experiment
The pipeline below is what happens to one question when it is treated as an experiment rather than a reading assignment. Each step has a way of failing that looks like the step succeeding; the right-hand column names it.
The step that gets skipped is the prediction. It costs one line and it is the only step that turns an answer into learning; without it the answer is a fact you now possess and nothing else.
- 1Name the dependent decision
Says which design, table, endpoint or state waits on the answer
fails by Writing "the architecture" — everything depends, so nothing ranks
- 2Estimate the cost
Minutes, an afternoon, a spike with a stub provider
fails by Pretending the expensive one is cheap because it is interesting
- 3Write the prediction
One line: "I expect the provider calls my backend directly"
fails by Writing it after the answer, from memory
- 4Answer it
The smallest observation that settles it — a log line, a test call, one documentation page
fails by Reading the whole section because the page was found
- 5Compare and decide
Gap between prediction and answer becomes the finding; the dependent decision is made now
fails by Filing the answer and moving to the next row
- 6Re-rank
Kill questions the answer settled; add the ones it raised
fails by Working down the original list
The loop is Experiment Design applied to questions; the difference is only that the apparatus is often a documentation page rather than code.
Why "read everything first" fails the ranking
The most common alternative to ranking is the claim that reading the provider's documentation end to end will answer every question at once. The ladder takes that claim apart. What was actually needed was the answer to one consequential question, and the simpler thing is to read the one page that answers it — while noting honestly when the whole-manual reading is right.
“I need to read the provider's whole documentation before designing checkout.”
- ↓Why the whole documentation? Because I do not know which parts matter and I do not want to miss something important.
- ↓Why would missing something matter? Because the order and payment design might be wrong and I would have to redo it.
- ↓Which part of the design could the documentation make wrong? Whether the provider confirms to my backend, and whether that confirmation can repeat or arrive early — that is what the order state depends on.
- ↓Why not read that part? It is one page on the integration flow and one on webhooks; everything else is about features V1 does not use.
the claim was right when The store is the team's core business and this provider is a long-term dependency: a full read is then an investment in the boundary you will live with, and "what features exist that we have not thought of" is itself a consequential question. Also when the documentation is short enough that reading it costs less than ranking it.
One order for the board, and another
Ranked, the store's board yields an order of questions. It is one defensible order; the device names another and when you would prefer it.
- 1Does the provider confirm to my backend, and can the confirmation arrive early or twice?
because Least confident, heaviest dependency (order state, webhook endpoint, table constraints), cheap in test mode.
- 2Does the cart belong to a session or an account, given guest checkout?
because Decides the cart schema; medium confidence; answered by one conversation with the founder.
- 3Is a pattern query fast enough for name search on the real catalog?
because Cheap, medium confidence, decides whether a search engine is even discussed for V1.
- 4What happens when two customers buy the last unit?
because Consequential, but the answer is well known (Invariants Under Concurrency) and the experiment can wait until the checkout slice exists.
- 5Object storage or server for images?
because Crossed out: high confidence, nothing in V1 depends on it.
How to do it
Most important first.
- Next to every question on the board write three columns: cost (how long to answer), confidence (how sure you already are), and depends (which decision or design waits on it). Leave "depends" blank rather than inventing something; a blank is the finding (The Unknowns Board).
- Cross out — do not delete — every question with a blank in "depends". They may matter later; they do not reduce uncertainty now.
- Among the rest, pick the one you are least confident about that is cheap to answer and has the heaviest dependency. Ties go to whichever answer, if it came back "no", would change the most.
- Write your predicted answer in one line before you research, run the experiment or ask anyone (Experiment Design).
- Answer it. Compare with the prediction. Make the dependent decision. Re-rank the board — this is the step people skip, and it is where the second-best question gets chosen correctly.
Worked on a concrete problem
The move has to produce something. This is what it produced.
- Store board, ranked. "Does the provider confirm to my backend, or only to the browser?" — cost: one test-mode payment with logging; confidence: low; depends: whether the order needs a pending state and a webhook endpoint at all. "Should images live in object storage?" — cost: an afternoon; confidence: high (yes); depends: nothing in V1, the catalog serves from anywhere. "Is a pattern query fast enough for name search?" — cost: minutes on the real table; confidence: medium; depends: whether V1 needs a search engine. Ranking: payments first, search second, images crossed out. The board was ordered by the afternoon count before; now it is ordered by what the answers decide.
- Prediction written for payments: "The provider calls a URL of mine with the verdict; the browser is also told, but I should not trust it." Result: correct in shape, wrong in one detail — the callback can arrive *before* my own request to the provider returns. The gap between prediction and result is the finding: the order must be created before payment is attempted, and the webhook must tolerate arriving first. Neither was on the board; both are now, and the data model changed before any code depended on it.
- Re-ranking after the answer: "what if the confirmation arrives twice?" is now the top question, because the webhook exists in the design and its idempotency decides the order table's constraints. It was not on the board at all when the afternoon started (Duplicate Requests).
How you know it worked
What now exists that did not before, and what question you can now ask.
- The board has a column that says what waits on each question, and some rows have nothing in it and are crossed out.
- You can say, for the question you are about to ask, what you expect the answer to be and what you will do if it is the opposite.
- Answers are followed within the hour by a decision, a design change or a new question — not by a note.
- The question that could invalidate the design was asked while it was still cheap for the answer to be "no".
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.
- ?Which decision is waiting on this answer — and if none, why am I asking?
- ?What do I expect the answer to be, and what would I do if it were the opposite?
- ?Which open question would change the most if its answer were "no", and how cheaply can I find out?
- ?After this answer, which questions on the board are now dead, and which new ones exist?
What can go wrong
- Ranking becomes the activity. The board is scored, re-scored, colour-coded, and nothing is asked. The ranking exists to pick *one* question; it should take minutes, and the minutes are recovered by not answering the wrong question.
- Everything depends on everything. "Depends" is filled in for every row with "the architecture", and the column cannot rank. Be specific: which table, which endpoint, which state. If the honest answer is "I do not know what depends on this", that is the question to ask.
- Confidence is faked. A question is marked "already sure" because the answer would be uncomfortable, so it is never asked. The questions people are most sure of, without evidence, are the ones most worth a cheap test.
- Predictions are written after the answer. It happens quietly — you read the answer, then "recall" that you expected it. Write it down first, in ink, or the gap you learn from disappears.
- Ranking by consequence sends you to the hardest questions first, which is the point and is also the least pleasant afternoon on the board. Momentum from easy answers is real, and this move spends it.
- A crossed-out question is one you deliberately do not know the answer to. Sometimes it comes back at a worse moment than the afternoon it would have cost — that is the bet, and it is usually right, and not always.
- Predictions cost honesty. Being wrong in writing, repeatedly, is what makes the move work and is why people stop doing it.
- "Information per hour means always ask the cheap questions." No — cheap and inconsequential is the bottom of the ranking. The unit is uncertainty removed *for a decision that matters*, divided by cost; a cheap question that decides nothing scores zero.
- "This is risk-first development." It is the same instinct one level down: Risk-First Development orders what to *build*; this orders what to *ask*, and asking is usually cheaper than building, which is why the question is often the better experiment.
- "Once ranked, work down the list." The ranking is valid until the first answer, and rarely after it. Re-rank every time; the second question is chosen by what the first one taught.
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.
- GENERALRanking questions by dependent decision, prior confidence and cost applies to any investigation — a debugging session, a technology evaluation, a research plan; the "decision" is what changes across them.
- CONTESTEDA strong opposing view: on a greenfield project you do not yet know what depends on what, so ranking by consequence is ranking by guess, and it is better to answer several cheap questions quickly to *build* the map of dependencies before trying to rank by it. Proponents of breadth-first exploration argue the expensive consequential question is often mis-specified until the cheap ones are done. The synthesis most teams land on: a short breadth pass, then rank.
- ILLUSTRATIVEThe dozen-question board, the three afternoons and the specific ranking are invented to show the shape of the move; a real board's ranking depends on what the team already knows.
Where the depth lives
This domain asks the question and hands the answer off by name.
- — The manifesto's "Debug without AI" route at /manifesto/without-ai applies the same rule to debugging probes: the probe worth running is the one that could still surprise you.