An Unknown Is Not a Blocker
"I don't understand payments" feels like a wall. It is a sentence with no question in it. The move is to ask "what exactly don't I understand?" until the wall becomes "how does a backend initiate and confirm a payment?" — a thing you can go and find out this afternoon.
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 are stuck on something you do not understand. How do you tell whether it is stopping you, or whether you have merely not asked it a question yet?
The checkout endpoint is half written. The next line needs to talk to the payment provider and you have never done that. You have said "I don't understand payments" to yourself twice and to your lead once, and each time it sounded like a reason to work on something else.
Treat the unknown as a gate. Put a ticket on the board called "learn payments", estimate it at a week, and move to the product-search feature in the meantime. It feels prudent — you are not pretending to know something you do not.
The ticket is a noun. "Learn payments" has no end condition, so it cannot be finished, so it stays open, so checkout stays blocked behind it. The search feature ships; the store still cannot take money.
- The ticket is a noun. "Learn payments" has no end condition, so it cannot be finished, so it stays open, so checkout stays blocked behind it. The search feature ships; the store still cannot take money.
- The vague unknown is treated as one thing, and it is not. Inside "payments" are a request to start a charge, a confirmation that arrives later, a failure path and a repeat. Three of those you could have built today; the ticket blocked all four.
- Because the unknown was never made specific, the reading that eventually happens has no target. A week of provider documentation produces familiarity with concepts the store does not use and no answer to the one thing checkout needed.
- Saying "I don't understand X" to a lead invites the reply "OK, learn it" — because the sentence contained nothing they could help with. The specific question would have got a two-minute answer.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Notice the shape of the sentence. "I don't understand payments" names a topic and a feeling. A blocker is something with a specific unmet dependency — a credential not issued, a decision not made. A topic is never a blocker; it is an unknown that has not been asked a question yet.
- Ask "what exactly don't I understand?" and refuse the first answer if it is still a noun. "The API" — what about it? "How it works" — which part, for which step of checkout? Keep going until the answer has a verb, a subject and an object: "how does my backend initiate a payment, and how does it confirm that the payment succeeded?"
- Check the question against the main problem. Checkout needs exactly two things from the provider: start a payment, learn its outcome. Everything else in the documentation — subscriptions, disputes, multi-party payouts — is a different unknown for a different day, and noticing that shrinks the reading by most of its volume.
- Then do the smallest thing that answers the question — read the one section, run the one example — and return to the main problem. The unknown was a detour of a known length, not a wall. Unknown, Question, Experiment describes the detour; this lesson is about seeing that it is one.
From a wall to a sentence
The same need, asked three ways. The vague form cannot be answered by anyone; the better form can be answered by a documentation section; the best form is answered by your own system's point of view and produces a design decision as a side effect.
why The best form names the two actions checkout actually needs, names the candidate paths so the answer can choose between them, and carries the invariant — paid exactly once — that decides which path is authoritative. The better form is answered by a diagram; the best form is answered by a decision you can build.
What blocks, and what does not
Not every "I can't continue" is the same, and the response differs. The decision below is the one to make before opening a ticket: is this a topic, a missing decision, or a missing input?
I cannot write the next line of checkout. Why?
when The sentence names an area — payments, inventory, auth — and contains no question.
cost Sharpen it into a question with a verb; build the lines that do not depend on it; answer it with a small experiment. Cost: an afternoon, in parallel.
when The question is specific — "is stock reserved at order or at payment?" — and the answer belongs to the founder, not to research.
cost Ask the person, offer a default, write the assumption on the board and build to it. Cost: one conversation and one entry in The Assumption Register.
when Credentials, an environment, a data file, an account. No amount of sharpening produces it.
cost This is a real blocker. Chase it, and build with a stub in the meantime (Treating External Systems as What They Are).
The detour has a length
Once the unknown is a question, it stops being an obstacle and becomes a step with a size. The pipeline is the whole detour; the point of the lesson is that it ends where it began — back at the main problem — and that each stage has a way of failing that keeps you on the detour.
- 1Vague unknown
"I don't understand payments." Written down so it does not stay a mood.
fails by Being filed as a ticket named after the topic.
- 2Specific question
"How does my backend initiate a payment and confirm its outcome?"
fails by Stopping at "how do payments work?" — a question mark on a topic.
- 3Research
The two documentation sections that address the two verbs, and nothing else.
fails by Reading the whole reference because it is there.
- 4Tiny experiment
One test-mode payment, one logged confirmation.
fails by Building the full integration "while I am at it".
- 5Understanding
You can predict what your endpoint will receive and when.
fails by Mistaking familiarity with the concepts for the ability to predict.
- 6Return
The one waiting line of checkout is written; the other lines were written meanwhile.
fails by Not returning — the experiment grows into a side project.
The stages are §14 of the domain; the lab at /thinking/unknowns walks the same detour with the question assessor.
How to do it
Most important first.
- When you hear yourself say "I don't understand X", write X down and ask "what exactly?" of it, in writing, until the answer is a question someone could answer.
- Test the question: could a colleague who knows the area answer it in a few minutes? If not, it is still a topic.
- Hold the question up against the feature. Which step of the main workflow needs this answer? If no step does, the unknown is not on the path and can wait.
- Time-box the answer before starting. A specific question has a predictable cost; if you cannot predict it, the question is not specific yet.
- Build the parts of the feature that do not depend on the answer while it is being found. A blocker stops everything; a question stops one line.
Worked on a concrete problem
The move has to produce something. This is what it produced.
- "I don't understand payments." What exactly? "How the provider works." Which part does checkout need? "Starting a payment and finding out whether it worked." So: "how does my backend initiate a payment with the provider, and by what mechanism does it confirm that the payment succeeded?" That question has two halves and a reading list of two pages.
- With the question written, the rest of checkout is unblocked: cart validation, order creation with status pending, the confirmation page keyed on the order id. Only one line — the one that starts the payment — waits on the answer, and it waits an afternoon rather than a week.
- The lead, shown the specific question, answers in one sentence: "start it server-side, confirm it from the webhook, never from the browser redirect." That sentence would never have been offered in response to "I don't understand payments", because there was nothing to answer.
How you know it worked
What now exists that did not before, and what question you can now ask.
- The unknown has become a sentence with a question mark, a verb, and a subject that is your system rather than a topic.
- You can say which single line of the feature depends on the answer, and you are writing the other lines now.
- The time to answer it has an estimate you would defend, and it is measured in hours.
- Explaining what you do not understand to someone else now gets a useful answer instead of "go read about it".
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 exactly do I not understand — and can I say it with a verb?
- ?Which single step of the main workflow needs this answer, and can the other steps be built now?
- ?Could someone who knows this area answer my question in a few minutes — and if not, what would I have to remove from it?
- ?Is this an unknown I can sharpen, or a dependency I have to chase?
What can go wrong
- The sharpening stops one step early: "how do payments work?" has a question mark and is still a topic. The test is whether a specific person could answer it in a few minutes, and nobody can answer that one.
- A real blocker gets mislabelled as an unknown. "I do not have the provider's test credentials" is not a question to sharpen; it is a dependency to chase. The move is for topics, not for missing inputs.
- The question is sharpened and then answered by reading alone. "How does the backend confirm a payment?" has a documented answer and a real one, and they differ in the order and repetition of the confirmations. Reading moves the unknown; the experiment settles it.
- The specific question is found and then treated as the whole of payments. Failures, repeats and refunds are separate unknowns; they are not blockers either, but they are not answered by this question.
- Sharpening takes effort the ticket did not: you have to think about what you do not know, which is harder than noting that you do not know it.
- Building around a question means committing to a shape before the answer arrives. Usually the shape is right; when the provider dictates a redirect flow, part of it is rewritten.
- A specific question can be answered wrongly with confidence. The vague form at least kept you cautious; the sharp form needs an experiment to keep you honest.
- "So unknowns never block." They can — when the unknown is a missing input rather than a missing understanding, or when the answer reshapes the design. The claim is narrower: a topic you have not asked a question of is not yet a blocker, and most of them never become one.
- "Just push through and figure it out." No — the move is to stop and write a question, which is the opposite of pushing through. The unknown is not ignored; it is made small.
- "The lead should have explained payments." The lead was given nothing to explain. Asking well is part of the work (Asking Better Questions).
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.
- GENERALThe topic-to-question move applies to any unfamiliar area — a protocol, a library, a codebase, a mathematical idea. Only the reading list changes.
- TEAM-SPECIFICA solo learner sharpens the question and then researches it; on a team, the sharpened question is often answered in a sentence by whoever built the last integration, and the move's main value is producing a question worth interrupting them with.
- ILLUSTRATIVEThe lead's one-sentence answer, the week-long ticket and the two-page reading list are invented to show the shape of the move.
Where the depth lives
This domain asks the question and hands the answer off by name.
- — The manifesto's /manifesto/delegating cards for a payment SDK list exactly which of these verbs the SDK does for you — the initiate half, usually, and never the "paid exactly once" half.