What Am I Actually Trying to Achieve?
Before "how", answer "what for": what will be different when this is done, for whom, and how would we tell? A goal you can check is the difference between building the store and building a store.
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 been asked to build something and you can describe it, but not what it is for. How do you find the goal behind the request, and how do you know you have found it?
The brief says "build a checkout". You could list the screens and the endpoints, and you could start any of them tomorrow. What you cannot say is what the founder will look at, when it is done, to decide whether it worked — and you have a feeling that if you asked, the answer would change what you build.
Take the request literally and start building it. "Build a checkout" is concrete enough to decompose, and decomposing it produces tasks, and tasks are what a day of work is made of. Asking "why" feels like stalling, or like doubting the person who asked.
The checkout gets built to the letter and the goal was never written down, so the first review is the first time anyone says "but we needed guest checkout, most of our buyers are one-time" — and the account-first design is already everywhere.
- The checkout gets built to the letter and the goal was never written down, so the first review is the first time anyone says "but we needed guest checkout, most of our buyers are one-time" — and the account-first design is already everywhere.
- Every scope argument is unwinnable because there is no goal to appeal to. "Should V1 have coupons?" is decided by who argues longest, since nobody can say whether coupons move the thing the store exists to move.
- Work is prioritised by what is buildable rather than what matters. The product page is polished while the reason for the store — orders being placed by people who have never been here — is unaddressed.
- Success is invisible. The store launches, and nobody can say whether it worked, because "worked" was never defined more precisely than "exists".
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Separate the request from the goal. The request is what you were asked to build; the goal is what will be different in the world when it works. "Build a checkout" is a request. "Visitors who already want a product can pay for it without abandoning" is a goal. The request is one way of reaching the goal, and rarely the only one.
- Write the goal as an observable change: who will be able to do what, that they cannot now, and what you would look at to see it happening. If you cannot name an observation, the goal is still a wish; keep asking "and how would we tell?" until it is something you could check.
- Ask the goal question of the person who asked, not of yourself. The founder knows why they want a store; you are guessing. The conversation is short and it is the highest-leverage twenty minutes of the project (Asking People).
- Hold the goal next to the request and look for daylight between them. Where the request implies something the goal does not need, that is a candidate for "not V1"; where the goal needs something the request does not mention, that is a hidden requirement, and it is better found now (What Can I Ignore for Now?, Missing Requirements).
The same request, asked three ways
The request is not wrong; it is just not the goal. The ladder below shows the same need at three levels of precision. The vague form is what arrives; the better form names a user; the best form names an observation, and it is the observation that lets every later scope argument be settled by evidence instead of by volume.
why The best form makes "do we need accounts in V1?" answerable (no — they work against the goal), makes "do we need coupons?" answerable (only if they move the fraction), and tells the data model to record cart-to-order progression, which the other two forms never mention.
Request against goal
Held side by side, the request and the goal disagree in both directions. The request contains things the goal does not need; the goal needs things the request never said. Both gaps are worth finding before the cart is designed, because the first gap is scope you can drop and the second is a hidden requirement that would otherwise arrive as a surprise (The Requirements Nobody States).
Accounts, addresses, saved cards, order history, then payment. The cart hangs off a user id. Guest checkout is "a later feature" because nobody said otherwise.
Guest checkout first: cart by session, email captured at payment, confirmation by email. Accounts, if ever, are a later feature that attaches to an existing order. The store records how far each cart got.
The goal says who the buyer is and what we need to observe. The request-driven version cannot serve the actual buyer without a redesign of the cart, and cannot report on the goal at all because nothing records cart progression.
What the goal leaves unknown
Finding the goal does not answer everything; it changes which unknowns matter. Before the conversation the unknowns were about payment mechanics. After it, the sharpest unknown is about identity without accounts — a question the request would never have raised.
- ✓Buyer: a visitor with no account, usually buying once.
- ✓Observation: the fraction of carts that reach a paid order, and orders placed without an account.
- ✓Not V1: accounts, saved cards, order history, coupons.
- ~A confirmation by email is enough for a guest to find their order later. To check with the founder — a lookup by order number and email may be needed.
? Guests and orders.
becomes How does a guest who closed the tab find their order again, and what identifies them — order number, email, a link in the confirmation?
experiment Write the confirmation email as text and the lookup form as a sketch; see whether order number plus email is enough to make both work.
? Cart without a user.
becomes If the cart is keyed by session, what happens to it when the session expires before payment, and does the goal care?
experiment Decide the session lifetime, then walk through a cart that is abandoned overnight; write what the customer sees the next morning.
? Measuring the fraction.
becomes Which events must be recorded, and at which moments, for "carts that reach a paid order" to be computable later?
experiment List the events on paper — cart created, checkout started, payment attempted, order paid — and check each one has a place to be written.
None of these unknowns existed before the goal was found. That is the point: the goal does not shrink the unknowns, it aims them.
How to do it
Most important first.
- Write the request in one sentence and, underneath it, the goal in one sentence starting "when this works, …". If the two are the same sentence, you have not found the goal yet.
- Attach an observation to the goal: what you would look at, and what you would expect to see. "Orders arrive from customers who have never had an account" is checkable; "a great buying experience" is not (Problem Framing).
- Ask the requester three questions: what happens today without this, what would make you call it a failure, and what would you cut first if we ran out of time. Their answers are the goal in their words.
- Re-read the request against the goal and mark each feature as "needed for the goal", "nice", or "contradicts the goal". The third category is the one that saves the project (Goal vs Implementation).
- Write the goal at the top of whatever you keep as a notebook and check every later decision against it (The Engineering Notebook).
Worked on a concrete problem
The move has to produce something. This is what it produced.
- Request: "build a checkout for the store". Goal, after asking: "a visitor who has found a product and decided to buy it can pay and receive a confirmation without creating an account, because most of our buyers are one-time gift purchasers". Observation: orders placed by customers with no account, and the fraction of carts that reach payment.
- Daylight between request and goal: the request implied accounts, addresses, saved cards and order history. The goal needs none of them in V1 and actively dislikes the first. Guest checkout is now a requirement, and "order history" moved to "later". The design of the cart changes — it cannot hang off a user id.
- The chat app version: request "build messaging". Goal, after asking: "two people in the same company can resolve a question faster than by email". Observation: threads that get an answer, and how long that takes. "Rich formatting" and "custom emoji" fell off V1 without an argument, because neither moves the observation.
- The URL shortener version: request "build a link shortener". Goal: "marketing can tell which campaign a click came from". The core is not shortness at all — it is the click log and the campaign tag, and a shortener that does not record clicks would meet the request and fail the goal.
How you know it worked
What now exists that did not before, and what question you can now ask.
- You can state the goal in one sentence that contains no feature names and that the requester agrees with.
- There is a named observation — something you would look at — attached to the goal, and it is checkable with what the system will record.
- At least one feature in the request has been moved out of V1, or one requirement not in the request has been added, on the strength of the goal.
- Scope arguments now end with "does it move the goal?" rather than with whoever is most tired.
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 will be different in the world when this works, for whom?
- ?What would I look at to see whether it worked — and does the system record that?
- ?Which parts of the request does the goal not need, and which things does the goal need that the request never mentioned?
- ?Who actually knows the answer to "what for?", and have I asked them?
What can go wrong
- The goal is chased upward until it becomes "make money". A goal that broad no longer discriminates between features; stop at the level where the goal still says what to build and what not to.
- The goal is written by the engineer and never checked with the requester. It reads well and it is wrong, and the store is built for a customer the founder does not have.
- The goal is treated as fixed. Goals move — the founder learns something from the first orders — and a goal that was right in the first week can be wrong in the sixth. Revisit it when the evidence changes (When Assumptions Change).
- Every task, however small, gets a goal interrogation. Fixing a broken image link does not need "what are we trying to achieve?"; the move is for requests whose shape you would otherwise guess.
- Asking "what for?" can sound like pushback, and with some requesters it costs trust before it earns any. The question has to be asked as curiosity about their problem, not as doubt about their request.
- A clearly stated goal makes scope decisions visible, and visible decisions get argued about. The request-as-given postponed those arguments; the goal brings them forward, where they are cheaper but not free.
- The goal can invalidate work already done. Finding out in week two that guest checkout is the point costs the account-first cart; it would have cost more in week six, but it is not nothing.
- "So I should refuse to build anything until the business goal is documented." No. You need one sentence and one observation, and you can often get both in a single conversation. The move is a question, not a gate.
- "The goal replaces the request." The request still carries real information — the founder said "checkout", not "a buy button", for reasons. The goal explains the request; it does not delete it.
- "If the requester cannot state a goal, the project is doomed." Often they can state it but have never been asked. Help them: offer the observation you would use, and let them correct it.
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.
- GENERALEvery request has a goal behind it, whether the thing built is a store, a library or a pipeline; for a library the "requester" is the caller and the observation is what their code can now do.
- TEAM-SPECIFICA solo learner building for practice can invent the goal — but should write it down, because the exercise is choosing scope against something. On a team the goal must come from whoever owns the outcome, and an engineer who invents it is guessing on their behalf.
- ILLUSTRATIVEThe founder, the gift purchasers and the marketing team are invented; the numbers and the fractions are for the shape of the argument only.
Where the depth lives
This domain asks the question and hands the answer off by name.
- — The manifesto at /manifesto argues the same thing about understanding in general: a goal you cannot state is a goal you have delegated to whoever wrote the request.