From pmm-execution
Builds, guides, and co-writes a complete HubSpot Product Requirements Document (PRD) with an embedded Solution Story. Use this skill whenever a user mentions PRD, product requirements, solution story, feature spec, GTM brief, launch plan, product brief, user stories, feature rollout, announcement level, or asks for help writing up a product idea, feature, or initiative. Also trigger when a PM or PMM asks how to structure a product document, align on messaging, define success metrics, or plan a feature launch — even if they don't use the word "PRD". This skill produces two tangible outputs: (1) a standalone Solution Story for PMM-led communications, and (2) a full collaborative PRD for PM + PMM.
How this skill is triggered — by the user, by Claude, or both
Slash command
/pmm-execution:prdThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
A guided workflow for Product Managers and Product Marketing Managers to co-create a
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.
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 leverConfidence 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 BUILDfirst — PRDs without strategy context miss the 'why now'. Continuing."
Cross-reference these skills when building PRDs:
| # | 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 |
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?"
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.
Ask these questions conversationally, not all at once. Group them into two rounds.
Round 1 — Core info (ask these together):
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.
Once Round 1 is complete, generate the Solution Story first. This is the PMM-led narrative that anchors the full PRD.
## 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:
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].
Document Header
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
2.2 Market Opportunity (PMM)
2.3 User Personas (PMM)
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:
Strategic Alignment:
Section 04 — Requirements & User Stories (PM)
High-Level Solution (2–3 sentences — what we're building and how it works)
Milestones:
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:
Section 05 — User Experience (PM + Design)
Section 06 — Technical Requirements (Engineering Lead)
Section 07 — Launch Plan (PMM + PM)
Experiment Design (if applicable):
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:
Go-to-Market (PMM):
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 |
Surface these moments explicitly when generating the PRD. Insert a clearly labelled
🤝 PM + PMM checkpoint comment at:
.docx file, refer to the docx skill[TO FILL — e.g. paste customer quote here]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.
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:
Do not pad. Three lines only.
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.
For sample prompts, filled-in examples, and PM + PMM collaboration scripts, refer the user to: hs_prd_sample_prompts.md
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.
npx claudepluginhub stefanoskarakasis/product-marketing-skills --plugin pmm-execution