Working Backwards: Start with the customer outcome before committing the build
A team commits to features before it can explain the customer problem, proposed experience, benefit, evidence, and questions that could stop the work.
The useful response is not another status layer. It is a mechanism that can start with the customer outcome before committing the build.
What the skill produces
The Working Backwards skill turns supplied context into a customer-centered future-state narrative, frequently asked questions, assumptions, and a decision packet. It should expose missing evidence instead of inventing it. The free skill packages this mechanism for explicit use. It does not fetch remote instructions, and the practitioner remains responsible for the facts and final decision.
Run the mechanism
- Describe the intended customer and future experience.
- Write the benefit, evidence, alternatives, risks, and unresolved questions.
- Use the document to decide whether and how to proceed.
The accountable owner reviews the output against the source evidence before it is used. Material unknowns remain labeled and receive an owner and date when they affect the decision.
Failure check
The method becomes fiction when the future-state language turns assumptions into customer facts or hides feasibility questions.
Attribution boundary
Working Backwards is an Amazon-developed product practice and should be attributed on first substantive public use.
Adoption test
Review one proposal before roadmap commitment. Count decisions changed, assumptions labeled, and unresolved questions assigned.
Keep the skill only if the result improves against that baseline. Revise the playbook when the same operating failure survives more than one review cycle.
Infographic
