Sign inGet started
Skills / Product-strategy

Working Backwards

We try to work backwards from the customer, rather than starting from what we're good at making and figuring out where to sell it. Working backwards from customer needs often demands that we acquire new competencies and exercise new muscles, never mind how uncomfortable and awkward-feeling those first steps might be.

Working Backwards is Amazon's customer-obsessed product development methodology, codified by Colin Bryar and Bill Carr from their years inside Amazon. Instead of starting with available technology or internal capabilities, teams write a fictional press release announcing the finished product — from the customer's point of view — before a single line of code is written. This PRFAQ discipline forces rigorous clarity on who the customer is, what problem they have, and why the solution matters, eliminating costly pivots later.

By Colin Bryar · Free
Specimen 01 · Live diagnosisWorking Backwards
Input

“We want to build an AI-powered expense reporting tool for finance teams. We have the ML infrastructure already, so we figured we could…”

Diagnosis
Working Backwards starts before the roadmap, before the sprint, before the architecture diagram.
Full transcript ↓
Calibrated referenceagent-skills.ai
The gap

Write the press release before you write the code — start at launch day

Working Backwards centers on the PRFAQ — a Press Release plus Frequently Asked Questions document — written before development begins. The press release has eight prescribed sections (heading, subheading, summary, the problem, the solution, an internal leader quote, a getting-started description, and a customer testimonial quote) and must be written entirely from the customer's perspective in plain language. Paired with it are External FAQs (questions real customers would ask) and Internal FAQs (business, cost, risk, and dependency questions). A separate artifact — the Six-Pager Narrative Memo — replaces PowerPoint for every significant meeting or proposal; attendees read it in silence before discussion begins ('the study hall'). The methodology also defines Single-Threaded Leadership, where every initiative is owned end-to-end by one undistracted person, and prescribes tracking input metrics (the leading indicators teams control) rather than output metrics (lagging results).

The problem

Most product teams build what they can build, then look for customers — a pattern Bryar and Carr call 'working forwards.' The result is roadmaps driven by engineering availability, features nobody asked for, and expensive late-stage pivots when the product reaches real users. Without a forcing function that makes teams articulate the customer's problem and the emotional payoff of the solution before any resources are committed, strategy documents remain vague and alignment stays shallow.

The solution

By writing the press release first, you lock in a customer-first definition of success that every stakeholder has reviewed and approved — so the team builds toward a concrete launch narrative, not a moving target.

You bring
  • A product idea, feature proposal, or initiative you want to define
  • A description of the target customer and the problem they face (even a rough one)
  • Any business constraints or context relevant to the Internal FAQ (cost assumptions, team size, timeline)
  • An existing spec, deck, or brief you want to convert into Working Backwards format
You get
  • A complete, section-by-section PRFAQ document ready for stakeholder review
  • An External FAQ that anticipates real customer objections and questions
  • An Internal FAQ that surfaces business risks, P&L assumptions, and operational dependencies
  • A Six-Pager Narrative Memo suitable for a strategy meeting or leadership review
  • A mapped list of input metrics you can directly control, separated from lagging output metrics
In action

Watch the methodology work.

Three specimens from a single real session: the same situation, unaided and calibrated, the full transcript, and the skill answering live in the channel where the work happens.

Fig.01The same situation, two ways
Specimens A · B
Specimen AVague
Unaided

“Your team has a compelling product idea and a capable engineering team. You've written a 15-slide deck with a market opportunity slide, a feature list, and a go-to-market section. The slides look polished, but in the review meeting three executives ask three different questions about who the target customer actually is — and you realize nobody's written it down in a sentence anyone agrees on.”

×Vague — nothing concrete to act on.
Specimen BCalibrated
With Working Backwards

“After a Working Backwards session, you have a one-page PRFAQ with a customer testimonial section that reads: 'I used to dread month-end close. Now I open it like any other morning.' Every stakeholder has reviewed and marked up the document before a sprint was planned. Your Internal FAQ has forced you to write down the build cost estimate and the biggest technical risk — in writing, with mitigations. The team is building toward a specific launch announcement they can all recite.”

