Working Backwards From the Customer Outcome

Most teams plan forwards. They start from what they have, a warehouse full of events or a model someone trained or a backlog of feature requests, and ask what they can build with it. It feels productive. You ship things. Six months later the roadmap is full, the team is busy, and nobody can say whether the customer's life actually got better.

Amazon planned the other way, and turned it into a mechanism. Before building anything, a team writes the press release first: a short, plain-language announcement of the finished product, dated in the future, written for the customer. Then an FAQ that tries to kill it. The document is not the point. The point is the direction. You start from the outcome you want a customer to feel, and you reason back to the work.

I've come to think that's the whole game. Not the six-pager, not the silent-reading meeting. The direction. Start from the outcome, and refuse to fund anything that can't trace a line back to it.

Start from a number the customer would recognize

The first move is choosing what sits at the top, and working backwards only holds up if that thing is what you actually want, stated the way a customer would state it.

That rules out most of the metrics companies lead with. Revenue is the company's outcome, not the customer's. Nobody opens a payments app to generate you revenue. They open it to move their money, and the moment it lands is the outcome worth naming. On a fintech I worked on, that moment was a deposit clearing on the first try, so the number that belonged at the top was deposit success rate: the share of deposits that actually go through. A failed deposit is the customer's money not arriving. Put that at the top, and every branch beneath it inherits a reason to exist.

The press release enforces this by making you write in the customer's language before you're allowed to build. If you can't describe the win in a sentence a customer would recognize, you don't understand the outcome yet, and no amount of building will fix that.

The metric tree is the map you work backwards down

An outcome on its own is a wish. What turns "start from the outcome" into a route is the metric tree: the outcome at the top, the drivers that move it below, and under those, inputs a team can change.

Working backwards is reading that tree top to bottom. The outcome names its drivers. Each driver names the inputs a team can actually move this week, and those inputs name the work. You don't start from the work and hope it matters. You start from the outcome and let the tree hand you the work.

Take deposit success rate. Work backwards from it and it opens into two levers, owned by different teams. Every deposit is routed to a payment service provider, a PSP. One lever is the roster: get better PSPs, cut the weak ones. That work is operations and business development. The other is routing: instead of a fixed provider, send each deposit to the healthiest PSP available right then. That work is product and engineering. Routing doesn't make any single PSP better. It just stops feeding the bad ones, and it lifts the success rate the user actually sees.

Amazon says the same thing without the picture: the way to hit an output metric is to find the controllable input metrics that feed it and drive those. Output metrics lag. You don't get to move them directly. Inputs are where you actually push. The tree is that idea drawn out one level at a time, with an owner on every node. When one outcome sits over two owners, the way deposit success sits over operations and product, working backwards is what keeps them pulling the same number instead of each polishing their own slice.

Prioritize by the line back to the outcome

Once the tree exists, prioritization stops being an argument about which idea is most exciting. Every candidate project has to name the node it moves. If it can't, it doesn't get funded. That single rule has killed more bad work for me than any scoring framework.

The hard part is telling a real lever from a number that only looks like one. You can rank every PSP by success rate, but that ranking is analysis, not a lever. Nobody moves the outcome by knowing which providers are bad. You move it by changing something: the providers on the roster, or the logic that picks between them. Those are the two levers, and no single team owns both.

So the test for a lever is narrow: can a team change it inside a normal week, and does the tree say it feeds the outcome? Plenty of "inputs" fail it. They sound controllable and aren't, or they worked last year and quietly stopped mattering. Provider reliability is the honest version of that: the best PSP this quarter won't be the best one next quarter, which is why the routing has to keep moving and the tree has to be re-checked. A tree isn't a monument; part of the job is noticing when a lever everyone still trusts has gone dead.

A real lever also needs a guardrail, or it games the outcome. Route everything to the healthiest PSP and you can buy success with fees, so cost per successful deposit sits next to the success rate; define success loosely and the number climbs while nothing improves, so what counts as a success gets pinned before anyone chases it. Those guardrails belong to finance and operations as much as to product, because a shared outcome has shared guardrails.

Targets are a direction, not a scoreboard

Working backwards changes what a target is for. If you set the target by reasoning down from the outcome, the target is a bet about the path, not a promise. The target says: if this input reaches roughly here, the outcome should follow. You won't be exactly right, and you're not meant to be.

Amazon plans for that openly. Teams are expected to fully hit about 75% of their goals; hitting 100% means the targets were sandbagged, set low enough to guarantee green. A wall of green usually just means the targets asked too little.

I care less about whether a target was hit than about whether it pointed the right way. A team that missed a stretch input and learned the lever was weaker than it thought is ahead of a team that cleared a soft one and learned nothing. Red is information. The moment red becomes a thing to hide, people quietly set targets they know they'll clear, and the whole system goes blind.

The review writes itself when everyone shares the model

For years I got this backwards. I thought the operating review was a meeting you design: agenda, cadence, a clean deck, stand it up and enforce it.

What actually made reviews work was teaching leadership the tree first. Once a CEO and a board can see the growth model, this outcome, driven by these few things, each with an owner, the question of what to watch every week stops being a debate. Everyone watches the inputs near the top against their targets, and the conversation is only about the ones that are off. The cadence falls out of the model instead of being bolted on over it. A shared model like that is what a decision culture is actually made of.

That shared model is also what keeps the meeting short. Amazon's Weekly Business Review runs on a standing deck read by exception: on-plan metrics get a flat "nothing to see here," and the room spends its time only where reality diverged from the plan. That only works if everyone already agrees what the numbers mean and how they connect. Without it you get a status read-out, every team narrating its slide, nothing decided.

Bezos has a line for why the mechanism beats the intention: "Good intentions don't work. Mechanisms do." The tree, the targets, and the weekly read by exception are the mechanism. Working backwards is what aims the whole thing at something a customer would care about.

Where it actually starts

None of this needs Amazon's scale, its 400-metric deck, or a ban on slides. The move is smaller, and it's free. Before the next thing gets built, say the outcome first, in a sentence a customer would recognize. Then walk backwards: which driver, which input, whose job, what target. If the work at the bottom can't trace a clean line back to the top, you have your answer before you've spent a sprint finding out.

That line, from the outcome down to the work, is the spine. Working backwards is just the discipline of building it in the right order.