Known and Unknown
Before the unknowns can be worked on they have to be separated from what you know and from what you are merely assuming. The board with four columns — known, unknown, assumed, need to verify — is the first hour of any problem you have never seen.
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 a problem you half understand. How do you find out which half, so the next hour goes on the half you do not?
The checkout feature is yours. You know what a cart is and how to write an endpoint. Payments, stock reservation and "what happens if the customer refreshes" are all somewhere between "I have read about it" and "no idea", and every time you start on the endpoint one of them surfaces and you stop.
Read until it feels solid. Open the provider's documentation, a blog post about inventory, a thread about double submits, and keep reading until the anxiety fades. It feels responsible: nobody can accuse you of not doing your homework.
Reading with no question produces the feeling of understanding and no test of it. Three hours later you can describe a payment intent and still cannot say what your backend has to do when the provider's confirmation arrives twice.
- Reading with no question produces the feeling of understanding and no test of it. Three hours later you can describe a payment intent and still cannot say what your backend has to do when the provider's confirmation arrives twice.
- Because the unknowns were never written down, they cannot be distinguished from assumptions. "Stock is reserved at checkout" was never checked with anyone; it was read in a tutorial, and it is now load-bearing.
- The things you did know were not written down either, so they get re-derived every session. The known half of the problem is re-read instead of built.
- The endpoint is still not written, and the reason is not any single unknown — it is that the unknowns have no edges, so there is no order to answer them in.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Split the problem into what you know, what you do not know, what you are assuming, and what you believe but need to verify — as four written lists, not as a mood. "Know" means you could build it today and predict what the tests would show. "Assume" means you are treating it as true without having checked. "Need to verify" means you have a belief and a reason to doubt it.
- Be strict about the known column. Something you have read about but never built goes in unknown; something you built once in a different system goes in "need to verify". The column is about your ability to act, not about familiarity.
- Every entry in the unknown column then has to become a question with a verb and an experiment — that is Unknown to Specific Question and Unknown, Question, Experiment. This lesson's job is smaller: get the columns right, because the wrong column costs the most. An assumption filed as known is the one that breaks in production.
- Return to the known column and start building from it. The board exists so that the known half of the problem gets built while the unknown half gets researched, in parallel, instead of the whole problem waiting on the hardest part.
The four columns, filled in
The board below is checkout after the sort. The unknown column already carries the sharpened question and the experiment for each item, because a board that stops at the vague form is a worry list; the lessons that follow explain how each transformation was made. What matters here is the placement.
Look at what is in "assumed" and "need to verify". Neither is an unknown — the engineer has a belief — but both are things a board without those columns would silently have promoted to known.
- ✓The cart holds product ids and quantities and can compute a total from current prices.
- ✓An order row can be created from a cart, with the items and prices captured at that moment.
- ✓A confirmation page can render an order by id.
- ~One currency in V1.
- ~A customer must be logged in to check out — guest checkout would change the cart's shape, so this needs the founder's answer before the cart is built.
? Payments.
becomes What requests does my backend send to the provider to start a payment, and by what path does it learn that the payment succeeded?
experiment One endpoint that creates a test-mode payment and one that logs whatever the provider sends back, with no store around them.
? Double submit.
becomes If the same checkout request reaches the backend twice, what must be true afterwards — one order or two — and what does the backend need in order to tell the second one is a repeat?
experiment Send the same request twice with a script; observe the database; then add an idempotency key and observe again.
? Stock.
becomes Is stock decremented when the order is created or when payment succeeds, and what happens to the reservation if payment fails?
experiment Draw both timelines for one unit and two customers; the drawing decides before any code does.
"Need to verify: the provider has a test mode without a business account" is not on this board because verifying it took five minutes on the pricing page. That is the right amount of ceremony for that column.
Why the columns are not a mood
The reflex reads until the problem feels understood. The move replaces the feeling with a test. The comparison below is the same engineer, same problem, before and after asking the only question that decides a column: could I build it and predict the test?
Payments: known. I have read the provider quick-start, watched a walkthrough, and could explain a payment intent to a colleague.
Payments: unknown. I cannot say what my endpoint receives when the payment succeeds, nor what to do if it receives it twice. Question: by what path does my backend learn that a payment succeeded? Experiment: a logging endpoint and one test-mode payment.
Familiarity predicts nothing about whether you can build it. The known column drives what you build first, so an entry that is only familiar puts the hardest unknown on the critical path disguised as the easy part.
The first build and the first research, on the same day
The board pays for itself when it produces two work items rather than one: something to build from the known column and something to research from the unknown column. The sequence below is one way to order them; the alternative is the risk-first order the CONTESTED scope describes.
- 1Order-from-cart with status "pending", no payment
because Entirely in the known column; it produces a real order row the payment work can later attach to.
- 2Payment probe: create a test-mode payment, log the confirmation
because The unknown whose answer most likely changes the order code — where "paid" is decided — gets an experiment before that code is written.
- 3Ask the founder about guest checkout
because An assumption that changes the cart's shape is cheaper to check than to build around.
- 4Double-submit experiment against the pending-order endpoint
because Now there is a real endpoint to send the same request to twice, so the experiment is cheap and concrete.
How to do it
Most important first.
- Write the four column headings and force every noun in the task under one of them. If a noun does not fit anywhere, it is a heading, not a thing — decompose it first (Decomposing a Problem).
- For each item in "known", write the test you would expect to pass. If you cannot, move it.
- For each item in "assumed", write who could confirm it and what changes if it is false (Making Assumptions Explicit). An assumption whose falsity changes nothing can stay assumed.
- For each item in "unknown", write the vague form as it was first said. Sharpening comes next; capturing the vague form first stops the item from disappearing.
- Pick the first thing to build from the known column and the first thing to research from the unknown column, and do them today. The board is not finished until both have been chosen.
Worked on a concrete problem
The move has to produce something. This is what it produced.
- Checkout, sorted. Known: the cart's contents and total; creating an order row from a cart; returning a confirmation page. Unknown: how the backend starts a payment and learns that it succeeded; what to do when the same checkout request arrives twice; whether stock is decremented at order time or payment time. Assumed: one currency; a customer must be logged in. Need to verify: that the provider supports a test mode without a business account — remembered from a previous job, possibly out of date.
- The column that moved most was "known". "Payments" had been sitting there because the provider's quick-start had been read twice. The test question — "what would I expect to see when the confirmation arrives?" — could not be answered, so it moved to unknown and became the first research item.
- The first build from the known column: order created from cart, no payment, status "pending". The first research item: one endpoint that starts a test-mode payment and one that logs whatever the provider sends back. Both fit in an afternoon and neither waits for the other.
How you know it worked
What now exists that did not before, and what question you can now ask.
- There is a page with four columns, and the known column contains only things you could build and predict the tests for.
- At least one item moved out of "known" when you tried to write its test. If nothing moved, either you understood the problem already or the test question was not asked honestly.
- You have started building from one column and researching from another on the same day.
- Someone reading the assumed column can tell you which entries are wrong — which is the point of writing them where they can be seen.
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 of these things could I build today and predict the test for — and which am I only familiar with?
- ?What am I treating as true that nobody has confirmed, and what changes if it is false?
- ?What is the first thing I can build from what I know, while the first unknown is being researched?
- ?Which unknown, if it turned out badly, would change the design of the parts I already know?
What can go wrong
- The board becomes the work. Forty entries, colour-coded, revised daily, and the endpoint still not written. The board is a map for choosing today's work; when today's work is obvious, close it.
- Everything goes in "unknown" out of modesty. That makes the board useless in the other direction: nothing is safe to build, so nothing is built. Be honest about what you can do.
- Assumptions are filed and then treated as decisions. "Assumed: one warehouse" was written to be checked, not to be built on for six months without anyone asking the founder.
- The board is done once and never revisited. Answering one unknown usually produces two more and promotes one assumption; a board that does not change is a board nobody is using.
- Sorting takes an hour that could have gone on the endpoint. On a problem you genuinely understood, that hour was pure cost.
- Moving items out of "known" is uncomfortable, and a board written for a manager's eyes will lie about it. The board only works if it is allowed to be embarrassing.
- Building from the known column while an unknown is open means some of what you build may have to change when the unknown resolves. That is usually cheaper than waiting, but not always — see the CONTESTED scope.
- "So I should not start until the unknown column is empty." No — you should start from the known column immediately. The board exists so that unknowns stop blocking the known work, not so that they block it more formally.
- "Known means I have read about it." Known means you could build it and predict the test. Reading moves things from unknown-unknown to unknown; only building or experimenting moves them to known.
- "Assumptions are bad." Assumptions are how V1 gets built at all. The failure is an unwritten assumption, not an assumption.
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.
- GENERALFour columns apply to any problem with a learning component — a feature, a migration, a bug, a new codebase. The column names change nothing; the discipline of testing "known" against "could I build it and predict the test" is what transfers.
- CONTESTEDSome practitioners argue that building from the known column before the biggest unknown is resolved is exactly the waste the board should prevent: if the payment integration forces a hosted checkout page, the order and confirmation code written in the meantime is thrown away, and a risk-first approach — resolve the unknown that could reshape the design, then build — costs less overall. The reply is that most unknowns do not reshape the design and the ones that might can be identified on the board and researched first; the disagreement is about how often "might" turns out to be "did".
- ILLUSTRATIVEThe checkout board, the provider quick-start read twice and the afternoon of work are invented to show the shape of the sort; no real project is being described.
Where the depth lives
This domain asks the question and hands the answer off by name.
- — The manifesto's delegation cards at /manifesto/delegating are a ready-made "need to verify" column for anything an SDK does on your behalf.