Help us improve
Share bugs, ideas, or general feedback.
From build-like-amazon
Guides product development using Amazon's Working Backwards methodology, from customer insight through PR/FAQ creation. Starts with 5 Customer Questions for lightweight validation before committing to a full cycle.
npx claudepluginhub robisson/build-like-amazon-agent-skillsHow this skill is triggered — by the user, by Claude, or both
Slash command
/build-like-amazon:working-backwardsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Working Backwards is Amazon's signature product development methodology. Instead of starting with a technology or business idea and finding customers for it, you start with the customer and work backwards to the technology. The output is a PR/FAQ document that describes the finished product as if it already exists, written from the customer's perspective. If you can't write a compelling press r...
Guides customer-first product discovery through the Working Backwards 5-stage process (Listen, Define, Invent, Refine, Test) to produce 5CQ, PR/FAQ, or Dear Customer Letter artifacts.
Generates PR/FAQ documents for product ideas using Amazon's Working Backwards process, starting from customer press release to validate worth building before speccing.
Guides writing a PR/FAQ press release and FAQ for product clarity and customer-centric thinking, following Amazon's Working Backwards process.
Share bugs, ideas, or general feedback.
Working Backwards is Amazon's signature product development methodology. Instead of starting with a technology or business idea and finding customers for it, you start with the customer and work backwards to the technology. The output is a PR/FAQ document that describes the finished product as if it already exists, written from the customer's perspective. If you can't write a compelling press release, you don't yet understand what you're building or why it matters.
The process has 5 stages, each with a clear deliverable that must pass review before advancing:
┌─────────────────────────────────────────────────────────────────┐
│ WORKING BACKWARDS FLOW │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ LISTEN │───▶│ DEFINE │───▶│ INVENT │───▶│ REFINE │ │
│ │ │ │ │ │ │ │ (PR/FAQ) │ │
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │
│ │ │ │ │ │
│ ▼ ▼ ▼ ▼ │
│ Customer Problem Solution PR/FAQ │
│ Insights Statement Selection Document │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ TEST & │ │
│ │ ITERATE │ │
│ └──────────────┘ │
│ │ │
│ ▼ │
│ Success Metrics │
│ & Experiments │
└─────────────────────────────────────────────────────────────────┘
Before committing to a full PR/FAQ, answer these 5 questions in 1-2 sentences each. This takes 30 minutes, not 3 weeks, and tells you whether the idea has enough substance to invest in a full Working Backwards cycle.
| Situation | Start With |
|---|---|
| Brainstorming session, exploring multiple ideas | 5CQ for each idea, then pick 1-2 for full WB |
| Clear mandate from leadership with defined customer | Jump to Stage 1 (Listen) with full process |
| Hack-a-thon or innovation sprint | 5CQ → rapid PR (no FAQ yet) |
| Annual planning, new product line | Full WB process, all 5 stages |
| Feature addition to existing product | 5CQ to validate, then abbreviated Refine stage |
| Cross-team initiative needing alignment | Full WB process — the PR/FAQ is the alignment mechanism |
At Amazon, no significant product investment begins without a Working Backwards document. The PR/FAQ is not a formality — it is the decision artifact. Leadership reviews the document (not a slide deck, not a verbal pitch) and makes investment decisions based on it. A PR/FAQ goes through multiple revisions (often 10-20 drafts) before it is approved. This is intentional: the writing process forces clarity of thought that slides and verbal discussions never achieve.
The mechanism works because:
Jeff Bezos: "If you can't write a clear press release, you can't think clearly about what you're building."
Each stage of Working Backwards has a mandatory human approval gate. The agent MUST NOT advance to the next stage without explicit user confirmation.
After completing each stage, the agent:
| Stage | Output Presented | Approval Question |
|---|---|---|
| Listen | Customer Insight Summary | "Does this customer profile look right? Want to adjust?" |
| Define | Problem Statement | "Does this problem statement capture it? Want to refine?" |
| Invent | Solution Recommendation | "Do these alternatives make sense? Happy with the chosen solution?" |
| Refine | PR/FAQ Document | "Review this PR/FAQ. What needs changing?" |
| Test & Iterate | Success Framework | "Are these success metrics right?" |
⛔ An agent that produces a PR/FAQ without showing Listen, Define, and Invent outputs first has violated the process.
Question: "Who is the customer and what insights do we have?"
Question: "What is the customer's problem or opportunity?"
Question: "What is the solution? Why this one over alternatives?"
Question: "How do we describe this so clearly that any reader understands the customer value?"
Question: "How will we measure success?"
Do you have a clear customer segment with data?
├── No → Start at Stage 1 (Listen)
├── Yes
│ Do you have a validated problem statement?
│ ├── No → Start at Stage 2 (Define)
│ ├── Yes
│ │ Do you have a recommended solution with alternatives analysis?
│ │ ├── No → Start at Stage 3 (Invent)
│ │ ├── Yes
│ │ │ Do you have a reviewed PR/FAQ?
│ │ │ ├── No → Start at Stage 4 (Refine)
│ │ │ └── Yes → Start at Stage 5 (Test & Iterate)
| Intention | Mechanism |
|---|---|
| "We'll talk to customers eventually" | Stage 1 requires documented customer conversations or data before Stage 2 begins |
| "Everyone knows what the problem is" | Stage 2 requires a written problem statement reviewed by someone outside the team |
| "We'll figure out the details as we build" | Stage 4 PR/FAQ must be approved before engineering begins |
| "We'll add metrics later" | Stage 5 success criteria are defined before any code is written |
| "Leadership already approved this verbally" | No investment without a written PR/FAQ — verbal approvals are not commitments |
| What They Say | Why It's Wrong | What To Do Instead |
|---|---|---|
| "We don't have time for a full PR/FAQ" | A PR/FAQ takes 2-4 weeks; building the wrong thing takes 6-12 months | Start with 5CQ (30 min). If the idea survives, invest in the full document |
| "The technology is ready, we just need to ship it" | Technology-first thinking is how you build features nobody wants | Write the press release first. If it's not compelling, the technology doesn't matter |
| "Our customers can't articulate what they want" | Customers can't design solutions, but they absolutely can describe their problems | Focus Stage 1 on observing behavior and pain points, not asking for feature requests |
| "The user seems to know what they want, I'll skip to PR/FAQ" | Skipping stages is how you build the wrong thing faster. Every stage exists to surface assumptions and force rigor. Even experts benefit from disciplined sequencing | Complete every stage in order. Present each output. Wait for approval. No shortcuts |
| "This is an internal tool, we don't need WB" | Internal users are customers too. They have the same need for clarity on value | Use the same process with internal customers. The press release is an internal announcement |
| "We already know this will work — [competitor] did it" | Copy-paste from competitors is not customer obsession. Their customers ≠ your customers | Validate that YOUR customers have this problem. Then solve it better, not the same |
Before approving a Working Backwards initiative to proceed to engineering:
.proto), async / events (AsyncAPI), data (ODCS), MCP, or agent tools — pick the standard that matches the protocol, not OpenAPI by default. This is the bridge between Working Backwards and API First — the customer outcome is the why, the API is the contract that delivers it.