Start With the Customer Outcome, Then Design the Product Backwards

Ask a product team how a new feature came to exist, and most of the time the honest answer traces back to an idea, not a problem. Someone saw a competitor’s screenshot, a customer said something offhand in a call, an engineer had a clever technical approach they wanted to try. The idea got a name, a design, a sprint, a launch. Only afterward, usually months later when someone finally checks the usage dashboard, does the question get asked that should have been asked first: did this actually help the customer do anything better? That sequence, idea first and evidence later, is so common it barely registers as a choice. It is a choice, and it is the wrong one for most product decisions that matter. Outcome-first product design simply reverses the order: state what should change for the customer, then work backward to the smallest thing you could build to find out if it will.

The Forward Approach and Why It Feels Natural

The forward approach looks like this: idea, feature, launch, hope. A team has a concept, builds it out to a reasonable level of completeness, ships it, and then waits to see what happens. It feels natural because it matches how creative work usually gets talked about. It also matches how software gets demoed, funded, and celebrated. A finished feature is concrete. It can be walked through in a meeting. Everyone in the room can nod.

The problem is not that ideas are worthless. The problem is that an idea, no matter how appealing, is still just a guess about what will help the customer. Building it out fully before testing that guess means the team pays the full cost of production before learning whether the guess was right. Melissa Perri called the broader pattern of organizing around output rather than validated value “the build trap,” and it is the natural resting state of a team that has not been asked, explicitly, to name the outcome before the output.

The Backward Approach, Step by Step

Outcome-first product design runs the same decision in reverse: outcome, evidence, minimum output. Concretely, it means working through this sequence before a single line of production code gets written:

1. Name the customer. Not “users” in general, but the specific core customer segment this work is for.
2. Name the outcome, in measurable terms. Not “improve the experience,” but something you could actually observe changing, like time-to-first-successful-task or rate of repeat manual corrections.
3. State the current assumptions and evidence behind the belief that this outcome matters and is achievable.
4. Design the smallest possible output that could plausibly create or test that outcome, not the full-featured version of the idea.
5. Decide, in advance, how you will measure whether it worked, including any guardrails that must not get worse.
6. Only then decide what gets built.

The order matters more than any individual step. Reversing steps two and four, deciding what to build before deciding what should change, is the single most common way teams quietly slide back into the forward approach while believing they are doing outcome-driven work.

An assumption written in a product document does not become a fact.

That line matters here because the backward approach only works if the team is honest about which of its beliefs are Known Facts, which are Assumptions, which are Hypotheses, and which are genuinely Unknowns. Skipping this distinction is how a team ends up building a full solution on top of a belief nobody actually checked.

A Detailed Walkthrough: One Problem, Two Approaches

Consider a hypothetical team building software used by physical therapy clinics to manage patient home-exercise plans. Clinicians report, in scattered conversations, that patients “don’t do their exercises.” This is illustrative and not a real client engagement, but it is representative of how these decisions get made in practice.

The Forward Version

A product manager hears “patients don’t do their exercises” and translates it directly into a feature idea: push notification reminders. The team spends five weeks building a notification system with configurable schedules, custom messages, and a settings panel so clinicians can adjust reminder frequency per patient. It ships. Clinicians are pleased there is something to point to. Ninety days later, the retention numbers for home-exercise-plan completion have not moved. A closer look shows most patients who were going to ignore their exercise plan also ignore or mute the notifications within the first week. The team built a real output. It never established what “not doing exercises” actually meant as a measurable outcome, so it had no way to know in advance whether reminders were even aimed at the actual cause.

The Backward Version

Now run the same starting point through the backward sequence.

Customer: patients recovering from outpatient orthopedic procedures, roughly the core 80 percent segment served by the clinics using the product, as distinct from the smaller secondary segment managing chronic pain conditions with different adherence patterns.

Outcome, stated measurably: increase the percentage of prescribed home-exercise sessions completed within the first two weeks of a plan, from a current baseline the team has to go establish, not assume.

Assumptions and evidence, made explicit:

• Known fact: clinicians report low completion, but nobody has measured actual completion rates yet.
• Assumption: patients forget or lose track of what was prescribed, rather than actively refusing to do it.
• Hypothesis: patients who don’t do their exercises don’t know if they’re doing them correctly, and disengage from uncertainty rather than forgetfulness.
• Unknown: whether the barrier is memory, motivation, confusion about technique, physical discomfort, or something else entirely.

Notice that this step alone already invalidates the forward team’s approach. A reminder notification only addresses the memory hypothesis. If the real barrier is uncertainty about technique, more reminders will not move the outcome at all, and the team would not have known that going in.

