pm-prd について
pm-prd は、市場を重視した Product Requirements Document の作成を支援するプロダクトマネジメントスキルです。市場の根拠と影響に基づいてペルソナ別の問題や要件を優先づけ、解決策の設計はチームに委ねます。
主な機能
- 01市場の問題を軸にした PRD 構成
- 02ペルソナと問題の根拠の記録
- 03根拠と影響に基づく要件の優先順位付け
- 04既存の機能ドシエ資料の再利用
- 05Markdown または DOCX での成果物作成
活用シーン
- 01製品リリースの要件定義
- 02記録済みの顧客課題の優先順位付け
- 03既存のペルソナ資料と製品文書の統合
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ julianoczkowski/ product-manager --skill pm-prdインストール後、Claude Code で/pm-prdを入力して読み込まれたか確認します。
詳細
製品要件定義書(実践的フレームワーク:計画)
ここでいう PRD は市場要件定義書です。市場の課題、ペルソナ、優先順位付けされた要件といった何を(WHAT)を定めます。設計、フロー、UI、プロトタイプ、エラー条件といったどのように(HOW)を決めるのはチームです。課題を最初に提示し、根拠を示し、ペルソナの一人称で課題を記述してください。以下で使用する基本要素については、../pm-copilot/references/framework.md を参照してください。
要件の形式: [ペルソナ] は、[利用シナリオで説明された課題] を [頻度] で抱えています。 優先度 = 市場の根拠 × 影響度(応用編:×(B + U + C + V)— 購入、利用、ビジョン、競争)。
既存の成果物を再利用する
情報を集める前に、../pm-copilot/references/artifact-output.md の「Find or resume the feature dossier」と「Reuse prior artifacts」に従って、機能ドシエを探すか、作業を再開してください。機能フォルダー(または NN-*.md ファイル、この会話の前半で作成された成果物)を探し、そこにあるペルソナ、課題、ポジショニングステートメント、優先順位付けされた要件を再利用してください。作業を重複させず、未解決の注意事項も引き継いでください。まだ何もなければ、ここで情報を集めるか、まず pm-personas、pm-market-problems、pm-requirements、pm-use-scenarios を実行することを提案してください。
ユーザーへの質問(一括で確認)
- 製品とリリース — 名称、バージョン、今回のリリースの目標。
- 市場の動向 — 今この取り組みを進める要因は何ですか?コンテンツ主導(課題が解決されたらリリース)ですか、それとも目標日主導(市場投入の時期が固定)ですか?
- ペルソナ — 購入者と利用者は誰ですか?(要約またはリンク)
- 市場の主な課題 — ペルソナの一人称で、それぞれに根拠(インタビュー件数、顧客の割合、受注・失注、サポートチケット、利用データ)を添えてください。
- 成功指標 — 成功したかどうかをどのように判断しますか?(価値/品質/進捗/満足度)
- 対象外、依存関係、リスク。
成果物のテンプレート
# Product Requirements Document — <Product> <Version>
*Confidential and subject to change. For internal use only. No external commitments
can be made based on this document since it is in early planning stages. Content and
timing are very likely to change.*
**Company:** <company> · **Feature / Product:** <feature / product name>
**Author:** <author> · **Contact:** <email> · **Date created:** <date> · **Version:** 1.0
## 1. Overview of the target release
Goal of this release: <one paragraph>.
Market forces driving it: <evidence-backed forces>.
Driven primarily by: <content | target date>. Target window: <date/quarter>.
Related artifacts: <positioning doc, roadmap, canvas, links>.
## 2. Personas
### Buyer persona — <name>
<motivations, buying process, barriers>
### User persona — <name>
<goals, behaviors, problems>
## 3. Market problems (persona's first person, with evidence)
- "<I can't …>" — evidence: <n interviews / % customers / win-loss>
- "<It takes too long to …>" — evidence: <…>
## 4. Requirements (grouped, prioritized)
### GROUP 1 — <group name>
1. **<Requirement>** — <Persona> has <problem, in a use scenario> with <frequency>.
Priority: <evidence> (inputs) × <impact> (impact) = **<priority>**.
2. **<Requirement>** — … Priority: … = **<priority>**.
### GROUP 2 — <group name>
1. …
## 5. Use scenarios (day-in-the-life)
**<Scenario name>** — <Persona> is trying to <goal>. Today, <what happens, the pain,
the current workaround>. This happens <frequency>. <Why it matters.>
## 6. Requirements summary
| Requirement | Persona | Market Evidence | Impact | Priority | Group | Group Order |
| :--- | :--- | ---: | ---: | ---: | :--- | ---: |
| <name> | <persona> | 25 | 4 | 100 | <group> | 1 |
## 7. Out of scope / non-goals
- <explicitly not doing …>
## 8. Success metrics
| Metric category | Metric | Current | Goal |
| :--- | :--- | :--- | :--- |
| Value | <LTV / revenue> | | |
| Quality | <defects / coverage> | | |
| Progress | <cycle time> | | |
| Satisfaction | <NPS / CSAT / renewal> | | |
## 9. Dependencies & risks
- <dependency / risk> — <mitigation>
## 10. Approvals
| Name | Title | Date | Signature |
| :--- | :--- | :--- | :--- |
| | Product Manager | | |
| | Systems Architect | | |
| | Development Manager | | |
| | Interaction Designer | | |
| | QA Lead | | |
## 11. Change tracking
| Version | Date | Changes | Reason |
| :--- | :--- | :--- | :--- |
| 1.0 | <date> | Initial draft | |
## Open questions / evidence to gather
- > TODO: <unproven claim or missing evidence>
成果物を提出する
../pm-copilot/references/artifact-output.md に従ってください。入力内容を確認し(情報が不足している場合は、根拠を捏造せず、仮定であることを明記して補足します)、Markdown または .docx のどちらにするか尋ねてください。.md を作成し、希望があれば、環境に備わっているドキュメント作成機能を使って .docx に変換します。
次の段階として、優先順位付けされた要件を確定済みの pm-release-plan にまとめ、全員の認識を合わせるために pm-stakeholder-communication を設定することを提案してください。