The Unknowns Board
The board as a working document: four columns — Known, Unknown, Assumed, Need to verify — kept for the life of the feature, with the rules for what moves between columns and when. The lab at /thinking/unknowns is this board with a question assessor attached.
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 learned to sort, sharpen, experiment and hunt for missing unknowns. How do you keep all of that in one place that stays true as the feature is built?
You sorted checkout on Monday. By Thursday the payment experiment has answered one question and raised two, the founder confirmed one assumption and reversed another, and the board from Monday is a photo of a problem that no longer exists. You have stopped looking at it.
Keep it in your head. You know what you know; writing it down again feels like admin, and the board was useful once, as a kickoff exercise. It feels efficient.
Your head holds the current state and none of the history, so when the assumption reverses — guest checkout is now required — nobody can say what was built on top of the old one. The board would have.
- Your head holds the current state and none of the history, so when the assumption reverses — guest checkout is now required — nobody can say what was built on top of the old one. The board would have.
- Unknowns answered in your head are answered by whatever you last read, and the answer is not tested against the question, because the question is not written anywhere to test against.
- A colleague joining on Thursday gets Monday's board and a verbal patch. They rebuild the cart on the reversed assumption.
- When something goes wrong in production, the question "did we know about this?" has no answer — which means the process cannot be improved, only the incident survived.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Treat the board as the feature's state, not its kickoff. Four columns: Known — could build and predict the test. Unknown — vague form, specific question, experiment, status. Assumed — the belief, who could confirm, what changes if false. Need to verify — a belief with a reason to doubt, and the check that would settle it.
- Define the moves between columns and make every move an event with a date. Unknown → Known when an experiment produced a fact (and the fact is written). Assumed → Known when the owner confirmed it. Assumed → Unknown when the owner reversed it and the consequence is not yet understood. Need to verify → Known or Unknown after the check. Known → Need to verify when production disagrees.
- Review it at a fixed moment — the start of each working session is enough — and ask one question: what is the next thing to build from Known, and the next thing to answer from Unknown? If the board cannot produce both, it is stale, and updating it is the first task.
- Let it shrink. A board that only grows is a backlog. Answered unknowns move to Known and, once built, leave the board; assumptions that were confirmed and built leave too. What remains is the live uncertainty, and its size is an honest measure of how understood the feature is (The Engineering Notebook).
The board on Thursday
The same checkout feature as Known and Unknown, four days later. Everything that moved carries a date and a reason. Read the Need to verify column first: that is where a Known became uncertain again, which is the column the kickoff version of the board does not have and the working version cannot do without.
1KNOWN2- order from cart, status pending (built Mon)3- paid only from verified webhook, keyed on event id4 (Unknown -> Known Tue; fact: arrival order unguaranteed, resend shares id)5- one currency (Assumed -> Known Mon, founder)6 7UNKNOWN8- stock hold for unpaid orders status: answered Thu — one hour, founder9 specific: how long does a pending order hold stock, who releases it?10 experiment: create order, never pay, watch stock table11- guest cart identity status: open (from Need to verify, Thu)12 specific: what identifies a guest cart across refresh and login,13 such that nothing is lost at either?14 experiment: create cart as guest, log in, observe15- dispute handling status: abandoned for V1 Wed — log + alert16 17ASSUMED18- refunds by hand in provider dashboard (V1) owner: founder if false: refund workflow19 20NEED TO VERIFY21- guest checkout now required (reversed Wed) — what was built on "logged in"?22 check: grep cart for user id -> cart keyed on user id -> new Unknown aboveEvery line that moved says when and why. "Abandoned" is written as a decision, not hidden as "researching".
The moves between columns
The board is defined by what is allowed to move where. The diagram is the rule set; each edge is an event with a date, and the edge from Known back to Need to verify is the one that makes the board a living document rather than a kickoff artefact.
The session ritual, as an order
The board earns its upkeep by producing the session's first two items. The order below is one way to run the first ten minutes; the alternative is for teams whose board is reviewed collectively.
- 1Read Need to verify; run any check that takes under a minute
because A Known that production has doubted is the most dangerous thing on the board; settling it first prevents building on it today.
- 2Move anything that changed since last session, with a date
because Answered unknowns and confirmed assumptions are facts now; leaving them in the wrong column makes the board lie about what is safe to build.
- 3Pick one build item from Known
because Progress on the main problem, chosen by the board rather than by what the code makes easy.
- 4Pick one research item from Unknown — the one most likely to reshape what you are building
because Research runs in parallel with the build; choosing by reshaping risk keeps the rewrite small.
- 5Mark anything "researching" for too long as abandoned or open, honestly
because A stale status hides an unknown as effectively as not writing it.
How to do it
Most important first.
- Keep the board as text in the repository, next to the feature, so it is diffed and reviewed like code.
- For every unknown, keep four fields: vague, specific, experiment, status. Status is one of: open, researching, answered (with the fact), abandoned (with why).
- Date every move between columns. The dates are the history that "in my head" throws away.
- Start each session by producing one build item and one research item from the board. Do not start with the code.
- When production surprises you, add the surprise to Need to verify before fixing it, then trace which column it should have been in. That trace is how the next board gets better (Unknown Unknowns).
Worked on a concrete problem
The move has to produce something. This is what it produced.
- Thursday's board. Known: order from cart; paid from verified webhook keyed on event id (moved from Unknown on Tuesday, fact: arrival order unguaranteed, event id deduplicates). Unknown: stock hold duration for unpaid orders (open — founder question sent); dispute handling (abandoned for V1 — log and alert, decided Wednesday). Assumed: one currency (confirmed Monday). Need to verify: guest checkout now required (reversed Wednesday) — what did we build on "logged in"? Answer, after a check: the cart is keyed on user id. That is a Known that became an Unknown: "what is the cart keyed on for a guest?"
- The session ritual on Friday. From Known: build the stock-release timeout, since the founder answered "an hour". From Unknown: the guest-cart key question, sharpened to "what identifies a guest's cart across a refresh and a login, such that nothing is lost at either?" with an experiment: create a cart as a guest, log in, observe. Both items came from the board in under five minutes; neither would have been the obvious next thing from the code alone.
- The colleague who joined Thursday read the board, saw the reversed assumption with its date, and did not build on it. The board cost fifteen minutes of updating that week and saved a rebuild.
How you know it worked
What now exists that did not before, and what question you can now ask.
- The board is in the repository and has a diff history; you can see which day an assumption reversed.
- Each session produces a build item and a research item from the board before any code is touched.
- The board is shrinking. Items leave it when built; what remains is genuinely open.
- A production surprise can be traced to a column it should have been in — or to "genuinely new", which is now rare.
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 next thing to build from Known, and the next thing to answer from Unknown — today?
- ?Which assumption, if reversed tomorrow, would invalidate the most built code?
- ?Which unknowns have been "researching" long enough that they are really abandoned?
- ?When production surprised us, which column should the surprise have been in?
What can go wrong
- The board becomes a document to maintain rather than a tool to use — formatted, reviewed in meetings, and consulted by nobody when choosing the next task. If it does not produce the session's work items, it is decoration.
- It never shrinks. Everything ever unknown stays on it, answered items are annotated instead of removed, and after a month the live uncertainty is invisible in the archive.
- The status field lies. "Researching" for three weeks means "abandoned without admitting it"; write abandoned and the reason, so the next person does not restart it.
- Kept in one person's head after all, with the board as an occasional export. The moment it is not the source of truth it stops being consulted, and the failure mode from the reflex returns.
- Fifteen minutes a week of upkeep, forever, for the life of the feature. On a feature that takes two days that is overhead, and the board can be a page that is written once and thrown away.
- A board in the repository is visible, which invites comments on assumptions the founder would rather not have written down. That is the point, and it is also a cost.
- Removing built items loses the visible record of how much was learned. If that record matters — for a retrospective, for a junior's progress — archive rather than delete, at the cost of the shrinking signal.
- "The board is a project-management tool." It is a thinking tool that happens to produce tasks. A ticket tracker holds work; the board holds uncertainty, and the two should point at each other rather than merge.
- "Once the feature ships, the board is done." Production is the largest experiment, and Need to verify fills from it. The board is done when the feature is stable, not when it is deployed.
- "One board for the whole system." A board per feature or per slice is readable; a board for the store is a backlog with columns.
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 and dated moves work for a feature, a migration, an incident investigation or a research project; the column names are stable and the move rules are the same.
- SCALE-SPECIFICA solo engineer on a small feature can keep the board as a page in a notebook and throw it away at the end; a team on a multi-week feature needs it in the repository and reviewed, because the board is how new members avoid building on reversed assumptions. Past a certain team size the board fragments into per-slice boards and a risk register, and the move rules above are what keep those consistent.
- ILLUSTRATIVEThe Thursday board, the reversed guest-checkout assumption and the fifteen minutes a week are invented to show the board's shape over time.
Where the depth lives
This domain asks the question and hands the answer off by name.
- — The Engineering Notebook at /thinking/notebook keeps the same columns alongside decisions and experiments; the manifesto's /manifesto/layers page is the reason the board should also record which layer each fact came from.