aj-geddes/bmad-prfaq

BMAD PRFAQ

Role: Pre-Phase Analysis — Working-Backwards stress-test

Function: Guide the user through the Amazon Working-Backwards method to produce a PRFAQ document (prfaq.md) that crystallises the product vision, validates the concept, and surfaces hard questions before a PRD, architecture, or a single line of code is written.

When to Use This Skill

Use when you need to:

• Validate a product concept before committing to a PRD or sprint plan
• Write a future press release that forces clarity on customer value
• Stress-test assumptions with a structured internal FAQ
• Prepare customer-facing answers before launch
• Update or validate an existing PRFAQ document
• Choose a BMAD planning track (the PRFAQ often precedes or replaces the product brief for Working-Backwards teams)

The Working-Backwards Method

Working-Backwards starts from the desired customer outcome and reasons backward to the product. The PRFAQ has two parts:

| Part | Purpose | |------|---------| | Press Release | Articulate the customer value as if the product already shipped | | Internal FAQ | Surface hard business and technical questions the team must answer | | External FAQ | Anticipate questions a curious customer or press contact would ask |

The process forces concrete answers to the hardest questions now, not after months of building.

Three Intents

This skill supports three modes. Identify intent from context:

| Intent | Trigger | Output | |--------|---------|--------| | Create | No existing PRFAQ; new concept | Full prfaq.md from scratch | | Update | Existing PRFAQ; requirements changed | Revised prfaq.md with decision log entry | | Validate | Draft PRFAQ exists; needs critique | Critique report; annotated checklist |

Core Workflow

1. Orient (all intents)

• Check output folder for existing prfaq.md, project-context.md, and decision-log.md.
• Confirm intent with the user (Create / Update / Validate).
• For Create: proceed to Step 2.
• For Update: read existing doc, identify changed sections, proceed to Step 4.
• For Validate: read existing doc, run the Validation Checklist (see below), produce a critique; stop — do not rewrite unless the user asks.

2. Gather (Create / Update)

Ask the minimum questions needed to fill the template. Stop after each cluster and confirm before moving on. Suggested clusters:

Cluster A — Customer & Problem

• Who is the target customer (role, segment, context)?
• What is the specific problem or unmet need?
• How do they currently cope without this product?

Cluster B — Product & Value

• What does the product do in one sentence?
• What is the single most important customer benefit?
• What measurable outcome does the customer achieve?

Cluster C — Differentiation & Availability

• How is this different from existing solutions?
• When and how will customers get it?
• What is the call to action at launch?

Cluster D — Hard Questions (Internal)

• What are the top 3 risks or unknowns?
• What must be true technically for this to work?
• What does success look like in 6 months? 12 months?

Cluster E — Customer Questions (External)

• What will customers ask first?
• What might make them hesitate?
• What evidence or proof do they need?

3. Draft Press Release

Use the template at ${CLAUDE_PLUGIN_ROOT}/skills/bmad-prfaq/templates/prfaq.template.md.

Fill in order:

1. Headline — product name + primary customer benefit in one line
2. Subheadline — who it is for and the key outcome
3. Opening paragraph — problem context (2-3 sentences)
4. Problem paragraph — paint the pain without naming the solution
5. Solution paragraph — introduce the product and its core capability
6. Benefit paragraphs — 2-3 paragraphs, one key benefit each
7. Customer quote — a realistic quote from a named persona
8. Call to action — how to get it, when, what to do next
9. Company quote — internal leader framing strategic intent

Keep the press release under 600 words. If you cannot keep it short, the concept is not clear enough — ask more questions.

4. Draft Internal FAQ

10-15 questions that the leadership team, investors, or a skeptical engineer would ask. Required question categories:

• Market: Why now? How large is the opportunity?
• Customer: How do we know this is a real problem?
• Business model: How does this make or save money?
• Technical: What are the hardest engineering problems?
• Risk: What are the top 3 ways this fails?
• Metrics: What does success look like at 30/90/180 days?
• Alternatives considered: What else did we consider and why not?
• Dependencies: What must exist before we can ship?

Answers must be specific. "We will figure it out" is not acceptable.

5. Draft External FAQ

5-10 questions that a customer, journalist, or analyst would ask at launch. Cover: pricing/access, privacy/security, compatibility, support, roadmap.

6. Assemble and Write

Assemble the three sections into prfaq.md in the output folder.

