working-backwards

Original source / Raw SKILL.md

---
name: "working-backwards"
description: "Create an Amazon-style PR/FAQ (future press release + FAQ) plus a backcasting launch plan to align on customer value, scope, and GTM readiness. Use for working backwards, PRFAQ / PR-FAQ, future press release, backcasting, launch plan."
---

# Working Backwards (PR/FAQ + Backcasting)

## Scope

**Covers**
- Turning a product idea into a customer-centric **future press release + FAQ (PR/FAQ)**
- Creating 2–3 divergent PR options to avoid solution lock-in
- Backcasting a launch: a concrete **GTM + operational “machinery” plan** from target date back to today
- Surfacing stakeholders, dependencies, constraints, and risks early

**When to use**
- “Write a PR/FAQ for…”
- “Working backwards from the customer…”
- “Create a future press release / press release from the future”
- “Backcast a launch plan / working backwards timeline”
- “We need alignment on what we’re building before writing a PRD”

**When NOT to use**
- You don’t yet understand the problem and need discovery framing (use `problem-definition`)
- You already have narrative alignment and need detailed requirements (use `writing-prds`)
- You need a build-ready engineering/design spec (use `writing-specs-designs`)
- You’re prioritizing among many initiatives (use `prioritizing-roadmap`)
- You only need marketing copy for an already-built product (this skill is for product decision-making)

## Inputs

**Minimum required**
- Product/context + target customer/user segment
- Problem statement (or symptoms) + why now
- Candidate solution idea(s) (can be vague; options are welcome)
- Constraints: timeline/launch target, platform, policy/legal, dependencies
- Success metrics (1–3) + guardrails (2–5)

**Missing-info strategy**
- Ask up to 5 questions from [references/INTAKE.md](references/INTAKE.md).
- If answers remain missing, proceed with clearly labeled assumptions and provide 2–3 options (PR variants, scope, rollout).

## Outputs (deliverables)

Produce a **Working Backwards Pack** in Markdown (in-chat; or as files if the user requests):

1) **Context snapshot**
2) **PR options:** 2–3 divergent future press releases (1 page each)
3) **Selected PR:** refined future press release
4) **FAQ:** customer + internal (business/ops/technical/legal) FAQs
5) **Backcasting plan:** milestones to launch (owners, dates, dependencies)
6) **Stakeholder + “machinery” plan:** approvals, comms, rollout, support readiness
7) **Success metrics + guardrails** (+ instrumentation notes)
8) **Risks / Open questions / Next steps** (always included)

Templates: [references/TEMPLATES.md](references/TEMPLATES.md)  
Expanded guidance: [references/WORKFLOW.md](references/WORKFLOW.md)

## Workflow (8 steps)

### 1) Intake + decision framing
- **Inputs:** user request; [references/INTAKE.md](references/INTAKE.md).
- **Actions:** Clarify the decision (invest vs not, choose approach), audience, and target launch date/timebox. Capture constraints + stakeholders.
- **Outputs:** Context snapshot.
- **Checks:** You can state the decision and time horizon in one sentence.

### 2) Write the problem paragraph (before any solution)
- **Inputs:** customer segment + evidence; why now.
- **Actions:** Draft “Problem today” in customer language. List top pains and current alternatives/workarounds.
- **Outputs:** Problem paragraph + alternatives bullets.
- **Checks:** Describes pain without specifying implementation; avoids “we want to build X” framing.

### 3) Draft 2–3 divergent future press releases (options)
- **Inputs:** problem paragraph; constraints.
- **Actions:** Create Option A/B/C PRs with different solution shapes. Keep them 1 page each.
- **Outputs:** 2–3 PR drafts.
- **Checks:** Options are meaningfully different; each promises clear customer value; no internal jargon.

### 4) Select the best option and refine to a single PR
- **Inputs:** PR options; decision criteria; stakeholder feedback (if available).
- **Actions:** Pick a winner (or hybrid) and refine the PR for clarity, boundaries, and a concrete “how it works”.
- **Outputs:** Selected PR.
- **Checks:** A stakeholder can restate the benefit and “why now” in one sentence; “who it’s for / not for” is explicit.

### 5) Write the FAQ (customer + internal)
- **Inputs:** selected PR; constraints; dependencies.
- **Actions:** Draft FAQs in sections: customer, business, technical/ops, legal/compliance. Include out-of-scope, risks, and measurement.
- **Outputs:** FAQ section.
- **Checks:** Top objections are answered; open questions are explicitly labeled; no “we’ll figure it out later” hand-waving.

