working-backwards — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited working-backwards (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
A product development method pioneered at Amazon: start from the customer experience and work backwards to the technology. The centerpiece is the PR/FAQ document — a fictional press release and FAQ written before a single line of code, forcing clarity of thought about who benefits, why they care, and what could go wrong. Includes a built-in pre-mortem step based on Gary Klein's prospective hindsight technique.
If you can't write a compelling press release, you don't understand the product yet. Writing forces thinking. A PR/FAQ written at the start — not the end — of a project exposes fuzzy thinking, missing logic, and unjustified assumptions before any resources are committed. If the press release is boring, the product will be boring.
The Working Backwards process inverts the typical development flow:
Traditional: Idea → Build → Launch → Explain to customers
Amazon: Customer need → PR/FAQ → Debate → Build only if compellingGoal: 10/10. When reviewing a PR/FAQ or product proposal, rate it 0-10:
| Score | Description |
|---|---|
| 0-2 | No written proposal. Idea is a verbal pitch or a slide deck with bullet points. |
| 3-4 | Written proposal exists but reads like an internal spec. Customer benefit is vague. No FAQ. |
| 5-6 | PR/FAQ format used but the press release is generic, FAQ avoids hard questions, no pre-mortem. |
| 7-8 | Strong PR/FAQ. Clear customer, specific benefit, honest FAQ, identifies key risks. |
| 9-10 | Exceptional. Press release makes you want the product. FAQ addresses every tough question. Pre-mortem reveals non-obvious risks with mitigations. The document alone could be used to decide go/no-go. |
Core concept: A fictional press release announcing the finished product as if it already exists. Written before any design or code, in the voice and format of a real press release a journalist might publish on launch day.
Why it works: Press releases force you to lead with the customer benefit in plain language. You cannot hide behind architecture diagrams, internal jargon, or feature lists. If the headline is boring, the product is boring — and you find that out in 2 hours of writing, not 6 months of building.
Key insights:
Structure:
| Section | Content | Length |
|---|---|---|
| Heading | Product name + customer benefit in one line | 1 sentence |
| Subheading | Who the customer is + what they can now do | 1 sentence |
| Opening paragraph | Summary: what it is, who it's for, why it matters | 3-4 sentences |
| Problem paragraph | The customer problem or pain point (in the customer's words) | 3-4 sentences |
| Solution paragraph | How the product solves it — specific, concrete, no jargon | 3-4 sentences |
| Quote from leader | Why the company built this (vision, mission alignment) | 2-3 sentences |
| How it works | Simple explanation a customer can follow | 3-4 sentences |
| Quote from customer | A fictional customer describing the benefit they experienced | 2-3 sentences |
| Call to action | How to get started | 1 sentence |
Rules:
Product applications:
| Context | Application | Example |
|---|---|---|
| New product idea | Write PR before any design work | Forces "what's the headline?" thinking before "what's the architecture?" |
| Feature proposal | Write a mini-PR for significant features | "Acme launches auto-save: never lose your work again" |
| Pivot decision | Write PR for the pivot and compare to current direction | If the pivot PR is more compelling, that's a signal |
Copy patterns:
Ethical boundary: The press release must describe a product you genuinely intend to build. Never use PR/FAQ as a marketing exercise for vaporware. If the PR describes capabilities you can't deliver, you're not working backwards — you're fabricating forwards.
See: references/press-release-writing.md
Core concept: Two paired Q&A sections that accompany the press release — an external FAQ written from the customer's perspective, and an internal FAQ written for stakeholders making the build/don't-build decision.
Why it works: The press release is aspirational; the FAQ is where honesty lives. By forcing yourself to list and answer the uncomfortable questions in writing, you surface the assumptions, risks, and unit economics that would otherwise stay buried until launch. The FAQ is the document's stress test.
External FAQ (customer perspective):
Internal FAQ (business perspective):
Key insights:
Copy patterns:
Ethical boundary: Never omit FAQ questions because the answers are unfavorable. The FAQ's value is proportional to its honesty. If an internal FAQ answer reveals a fatal flaw, that's the FAQ doing its job — not a reason to delete the question.
See: references/faq-construction.md
Core concept: A structured failure imagination exercise based on Gary Klein's prospective hindsight technique. After writing the PR/FAQ, assume the product has launched and failed, then work backwards from failure to identify what went wrong — and what you can do now to prevent it.
Why it works: By the time you've written a compelling PR and an honest FAQ, you're emotionally invested in the idea. The pre-mortem is the structured antidote to optimism bias. Klein's research (1989) showed that imagining an event has already happened makes people roughly 30% better at identifying reasons for outcomes than asking "what might go wrong?" in the abstract.
The Pre-Mortem Protocol:
Prompt: "It is [12 months from now]. This product launched and failed
to meet its goals. Customers didn't adopt it. The team is disappointed.
What went wrong?"Generate 5-7 failure scenarios across these categories:
| Category | Question | Example failure |
|---|---|---|
| Customer | Did we solve a real problem? | "Users didn't have this problem often enough to change behavior" |
| Market | Is the timing/competition right? | "A well-funded competitor launched the same thing 2 months before us" |
| Execution | Can we actually build and ship this? | "The ML model never achieved the accuracy we assumed in the PR" |
| Business model | Do the economics work? | "Customer acquisition cost was 3x what we modeled" |
| Adoption | Will people switch? | "Users were too entrenched in their current workflow to migrate" |
| Internal | Does the organization support this? | "The sales team couldn't explain the product and stopped selling it" |
For each failure scenario, specify:
Key insights:
Product applications:
| Context | Application | Example |
|---|---|---|
| Go/no-go decision | Pre-mortem reveals deal-breakers before committing resources | "3 of 5 failure scenarios are High likelihood — rethink before proceeding" |
| Risk planning | Convert mitigations into sprint-zero tasks | "Build a competitive monitoring dashboard before launch" |
| Team alignment | Share pre-mortem to build shared understanding of risks | Team sees risks they individually sensed but never voiced |
Ethical boundary: The pre-mortem must be genuinely open-ended. Never write it to rubber-stamp a decision already made. If the pre-mortem reveals fatal risks, take them seriously.
See: references/pre-mortem-protocol.md
| Step | Action | Time |
|---|---|---|
| 1 | Write the Press Release (1 page) | 2-4 hours |
| 2 | Write the FAQ — external + internal (2-5 pages) | 4-8 hours |
| 3 | Run the Pre-Mortem (1 page) | 1-2 hours |
| 4 | Circulate for feedback — silent reading, written comments | 1 week |
| 5 | Revise based on feedback | 2-4 hours |
| 6 | Decision meeting: go / no-go / revise | 1 hour |
Key insights:
| Mistake | Why It Fails | Fix |
|---|---|---|
| Writing the PR after building | Defeats the purpose — it's a rationalization, not a thought tool | Write the PR as the very first step, before any design or code |
| Jargon in the press release | If customers can't understand it, you don't understand it | Read it to someone outside the team. If they're confused, rewrite. |
| Softball FAQ questions | Avoids the hard questions that kill projects later | Include every question that makes you uncomfortable |
| Skipping the pre-mortem | Optimism bias goes unchecked; risks surface too late | Always do the pre-mortem. It takes 1 hour and can save months. |
| Treating PR/FAQ as a formality | Going through motions without genuine debate | If the go/no-go meeting is always "go," the process is broken |
| Solo authorship | One person's blind spots become the project's blind spots | Product trio writes together; diverse perspectives improve quality |
| Question | If No | Action |
|---|---|---|
| Can you state the customer benefit in one sentence? | Idea isn't clear enough | Write the PR headline first — if you can't, keep thinking |
| Would a customer understand your press release? | Too much insider language | Rewrite in the customer's words |
| Does your FAQ include questions you're afraid to answer? | You're avoiding hard truths | Add 3 uncomfortable questions and answer them honestly |
| Have you run a pre-mortem? | Optimism bias is unaddressed | Spend 1 hour imagining failure — identify top 5 risks |
| Has anyone outside the team read the document? | Echo chamber risk | Share with a skeptic and incorporate their feedback |
Colin Bryar and Bill Carr are former Amazon executives. Bryar served as Jeff Bezos' "shadow" (Technical Advisor) for two years. Carr led the launch of Amazon's digital media businesses including Prime Video and Amazon Music. Together they spent 27 years at Amazon and witnessed the development of its distinctive management practices firsthand.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.