Write the Press Release Before You Write a Line of Code

Most teams write documentation to justify what they’ve already decided to build. Amazon’s Working Backwards method forces the order the other way round: write the press release first, then earn the right to build the product it describes.

The mechanics are simple to state and hard to do well. Before development starts, the team drafts a mock press release announcing the finished product, addressed to the customer rather than leadership. Former Amazon director Ian McAllister’s version requires the product’s name, the intended customer, the problem it solves, the benefit to that customer, a quote explaining why the company built it, and a call to action, often with an FAQ addendum covering the tactical and business questions behind the scenes. McAllister is blunt about the real work: a team spends far more time cutting and revising the document than writing the first draft, and it isn’t finished until it’s short, clear, and genuinely makes the case.

The instinct is that speed comes from skipping documentation and getting straight into building an MVP, a deck, a sprint.

Amazon’s internal practice runs in the opposite direction. Meetings open with twenty minutes of silent reading of a six-page narrative memo instead of a slide deck, specifically because full sentences force an argument to actually hold together in a way that bullet points let you fake. The PR/FAQ applies the identical logic to a proposition before it exists: writing a press release in plain customer language is a far harder test than listing features, and if nobody on the team can draft one they’re genuinely excited about, that’s the signal, cheaper by far than discovering the same gap three sprints into a build. This isn’t a slower route to speed. It’s the actual gate.

Design at Scale™ already asks for a version of this test inside Proposition Shaping, and the PR/FAQ sharpens it in a specific way: our Proposition Identification Document proves a proposition to business, design, and engineering, an internal audience. A press release proves the same proposition to the person who has to want it, a different and sharper test, since jargon that survives an internal review rarely survives a sentence written for a stranger. Two more of Amazon’s practices align with principles we already document independently, which is worth naming rather than treating as a coincidence. Amazon’s Single-Threaded Leader, one person with undivided focus on one initiative, is close to identical to our own Design Shaping requirement for a Single Point of Contact with Engineering: “regardless of project size, there should be only one.” And the Two-Pizza Team, small enough to stay genuinely accountable, is the same instinct behind our Method’s One Team habit at the Accelerate stage: a proposition owned by everyone is owned by no one. Two further Amazon principles round out the picture even though this piece keeps its focus on the PR/FAQ itself: Bar Raisers, experienced reviewers brought in specifically to hold a hiring decision to a higher standard than the hiring manager alone would, echo the same instinct as our Journal’s own “On Quality” reflection, that quality erodes fastest under deadline pressure unless something structural protects it. And Amazon’s explicit embrace of failure as a source of learning sits close to our Journal’s “Let It Go”, the practice of treating a cancelled or reworked project as data rather than defeat.

“We don't have time to write a press release for something we haven't built”

Is the most common objection, and McAllister’s own point answers it directly: drafting a mock announcement costs a fraction of what building an MVP or running a full survey round costs, and discovering you’re not excited to write it is far cheaper feedback than discovering it after launch.

“This is just Amazon culture, it won't translate to us”

Is the second. AWS’s own case studies argue otherwise: QsrSoft, a hospitality software vendor with nowhere near Amazon’s resources, used the same working-backwards discipline to build a real-time staff messaging product during the pandemic, and one franchisee saw participation in a linked charity campaign rise over 1,100% through the feature it produced. The method scales down as readily as it scales up.

“We already have a PRD, isn't this redundant?”

Is the third, and it misreads what each document is for. A PRD documents requirements for people already inside the project. A press release tests whether the same proposition survives being explained to someone who has never heard of it and has no reason to keep reading. Run both, side by side, and the gaps between them tell you exactly where the proposition is still fuzzy.

The tool matters less than the discipline underneath it: write for the customer, in full sentences, before you write a single line of code for the engineer. If nobody on the team can draft that press release with genuine enthusiasm, that’s the most honest signal available that the proposition isn’t ready yet.

Before you write another requirements document, try writing the press release first. One page, aimed at your actual customer, no jargon. If it’s boring to write, it’ll be boring to use. More Supply resources at designatscale.co/spy.

REFERENCES

• ProductPlan, “Working Backwards (the Amazon Method)”
• Agile Academy (Sohrab Salimi), “The 10 Most Important Insights from ‘Working Backwards' by Colin Bryar”
• AWS Smart Business Blog (Ben Schreiner),” 'Working Backwards’ to Drive Customer Experience and SMB Innovation Forward”
• Bryar, C. & Carr, B. (2021) Working Backwards: Insights, Stories, and Secrets from Inside Amazon
• Design at Scale™ Book & Journal (internal)

SUMMARY

• The PR/FAQ forces a proposition to be written in plain customer language before any building starts — a sharper test than an internal requirements document.
• Amazon’s six-page narrative memos, rather than slide decks, apply the same “full sentences force real arguments” logic used throughout Working Backwards.
• Two Amazon practices converge independently with DaS™ principles already documented: Single-Threaded Leader ≈ Single Point of Contact with Engineering; Two-Pizza Teams ≈ One Team.
• AWS’s own SMB case studies (QsrSoft, Tradeling) show the method scaling down to businesses with far fewer resources than Amazon’s.
• A PRD and a press release target different audiences — running both side by side exposes exactly where a proposition remains unclear.

https://www.figma.com/community/file/1383948067509934454/das-working-backwards-pr