hs-product-requirement-doc

HS Product Requirements Doc — Skill

A guided workflow for Product Managers and Product Marketing Managers to co-create a complete PRD with an embedded Solution Story. Produces two outputs in one document.

On startup: Read knowledge/INDEX.md first. Load only the subfolder(s) relevant to the current task. Do not load everything at once.

---

⓪ PMM CONTEXT — LOAD FIRST

Before intake, check .agents/product-marketing-context.md.

If it exists — load silently:

• ## Product Strategy Canvas → Vision, Trade-offs, and Key Metrics as anchors
• ## ICP Prioritisation → pre-fill target customer section
• ## Buyer Committee Personas → inform stakeholder mapping in the PRD
• ## Positioning → sharpen Solution Story framing
• ## Revenue Levers → confirm feature aligns to priority lever

Confidence awareness: If Product Strategy Canvas is 🔴, flag:

"Product Strategy is marked Placeholder — the PRD may lack strategic grounding. Update context first?"

If missing: Proceed. Surface once:

"Run hs-product-marketing-context BUILD first — PRDs without strategy context miss the 'why now'. Continuing."

RELATED SKILLS

Cross-reference these skills when building PRDs:

• hs-brainstorm-okrs → feature PRDs should align with quarterly project OKRs
• hs-gaccs-brief → PRD Solution Story feeds directly into the launch campaign brief
• experiment-doc-builder → risky assumptions in the PRD → suggest an experiment doc

---

Outputs

#	Output	Primary Owner	When to share it
1	Solution Story	PMM	Before engineering kicks off — aligns team on the 'why'
2	Full PRD	PM + PMM	Throughout discovery, design, and launch

---

Workflow

Step 1 — Identify where the user is starting from

When this skill triggers, first ask:

"Are you starting from scratch, or do you already have some notes / a brief / an existing doc I should work from?"

• If scratch → run the intake interview (Step 2)
• If existing content → read it, extract what's already answered, then ask only for gaps (Step 2, targeted)
• If a specific section only → jump directly to that section and generate it

Before running intake, check knowledge/false-beliefs/catalog.md — if the user's framing contains a known weak pattern (vague problem statement, missing success metric, announcement level mismatch), surface it immediately rather than letting it persist into the document.

---

Step 2 — Intake interview

Ask these questions conversationally, not all at once. Group them into two rounds.

Round 1 — Core info (ask these together):