Specific, grounded, and ends with one clear next step.
Fig.02A real session, unedited
In-app · assistant
Working BackwardsClaude
Working Backwards
Working Backwards starts before the roadmap, before the sprint, before the architecture diagram. The first question isn't 'what should we build?' — it's 'who is the customer, and what problem are we solving for them?' Tell me about the product or initiative you're working on. What customer are you thinking about, and what's the pain they're experiencing?
We want to build an AI-powered expense reporting tool for finance teams. We have the ML infrastructure already, so we figured we could auto-categorize receipts and flag policy violations automatically.
That's a working-forward framing — you're starting from what your ML infrastructure can do and looking for a use case. Let's flip it. Forget the infrastructure for a moment. Who is the customer experiencing the most pain in the expense reporting process right now — is it the employee submitting receipts, the finance team reviewing them, or both? And what is the most frustrating moment in their week because of how expense reporting currently works?
Honestly, it's the finance manager. She spends about 6 hours every month chasing down employees for missing receipts and correcting miscategorized expenses before the books close. It's the same errors every cycle.
That's your customer. Now let's write the press release — specifically the Problem paragraph, which is the emotional core of the whole PRFAQ. It should articulate her pain so accurately that she'd read it and say 'yes, exactly.' Here's a draft to react to:
The Problem: Every month-end close, finance managers at mid-sized companies lose days chasing the same preventable errors: missing receipts, personal charges submitted as business expenses, and amounts coded to the wrong cost center. These mistakes aren't malicious — employees are busy and expense policy is hard to remember. But fixing them falls entirely on the finance team, delaying the close and creating a recurring cycle of friction between finance and the rest of the organization.
Does that capture her actual pain, or is something off?
That's almost exactly right. The 'same preventable errors every cycle' part is particularly accurate — she says it herself. The delay to close is a real pain too, she has a hard deadline with the CFO.
Perfect — that's your problem paragraph locked. Now the Solution paragraph must be the flip side: what does life look like for this finance manager after she's been using your product for three months? Write it as if you're describing a real outcome, not a feature list. Something like: 'With [Product Name], the finance manager opens month-end with a clean expense queue — real-time policy alerts caught violations at submission, not at review, and AI-assisted categorization reduced miscoding by 80%. The close that used to take three extra days now happens on schedule.' What part of that resonates, and what should change?
The 'caught at submission not at review' framing is exactly our product's key insight. That's what makes us different — we intervene before the damage is done, not after.
Reply to Working Backwards
What the skill is doing
01PRFAQ Builder
02Working-Forward Detector
03Six-Pager Narrative Workshop
Fig.03The same skill, in the channel you already use
WhatsApp · live
9:41
WBWorking Backwardstyping…
Messages are end-to-end encrypted. No one outside of this chat can read them.
Today
We want to build an AI-powered expense reporting tool for finance teams. We have the ML infrastructure already, so we figured we could auto-categorize…9:14✓✓
Working Backwards starts before the roadmap, before the sprint, before the architecture diagram.9:14
The first question isn't 'what should we build?' — it's 'who is the customer, and what problem are we solving for them?' Tell me a…9:15
What customer are you thinking about, and what's the pain they're experiencing?9:15
Message

The same skill, where the work happens.

No new app to learn. The methodology runs over the WhatsApp Business API, so the answer lands as a reply in the thread you’re already in — same rigour, zero context-switch.

Reads the situation, names the pattern, returns one concrete next move.
Delivered in seconds, inside a conversation that already exists.
Specimen · WhatsApp Business API · live
Capabilities

What it does, specifically.

Each capability is a distinct move drawn straight from the source methodology — not a generic assistant guessing.

CapabilityC-01

PRFAQ Builder

Guides you section by section through the full PRFAQ document: heading, subheading, summary, the problem paragraph, the solution paragraph, the internal leader quote, the getting-started description, and the imagined customer testimonial. Each section is reviewed against Bryar's standards — plain language, customer perspective, no jargon — before moving to the next.

