Working Backwards

Working Backwards

Use this skill to work from a specific customer outcome toward a future promise, the evidence needed to trust it, and an explicit next decision. The attached case materials are reference-backed examples, not current organizational policy. The Digikala Instant Exchange case is fictional; never present its people, numbers, zones, targets, economics, or boundaries as facts.

Choose the level of rigor

• Use the complete workflow when the customer problem or success signal is ambiguous, multiple functions must make one promise, the change creates meaningful customer exposure, or important assumptions about value, feasibility, quality, accessibility, safety, privacy, policy, or economics are untested.
• Use a lighter customer-outcome and decision record when the change is routine, low-risk, clearly evidenced, easily reversible, and already has decision ownership. Keep the customer outcome, owner, and next decision even when a full PR/FAQ is unnecessary.

Core workflow

1. Frame one customer and outcome. Name a specific customer situation, the present struggle, and an observable outcome. Avoid broad personas, generic aspirations, and solution language. Write the smallest useful in-scope and out-of-scope boundary.
2. Write the future promise before the mechanism. Draft an outcome-led headline and benefit, then describe the experience as request -> confirmation -> fulfillment or handoff -> status -> recovery. State the success signal, boundary, and fallback. Architecture, operations, and policy should be evaluated against this experience, not substituted for it.
3. Ask hard FAQs. Challenge customer eligibility and recovery, accessibility, feasibility, architecture, operations, quality, safety, abuse and fairness, privacy and policy, data validity, and economics. Each answer should expose a guardrail, refusal condition, failure path, or learning need; do not use FAQs as reassurance copy.
4. Label uncertainty. Separate:
   • Evidence: observed, sourced, dated, bounded, and limited.
   • Assumption: plausible but unproven, with impact stated.
   • Experiment: the cheapest credible way to learn, with an owner and exit evidence.
   • Decision: a named DRI, deadline, reversibility, dissent or risk, and commitment. Record source, date, population, method, limitations, impact, and owner. A target is not a baseline and an illustrative number is not proof.
5. Recommend the next decision. Choose test, invest, pause, or stop. Stage evidence so each step buys learning while keeping exposure reversible: customer evidence and prototype, technical or state test, operations simulation, capped live pilot, then review. Define entry evidence, exit evidence, stop conditions, and who can stop.
6. Set decision rights. Name one DRI who integrates input and owns the recommendation. Name contributors for customer experience, engineering and architecture, operations, QA, data, risk or policy, and support as applicable. A sponsor ratifies hard-to-reverse customer exposure, policy, or investment. Record dissent rather than treating consensus as ownership.

Decision-ready quality gate

Before calling a PR/FAQ ready, verify that a reader can state the promise, strongest evidence, highest-impact unknown, protected boundary, DRI, and next action. Check that:

• customer, struggle, benefit, and observable outcome form one coherent statement;
• the experience covers request, confirmation, fulfillment or handoff, status, and recovery;
• the mechanism supports the promise rather than replacing it;
• evidence is sourced, dated, bounded, and separated from assumptions and targets;
• in-scope and out-of-scope conditions are specific;
• fallback, accessibility, quality, safety, privacy, policy, and economic controls are explicit;
• entry criteria, stop conditions, and stop authority are named;
• one DRI integrates the recommendation and contributors own their evidence;
• the decision, remaining risk, dissent, next action, deadline, and review checkpoint are written down.

PR/FAQ output shape

When asked to draft a PR/FAQ, use this order unless the user needs a smaller artifact:

1. Status and scope note (mark fictional, illustrative, draft, or approved as appropriate).
2. Target customer, current struggle, observable outcome, and pilot or product boundary.
3. Future press release: outcome-led headline, who benefits, what becomes possible, honest boundary, and why it matters.
4. Customer experience: request, eligibility or confirmation, fulfillment or handoff, status, and recovery.
5. Customer and internal FAQs covering the hard questions above.
6. Product frame: tenets and non-goals that protect the promise.
7. Evidence and assumption ledger.
8. Metric definitions, baselines, denominators, segments, and illustrative targets clearly labeled.
9. Risks, mitigations, guardrails, and DRIs.
10. Staged experiment plan, bounded recommendation, decision rule, open decisions, and governance record.

Use plain, operational language and compact tables. Make boundaries and failure behavior as concrete as the happy path. If the user asks for a presentation or handout, keep the same reasoning chain but use progressive disclosure: explain why ambiguity is risky, show the six-step loop, walk a bounded case, then end with the experiment plan and decision rights.

Reusing the supplied example

The supplied Digikala case is a model of the method, not a default product proposal. Its useful pattern is: reserve the same-SKU replacement before confirmation, perform a one-visit exchange, preserve a penalty-free standard fallback, keep the pilot narrow and reversible, and require evidence before a live promise. Replace every case-specific customer, policy, geography, volume, target, economic, and operating detail with the user's real context and label assumptions until validated.

Supporting references

Read only the reference that matches the current task:

• Practical playbook for the compact process, quality gates, roles, and failure modes.
• PR/FAQ writing guide for the detailed artifact sections and FAQ lenses.
• Walkthrough facilitation guide for a 90-minute presentation or workshop flow.
• Completed case pattern for the illustrative Digikala example, its evidence ledger, metrics, risks, staged plan, and governance.
• Source PDFs when exact wording, page layout, or source verification is needed. Treat them as read-only reference material.