Unknowns
An unknown is not a blocker. "I don't understand payments" becomes a specific question, a tiny experiment, and a return to the main problem.
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.
"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 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 full detour from §14: Unknown → Specific Question → Research → Tiny Experiment → Understanding → Return to the main problem. The experiment is the step people skip, and it is the only step that produces knowledge rather than familiarity.
The same need asked three ways: "how do payments work?" cannot be answered; "how does a backend confirm a payment?" is answered by a diagram; "which system should be authoritative for whether an order has been paid?" is answered by a decision. The ladder is how you tell where a question stands.
The board lists what you know you do not know. The unknowns that hurt are the ones not on it — and there are moves that surface them: asking what the experts in this area worry about, walking the failure paths, reading a real system's incident history, and listening for the word "just".
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.