File path: {outputFolder}/prfaq.md

7. Log Decision (Create / Update)

Append a concise entry to {outputFolder}/decision-log.md:

• Date
• Intent (Created / Updated)
• Key decisions captured in the PRFAQ
• Open questions deferred to PRD phase

8. Recommend Next Steps

Suggest the appropriate BMAD track and next skill:

• If the PRFAQ is thin (few stories expected): Quick Flow → hand off to product-manager for a tech spec.
• If the PRFAQ is solid (multi-epic product): BMAD Method → hand off to product-manager for a PRD, then system-architect.
• If the PRFAQ reveals strategic uncertainty: recommend another round of creative-intelligence research before proceeding.

Validation Checklist

When intent is Validate (or as a self-check before finalising):

• [ ] Headline names a specific customer benefit (not a feature)
• [ ] Press release stays under 600 words
• [ ] Customer quote sounds like a real person, not marketing copy
• [ ] Internal FAQ has at least 10 questions with specific answers
• [ ] Internal FAQ includes at least one "how does this fail?" question
• [ ] Internal FAQ includes success metrics at 30/90/180 days
• [ ] External FAQ anticipates hesitation (not just enthusiasm)
• [ ] All open questions are explicitly labelled as open (not papered over)
• [ ] No implementation details in the press release section
• [ ] Document does not include velocity, story points, or burndown charts

Output Quality Standards

A complete PRFAQ must:

• Be readable by a non-technical executive and a skeptical engineer
• Surface at least 3 genuine open questions (not rhetorical ones)
• Be grounded in specific customer language, not internal jargon
• Avoid commitments to specific technical approaches (that is architecture's job)
• Be 1,000–2,500 words total (press release + both FAQs)

Subagent Strategy

Pattern: Sequential gather, parallel draft

For large or complex products where multiple customer segments exist, fan out FAQ drafting across segments:

| Agent | Task | Output | |-------|------|--------| | Agent 1 | Draft Internal FAQ (business/market/risk questions) | {outputFolder}/prfaq-internal-faq-draft.md | | Agent 2 | Draft External FAQ (customer/press questions) | {outputFolder}/prfaq-external-faq-draft.md |

Coordination:

1. Complete Clusters A–E interactively (sequential).
2. Write gathered context to {outputFolder}/prfaq-inputs.md.
3. Draft press release in main context (short, judgment-intensive).
4. Launch Agent 1 and Agent 2 in parallel with shared inputs.
5. Main context reviews both FAQ drafts, merges, and writes prfaq.md.

Example subagent prompt (Internal FAQ agent):

Task: Draft the Internal FAQ section of a PRFAQ document.
Context: Read {outputFolder}/prfaq-inputs.md for the product concept, customer
         segments, risks, and success metrics gathered from the user.
Objective: Produce 10-15 internal FAQ questions and specific answers covering
           market opportunity, customer validation, business model, technical
           risk, success metrics, alternatives considered, and dependencies.
Output: Write draft to {outputFolder}/prfaq-internal-faq-draft.md.
Constraints:
- Answers must be specific, not aspirational placeholders.
- Include at least one "what are the top ways this fails?" question.
- Include success metrics at 30, 90, and 180 days.
- Do not include implementation code or technical architecture decisions.

Integration

Receives input from:

• business-analyst (product brief, discovery notes)
• creative-intelligence (research, brainstorm outputs)
• User (direct concept description)

Provides output to:

• product-manager (PRFAQ feeds into PRD creation)
• system-architect (open technical questions from internal FAQ)
• decision-log.md (decisions recorded for future skills)

Tips for LLMs

• Use TodoWrite to track the cluster-by-cluster gather process.
• Ask one cluster of questions at a time; do not dump all questions at once.
• If the user is vague, use WebSearch to ground the problem in real market data before drafting (cite sources in the internal FAQ).
• The press release must be written as if the product has already launched — use past-tense achievements, not future promises.
• Customer quotes should sound human. Revise until they pass the "would a real person say this?" test.
• Do not proceed to architecture or story creation from this skill. Hand off.

---

Part of the BMAD Planning & Orchestrator plugin — a Claude Code harness for the BMAD Method by the BMAD Code Organization (https://github.com/bmad-code-org/BMAD-METHOD). Implements the spirit of bmad-prfaq. All methodology credit belongs to the BMAD Code Organization.