Working Backwards: PR/FAQ

Purpose

Guide the user through the Amazon Working Backwards process to produce a professional PR/FAQ document. The output is a LaTeX file that compiles to a polished PDF suitable for executive review and product decision-making. The process forces clarity about customer value, surfaces risks early, and creates a shared artifact for go/no-go decisions.

When to Use

• Evaluating whether a new product or feature is worth building
• Forcing specificity on a vague product idea
• Preparing a product pitch for leadership review
• Testing whether a team truly understands the customer problem
• Structuring a go/no-go decision with an auditable artifact

Revise Mode

Before starting the full workflow, check if a prfaq.tex file already exists in the project root (or the path the user specifies). If it does, enter revise mode instead of starting from scratch.

1. Read the existing document. Parse the .tex file to understand what's already written — the press release, FAQs, and risk assessment.

2. Ask what to revise. Present the user with the sections found and ask what they want to improve. Common revision goals:

   • Refine the product — sharpen the problem statement, solution, or differentiation based on new thinking
   • Incorporate research — thread new primary data (customer interviews, market analysis, survey results) into existing sections. Run Phase 0 research discovery to find new materials.
   • Add FAQs — add new external or internal FAQ pairs to cover questions that came up in review
   • Strengthen evidence — replace inferred claims with primary data, add citations, improve specificity
   • Update risk assessment — revise risk ratings based on new information or changed assumptions
   • Revise feature appendix — move features between must/should/won't categories as scope evolves

3. Edit surgically. Only modify the sections the user wants changed. Read the existing .tex file, make targeted edits, and preserve everything else. Do not regenerate the entire document.

4. Recompile and review. After edits, run the compile script and present the changes for review. If the compile script reports overfull hbox warnings, fix them before presenting (see Phase 4 for common fixes). Offer to re-run the peer reviewer (Phase 3c) on the revised document. Offer further iteration.

If the user explicitly asks to start a new PR/FAQ (not revise), proceed to the full workflow below even if a document exists.

Workflow

Stage and Version Detection

When working with an existing document (revise mode), read the .tex file and extract:

• Stage via \prfaqstage{value}. Valid stages: hypothesis, validated, growth. If absent, assume hypothesis.
• Version via \prfaqversion{major}{minor}. If absent, add \prfaqversion{1}{0} to the preamble.

Stage affects evidence expectations throughout the workflow:

• Hypothesis — Pre-validation. No primary customer data required. Logical consistency and testable assumptions matter most. [CITATION NEEDED] markers are acknowledged gaps, not failures.
• Validated — Post-interviews or post-testing. Customer interviews and usability data expected in the FAQs. TAM should have real data sources. Risk ratings should reflect actual evidence, not assumptions.
• Growth — Existing product with users. All claims should be data-backed. Usage analytics, churn rates, and unit economics should come from real operations, not projections.

The press release customer quote is fictional at all stages — it is an aspirational portrait of the customer experience, not a real testimonial. At hypothesis stage, it needs only to be plausible. At validated stage, it should be informed by interview insights. At growth stage, it should be informed by real usage patterns. The evidence for customer demand lives in the FAQ section, never in the press release quote. See pr-structure.md for details.

Phase 0: Research Discovery

Before asking the user any questions, look for primary research that should ground the entire document.

1. Scan for research materials. Use Glob to check for ./research/**/* in the project root. If the directory exists, list the files found (PDFs, markdown, text, etc.).

2. If research files are found:

   • Read and summarize each file (prioritize .md, .txt, .pdf; skip binary files that aren't PDFs).
   • Present a summary to the user: "I found these research sources in ./research/. Here's what they contain..." Ask which are relevant to this PR/FAQ.
   • Extract key data points: customer quotes, pain points, market sizing, competitive intel, usage metrics, survey results.

3. If no research directory exists:

   • Ask the user: "Do you have primary research — customer interviews, survey data, market analysis, competitive intelligence, or usage analytics — that should inform this PR/FAQ? If so, you can place files in ./research/ or paste key findings directly."
   • If the user provides data inline, capture and organize it the same way.

4. Invoke the researcher agent. Use the Task tool with subagent_type: "prfaq:researcher". Pass the user's product description and any specific claims or topics to investigate. The researcher autonomously discovers ./research/ files (including its own prior results), searches the web for claims not already cached, and queries any available MCP data providers (quarry-mcp, financial data servers, etc.). Results are persisted to ./research/ for future runs.

   The researcher returns three sections:

   • Evidence Found — per-claim verdicts (supported/contradicted/unsupported) with sources and recommendations
   • Bibliography Entries — ready-to-append biblatex entries
   • Research Gaps — claims where no evidence was found, with suggested actions

   After receiving the results:

   • Create the .bib file (same directory and basename as the .tex file — e.g., prfaq.tex → prfaq.bib) with the bibliography entries the researcher returned.
   • Present the findings to the user: what was supported, what was contradicted, what gaps remain.
   • The user can also invoke the researcher standalone later via /prfaq research to verify specific claims or find additional evidence.

5. Carry forward. Compile all discovered research into a working context that you reference throughout Phases 1–5. Specifically thread research evidence into:

   • Problem section — evidence of customer pain
   • Customer evidence FAQ — primary data over inferred claims
   • TAM/market FAQ — real market sizing where available
   • Competitive landscape FAQ — named competitors and positioning
   • Risk assessment — note which risk assessments are grounded in primary data vs. inferred
   • Flag any claims in the final document that are unsupported by available evidence.

Phase 1: Discovery

Before writing anything, gather the inputs that make a PR/FAQ credible. If Phase 0 found research, use it to sharpen these questions — ask about specific customer segments, pain points, or competitors surfaced in the research rather than asking generic questions.

Ask the user these questions (adapt based on what they've already shared and what research revealed):

1. Stage — What stage is this product at? Ask via AskUserQuestion with three options:

   • Hypothesis — Pre-validation. No users yet, testing whether the idea is worth building.
   • Validated — Post-interviews or post-testing. Some real evidence, iterating on a proven concept.
   • Growth — Existing product with users and data. Adding features or repositioning.

   Set \prfaqstage{value} in the .tex preamble based on the answer (always lowercase: hypothesis, validated, or growth). This calibrates evidence expectations for peer review and meetings.

2. Customer — Who is the specific target customer? What is their role, context, and daily reality?

3. **Pr