Problem Framing
"Build an e-commerce platform" is a bad frame; "customers browse, add to cart, pay, and admins manage products" is better; adding what must never happen, what is outside the system and what V1 leaves out is better still. The frame is the first artefact.
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 sentence and you need a problem. What does a well-framed problem contain, what does a badly-framed one leave out, and how do you get from one to the other?
The brief is "build an e-commerce platform for us". You have asked what they mean and been told "you know, a shop — products, buy them". Everyone in the room seems to think the problem is clear, and you are the only one who cannot see what to do on Monday.
Accept the sentence as the frame and go looking for the standard answer. E-commerce is a known category; there are reference architectures, open-source stores, tutorials. If the problem is "a shop", the solution is "a shop", and the work is choosing which one.
The standard answer is a frame for someone else's problem. The open-source store has multi-vendor support, tax zones and wishlists because its users needed them; this founder needs guest checkout for gift buyers, and the standard answer makes that the hardest thing to add.
- The standard answer is a frame for someone else's problem. The open-source store has multi-vendor support, tax zones and wishlists because its users needed them; this founder needs guest checkout for gift buyers, and the standard answer makes that the hardest thing to add.
- Nothing can be argued against. "Should V1 have reviews?" cannot be answered from "a shop", so it is answered from taste, and taste changes weekly.
- The unknowns are invisible. "A shop" contains payments, inventory, and taxes as unstated assumptions, so nobody researches them until the code arrives there — and the code arrives there last.
- Progress cannot be measured because nothing was stated. A month in, the store has a product page and a cart, and whether that is a third of the way or a tenth depends on a frame nobody wrote.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- A frame is a statement of the problem precise enough to disagree with. It names who acts, what they do, what must be true throughout, what is outside the system, and what is deliberately left out of the first version. It contains no technology, and it fits on a page.
- Build it in three passes. The bad frame is the sentence you were given. The better frame adds actors and actions in plain verbs — customers browse, add to cart, pay; admins manage products. The better-still frame adds what must never happen (never oversell, never charge twice), what is outside (the payment provider, email), and what is not V1 (coupons, reviews, multiple warehouses). Each pass makes a new class of decision possible.
- Test the frame by trying to disagree with it. If a colleague can read it and say "no — customers should not need an account", the frame is doing its job, because that disagreement is cheaper now than after the cart is built. A frame nobody could disagree with is still the bad frame.
- Keep the frame as the reference for everything after. Scope arguments, decomposition, the first slice, what to research first — all of them point back at the page. When the frame changes, and it will, change the page first and the code second (Requirements Are a Snapshot).
Bad, better, better still
The three frames for the store, side by side. Each column adds one class of decision that the previous column could not make. The bad frame cannot decide anything; the better frame can decide what to build; the better-still frame can decide what to test, what to research, and what to leave out — which is most of the decisions a project actually makes.
| Bad | Better | Better still | |
|---|---|---|---|
| The frame | "Build an e-commerce platform." | Customers browse, view, add to cart, check out, pay, see a confirmation. Admins create products, change price and stock. | The better frame, plus: never oversell, never charge twice; payment, email and images are external; V1 is one currency, one warehouse, guest checkout, no coupons or reviews. |
| Can decide what to build | No — anything is "a shop". | Yes — the actions are the features. | Yes, and what not to build. |
| Can decide what to test | No. | Partly — each action has a happy path. | Yes — each invariant is a test that must never fail. |
| Can decide what to research | No — the unknowns are hidden inside "shop". | Partly — "pay" is visibly an unknown. | Yes — every external system and invariant is a question. |
| Can be disagreed with | No. | Yes — "customers need accounts?" | Yes, and the disagreements are about things that matter. |
The same need, asked three ways
The frame is a set of answers, and each answer came from a question. The ladder below is one of them — the one that turned "a shop" into the invariant about stock — at three levels of precision. The best form is the one that could be turned into a test.
why The best form yields an invariant (stock never below zero), a requirement (the loser sees a reason), a design decision (where the check lives), and an experiment (two concurrent decrements on one row). The vague form yields a reading list; the better form yields one screen.
What the better-still frame leaves open
A good frame does not shrink the unknowns; it exposes them and turns them into questions. The board is the store's frame after the third pass, with the unknowns that appeared only because the frame named external systems and invariants. None of these was visible in "a shop".
- ✓Actors and actions, as in the better frame.
- ✓Invariants: never oversell; never charge twice for one order.
- ✓External: payment provider, email, image storage.
- ✓Not V1: coupons, reviews, accounts, multiple currencies or warehouses, search beyond name filter.
- ~Prices do not change while a customer is checking out. Probably false; the frame will need "the price shown is the price paid" as an invariant.
? Payments.
becomes Which system is authoritative for "this order is paid", and how does my backend learn it — synchronously, by webhook, or both?
experiment Create a test-mode payment and log every message that arrives afterwards, with timestamps; do it twice to see whether messages repeat.
? Never charge twice.
becomes If the customer clicks Pay twice, or the browser retries, what stops a second charge, and does the provider help?
experiment Submit the same checkout twice quickly against test mode and observe how many payment attempts exist.
? Images.
becomes Are product images uploaded by the admin through my server, or directly to storage, and does either need to be in V1?
experiment Upload one image both ways; count the code and the failure cases each needs.
The frame is finished when every unknown on it is a question with an experiment — not when the questions are answered.
How to do it
Most important first.
- Write the sentence you were given at the top of a page. Below it, list actors and, for each, their actions as concrete verbs. Read it to the person who gave you the sentence and let them correct it (Requirement Discovery).
- Add three short lists: what must never happen, what is outside the system, and what is not in V1. The first is your invariants, the second your boundaries, the third your scope (What Must Be True?, What Can I Ignore for Now?).
- Find at least one thing on the page someone would disagree with, and resolve it with them now. If you cannot find one, the page is too vague to be wrong.
- Attach the vague words to an unknowns list — "payments", "inventory", "images" — and sharpen each into a question before you consider the frame done (Unknown to Specific Question).
- Put the page where the team will see it and date it. It is the first artefact of the project, and it will be revised.
Worked on a concrete problem
The move has to produce something. This is what it produced.
- Bad: "build an e-commerce platform". Better: "customers browse products, view one, add it to a cart, check out and pay, and see a confirmation; admins create products and change price and stock". Better still, added: never sell more than is in stock; never charge a customer twice for one order; payment, email and image storage are external; V1 has one currency, one warehouse, no accounts required, no coupons, no reviews, no search beyond filter by name.
- The disagreement the frame produced. The founder read "no accounts required" and said "but we want to email them offers later". The frame had surfaced a real tension — guest checkout against a marketing list — in the first hour, and it was resolved by capturing an email at checkout with a consent box. The cart design that followed did not hang off a user id, and the marketing requirement was met.
- The chat app, framed the same way. Bad: "build a chat app". Better: "users start conversations with colleagues, send messages, and see which messages the other person has read". Better still: a message is never lost once sent; a message is never shown as read before the reader has seen it; push notification and identity provider are external; V1 is text only, one-to-one, one device per user. The last item is the one that later changed, and because it was written down, everyone knew why the read-state design had to.
How you know it worked
What now exists that did not before, and what question you can now ask.
- A page exists with actors, actions, invariants, boundaries and not-V1 on it, in plain language, and the requester has read and corrected it.
- At least one disagreement has been found and resolved against the page rather than against the code.
- Every vague word on the page has a sharpened question attached to it.
- Scope questions are answered by pointing at the page, and when the answer is not on the page, the page gets updated.
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.
- ?Who acts, and what does each of them do — in verbs, not in features?
- ?What must never happen, what is outside the system, and what is deliberately not in V1?
- ?What on this page could someone disagree with — and have I asked them?
- ?Which vague word on the page has not yet become a question?
What can go wrong
- The frame becomes a specification. Three lists and a paragraph turn into forty pages, and the frame is now too long to read and too expensive to revise. A frame that cannot be re-read in ten minutes has stopped being a frame.
- The frame is written once and defended. Its purpose is to be disagreed with and revised; a frame protected from change is the bad frame with more words.
- The frame is written by the engineer alone. It reads well, is internally consistent, and describes a store the founder did not ask for.
- Framing is applied to problems that were already framed. A ticket that says "the total is wrong when a discounted item is removed" is a frame; re-deriving actors and boundaries for it is procedure, not thinking.
- A frame written in the first hour is wrong in details that only building will reveal, and revising it costs a conversation each time. The alternative is a frame nobody wrote, which is also wrong and cannot be revised.
- Writing "not V1" in front of a requester starts the scope argument early. Early is cheaper, but it is not free, and some requesters hear "not V1" as "never".
- The better-still frame takes longer than the better one, and on a small internal tool the extra lists may name nothing that matters. Judge by what a wrong invariant would cost here.
- "So the frame is the requirements document." It is the page that makes requirements discoverable — the actors and actions are where functional requirements come from, and the invariants are where the non-functional ones start. It is shorter than either and comes before both (Functional and Non-Functional Requirements).
- "A good frame removes the unknowns." It exposes them. The better-still frame for the store has more unknowns on it than the bad one, because it names payments, inventory and images as things that must work; the bad frame hid them.
- "Framing is for greenfield projects." An existing system has a frame, usually unwritten. Framing there means writing down what the system actually does and where the new requirement fits, which is often the first time anyone has.
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.
- GENERALAny problem can be framed by actors, actions, invariants, boundaries and scope; for a library the actors are callers, for a pipeline they are upstream and downstream systems, and the lists are the same.
- STAGE-SPECIFICGreenfield: the frame is invented with the requester and is the first artefact. Existing system: the frame is recovered by reading the system and is often the first written statement of what it does; the new requirement is then placed against it rather than argued from scratch.
- ILLUSTRATIVEThe founder, the gift buyers, the consent box and the chat app's one-device rule are invented to show the three passes; no real product is described.
Where the depth lives
This domain asks the question and hands the answer off by name.
- — The Requirement Discovery Canvas at /thinking/canvas is the better-still frame as a form: goal, actors, actions, data, constraints, external systems, failures, unknowns, first milestone, with the store filled in.