Goal vs Implementation
"The user can pay" is a goal. "Stripe Checkout" is an implementation. Requirements that arrive as implementations lock in decisions nobody made; the move is to separate the two so the goal can be met by the best implementation, not the first one named.
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.
A requirement has arrived already containing its solution. How do you separate the goal from the implementation it came wrapped in, and when is the implementation actually part of the requirement?
The ticket says "integrate Stripe Checkout". You start reading Stripe's docs and find three different products with that name in them, each implying a different flow. It occurs to you that nobody has said what the customer is supposed to be able to do.
Build what the ticket says. It names a product; the product has documentation; the documentation has a quickstart. Following it produces a working payment page, and "integrate Stripe Checkout" can be marked done.
The ticket's implementation decides things the goal never asked for. A hosted checkout page means the customer leaves the store to pay; whether that is acceptable was never discussed, and by the time someone objects, the order flow is built around the redirect.
- The ticket's implementation decides things the goal never asked for. A hosted checkout page means the customer leaves the store to pay; whether that is acceptable was never discussed, and by the time someone objects, the order flow is built around the redirect.
- The goal is never written down, so the implementation cannot be checked against it. "Does the customer get a confirmation?" "Does it handle a declined card?" Nobody knows, because the requirement was a product name.
- Alternatives are never considered, including simpler ones. If the goal was "take card payments from guests", an embedded form, a hosted page, and a payment link all meet it with very different trade-offs; the ticket chose one before the trade-offs existed.
- When the implementation fails — the provider changes the product, or the redirect breaks on mobile — there is no goal to fall back to, so the fix is "make the same implementation work" instead of "meet the goal another way".
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Split every requirement into what must be true (the goal) and how it is proposed to be made true (the implementation). "The user can pay" is the goal; "Stripe Checkout" is one way. Write both, separately, and treat only the first as the requirement until you have a reason to fix the second.
- Recover the goal by asking what would be true when this is done, for whom, and what would make it a failure. The answer names capabilities and constraints — guests can pay by card, they get a confirmation, a declined card is handled — and never a vendor.
- Then ask whether the implementation was a requirement in disguise. Sometimes it is: an existing contract, a compliance rule, a team that already runs it, a partner who mandates it. When the implementation is fixed for a real reason, write the reason next to it, so it is a constraint and not a habit (Known vs Required Technology).
- Choose the implementation against the goal, with the alternatives visible. Often the named one wins — it was named for a reason — but now it wins on the goal's terms, and when it fails later, the goal tells you what any replacement must do.
The ticket, split
The same ticket written as it arrived and as it should be read. The worse version is not wrong about the vendor; it is silent about everything else, and that silence is where the redirect-away decision was made by nobody.
Integrate Stripe Checkout. Follow the quickstart. A hosted page takes the payment; the customer is redirected back. Done when the test card succeeds.
Goal: a guest can pay by card for their cart, is told at once whether it worked, and a declined card leaves no order behind; the customer should stay on our domain if possible. Proposal: this vendor — not mandated, no existing relationship. Candidates: hosted page, embedded element, payment link.
Only the second version can be checked. It says what a declined card must do, which the quickstart does not mention; it surfaces the on-domain constraint, which chooses between the vendor's products; and it records that the vendor is a choice, so a future failure can be met by any implementation that satisfies the goal line.
The implementation, decompressed
The Why Ladder applied to the proposal. Its endpoint is not "do not use the vendor" — it is the real requirement, the simplest thing that meets it, and the case where the proposal was right. In this instance the vendor survives and the specific product changes.
“We need Stripe Checkout.”
- ↓Why that product? It is the fastest way to get a working payment page.
- ↓What must the payment page do for us? Take a guest's card, tell them at once whether it worked, never leave an order behind on a decline.
- ↓Does the hosted page do all of that? Yes — and it also sends the customer off our domain, which the founder would rather avoid.
- ↓Is the vendor mandated? No; there is no existing relationship. It is a reasonable default, not a constraint.
the claim was right when The on-domain constraint is dropped, or compliance scope must be minimised at all costs, or the team has no capacity for the embedded integration — then the hosted page is the right product, for a reason that is now written down.
Is the implementation part of the requirement?
Sometimes the named implementation is the requirement. The decision below sorts the reasons that can fix an implementation, and says what to record in each case, so the fixed ones are constraints with a source and the unfixed ones are choices with alternatives.
Is the implementation fixed, and by what?
when A signed agreement, a regulation, or an integration partner names it.
cost Fixed. Record the mandate and its expiry; still write the goal line, because the mandate does not tell you what "done" means.
when The company already runs it and the new feature must interoperate.
cost Fixed for now. Record it as a constraint; note what would have to change for it to be revisited (Constraints Shape Architecture).
when The team knows it well and nothing mandates it.
cost A strong preference, not a requirement. Record it as a reason; still list one alternative so the choice is visible.
when No mandate, no existing system, no particular expertise.
cost A proposal. Evaluate against the goal with at least two alternatives; the proposal often still wins, and then it wins honestly.
How to do it
Most important first.
- Rewrite the ticket as two lines: "goal:" with no product names, and "proposed:" with the product. If the goal line is empty, that is the work: ask.
- Add the goal's constraints as sentences a test could check: guests can pay without an account; the customer is told immediately whether payment succeeded; a card decline does not create an order (What Must Be True?).
- List at least two implementations that meet the goal, including the proposed one, and one line each on what they cost. The point is not to reject the proposal but to be able to say why it wins.
- Ask whether the proposal is mandated — by contract, law, an existing integration, or a partner. If it is, record the mandate; if not, record that it is a choice (Budget and Legal Constraints).
- Write the decision with the goal beside it, so a future engineer replacing the implementation knows what it had to do (The Decision Journal).
Worked on a concrete problem
The move has to produce something. This is what it produced.
- "Integrate Stripe Checkout." Goal: a guest can pay for a cart by card, is told at once whether it worked, and a failed payment does not create an order. Constraints found by asking: the founder wants the customer to stay on the store's domain if possible, and there is no existing provider relationship. Implementations: hosted checkout page (fast, redirects away), embedded payment element (stays on-site, more code), payment link (no integration, no cart binding). The embedded option wins on the founder's constraint. The ticket's proposal was the right vendor and the wrong product, and only the goal could show that.
- The one where the implementation was the requirement. "Use the company SSO for the admin login." Goal: only staff can reach the admin. Asking revealed the mandate: the security policy requires every internal tool to authenticate through the identity provider. The implementation stays, with the policy written next to it, and the goal line still matters — it says the requirement is met when non-staff cannot get in, which is a test the SSO integration alone does not prove.
- The chat app version. "Use WebSockets for messages." Goal: a message sent by one person appears for the other without them refreshing, promptly enough that a conversation feels live. Implementations: WebSockets, server-sent events, polling every few seconds. For a one-to-one text chat at small scale, polling meets the goal with a fraction of the operational surface; the named implementation may still win later, on a measured latency requirement, and then it wins for a reason.
How you know it worked
What now exists that did not before, and what question you can now ask.
- Every requirement can be read as a goal line with no vendor in it, and a proposed line that may or may not be fixed.
- For each fixed implementation there is a written reason — contract, law, existing system — and for each unfixed one there is at least one alternative that was considered.
- The goal has constraints a test could check, and the implementation is judged against them.
- When an implementation breaks, the conversation starts from "what did it have to do?" rather than "how do we make it work again?"
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 must be true when this is done, stated with no product names in it?
- ?Is the named implementation mandated — by contract, law, an existing system, a partner — or is it a proposal?
- ?What are two other ways to meet the goal, and what does the named one win on?
- ?If this implementation broke tomorrow, what would any replacement have to do?
What can go wrong
- The split is used to relitigate every choice. A team that has run one provider for years does not need three alternatives evaluated for each new payment feature; the implementation is fixed by familiarity, and that is a reason worth writing down once.
- The goal is recovered by the engineer and never checked. "The user can pay" sounds right and misses the founder's constraint about staying on-domain, which only the founder could have supplied.
- The goal is written so abstractly it no longer constrains. "Money is collected" admits invoicing by post. Keep the goal at the level where it still excludes things.
- Implementations that are genuinely mandated are treated as habits and challenged, costing trust and time. Ask about the mandate before arguing the alternatives.
- Separating goal from implementation delays a ticket that could have been started immediately, and the delay is visible while the avoided rework is not.
- Listing alternatives invites debate, and debate about payment providers can consume more time than either provider would have cost.
- A recorded goal is a commitment: when the implementation later fails to meet it, the record is evidence, and some teams prefer not to have that kind of evidence.
- "Never accept a requirement that names a technology." Accept it; split it. The technology name is information about what the requester expects, and often it is the right answer. What is wrong is treating the name as the requirement.
- "The goal is always what the user can do." Usually, but goals also come from operators, from law, and from the business: "we must be able to refund within a day" is a goal too, and it constrains the implementation as hard as any user story.
- "This is about vendors." It is about any solution that arrives inside a requirement — a pattern, a data structure, an architecture. "Use a message queue for order events" has a goal inside it, and the same split applies (Problem Before Technology).
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 requirement can be split into what must be true and how it is proposed to be made true; the proportion that turns out to be mandated is domain-specific.
- DOMAIN-SPECIFICIn regulated domains — payments, health, identity — the implementation is often genuinely fixed by law or contract, and the split serves mainly to record why. In an internal tool almost nothing is mandated and the split regularly changes the answer.
- ILLUSTRATIVEThe ticket, the founder's domain preference, the SSO policy and the provider product names are invented to show the split; no vendor's actual product line is described.
Where the depth lives
This domain asks the question and hands the answer off by name.
- — The delegation cards at /manifesto/delegating show what a payment SDK handles for you and what stays yours — the "stays yours" column is the goal line of this lesson.