Based on the eight-section press release structure documented in 'Working Backwards,' which must be iterated and approved by stakeholders before any development begins.
CapabilityC-02

Working-Forward Detector

Analyzes your product idea or existing spec to identify 'working-forward' assumptions — places where the logic starts from a capability, technology, or business constraint rather than from a customer need. Reframes each one using the customer-back lens.

Directly applies Bryar and Carr's central diagnostic: distinguishing 'working forwards' (technology-first) from 'working backwards' (customer-first) as described in Chapter 1 of the book.
CapabilityC-03

Six-Pager Narrative Workshop

Helps you write a complete Six-Pager Narrative Memo — Amazon's required format for meetings, proposals, and strategy reviews — structured as full prose paragraphs that build a coherent argument, not bullet-point slides. Includes coaching on the silent 'study hall' reading protocol for distributing the memo in meetings.

Based on Amazon's mandate, documented by Bryar, that all significant meetings require a written narrative memo (max six pages) read in silence at the start of the session to eliminate the vagueness inherent in presentation decks.
CapabilityC-04

External & Internal FAQ Drafting

Separately drafts the two FAQ sections of the PRFAQ: External FAQs anticipate real customer questions about pricing, availability, and how the product works; Internal FAQs surface the hard business questions — estimated cost to build, P&L implications, organizational dependencies, risks, and mitigation plans.

Follows Bryar's explicit distinction between external-facing and internal-facing FAQ sections, each serving a different audience and requiring different levels of business-model depth.
CapabilityC-05

Input Metric Identification

Works with you to define the input metrics — the leading-indicator activities your team directly controls — and distinguish them from output metrics (revenue, NPS, retention) that are lagging results you can only influence. Maps controllable inputs to each desired output.

Applies the input-metrics-vs-output-metrics framework from 'Working Backwards,' which Bryar argues is the key to building accountability structures that teams can actually act on.
Tested

Graded before it shipped.

Every skill is scored against independent scenarios for methodology fidelity before it goes live — not vibes, a rubric.

What it produces
OutputD-01

Working Backwards PRFAQ Document

A complete, submission-ready PRFAQ with all eight press release sections plus annotated External and Internal FAQ sections — formatted so it can be dropped directly into a team review or stakeholder approval process.

OutputD-02

Six-Pager Narrative Memo

A full narrative prose memo covering the strategic situation, proposed approach, key tradeoffs, and recommended decision — structured for a silent-read meeting opening and written to stand alone without the author presenting it.

OutputD-03

Input vs. Output Metrics Map

A structured table separating the metrics your team can directly control (inputs) from the lagging outcomes you're trying to move (outputs), with suggested tracking cadences and owners for each input.

OutputD-04

Single-Threaded Owner Charter

A one-page charter defining the scope, decision rights, success criteria, and resource commitments for a Single-Threaded Owner (STO) leading a new product initiative — built to clarify accountability from day one.

The source

Grounded in the original work.

Every answer traces back to a real source and the practitioner who wrote it — not a secondhand summary. Here is the source of record.

Source authorA-01

Colin Bryar

Colin Bryar served as Jeff Bezos's Chief of Staff and Technical Advisor — Amazon's 'shadow' role — from 2003 to 2005, giving him a front-row seat to how Amazon's core management practices were forged and applied. He subsequently led multiple Amazon divisions before leaving to co-author 'Working Backwards' (2021) with former Amazon VP Bill Carr. The book draws on insider case studies including the launches of Amazon Prime, Kindle, and AWS.

Status · Inspired by Colin Bryar’s work — not yet claimed. Are you Colin Bryar?
Primary sourceS-01

Working Backwards: Insights, Stories, and Secrets from Inside Amazon

by Colin Bryar
Bestseller
Read the original ↗
Citationworkingbackwards.com
In the build queue

Be first to run it.

Working Backwards is being built right now. Leave your email and we’ll tell you the moment it goes live.

Notify meEmail
At launchI want to work backwards on a new product idea. I've been thinking about it in terms of what we could build, but I want to reframe it from the customer's perspective and write a proper PRFAQ. Can we start with the customer problem?