mcpField
P
product-management

product-management

github.com/vasilyu1983生産性914 回インストール
リポジトリ

product-management について

プロダクトチーム向けのプロダクトマネジメントスキルです。ディスカバリー、PMF評価、優先順位付け、ロードマップ策定を支援し、根拠に基づく判断と測定可能な成果、撤退条件を重視します。

主な機能

  1. 01顧客インタビューと仮説検証のテンプレート
  2. 02セグメント別のPMF・継続率評価
  3. 03ロードマップ、戦略、指標の計画
  4. 04バックログの採点と優先順位付け
  5. 05意思決定メモとステークホルダー資料

活用シーン

  1. 01顧客の意見をディスカバリー計画に整理
  2. 02顧客セグメント別にPMFの兆候を評価
  3. 03指標とガードレールを含むロードマップを作成
  4. 04バックログの優先順位と撤退条件を設定

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/vasilyu1983/ai-agents-public --skill product-management

インストール後、Claude Code で/product-managementを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

agents/
openai.yaml
assets/
pmf-bet-memo-template.md
pmf-scorecard-b2b.yaml
pmf-scorecard-b2c.yaml
assets/ai/
agentic-ai-orchestration.md
ai-lifecycle-template.md
assets/data/
data-product-canvas.md
assets/discovery/
assumption-test-template.md
customer-interview-template.md
opportunity-solution-tree.md
pmf-survey-template.md
assets/metrics/
metric-tree.md
okr-template.md
assets/ops/
1-1-template.md
a3-debrief.md
feedback-template.md
negotiation-one-sheet.md
template-dor-dod.md
assets/prioritization/
kill-criteria-template.md
prioritization-scorecard.md
assets/roadmap/
outcome-roadmap.md
theme-roadmap.md
assets/strategy/
opportunity-assessment.md
positioning-template.md
PRFAQ-template.md
product-vision-template.md
quarterly-product-review.md
data/
sample-features.json
sample-pmf-data.json
sources.json

詳細

プロダクトマネジメント

クイックリファレンス

タスク使用するもの
ディスカバリーとインタビューassets/discovery/customer-interview-template.md、assets/discovery/assumption-test-template.md、assets/discovery/opportunity-solution-tree.md
PMF とリテンションassets/discovery/pmf-survey-template.md、references/pmf-measurement.md
PMF スコアカード(B2B/SaaS)assets/pmf-scorecard-b2b.yaml — 運用上の目安を示すものです。ベンチマークと比較する前に、指標ごとの検索手順を使用してください
PMF スコアカード(B2C/コンシューマー)assets/pmf-scorecard-b2c.yaml — バイラル係数と短期回収を重視
PMF ベットメモ(エンジンダイジェスト → 単一の実験)assets/pmf-bet-memo-template.md
ダイヤモンド・ディスカバリー(4 つのレンズで隠れたプロダクトの可能性を発見し、反証ゲートと価格を設定したベットを行います。分析データがなくても機能します)references/diamond-discovery.md
優先順位付けと中止基準assets/prioritization/prioritization-scorecard.md、assets/prioritization/kill-criteria-template.md、python3 scripts/product_scorer.py rice --help
ロードマップと戦略assets/roadmap/outcome-roadmap.md、assets/strategy/product-vision-template.md、assets/strategy/positioning-template.md、assets/strategy/quarterly-product-review.md
指標と OKRassets/metrics/metric-tree.md、assets/metrics/okr-template.md
人間のチーム向け PRD、レビュー、ステークホルダー調整プロセスreferences/traditional-prd-writing.md、references/prd-review-facilitation.md、references/prd-stakeholder-alignment.md、references/pm-collaboration-guide.md
ステークホルダーおよびリーダーシップ向け成果物assets/ops/1-1-template.md、assets/ops/feedback-template.md、assets/ops/a3-debrief.md、assets/ops/negotiation-one-sheet.md
バックログのスコアリングと PMF 前の機会スコアpython3 scripts/product_scorer.py --help を実行してください。pmf サブコマンドは PMF の測定値ではなく、PMF 前の機会スコアです(リテンションの入力なし)。PMF の判定には、上記の YAML スコアカードを使用してください

このスキルを使用する場面

  • 創業者のメモ、顧客からの情報、市場シグナルをロードマップ、PMF 計画、または意思決定ブリーフにまとめます。
  • プロダクト領域のアクティベーション、リテンション、ガードレール、ビジネス指標を定義します。
  • バックログの優先順位を付け、中止基準を設定し、価値の低い作業を削減します。
  • 四半期ごとのプロダクトレビュー、機会評価、または戦略の説明を作成します。
  • 明確なトレードオフと測定可能な成果が求められる、プロダクト向けの成果物を作成します。

