Comparisons
Pairs engineers genuinely confuse — goal and implementation, MVP and bad prototype, prototype and spike, reversible and irreversible. Neither column wins; what decides is the problem. Each record leads with the confusion, because the confusion is what it costs.
Problem framing vs requirements
Requirements are gathered before the problem is framed, so the list is long, internally inconsistent and about three different products, and every meeting reopens scope because nobody agreed what the thing was. The cost is a specification that is complete and wrong. The opposite failure is framing that never ends — the one-page framing becomes a twelve-page vision and no requirement is ever written. The framing is a page; when the next question is obvious, it is done, and the requirements are the next question.
First, and again whenever conversations keep landing in different places. It makes the requirements possible to discover.
After the framing holds still. They are derived from it and checked against it.
| Aspect | Problem framing — what is being asked, for whom, what must be true, what is out of scope: one page | Requirements — the specific functional and non-functional statements the system must satisfy |
|---|---|---|
| Length | One page | As long as the system needs |
| Answers | "What is this, and what is it not?" | "What exactly must it do, and how well?" |
| Produced by | Restating and being corrected | Discovery: actors, actions, numbers, failures |
| Changes | Rarely once agreed | Throughout implementation |
| Failure when skipped | Requirements for three different products | A framed problem nobody built |