Write the Press Release First
Before building anything, write the launch press release as if the product shipped today.
- Difficulty
- Easy
- Time to result
- ~weeks to results
- Steps
- 3
- Confidence
- 88%
A forcing function for product definition: the very first artifact a PM produces is not a spec but the finished product's press release, written as though it launches today. Drafting what you'd tell users forces a thorough articulation of the value proposition before a line of code is written, keeping the team anchored to the customer problem rather than the technology.
Origin
Attributed by Shweta Shrivastava to Amazon's working-backwards / PR-FAQ process, which she used as a PM there and considers highly effective. She notes Waymo has its own version and other companies are adopting the practice; the underlying tenet is working backwards from the customer problem.
Core principles
- 01Work backwards from the customer or user problem, not from the technology
- 02Building technology for its own sake doesn't go far
- 03Force the value proposition to be articulated before building
- 04Know who you're building for and what problem you're solving before you start
How to run it
- 1
Write the press release before building
As the first step of the project, write the press release for the finished product as if it is launching today — describe what you're telling users about it.
Pro tip Frame it entirely from the user's point of view: what changes for them, in plain language.
- 2
Pressure-test the value proposition
Use the draft to force the team to think through the value proposition more thoroughly — if the press release is unconvincing, the product idea isn't ready.
Watch out A press release that only excites the builders, not the users, is a signal the customer problem isn't real enough.
- 3
Adapt the format to your product flavor
Different product types (technically deep vs. commercially focused) need their own version of working backwards, but all keep the customer problem as the core tenet.
Pro tip Keep the ritual even when the artifact format changes — the discipline of working backwards is the point.
In the wild
Shweta recounts that at Amazon, PMs 'have to write a press release for the finished product even before they start building the product' — the first thing they do is write it as if the product is about to launch today, describing what they'd tell users.
→ The practice forced PMs to think through the value proposition thoroughly; Shweta found it very effective and carried the working-backwards tenet across companies.
Common mistakes
Building technology for its own sake
Starting from a cool capability rather than a customer problem produces products that don't go far, because no clear user value was defined up front.
Treating 'work backwards' as a platitude
The phrase has become such a cliché in product that teams say it without practicing it; skipping the actual press-release artifact means the value proposition never gets rigorously articulated.
Is it for you?
Best for
Product managers and founders starting a new product or feature who want to validate the value proposition before committing engineering resources.
Not ideal for
Small incremental changes or bug fixes where a full press-release exercise would be overhead, or exploratory research where the customer problem is deliberately still being discovered.
From the transcript
“you have to work backwards from the customer problem or the user problem right uh building a technology for the sake of it is you…”
“Amazon has this um great process where the PMS have to write uh a press release for the finished product even before they start building…”
“that's the first thing that they have to do is to write their press release like the products about to launch today right what are…”
From the episode
Product lessons from Waymo
Shweta Shrivastava (Waymo, Amazon, Cisco)