### 6) Backcast: build the launch and “machinery” plan
- **Inputs:** target launch tier/date; FAQ dependencies.
- **Actions:** Create a milestone plan working backward (design, eng, data, legal, docs, support, comms). Define launch tiers and rollback.
- **Outputs:** Backcasting plan + launch tiers/rollback plan.
- **Checks:** Each milestone has an owner + success criteria; major dependencies have a plan.

### 7) Stress-test: pre-mortem + metrics + guardrails
- **Inputs:** PR/FAQ + backcasting plan.
- **Actions:** Run a pre-mortem. List failure modes (trust/safety/quality/cost). Define success metrics + guardrails + instrumentation needs.
- **Outputs:** Risks + metrics/guardrails + validation notes.
- **Checks:** Each major risk has a mitigation/monitor; metrics are computable and owned.

### 8) Quality gate + finalize pack
- **Inputs:** full draft pack.
- **Actions:** Run [references/CHECKLISTS.md](references/CHECKLISTS.md) and score with [references/RUBRIC.md](references/RUBRIC.md). Ensure final section includes risks/open questions/next steps.
- **Outputs:** Final Working Backwards Pack.
- **Checks:** Pack is decision-ready and shareable async (no meeting required).

## Quality gate (required)
- Use [references/CHECKLISTS.md](references/CHECKLISTS.md) and [references/RUBRIC.md](references/RUBRIC.md).
- Always include: **Risks**, **Open questions**, **Next steps**.

## Examples

**Example 1 (B2B SaaS):** “Write a PR/FAQ and backcasting plan for ‘Role-based dashboards’ for enterprise admins, with a beta in 8 weeks.”  
Expected: 2–3 PR options, selected PR/FAQ, and a milestone plan covering security review, instrumentation, docs/support.

**Example 2 (Consumer):** “Work backwards for ‘Saved routes’ in a navigation app; propose two alternative product concepts and pick one.”  
Expected: divergent PRs that surface trade-offs, clear metrics (repeat usage, retention), and guardrails (privacy, battery, safety).

**Boundary example:** “Write a PR/FAQ for ‘use AI’ (no user problem).”  
Response: ask intake questions, redirect to `problem-definition` if needed, and do not pretend to have customer clarity.



---

## Referenced Files

> The following files are referenced in this skill and included for context.

### references/INTAKE.md

```markdown
# Intake (Question Bank)

Ask **up to 5 questions at a time**, then proceed. If answers remain missing, state assumptions explicitly and offer 2–3 options (PR variants, scope, rollout).

## Minimum set (use first)
1) What product + primary customer/user segment is this for?
2) What is the customer problem (or top symptoms) and **why now**?
3) What decision are we making (invest vs not, which approach, what launch tier/by when) and who is the DRI/approver?
4) What constraints are non-negotiable (platform, policy/legal/privacy, dependencies, time/headcount)?
5) What does success look like (1–3 metrics) and what guardrails matter (trust, quality, cost, latency, support load)?

## Helpful follow-ups (pick what’s relevant)

### Alternatives + evidence
- What do customers do today (workarounds, competitors, “do nothing”)?
- What evidence do we have (quotes, data, tickets)? What are we assuming?
- What is the “value moment” the customer gets when this works?

### Launch + GTM “machinery”
- Target launch tiers (internal → beta → GA) and target dates?
- What must be ready at launch: docs, support, sales enablement, marketing site, billing, analytics?
- Which stakeholders/teams can block or constrain this (security, legal, compliance, finance, marketplace ops)?

### Scope boundaries
- What is explicitly out of scope for v1?
- What are the top 3 risky edge cases or abuse/failure modes?
- What dependencies are required and what happens if they slip?

### Packaging + monetization (if relevant)
- Pricing/packaging assumptions? (If unknown, propose 2–3 options.)
- Enterprise requirements: SSO, audit logs, permissions, data retention?


```

### references/TEMPLATES.md

