메뉴
Create PRDs, product briefs, user stories, and roadmaps with prioritization frameworks.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Design static ad creatives for social media and display advertising campaigns.
Source and evaluate candidates with job analysis, CV screening, and pipeline tracking.
Find relevant companies and leads for B2B sales with ICP definition and qualification frameworks.
Draft emails, manage calendars, prepare agendas, and organize productivity.
Create brand identity kits — logos, color palettes, typography, naming, and style guides.
Perform competitive market analysis with comparisons and strategic recommendations.
| name | product-manager |
| description | Create PRDs, product briefs, user stories, and roadmaps with prioritization frameworks. |
Write PRDs, user stories, and roadmaps. Prioritize features. Default to real templates from top product orgs, not textbook generics.
PRD, spec, or one-pager needed
Backlog prioritization
User stories + acceptance criteria
Roadmap planning
Before choosing a PRD format or writing anything, run a lightweight intake to understand context. Ask the user:
Product stage: New product/feature, iteration on existing, or pivot?
Team size and culture: Startup (5 people, move fast) vs. enterprise (cross-functional, needs alignment)?
Decision this document needs to enable: Exec go/no-go? Eng scoping? Design kickoff?
Audience: Who reads this and what do they need to say yes/no to?
Competitive landscape: Are there direct competitors or alternatives the user is aware of? Reference the competitive-analysis secondary skill if the user needs a deeper market scan before writing the PRD.
Use the answers to select the right PRD format below. Do not default to the longest template — match format to context.
Before writing the PRD, clarify who is involved. Use a DACI matrix (Atlassian/Intuit standard):
| Role | Who | Responsibility |
|------------|------------------|---------------------------------------------|
| Driver | [name/role] | Owns the document, drives decisions forward |
| Approver | [name/role] | Final sign-off authority (one person only) |
| Contributor| [names/roles] | Provides input, reviews, raises concerns |
| Informed | [names/roles] | Kept in the loop, no active role |
Rules: Exactly one Approver. Driver is usually the PM. If there are more than 3 Contributors, the scope is probably too broad — split the PRD.
Best for: Amazon PR/FAQ (where exec alignment is the goal), any cross-functional project, or when the user says "I need buy-in from multiple teams."
The three most-copied templates in tech. Ask the user their team size and culture, then pick:
Write the press release before building. Used for every Amazon product since 2004 (AWS, Kindle, Prime). Format:
[Company] announces [product] to enable [customer] to [benefit]), sub-headline, dated intro paragraph, problem paragraph (3-4 problems max), solution paragraph, customer quote, how to get started.Why it works: the press-release frame forces customer language and ruthlessly exposes when you can't articulate the benefit. If the PR is boring, the product probably is too.
Source templates: Colin Bryar (ex-Bezos chief of staff) at coda.io/@colin-bryar/working-backwards, Ian McAllister's LinkedIn template,github.com/Green-Software-Foundation/pr-faqs for a real org using PR/FAQ on GitHub.
Best for: Big bets, new product lines, when you need exec alignment before committing eng resources.
Paul Adams (VP Product): "An Intermission must always fit on a printed A4 page. If it does not, you haven't a clear enough view of the problem yet." Sections:
Problem: What's broken, why now, links to customer conversations
Job Stories (Intercom invented these — replaces user stories): When [situation], I want to [motivation], so I can [expected outcome]. Situation > persona. "When I'm on-call at 3am and an alert fires" beats "As a DevOps engineer."
Success criteria: Qualitative + quantitative
NO solution section — solutions go in Figma, not the PRD
Best for: Feature-level work, fast-moving teams, when scope creep is the enemy.
Nan Yu (Head of Product at Linear). Short, outcome-focused: Problem → Proposed solution → Success metrics → Non-goals → Open questions. Non-goals are load-bearing — explicitly listing what you're not building is the single most effective scope-creep prevention.
Best for: Eng-heavy teams already in Linear, projects with clear shape.
Full template collection: hustlebadger.com/what-do-product-teams-do/prd-template-examples/ (Figma, Asana, Shape Up, Lenny's 1-Pager all compared).
Every PRD should include a lightweight competitive scan. Add this section after the problem statement in any format:
## Alternatives & Competitive Landscape
| Alternative | How users solve this today | Key weakness we exploit |
|---------------------|---------------------------|-------------------------------|
| [Competitor/workaround] | [description] | [gap or pain point] |
| [Status quo] | [what they do without us] | [cost, time, error rate] |
If the user needs a deeper analysis, reference the competitive-analysis secondary skill.
Problem strictly before solution — every high-performing template enforces this
Explicit "Non-goals" section — second most common element
Living docs — version + changelog, not write-once
Effort estimates feed into RICE and roadmap sequencing. Use one of these approaches depending on maturity:
When detailed estimates are unreliable, use relative sizing:
| Size | Rough meaning | Example |
|------|--------------------------------------|----------------------------------|
| XS | < 1 day, one person | Copy change, config tweak |
| S | 1-3 days, one person | New API endpoint, simple UI page |
| M | 1-2 weeks, 1-2 people | Feature with frontend + backend |
| L | 2-4 weeks, small team | Multi-screen flow, new integration|
| XL | 1+ month, cross-functional | New product area, platform change|
Compare to similar past work. Ask the user: "What shipped feature is this most similar to? How long did that take?" Adjust from there. This outperforms bottom-up estimation for novel work (Kahneman & Tversky's "planning fallacy" research).
Always estimate in ranges, not points: "2-4 weeks" not "3 weeks"
Include all functions in the estimate (PM + design + eng + QA), not just eng
Explicitly flag unknowns that could blow up the estimate — these become "Open questions" in the PRD
RICE (Intercom's framework — the de facto standard):
Reach: Users affected per quarter. Use real numbers from analytics, not guesses.
Impact: 3 = massive, 2 = high, 1 = medium, 0.5 = low, 0.25 = minimal
Confidence: 100% = data-backed, 80% = strong intuition, 50% = guessing. This multiplier is what makes RICE better than ICE — it punishes wishful thinking.
Effort: Person-months, all functions (PM + design + eng + QA)
Score = (R × I × C) / E. Build as a spreadsheet — agent can generate CSV.
When NOT to use RICE: When effort estimates are garbage (early-stage), when one item is existential (just do it), when the list is >30 items (you have a strategy problem, not a prioritization problem).
Cost of Delay / WSJF (SAFe framework): (User value + Time criticality + Risk reduction) / Job size. Better than RICE when timing/sequencing matters (regulatory deadlines, market windows).
Kano: Survey users on each feature twice — "how would you feel if we had this?" and "how would you feel if we didn't?" Cross-tab reveals Basic/Performance/Delighter/Indifferent. Reference: foldingburritos.com/blog/kano-model for the full method + survey template.
Now / Next / Later (GOV.UK popularized this — intentionally vague on dates to avoid roadmap-as-contract):
## Theme: [one strategic bet this quarter]
## Goal/OKR link: [which company or team OKR does this theme serve?]
### Now (committed, in flight)
| Initiative | Owner | Goal/OKR link | Success metric | Status |
### Next (committed, not started)
| Initiative | Why now | Goal/OKR link | Dependency |
### Later (directional, not committed)
- [bullets only — dates here are lies]
Every roadmap item should trace back to a goal or OKR. If an item doesn't link to any goal, it's either a missing goal or a distraction — surface this to the user.
Public roadmap examples to reference: github.com/github/roadmap (GitHub's own), Buffer's transparent roadmap, Linear's changelog.
Gherkin syntax (Given/When/Then) — directly executable as test cases:
Given [precondition]
When [action]
Then [observable result]
And [additional result]
One scenario per acceptance criterion. If you can't write it as Given/When/Then, the requirement is ambiguous.
PRDs are not write-once artifacts. Include this header in every PRD:
---
Version: [1.0]
Last updated: [date]
Status: [Draft | In Review | Approved | Superseded]
Owner: [Driver from DACI]
---
### Changelog
| Version | Date | Author | Change summary |
|---------|------------|--------|-----------------------------------|
| 1.0 | YYYY-MM-DD | [name] | Initial draft |
| 1.1 | YYYY-MM-DD | [name] | Added success metrics from review |
Review cadence: Recommend the user revisit the PRD at each major milestone — after design review, after eng scoping, and after launch. Update status and log changes.
Default output is markdown. Adapt format when it serves the user better:
RICE scoring table: Generate as CSV when the user wants to import into a spreadsheet or share with stakeholders
Roadmap: Markdown table for docs, CSV for spreadsheet import
Connected tools: Check if the workspace has project management integrations (Linear, Jira, etc.) via the integrations skill. If connected, format output to match the tool's conventions (e.g., Linear project spec format for Linear users) and mention that items can be copied into their tool
Cannot integrate with Jira/Linear/Asana — deliver as markdown for copy-paste
Cannot access user analytics — ask user for reach/retention numbers before RICE scoring
Templates are starting points; teams should adapt