別のスキルを使用する場面

  • コーディングエージェント向けの実装可能な仕様には、docs-ai-prd を使用してください。人間の PM チーム向けに作成する PRD はここで扱います(上記の PRD の行を参照)。
  • GTM の進め方、ICP の選定、またはチャネル戦略には、startup-gtm-strategy を使用してください。
  • グロース実験と顧客獲得ループには、startup-growth-execution を使用してください。
  • プロダクト分析の計測設定とイベント設計には、marketing-product-analytics を使用してください。
  • アーキテクチャまたは技術的な目標状態の設計には、software-architecture-design を使用してください。

デフォルト

  • ドキュメントではなく、意思決定から始めます。
  • 指標は、計算式、期間、データソースとともに定義します。
  • 確信度が重要な場合は、「強い」「中程度」「弱い」などのエビデンスラベルを使います。
  • 機能の一覧より、成果に基づくロードマップを優先します。
  • 重要な賭けには、撤退基準またはロールバック条件を必須とします。
  • PMF は、会社全体で集計した単一のスコアではなく、セグメントごとに測定します。

ワークフロー

  1. 意思決定の内容、期間、担当者、および推奨を変える要因を明確にします。
  2. 成果物の種類を選びます。ディスカバリープラン、ロードマップ、PMF 評価、優先順位付け、戦略メモ、またはステークホルダー向け概要から選択します。
  3. 意思決定を支えるために必要なエビデンスだけを集めます。
  4. 成功指標、ガードレール、明示的な対象外事項を定義します。
  5. 一貫した単一の方法で選択肢に順位を付け、トレードオフを記録します。
  6. 成果物に加え、次回のレビューを開始する条件も提示します。静的なドキュメントだけで終わらせません。
意思決定権限の確認

ロードマップの日付、ローンチの確約、または取り消し不能な優先順位の決定を行う前に、意思決定者、必ず相談する相手、エビデンスの締め切り、再検討の条件の4項目を記載します。ステークホルダーからの意見によってエビデンスや制約が変わることはありますが、それによって意思決定者が暗黙のうちに変わるわけではありません。意思決定権限を持つ人がいない場合は、合意があるように見せかけたロードマップを作るのではなく、未解決の意思決定と、権限を割り当てるべき人を提示します。

エビデンスの締め切り時点で、判断に用いる情報を固定します。それ以降に得られたエビデンスは、意思決定の理由を遡って変えるのではなく、再検討の条件を通じて取り入れます。これにより、ロードマップのレビューが、過去の会話の記憶をもとに何度も投票する場になるのを防ぎます。

中核となる意思決定

ディスカバリーとエビデンス

構築に着手する前に価値の不確実性を減らすため、ディスカバリーを活用します。

  • 顧客インタビューで、課題、乗り換えの行動、意思決定の基準を把握します
  • リスクの高い前提を検証するため、仮説テストを行います
  • 複数の課題が注目を集めようと競合している場合は、機会マッピングを行います

エビデンスが不十分な場合は、その旨を明示し、確信度を高めるために何が必要かを定義します。

ディスカバリーの定期的なサイクルを回すことと、学びを得ることは同じではありません。成果物を信頼する前に、ディスカバリーシアターに陥っていないか確認します。たとえば、意見を裏付けるだけのインタビュー、四半期にわたって形が変わらない機会ツリー、実際の失敗条件がない実験などです。

優先順位付けと「やらない」判断

一貫して単一のフレームワークを使います。

  • 順位付けされたバックログには、RICE または ICE
  • ディスカバリーが中心の作業には、機会スコアリング
  • 時間的制約のあるフローの課題には、遅延コストまたは WSJF

最低限、次の項目を用意します。

  • スコアカード
  • 撤退基準
  • 下位に順位付けされた作業を今は実施しない理由を説明する一文

ステークホルダーからの圧力を、トレードオフの記録の代わりにしてはいけません。

スコアに基づく順位付けは、判断の代わりにはなりません。RICE などの計算式は、点推定の推測から見せかけの精密さを生み出します。その兆候(順位がまったく変わらない、エビデンスではなく役職の高さで同点を解消する、ゼロから始める賭けを同じ作業群の戦術的な作業と比較して採点する)については、RICE の精密さを装うことを参照してください。フレームワークは、トレードオフについて明示的に話し合うきっかけとして使い、その議論を終わらせるために使ってはいけません。