1. What is the feature or initiative name?
2. Who is the target customer / user persona?
3. What problem does it solve? (Even a rough answer is fine — we'll sharpen it.)
4. What's the one outcome you most want to achieve?

Round 2 — Depth (ask after Round 1 is answered): 5. What evidence do you have that the problem is real? (data, quotes, tickets) 6. Who is on the team? (PM, PMM, Design, Engineering Lead) 7. What's the rough timeline or key dates? 8. Is there an experiment / A/B test planned, or is this a direct rollout? 9. What announcement level is this? (P1 Major / P2 Notable / P3 Improvement / P4 Minor)

If the user says "just get started" or seems impatient, use what you have and fill gaps with clearly labelled placeholders. Never block on perfect information.

Consult knowledge/craft/patterns.md before generating — confirmed patterns about what makes problem statements, pitches, and user stories land should inform every section.

---

Step 3 — Generate Output 1: Solution Story

Once Round 1 is complete, generate the Solution Story first. This is the PMM-led narrative that anchors the full PRD.

Solution Story structure

## Solution Story — [Feature Name]

### Feature Identity
- Feature Name: [name]
- Tagline (1–2 words): [tagline]
- Short Value Description: [one sentence — what it does and why it matters]
- Announcement Level: [P1 / P2 / P3 / P4 + one-line rationale]

### The One-Paragraph Pitch
[4–6 sentences. Open with what's broken about existing solutions. Explain what
this product does differently. Close with the key customer benefit. Confident,
clear, slightly opinionated. No jargon.]

### Press Paragraph
[3–4 sentence press-ready version, or N/A if same as above]

### Customer Proof Points
1. [Insight] — [supporting quote or data] (Source: [X])
2. [Insight] — [supporting quote or data] (Source: [X])
3. [Insight] — [supporting quote or data] (Source: [X], optional)

Writing rules for the pitch:

• Start with the broken status quo — don't open with "Introducing…"
• Name the pain specifically: who feels it, how often, what it costs them
• The solution sentence should feel inevitable given the problem
• End on the customer outcome, not the product feature
• Read it aloud — if it sounds like a press release, simplify it

---

Step 4 — Generate Output 2: Full PRD

After the Solution Story is confirmed or accepted, generate the full PRD. Use the structure below. Every section should either be filled with real content from the intake or clearly marked [TO FILL — hint about what goes here].

Full PRD structure

---

Document Header

• Feature Name:
• Author:
• Date:
• Version: v1.0
• Status: Draft

---

Section 00 — Team

Role	Name	Responsibility
Product Manager (PM)		Owner
Product Marketing Manager (PMM)		Owner
Design		Contributor
Engineering Lead		Contributor
Analytics		Contributor
Stakeholder / Exec Sponsor		Approver

---

Section 01 — Solution Story Summary (PMM)

Pull from Output 1. Paste tagline, value description, and pitch here so engineers and stakeholders see the 'why' before reading requirements.

---

Section 02 — Problem & Background (PM + PMM)

2.1 Problem Statement

• Who: [specific segment]
• Problem: [concrete, observable struggle]
• Evidence: [data, quotes, tickets — linked]
• Secondary Issues: [knock-on problems]

2.2 Market Opportunity (PMM)

• Market Size / TAM:
• Trend (why now):
• Competitor landscape:
• Our differentiation:

2.3 User Personas (PMM)

• Primary Persona: [name, role, top 3 frustrations, current workaround, JTBD]
• Secondary Persona: [if applicable]

---

Section 03 — Goals & Success Metrics (PM)

Type	Metric	Baseline	Target	Timeframe
Output (North Star)
Input 1 (Leading)
Input 2 (Leading)
Input 3 (Leading)

Non-Goals:

• [What's out of scope and why]

Strategic Alignment:

• Company OKR / Goal:
• Synergies:
• Risk if not built:

---

Section 04 — Requirements & User Stories (PM)

High-Level Solution (2–3 sentences — what we're building and how it works)

Milestones:

• Phase 1 — MVP: [scope + date]
• Phase 2 — V2: [scope + date]
• Phase 3 — Future: [backlog ideas]

User Stories:

Priority	User Story	Benefit
P0 Must Ship	As a [user], I want [capability]…	…so that [benefit]
P0 Must Ship	As a [user], I want [capability]…	…so that [benefit]
P1 Should Ship	As a [user], I want [capability]…	…so that [benefit]
P1 Should Ship	As a [user], I want [capability]…	…so that [benefit]

Open Questions:

• [Question — @owner — due date]

---

Section 05 — User Experience (PM + Design)

• Figma / Prototype Link:
• Design Principles:
• Key UI Components:
• User Journey (entry → core flow → success state → edge cases):
• Accessibility standard (WCAG AA/AAA):

---

Section 06 — Technical Requirements (Engineering Lead)

• Tech Stack:
• System Architecture:
• Key Integrations / APIs:
• Security Considerations:
• Performance Benchmarks:
• Scalability Notes:

---

Section 07 — Launch Plan (PMM + PM)

Experiment Design (if applicable):

• Success Criteria:
• Eligibility:
• Test Group:
• Control Group:
• Split:
• Minimum Duration:

Rollout Plan:

Phase	Audience	Duration	Watch Metric	Go / No-go Owner
1	Internal / Alpha (5%)			PM
2	Beta (25%)			PM + PMM
3	GA (100%)	Ongoing		PM + PMM

Rollback Criteria:

• Trigger Metric:
• Threshold:
• Decision Owner:
• Rollback Process:

Go-to-Market (PMM):

• Messaging Headline:
• Target Channels:
• Key Dates:
• Sales Enablement:
• Support Documentation:

---

Section 08 — Milestones & Risks (PM)

Key dates: Discovery → Design sign-off → Engineering kickoff → Alpha → Beta → GA → Post-launch review

Risk	Likelihood	Impact	Mitigation
	High/Med/Low	High/Med/Low

---

Section 09 — Sign-Off

Role	Name	Approval	Date
PM
PMM
Design Lead
Engineering Lead
Exec Sponsor

---

Step 5 — Collaboration checkpoints

Surface these moments explicitly when generating the PRD. Insert a clearly labelled 🤝 PM + PMM checkpoint comment at:

1. After §01 — before filling §02–§04: "Run a 30-min kick-off sync. PM confirms the pitch is technically accurate. PMM flags messaging risks from early constraints."
2. After §04 user stories — before engineering kickoff: "PMM reviews P0 stories. Can you build launch messaging from these alone? Any gaps vs what's been promised to customers?"
3. At §07 launch plan — when scope is finalised: "GTM handoff meeting. PM brings final scope + experiment design. PMM brings draft copy + sales enablement. Align on go/no-go criteria."

---

Step 6 — Output format

• Default output: clean markdown, structured for copy-paste into Google Docs or Notion
• If the user asks for a .docx file, refer to the docx skill
• Always produce both outputs (Solution Story first, then Full PRD) in the same response unless the user asks for one specifically
• Label every placeholder clearly: [TO FILL — e.g. paste customer quote here]
• Never leave a section silently blank — either fill it or explain what's needed

---

Writing Principles

Problem statements — be specific. "New users churn" is weak. "New users who signed up via organic search churn at 42% on Day 2 when their first feed session shows zero content matching their stated interests" is strong.

Pitches — open with the broken status quo, not "Introducing X". The problem should feel so obvious that the solution feels inevitable.

User stories — write the benefit as a real outcome, not a restatement of the feature. "So that I can see topics" is weak. "So that my feed feels relevant from the moment I sign up" is strong.

Metrics — one output metric, two to three inputs with causal logic. If you can't explain why moving an input will move the output, it's the wrong input.

Non-goals — these are not a dump of "things we won't do forever." They are a specific, time-bounded list of what's out of scope for this release and why.

---

Learning Mode

Run this at the end of any session where a full PRD or Solution Story was produced, a section was significantly revised, or the user corrected the output. Never mid-task. Only at natural close.

Step 1 — Pattern check Did this session surface evidence for or against anything in knowledge/hypotheses/active.md? If yes: update the relevant hypothesis with a one-line evidence note and current signal strength.

Step 2 — Knowledge update Did a confirmed pattern emerge (3+ consistent data points)? If yes: propose adding it to knowledge/craft/patterns.md. Did a belief get killed by data or repeated correction? If yes: propose moving it to knowledge/false-beliefs/catalog.md with a note on what was observed — including which section triggered it.

Step 3 — Session log Ask once: "Log this session? [yes/no]" If yes: append a 3-line summary to knowledge/sessions/log.md:

• What was produced (PRD, Solution Story, specific section, or full doc)
• What was accepted without revision / what got rewritten or pushed back
• One pattern to watch

Do not pad. Three lines only.

---

Self-Improvement Trigger

If you notice a pattern across three or more sessions that contradicts a current instruction in this SKILL.md, surface it explicitly before the session closes:

"Observation: [what I'm seeing across sessions]. This conflicts with: [current instruction]. Suggested update: [proposed change]. Approve?"

Do not silently adapt. Surface it so the human decides.

---

Reference

For sample prompts, filled-in examples, and PM + PMM collaboration scripts, refer the user to: hs_prd_sample_prompts.md