home / skills / wdavidturner / product-skills / working-backwards

working-backwards skill

/skills/working-backwards

This skill helps you define customer-centric products by drafting an internal press release and FAQ before building.

npx playbooks add skill wdavidturner/product-skills --skill working-backwards

Review the files below or copy the command above to add this skill to your agents.

Files (17)
SKILL.md
5.0 KB
---
name: working-backwards
description: Use when asked to "working backwards", "PR/FAQ", "Amazon PR/FAQ", "write a press release", "define a new product", or "write a customer-focused PRD". Helps define products by starting with the customer problem and desired outcome before building. The Working Backwards process (developed at Amazon) forces clarity on customer value before committing engineering resources.
---

# Working Backwards

## What It Is

Working Backwards is Amazon's product development methodology. The core insight: **start with the customer problem and work backward to the solution, not the other way around.**

Most teams work forward: "We have this technology/capability/idea — what can we build with it?" Working Backwards inverts this: "What problem does the customer have? What would the ideal solution look like? Now, how do we build it?"

The mechanism: Write an internal press release and FAQ *before* building anything. If you can't write a compelling press release, you don't have a compelling product.

As Jeff Bezos put it: "We took it as an article of faith — if we served customers well, if we prioritized customers and delivered for them, things like sales, revenue, and free cash flow would follow."

## When to Use It

Use Working Backwards when you need to:

- **Define a new product or major feature** before committing resources
- **Evaluate competing product ideas** and choose which to build
- **Align stakeholders** on what you're building and why
- **Force clarity** on vague product concepts
- **Prevent building solutions in search of problems**
- **Create a shared vision** that engineering, design, and leadership can rally around
- **Decide whether an idea is worth pursuing** at all

## When Not to Use It

- The work is incremental optimization (A/B tests, bug fixes)
- You're executing on an already-defined product
- The scope is too small to warrant the overhead
- You're just exploring technical feasibility (do that first, then write the PR/FAQ)

## Patterns

Detailed examples showing how to apply Working Backwards correctly. Each pattern shows a common mistake and the correct approach.

### Critical (get these wrong and you've wasted your time)

| Pattern | What It Teaches |
|---------|-----------------|
| [solution-first-thinking](patterns/solution-first-thinking.md) | Don't start with the solution and retrofit a problem |
| [missing-problem-paragraph](patterns/missing-problem-paragraph.md) | If you skip the problem, there probably isn't one |
| [vague-customer-definition](patterns/vague-customer-definition.md) | "Everyone" is not a customer — be specific |
| [writing-pr-after-building](patterns/writing-pr-after-building.md) | The PR comes first, not as documentation after |
| [internal-jargon-in-pr](patterns/internal-jargon-in-pr.md) | Press releases are for customers, not engineers |

### High Impact

| Pattern | What It Teaches |
|---------|-----------------|
| [faq-avoids-hard-questions](patterns/faq-avoids-hard-questions.md) | The FAQ must address what makes you uncomfortable |
| [hyperbole-instead-of-specifics](patterns/hyperbole-instead-of-specifics.md) | No marketing fluff — use data and concrete claims |
| [customer-quote-sounds-fake](patterns/customer-quote-sounds-fake.md) | Customer quotes reveal whether you understand the job |
| [too-many-features](patterns/too-many-features.md) | One press release, one compelling benefit |
| [no-measurable-outcome](patterns/no-measurable-outcome.md) | Define what success looks like with numbers |
| [combining-ideas](patterns/combining-ideas.md) | One PR/FAQ per idea — don't bundle concepts |

### Medium Impact

| Pattern | What It Teaches |
|---------|-----------------|
| [skipping-the-iteration](patterns/skipping-the-iteration.md) | PR/FAQs improve through concentric circle review |
| [missing-the-date](patterns/missing-the-date.md) | The hypothetical launch date signals ambition and scope |
| [faq-too-short](patterns/faq-too-short.md) | External and internal FAQs serve different purposes |


## Deep Dives

Read only when you need extra detail.

- `references/working-backwards-playbook.md`: Expanded framework detail, checklists, and examples.

## Resources

**Books:**
- *Working Backwards* by Bill Carr and Colin Bryar — the definitive guide from former Amazon VPs
- *The Everything Store* by Brad Stone — context on Amazon's culture and innovation

**Templates:**
- Working Backwards PR/FAQ Template (available at workingbackwards.com)

**Podcasts:**
- Bill Carr on Lenny's Podcast — deep dive on implementing Working Backwards
- Ian McAllister on Lenny's Podcast — practical application of the process

**Other:**
- *Good to Great* by Jim Collins — influenced Amazon's thinking on flywheels and focus
- *The Lean Startup* by Eric Ries — complementary approach to validating ideas

---

*Credit: The Working Backwards process was developed at Amazon, primarily during 2004-2007. Key contributors include Jeff Bezos, Bill Carr, Colin Bryar, Jeff Wilke, and many others. This skill synthesizes insights from Bill Carr and Ian McAllister's interviews on Lenny's Podcast.*

Overview

This skill teaches the Working Backwards product method: define the customer problem and desired outcome first, then design the solution. It guides teams to write a customer-facing press release and FAQ before building. The result is clearer product intent, measurable success criteria, and reduced risk of building solutions in search of problems.

How this skill works

The skill leads you through creating a one-page press release that describes the target customer, the problem, and the single compelling benefit. It then builds an FAQ that confronts hard questions, trade-offs, and success metrics. Use the artifacts to align stakeholders, scope work, and decide whether to proceed before committing engineering resources.

When to use it

  • Defining a new product or major feature before development
  • Evaluating and comparing competing product ideas
  • Aligning cross-functional stakeholders on customer value
  • Forcing clarity when concepts are vague or solution-led
  • Deciding whether an idea is worth investing in

Best practices

  • Write the press release first and treat it as the north star for scope and messaging
  • Define a specific customer and measurable outcomes, not "everyone" or vague benefits
  • Keep the press release focused on one compelling benefit; avoid feature bloat
  • Make the FAQ honest: surface uncomfortable trade-offs and assumptions to test early
  • Iterate PR/FAQ through concentric-review cycles before design and engineering work begins

Example use cases

  • A PM needs to choose between three competing feature bets and justify one with customer outcomes
  • A startup founder wants to validate product-market fit before hiring engineers
  • A product leader wants a clear launch narrative and measurable success criteria for a major initiative
  • A team is stuck in solution-first thinking and needs to reframe around customer jobs-to-be-done
  • Preparing a go/no-go decision for a roadmap item with documented assumptions and risks

FAQ

What if the team has a technical architecture already?

Working Backwards still applies: document the customer problem and ideal outcome first, then map which existing technical choices support that outcome. If architecture drives the idea, reconsider the customer need.

How long should a PR/FAQ take to produce?

A first draft can be written in a few hours to a day; meaningful iteration with stakeholders usually takes several review cycles over a week or two depending on scope.