Minimum Viable Output: rather than building the full reminder system, the team designs a small, deliberately limited output: a short, structured check-in question sent once at the midpoint of week one, asking the patient to self-report whether they completed the prescribed session and, if not, why not, with three tap-to-select reasons (forgot, unsure how, too painful). No notification engine, no settings panel, nothing configurable. It exists to produce evidence, not to be the finished product.

Measurement and guardrails: primary outcome metric is two-week completion rate compared to a baseline measured over the prior month. Guardrail: check-in response rate itself must not become a burden that increases dropout from the app overall.

Experiment statement: “We believe patients recovering from outpatient orthopedic procedures will complete more of their prescribed home-exercise sessions if they receive a single structured mid-week check-in. We will consider this supported if two-week completion rates increase by a meaningful margin over baseline within one full prescribing cycle.”

When the results come back, suppose “unsure how” is selected far more often than “forgot.” That is the outcome-first approach doing its job: it just saved the team from spending five weeks on a notification system aimed at the wrong cause, and pointed them toward the real next minimum output, likely something closer to short technique-confirmation video clips than a reminder schedule.

This is the practical shape of the Minimum Viable Output idea. It draws on the same build-small-to-learn lineage as Eric Ries’s Lean Startup and Steve Blank’s Customer Development work, but it is a distinct concept from a general-purpose MVP. An MVP is usually described as a cut-down version of the eventual product. An MVO is defined by its relationship to a specific outcome: the smallest thing that can create or test that outcome, which in this case was not a lighter version of a notification system at all, it was a single question.

Why This Is Harder Than It Sounds

Nobody disputes, in the abstract, that understanding the customer’s problem before building a solution is a good idea. The difficulty is not conceptual, it is procedural. Working backward from outcome requires a team to sit with an uncomfortable amount of not-knowing before anyone is allowed to talk about solutions, and most team dynamics actively resist that.

Solutions are more comfortable to discuss than problems. A meeting about “what should we build” generates energy, sketches, and a sense of momentum. A meeting about “how would we even measure whether patients are struggling with technique versus memory” generates silence, because it requires admitting nobody has that data yet. Teams gravitate toward the conversation that feels productive, even when it is premature.

Naming a measurable outcome exposes how vague the original problem statement was. “Patients don’t do their exercises” sounds like a clear problem until you try to state, numerically, what would count as it getting better. Forcing that translation is often the moment a team discovers it does not actually understand the problem strength: how frequent, how severe, how urgent, how costly the inaction is, and how willing patients are to change. A complaint is not automatically a high-priority product problem, and outcome-first design is the mechanism that forces that check to happen before resources are committed.

Stakeholders often want to see something. A single check-in question feels underwhelming to present compared to a fully built reminder system. Holding the line on a genuinely minimal output requires explaining, repeatedly, that the smallness is the point, not a limitation to apologize for.

Keeping a Team Disciplined About the Order

A few practical guardrails help keep the sequence from collapsing back into the forward approach.

Require a written outcome statement, with a metric and a rough current baseline, before any solution is discussed in a planning meeting. If nobody can state the metric, the discussion is not ready to move to solutions yet, no matter how much enthusiasm exists for an idea.

Make the assumptions and evidence list a visible artifact, not a private mental exercise. When it’s written down and reviewed by more than one person, it becomes much harder to quietly skip from “we assume” to “we know.”

Ask, before approving any build, whether the proposed output is the smallest version that could produce evidence, or whether it has already grown into a fuller product because that felt safer or more impressive. This question alone catches most attempts to relabel an MVP as an MVO without actually shrinking scope.

Treat every output as ending in a decision, not a launch celebration. Continue, improve, pivot, pause, or stop, based on what the evidence actually showed. A launch without a predefined decision point tends to quietly become permanent regardless of what the data says, because nobody was assigned the job of closing the loop.

None of this eliminates judgment or intuition from product work. Good instincts about where to look for problems remain valuable. What outcome-first design changes is the order of operations: instinct is used to identify where to investigate, not as a substitute for stating, in advance, what success would measurably look like. Readers who want the full sequence this fits into, including how minimum outputs connect to readiness and scaling decisions, can see the complete framework at the framework overview.

Key Takeaway

Outcome-first product design is not a slogan, it is an ordering rule: name the customer and the measurable outcome before anyone proposes a solution, then work backward to the smallest output that could plausibly create or test that outcome. The discipline is uncomfortable precisely because it exposes how much of a “clear problem” was actually a vague complaint, and how much of a “solution” was actually a guess dressed up as a plan. Teams that hold the line on this order end up building less, but what they build is far more likely to change something real for the customer.