```markdown
# Templates (Copy/Paste)

Use these templates to produce a **Working Backwards Pack**.

## 0) Context snapshot (bullets)
- Product:
- Target customer/user segment:
- Problem today (1–2 sentences):
- Why now (what changed):
- Decision to make (and by when):
- DRI / approver:
- Constraints (timeline, platform, policy/legal, dependencies, capacity):
- Current alternatives / workarounds:
- Success metrics (1–3):
- Guardrails (2–5):
- Target launch tier/date (if known):
- Stakeholders/reviewers:

## 1) PR options (A/B/C) comparison table

| Option | Core promise (customer value) | Key mechanism / concept | Biggest risk | What’s out of scope | Why this could win |
|---|---|---|---|---|---|
| A |  |  |  |  |  |
| B |  |  |  |  |  |
| C |  |  |  |  |  |

## 2) Future press release template (1 page)

- **Release date:** <hypothetical>
- **Headline:** <customer-readable>
- **Summary (2–3 sentences):** <what changed + who benefits>

### Problem today
<pain in plain language + evidence/impact>

### Introducing: <product/feature name>
<what it does, in customer terms>

### Customer quote
“...”

### Company/PM quote
“...”

### How it works (high level)
- …
- …
- …

### Who it’s for / who it’s not for
- For:
- Not for:

### Availability / rollout (assumptions ok)
- Launch tier (internal/beta/GA):
- Eligibility:
- Regions/platforms:

### Pricing/packaging (if relevant; assumptions ok)
- …

## 3) FAQ template (start here)

### Customer FAQs
1) Who is the target customer/user and what’s the primary use case?
2) What does the core user journey look like (happy path)?
3) What are the top limitations or edge cases?
4) What permissions/roles are required (if any)?
5) What are the top alternatives/workarounds today and why is this better?

### Business FAQs
1) Why should we build this now (and what happens if we don’t)?
2) What’s out of scope for v1 (explicit exclusions)?
3) Pricing/packaging assumptions (and how we’ll decide if unknown)?
4) Positioning: how do we explain this in one sentence (internal + external)?
5) Support/sales impact (tickets, training, enablement)?

### Technical/ops FAQs
1) Major dependencies (teams/systems) and required approvals?
2) Reliability/performance expectations (latency, uptime, scale)?
3) Instrumentation plan: what events/metrics must exist at launch?
4) Rollout plan (internal → beta → GA) and rollback triggers?
5) Data handling: privacy, retention, access controls?

### Legal/compliance FAQs (if applicable)
1) What regulatory or contractual constraints apply?
2) Security review required (yes/no) and timeline?
3) Data processing: what data is collected, where stored, who can access?
4) Customer consent and audit/logging requirements?

## 4) Backcasting plan template (milestones)

| Date (or T-minus) | Milestone | Owner | Dependencies | “Done” criteria | Risks |
|---|---|---|---|---|---|
|  |  |  |  |  |  |

## 5) Stakeholder + “machinery” plan

| Stakeholder/team | Why they care | Likely objection | What they need to say “yes” | When to involve | Owner |
|---|---|---|---|---|---|
|  |  |  |  |  |  |

## 6) Final section template (required)

### Risks
- …

### Open questions
- …

### Next steps
1) …


```

### references/WORKFLOW.md

```markdown
# Working Backwards — Expanded Workflow Notes

Use this file when you need more detail than the 8-step workflow in `../SKILL.md`.

## Principles (convert “insights” into rules)

### 1) Start with the customer problem, not a solution
- **Rule:** The PR must contain a “Problem today” paragraph before describing the solution.
- **Anti-pattern:** “We want to build X” → reverse it into “Customers struggle with Y, causing Z.”
- **Check:** If you removed the solution section, the problem paragraph still stands as coherent and compelling.

### 2) Use options to prevent solution lock-in
- **Rule:** Draft 2–3 divergent PR options before committing to one.
- **Check:** Options differ on the core mechanism or value delivery (not just wording).
- **Artifact:** Use the Option A/B/C table in [TEMPLATES.md](TEMPLATES.md).

### 3) Backcasting is about the whole system (“machinery”), not just a doc
- **Rule:** The output must include a backcasting plan with owners, milestones, and dependencies.
- **Check:** Legal/compliance, analytics, docs/support, and rollout are addressed (when relevant).

### 4) Make assumptions explicit and testable
- **Rule:** If key facts are missing, write assumptions as a numbered list and propose 1–3 validation tests.
- **Check:** At least one test can be run before full build (prototype, concierge/WoZ, research, data pull).

## How to draft strong press releases

### Make it customer-readable
- Avoid internal acronyms and org names.
- Lead with the customer outcome, not the feature.
- Keep “How it works” to 3–6 concrete bullets.

### Include boundaries to keep scope honest
- Always include “Who it’s for / not for”.
- Call out “Out of scope for v1” in the FAQ (and optionally the PR).

### Write credible quotes
- Customer quote should reflect a real pain and a measurable/observable improvement.
- Company quote should emphasize customer obsession and why now.

## How to write an FAQ that de-risks execution

Aim for four sections:
1) **Customer FAQs** (use cases, permissions, UX, limitations)
2) **Business FAQs** (pricing/packaging, positioning, sales/support impact)
3) **Technical/ops FAQs** (dependencies, reliability, rollout, rollback, instrumentation)
4) **Legal/compliance FAQs** (privacy, data retention, regulatory constraints, security review)

Prefer concrete answers and explicit unknowns:
- If unknown: “Open question: … Options: A/B/C. Proposed decision owner + date.”

## Backcasting: turning narrative into a plan

### Start from a launch tier and date
Pick a tier (internal, beta, GA) and a date or timebox. If unknown, propose a realistic sequence:
- Internal dogfood → limited beta → GA

### Milestones to include (as relevant)
- Prototype / validation checkpoint
- Engineering milestones (MVP, hardening, scalability)
- Data/instrumentation readiness (events, dashboards, monitoring)
- Legal/privacy/security reviews and sign-offs
- Docs/support readiness + escalation paths
- Comms: release notes, customer emails, sales enablement
- Rollout + rollback plan

## Stress-testing (pre-mortem)

Write: “It’s 6 weeks after launch and this failed. Why?”
Cover at least:
- Adoption failure (wrong segment, weak value)
- Trust/safety/privacy failure (abuse, leakage, bad outcomes)
- Operational failure (support load, edge cases, reliability)
- Business failure (pricing mismatch, cannibalization, margin/cost blow-up)

Then add mitigations + monitoring signals for each.


```

