Working Backwards: The Complete Guide

What Working Backwards means

Most teams work forward: they start with what they can build - a technology, a feature, a capability they already have - and push it toward a market. Working Backwards inverts that. You start from the customer and the outcome they want, then reason backward to the smallest thing you could build to deliver it.

The forcing function is a document, not a meeting. Before a line of code is written, the team drafts a PR/FAQ - a mock press release for the finished product plus the questions it will raise. If the idea can’t be made compelling on paper, it almost certainly won’t be compelling in production. You catch the weak idea in a document instead of in a launch.

Why Amazon works backwards

Amazon adopted the method because traditional planning rewards the wrong thing: a confident slide deck. Slides hide vague thinking behind bullet points. A narrative press release does the opposite - it exposes fuzzy customers, soft problems, and benefits that don’t actually beat the status quo. As Bryar and Carr describe it, the press release is a “forcing function” that keeps the team obsessed with the customer rather than with their own cleverness.

The PR/FAQ, explained

PR/FAQ stands for Press Release + Frequently Asked Questions. It has two parts:

• The press release - about one page, written in plain language as if the product just launched. It names the customer, states the problem, describes the solution, and includes a realistic customer quote. No jargon, no internal metrics.
• The FAQ - the harder half. It splits into customer questions (How much does it cost? How do I start?) and stakeholder questions (What does this cost us to build? What’s the biggest risk? Why now?). Honest answers here are what separate a real idea from a hopeful one.

Want the format with an annotated example? See How to write a PR/FAQ, or browse real PR/FAQ examples.

The process, step by step

1. Start from the customer. Write down exactly who they are and the problem you’re solving - before any solution.
2. Write the press release. Announce the finished product: headline, sub-headline, the problem, the solution, and a customer quote that only makes sense if the product is genuinely good.
3. Write the FAQ. Answer the customer questions, then the questions a skeptical board would throw at you. Don’t dodge the uncomfortable ones - they’re the point.
4. Run the so-what test. Read it cold and ask whether this is meaningfully better than the alternative.
5. Turn it into a PRD. Once it holds up, expand it into a product requirements document an engineer can build from.

The so-what test

This is the heart of the method. After writing the press release, read it and ask: so what? Is the product meaningfully better, faster, easier, or cheaper than what the customer does today? If the honest answer is “not really,” the fix is never better wording - it’s a better idea. Change the inputs (the customer, the problem, or the solution) and write it again.

Common mistakes

• Writing it after you’ve decided. The document is for deciding, not for justifying a decision already made.
• Marketing language. Superlatives hide weak thinking. Write like a journalist, not a brochure.
• Skipping the hard FAQs. The stakeholder questions are where ideas live or die.
• One draft. A good PR/FAQ is rewritten several times as the inputs sharpen.

FAQ

Write the press release before you write the code

Turn your idea into an Amazon-style PR/FAQ, a scored verdict, and a PRD - free to start.

Start your PR/FAQ