PMF とリテンション

PMF はアンケート結果ひとつで判断するものではありません。確認は次の順序で行います。

  1. ゲート — コホート別・セグメント別に、横ばいになるリテンション曲線。 コホートの曲線がゼロに向かって下がり続けるなら、アンケートの結果にかかわらず、そのセグメントでは PMF がありません。統合した曲線が横ばいになっているのは、ひとつのセグメントだけが支えているためかもしれないので、セグメントごとに確認します。
  2. 診断 — Sean Ellis の「なくてはならない」アンケート。 これは、製品が 誰 に適合するか(「とても残念」と回答したセグメント)とその理由を示しますが、リテンションのゲートに代わるものではありません。曲線が減衰しているのにスコアが高い場合、PMF ではなく、サンプリングまたはセグメント構成の問題です。
  3. 候補となるメカニズム — 持続的なリテンションを予測するアクティベーション。 予測できるだけでは、そのイベントにユーザーを誘導することでリテンションが高まるとは証明できません。因果関係を主張する前に、その介入を検証します。

製品が好まれていても、なくてはならない存在ではない場合は、対象範囲を広げる前に、なくてはならない状態へ至る経路を強化します。

データが豊富な製品では、marketing-product-analytics の PMF Insight Engine(assets/pmf-insight-engine.md + 10 個の盲点検出器)を実行し、チームが直感では気づけないシグナルを見つけます。そのうえで、適切な経路に照らしてスコアを付けます。

  • Path A(B2B/SaaS) — assets/pmf-scorecard-b2b.yaml。リテンション曲線、NRR、CAC の回収期間、ICP の集中度、価値指標との整合性をより重視します。各スコア帯は運用目標として扱い、ルックアップ手順を使って、取締役会での比較に適した一次コホートベンチマークを取得します。従量課金型または AI ネイティブの製品では、座席数ベースの PMF の前提を当てはめると、消費量ベースの製品を誤って診断することになります。このスコアカードと併せて、references/pmf-measurement.md の UBP シグナルを使います。
  • Path B(B2C/コンシューマー) — assets/pmf-scorecard-b2c.yaml。Week-4 のリテンション、乗り換えのきっかけを示す証拠、バイラル係数、6 か月での回収期間、カテゴリーのエントリーポイントをより重視します。

スコアカードは、0〜100 の準備度スコアと最も弱いディメンションを出力します。最も弱いディメンションが検出器にも検出された場合、それが bet memo の候補になります。bet memo は、証拠を、キル基準を設けたひとつの実験に落とし込むための契約です。

ロードマップと戦略

次を優先します。

  • 成果ロードマップ
  • 不確実性が高い場合はテーマロードマップ
  • 順序、重点、またはターゲット顧客が変わる場合に限り、戦略アーティファクト

すべてのロードマップには、次を明記します。

  • 目標とする成果
  • 主要な賭け
  • 指標とガードレール
  • 意図的に対象外とするもの

コミットメントのトレードオフ:ロードマップに日付を記載するたびに、探索の柔軟性を手放すことになります。「Now」の期間に確定日を設定するのが適切なのは、賭けがディスカバリーを通過した後です。未検証の「Later」の賭けに日付を設定すると、仮説が、証拠が何を示そうともチームが出荷する義務へと変わってしまいます。ステークホルダーから「Later」の項目の日付を求められた場合、正直な回答は、圧力に押されて提示する日付ではなく、範囲と、先に通過すべき検証ゲートです。高い誠実性を伴うコミットメント(Cagan 著、Empowered)は、価値、ユーザビリティ、実現可能性、事業性の各リスクに対処した後にのみ認められる例外であり、ロードマップの標準的な運用方法ではありません。

AI と自動化

AI プロダクトの取り組みは付加要素ではなく、PM の主要領域として扱ってください。AI プロダクトのライフサイクル、エージェント型パターン、RAG、リスクガバナンス、実験の種類、AI とルールのどちらを使うかを判断するツリーを網羅した運用ガイドについては、references/ai-product-patterns.md を参照してください。主な運用原則は次のとおりです。

  • AI による支援は明示的に必要な場合にのみ使い、範囲を限定してください。候補となる機会のスコアリング、インタビューメモの整理、選択肢の比較、フィードバックや利用状況における異常の検出などに活用します。
  • AI 機能では、リリース前に問題の妥当性確認、データ準備度スコア、評価指標、安全対策、人間が介在する手順、ドリフト監視を必須としてください。
  • エージェント型プロダクトでは、エージェントの役割、ツールへのアクセス、制約、成功基準、失敗モード、エスカレーション経路を明確に定義してください。