### references/CHECKLISTS.md

```markdown
# Checklists

Use these before you circulate a Working Backwards Pack.

## PR (future press release) checklist
- Problem-first: “Problem today” is clear before any solution language
- Customer language: no internal jargon, acronyms, or org names
- Clear value: headline + summary state who benefits and how
- Concrete “how it works”: 3–6 bullets; not a vague feature list
- Boundaries: “who it’s for / not for” is explicit
- Credible quotes: customer quote reflects a real pain + outcome
- Rollout assumptions are stated (tier/date/eligibility) or flagged as open questions

## FAQ checklist
- Addresses: why now, alternatives, out of scope, risks, success metrics
- Includes internal “machinery” questions (support, docs, analytics, approvals)
- Open questions are labeled with an owner + decision date (not buried)
- No hand-waving: uncertain answers include options (A/B/C) and a proposed path to decide

## Backcasting plan checklist
- Launch tier(s) are defined (internal/beta/GA) with a target date/timebox
- Each milestone has an owner and clear “done” criteria
- Dependencies and sign-offs are listed (security/legal/compliance when relevant)
- Instrumentation and monitoring are included as milestones (not afterthoughts)
- Rollout + rollback triggers are defined

## Common failure modes (use as a red-flag scan)
- Solution-first doc: the “problem” reads like a justification for a predetermined build
- Options are superficial: A/B/C differ only in wording, not in approach
- Missing “machinery”: no owners, dependencies, or plan beyond the PR text
- Undefined success: metrics/guardrails are missing or not computable
- Risks are generic: no specific failure modes or mitigations


```

### references/RUBRIC.md

```markdown
# Rubric (0/1/2 scoring)

Score each item 0/1/2:
- 0 = missing / unusable
- 1 = present but incomplete
- 2 = clear, concrete, decision-ready

Suggested passing bar: **>= 14/18**.

## 1) Customer clarity (0–2)
- Problem today is specific and customer-readable.

## 2) “Why now” urgency (0–2)
- Trigger and timing are credible; opportunity cost is explicit.

## 3) Options quality (0–2)
- 2–3 PR options are meaningfully different and trade-offs are surfaced.

## 4) Selected PR quality (0–2)
- Headline/summary, how-it-works, and boundaries are concrete.

## 5) FAQ completeness (0–2)
- Customer + internal (business/ops/tech/legal) FAQs cover top objections.

## 6) Backcasting plan realism (0–2)
- Milestones, owners, dependencies, and “done” criteria exist and are plausible.

## 7) Metrics + guardrails (0–2)
- Success metrics and guardrails are computable, owned, and connected to the narrative.

## 8) Risk handling (0–2)
- Pre-mortem produces specific failure modes with mitigations/monitors.

## 9) Decision readiness (0–2)
- The pack enables an async “go / no-go / revise” decision; open questions are explicit.


```