I spent years at Amazon and Amazon Web Services. The "Working Backwards" process is genuinely one of the best product development frameworks I've encountered. It's also one of the most misunderstood — by people inside the company and by the large number of people outside who've read about it secondhand.
What It Actually Is
Working Backwards starts with the customer and works toward the product, rather than starting with a technology or idea and working toward a market. The primary artifact is the PR/FAQ: a mock press release announcing the finished product, followed by a Frequently Asked Questions document that covers both customer questions and internal questions from skeptical stakeholders.
The press release forces clarity. It requires you to articulate who the customer is (specifically, not abstractly), what problem they have, what your product does, and why it's meaningfully better than what exists. You write it before you've built anything — which means you have to actually think.
The FAQ forces honesty. The internal questions section is where you surface the hardest objections: why hasn't someone done this already, what happens if a competitor copies it, what do we get wrong in our first version, what does this cannibalize. Writing good internal FAQs is uncomfortable. That's the point.
What People Get Wrong
The most common misapplication I see is treating the PR/FAQ as a communication artifact rather than a thinking tool. Teams write polished press releases that describe the product they already decided to build — the document becomes a rationalization exercise, not a discovery exercise.
Working Backwards only works if you're genuinely willing to kill the idea based on what you learn writing the document. If the answer to "who is the specific customer this serves" is "enterprise customers broadly," you haven't done the work. If the answer to "why will customers switch from the existing solution" is "because ours is better," you haven't done the work.
The discipline is in the precision. Amazon's best PMs can name the customer — not a persona but an actual representative customer — and describe their day before the product exists and after. That granularity forces decisions that vague customer definitions let you avoid.
The Part That Transferred to My Work Outside Amazon
I've used adapted versions of Working Backwards at every role since leaving Amazon — at Fidelity, at Wells Fargo, and in my own ventures. The format changes but the discipline doesn't: define the customer specifically, articulate the job they're trying to do, describe the outcome they want, and only then work back to what you need to build.
The biggest transfer is in executive conversations. When I walk into a QBR or a strategy session with a customer-first narrative — here is the specific person this serves, here is the specific friction it removes, here is what success looks like for them — the conversation changes. Stakeholders stop debating features and start debating whether we've correctly understood the customer. That's a much more productive debate.
At AWS, I used this framing to help enterprise customers structure their own internal AI and cloud business cases. Instead of leading with technology ("we want to implement Amazon Bedrock"), we'd lead with the customer problem ("our financial advisors spend 40% of their time retrieving client information that should be instantly accessible"). The technology became the enabler of a clearly articulated customer outcome — which is a completely different conversation with a CFO than "we want to invest in AI."
Where It Falls Short
Working Backwards is a pre-product-market-fit tool. It's excellent for scoping new initiatives and stress-testing product assumptions. It is less useful once you're in market and need to respond to what you're actually learning from customers at scale.
It also breaks down in highly exploratory research contexts where you're genuinely trying to discover what the problem is rather than validate a hypothesis you already have. The structure of the PR/FAQ assumes you have a hypothesis worth stress-testing. If you don't yet know what you're solving for, you need ethnographic research before you need a press release.
But for the thing it was designed for — rigorously defining a product worth building before you commit resources to building it — it remains one of the best frameworks I've used. The core idea transfers even if you never write a formal press release: start with the customer, make the problem specific, define what success looks like for them, and work backwards from there.
Everything else is execution.