優先順位付け、倫理、取り消せないプロダクトへの賭けについては、引き続き人間の判断を重視します。

出力モード

次のいずれかをデフォルトとして使用してください。

  • プロダクト意思決定ブリーフ: 推奨事項、根拠、トレードオフ、指標、次回のレビュー時点。
  • 成果ロードマップ: 成果、賭け、ガードレールを含む「今」「次」「後」。
  • PMF 評価: セグメントごとのシグナルレビュー、リテンションの見方、アクティベーションの定義、回復ループ。
  • PMF スコアカード+賭けのメモ: B2B または B2C のスコアカードに基づいて準備状況を採点し、実施中の実験ごとに賭けのメモを 1 つ作成します。PMF Insight Engine の検出根拠に結び付けます。
  • 優先順位付けパッケージ: 優先順位を付けたバックログ、中止基準、明示的な対象外事項。

アンチパターン

  • 測定可能な成果がないロードマップの見せかけ。
  • アクティベーションやリテンションの定義がない虚栄の指標。
  • 根拠を後から探すことを前提に、まず構築すること。
  • トレードオフを調整せずにスコープを拡大すること。
  • PMF を単一の二者択一のマイルストーンとして扱うこと。
  • ステークホルダーに頼まれたという理由だけですべてに同意すること。
  • ゼロから 1 を目指す賭けを、戦術的なバックログ作業と同じ RICE/WSJF の枠組みで採点すること — 分母の構造上、新規で未実証のものは不利になります(戦略的な賭けと戦術的なバックログを参照)。
  • スコーピングの議論を終わらせるためだけに、ディスカバリーを通過していない「後で」扱いの賭けに確定日を約束すること。

チェックリストでは見落とし、経験豊富な実務担当者が見抜くこと:成果物がテンプレートを埋めているだけなのか、それとも事業が直面する実際の意思決定に答えているのか、という点です。RICE の一覧、OST、OKR シートはすべて正しく記入されていても、根底にある意思決定 — 内製か購入か、拡大か集中か、どのチームに資金を投入するか — が明確にされていなければ、要点を外すことがあります。成果物を作成する前に、それがどの意思決定に役立つものかを一文で述べてください。その一文を書けない場合、その成果物は単なる忙しい作業です。

ナビゲーション

以下の基盤を呼び出す前に必ず行うこと: 未解決の意思決定を明確にし、そのうえで基盤の対象範囲、対象外事項、手法の前提を確認してください。返される成果物がその意思決定を変え得る場合にのみ、関連するリファレンスを読み込んでください。定型的な適用作業は省略します。選択は正確なセクション見出しには左右されません。

条件付き最適化への引き継ぎ

通常のRICE/WSJFによる順位付け、定性的なロードマップの議論、ディスカバリーは、プロダクトマネジメントで扱ってください。トリガー: 合意済みの効用と明示された依存関係または非両立性を前提として、チームのキャパシティ/予算の明示的な制約下で、分割できない機能や作業パッケージの配分を定量化する場合で、順位付けだけでは実行可能な選択を導けないときです。この未解決の選択問題には、foundations-mathematical-optimization を読み込んでください。スキップ: 制約のない順位付け、効用についての意見の相違、工数/キャパシティの見積もり不足、または分割できない機能に適用する連続LPの前提がある場合です。まずプロダクトに関する根拠を明確にしてください。返却内容: 決定変数とその定義域、効用/目的関数、ハード制約と依存関係のルール、キャパシティの合計を独立して検証した実行可能な選択セット、ソルバー/ステータス/モデルの境界、効用または工数の不確実性に対する感度を示してください。実際の整数モデルについて有効な根拠がある場合に限り、最適性またはギャップを報告してください。この基盤の連続LP証明書ヘルパーでは、分割できないロードマップを証明できません。デリバリーの決定とステークホルダー間のトレードオフは、引き続きプロダクトマネジメントが担います。

学びのループ

過去の決定や落とし穴が関係する場合は、learnings.consolidated.md があれば参照してください。必要な履歴を確認する場合、または利用可能な代替手段としてのみ、learnings.md を使用してください。それ以外の場合は、どちらも参照しないでください。

適用後、記憶する価値のあるパターン、防ぐべきミス、または意外だったドメイン知識に遭遇した場合は、agents-skills-feedback-loop/scripts/append_learning.py を使って、日付付きの箇条書きを1つ learnings.md に追記してください。SKILL.md 自体は変更しないでください。

コメント