Unknown to Specific Question
The rewriting step itself: how a topic becomes a question your system could ask. Subject, verb, object, the step of the workflow it serves, and the observation that would count as an answer.
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 written down what you do not know and it is a list of nouns. How do you turn each one into a question that can be answered?
The board says: payments, inventory, images, "what if they refresh", sessions. You have been told to sharpen them and you have tried. "How does inventory work?" is the best you have, and it still does not tell you what to go and read.
Search the noun. "Inventory management e-commerce" returns architectures for warehouses you do not have; "payments" returns the provider's marketing page. The results feel like research because they are about the topic.
A noun searched returns the whole field. The results describe every inventory system, so none describes yours, and reading them produces vocabulary without a decision.
- A noun searched returns the whole field. The results describe every inventory system, so none describes yours, and reading them produces vocabulary without a decision.
- The question, if it exists, has no subject. "How does inventory work?" does not say whose inventory, at which moment, doing what — so any answer is correct and none is usable.
- Nothing on the list says which step of checkout needs it. "Sessions" might be a V1 problem or a never problem; without the link to a workflow step there is no way to tell, so it is treated as equally urgent.
- The list is sharpened in your head, where it is sharpened differently each time. The written noun stays a noun, and next week it is searched again.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Give the question a subject that is your system. Not "how does inventory work?" but "what should my checkout do when…". The subject forces the answer to be about a decision you own rather than about the field in general.
- Give it a moment. Unknowns are almost always about a specific point in a workflow: at add-to-cart, at order creation, at payment confirmation, on refresh. Naming the moment shrinks the question to the one branch that matters.
- Give it an observation that would count as an answer. "What should happen when two customers buy the last unit at the same time?" is answered by a sentence describing the end state — one order, one apology — which you can then test for. If you cannot say what an answer would look like, the question is not finished.
- Check that the question is about the main problem, not about the topic. Inventory has forecasting, multi-warehouse allocation and returns; checkout in V1 needs one thing from it — do not sell what you do not have — and the question should be that narrow. Anything else goes on the board as a separate unknown, or as "not V1".
The rewrite, step by step
The pipeline is what "sharpen" means when it is done on paper rather than in the head. Each stage adds one thing to the question; each has a way of failing that leaves the question looking finished.
- 1Capture the vague form
Write the noun exactly as it was said — "inventory".
fails by Tidying it into a fake question on the way to the page.
- 2Add the subject
"What should my checkout do…" — your component, not the field.
fails by "How does inventory work?" — the subject is the world.
- 3Add the moment
"…when it creates an order for the last unit…"
fails by A question that is true at every moment and therefore decides nothing.
- 4Add the property
"…such that we never sell more than we have?"
fails by A question with no property has no wrong answer.
- 5Write the answer shape
"An end state for two concurrent buyers, and the component that enforces it."
fails by Searching before knowing what would count.
- 6Link to the workflow
Order creation, on the core path — so it is answered before payment failure handling.
fails by Every question looks equally urgent.
Three lists become one board
The board below shows the worked examples after the rewrite. Note that one entry merged with another, one was demoted to an assumption, and one produced a hand-off to a different domain — all consequences of giving each noun a subject and a moment.
- ✓Orders capture prices at creation, so a later price change does not alter an existing order.
- ✓The checkout page submits once per click; what happens on refresh is the unknown below.
- ~Customers are logged in, so "sessions" belongs to the auth library and not to this board.
? Inventory.
becomes When two checkouts create an order for the last unit at the same instant, what must the end state be, and which component enforces it?
experiment A stock table with one row; two concurrent decrements in a script; observe with and without a constraint or a lock — see Invariants Under Concurrency.
? What if they refresh. (Merged with: double submit.)
becomes If the checkout request reaches the backend twice, what must the backend hold so that the second is recognised and exactly one order exists?
experiment Replay the same request twice; then add an idempotency key derived from the cart and replay again.
The inventory question is answered in the database domain; this board's job was to produce a question that domain could answer.
Searching the question instead of the noun
A sharpened question changes what search returns. The comparison is the same engineer with the same unknown, before and after — the difference is in what came back and whether it could be used.
Search: "e-commerce inventory management". Results: warehouse systems, demand forecasting, an article on multi-location allocation. Two hours; no decision.
Search: "prevent overselling last item concurrent orders database constraint". Results: a check constraint versus a row lock versus an optimistic version column, with the trade-offs. Twenty minutes; three candidate mechanisms and an experiment to choose between them.
Search matches words, and the question's words — concurrent, constraint, oversell — are the words the answer uses. The noun's words are the words the industry uses to sell things.
How to do it
Most important first.
- Rewrite each noun as "what should [my component] do when [moment], such that [property]?" It will not always fit, but the attempt exposes the missing parts.
- For each question, write the workflow step it serves. If no step needs it, move it to "later" and stop sharpening it.
- Write the shape of an acceptable answer before searching for one — a sentence, a diagram, a number, a yes or no.
- Search the question, not the noun. "webhook confirm payment idempotent" finds the page; "payments" finds the industry.
- Read the question back as if you were the person who would answer it. If you would reply "it depends", say on what, and put that into the question (Question Quality).
Worked on a concrete problem
The move has to produce something. This is what it produced.
- "Inventory" → subject: checkout; moment: when the order is created; property: never sell more than exists → "When checkout creates an order for the last unit and another checkout does the same at the same instant, what must the end state be, and which component enforces it?" Acceptable answer: one order succeeds, one is told the item sold out, and the enforcement point is named. Workflow step: order creation. That question is answered by an experiment with one row and two concurrent decrements — and hands off to the database domain.
- "What if they refresh" → subject: the checkout page; moment: after clicking Pay and before the confirmation renders → "If the customer refreshes between submitting checkout and seeing the confirmation, what does the browser re-send, and what must the backend do so that exactly one order exists?" Acceptable answer: what is re-sent, and a mechanism. Workflow step: checkout submit. The question turned out to be the same as the double-submit unknown from another list, so the two merged.
- "Sessions" → attempted rewrite: "what should the store do when… " — no moment fits, because the assumption "customer must be logged in" makes the session the auth library's problem. Moved to "assumed", not sharpened. Not every noun on the list is an unknown.
How you know it worked
What now exists that did not before, and what question you can now ask.
- Every question has a subject that is a component of your system and a moment in a workflow.
- You can describe what an answer would look like before you have one, which means you can tell a good search result from a bad one.
- Two nouns from different lists have merged into one question, or one noun has split into three. The list is being shaped by the workflow, not by vocabulary.
- Searching the question returns the page rather than the industry.
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 subject of my question — and is it my system or the whole field?
- ?At which moment in which workflow does this unknown actually bite?
- ?What would an answer look like — and would I recognise a wrong one?
- ?Is this one unknown, or three wearing one word?
What can go wrong
- The question is sharpened past the point of usefulness: so specific to today's design that the answer cannot be applied when the design shifts. Keep the property — "exactly one order" — and let the mechanism be the answer, not part of the question.
- Questions are sharpened but never linked to a workflow step, so all of them look equally urgent and the easiest is answered first. The link is what lets you order them.
- The acceptable-answer shape is written so narrowly that the real answer is rejected. "Yes or no" for "should stock be reserved at order time?" misses the answer "reserve with a timeout", which is the right one.
- The exercise is applied to nouns that were never unknowns — things you knew and did not write in the known column. Sharpening those is decoration.
- A sharp question is narrower than the topic, and the narrowing can be wrong: "at order creation" may turn out to be the wrong moment, and the question has to be rewritten. That rewrite is cheap; the vague form was never going to be answered at all.
- Writing the acceptable-answer shape before researching invites confirmation — you find the answer you described. The experiment step exists to catch that.
- "A specific question is a long question." Length is not specificity. "How does my backend confirm a payment?" is short and specific; a paragraph about payments can be vague throughout.
- "Sharpening replaces research." It targets research. The question tells you which section to read and which experiment to run; it does not contain the answer.
- "Every noun on the list must become a question." Some become assumptions, some become "not V1", some were known all along. Sharpening is also sorting.
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.
- GENERALSubject, moment, property and answer-shape apply to any unknown in any domain — a compiler pass, a network protocol, a statistics question. What changes is which domain the answer hands off to.
- SIMPLIFIEDThe "what should [component] do when [moment], such that [property]?" template is a scaffold for the first attempts; real questions outgrow it, and forcing every unknown into it produces stilted questions about things that were never behaviours.
Where the depth lives
This domain asks the question and hands the answer off by name.