PMのためのAIプロンプトライブラリ

ユーザーストーリー生成プロンプト

用途: ユーザーリサーチの実務で「ユーザーストーリー生成」を短時間で作る

主な出力: 調査目的、対象者、質問、分析観点、次の検証アクション

# ユーザーストーリー生成プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ユーザーリサーチの実務で使える「ユーザーストーリー生成」を日本語で作成してください。

用途: ユーザーリサーチの実務で「ユーザーストーリー生成」を短時間で作る

## 入力
- 対象ユーザー: [ここに記入]
- 利用状況・きっかけ: [ここに記入]
- 達成したいこと: [ここに記入]
- 価値・理由: [ここに記入]
- 既存仕様・制約: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 解決策を先に固定せず、ユーザーの状況・目的・価値と、テスト可能な受け入れ条件を分けてください。

## 出力形式
1. ユーザーストーリー
2. 背景・根拠
3. 受け入れ条件
4. 例外・失敗時の扱い
5. 未決事項

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

PRD作成プロンプト

用途: プロダクト戦略の実務で「PRD作成」を短時間で作る

主な出力: 戦略仮説、選択肢、判断基準、リスク、次の意思決定

# PRD作成プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、プロダクト戦略の実務で使える「PRD作成」を日本語で作成してください。

用途: プロダクト戦略の実務で「PRD作成」を短時間で作る

## 入力
- 対象ユーザー: [ここに記入]
- 解決したい課題と根拠: [ここに記入]
- 目的・非目的: [ここに記入]
- 既存仕様・制約: [ここに記入]
- 成功指標・計測: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 機能一覧ではなく、課題→目的→要件→成功条件が追跡できるようにし、非スコープと未決事項を明示してください。

## 出力形式
1. 背景・課題
2. 対象ユーザーと利用状況
3. スコープ・非スコープ
4. 要件・受け入れ条件
5. 成功指標・リスク・未決事項

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

競合分析フレームワークプロンプト

用途: プロダクト戦略の実務で「競合分析フレームワーク」を短時間で作る

主な出力: 戦略仮説、選択肢、判断基準、リスク、次の意思決定

# 競合分析フレームワークプロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、プロダクト戦略の実務で使える「競合分析フレームワーク」を日本語で作成してください。

用途: プロダクト戦略の実務で「競合分析フレームワーク」を短時間で作る

## 入力
- 自社・対象市場: [ここに記入]
- 比較対象: [ここに記入]
- 対象segment: [ここに記入]
- 比較したいJob: [ここに記入]
- 一次情報・調査期限: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 機能表だけで終えず、sourceと更新日を残し、確認できない情報を推測で埋めないでください。

## 出力形式
1. 比較対象とsource
2. segment / Job別比較
3. 強み・弱み・代替
4. 差別化仮説
5. 追加調査・不確実性

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

RICE機能優先順位づけプロンプト

用途: 機能開発の実務で「RICE機能優先順位づけ」を短時間で作る

主な出力: 要件、優先順位、受け入れ条件、実装・検証観点

# RICE機能優先順位づけプロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、機能開発の実務で使える「RICE機能優先順位づけ」を日本語で作成してください。

用途: 機能開発の実務で「RICE機能優先順位づけ」を短時間で作る

## 入力
- 候補施策: [ここに記入]
- 対象ユーザー・Reach根拠: [ここに記入]
- 期待Impact: [ここに記入]
- Confidenceの根拠: [ここに記入]
- Effort・制約: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- スコアを最終判断そのものにせず、各入力値の根拠、反証、戦略・依存関係を別に残してください。

## 出力形式
1. 評価前提
2. 比較表・スコア
3. 不確実性・感度
4. スコア外の制約・戦略適合
5. 推奨順位と見直し条件

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

ユーザーインタビュー質問設計プロンプト

用途: ユーザーリサーチの実務で「ユーザーインタビュー質問設計」を短時間で作る

主な出力: 調査目的、対象者、質問、分析観点、次の検証アクション

# ユーザーインタビュー質問設計プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ユーザーリサーチの実務で使える「ユーザーインタビュー質問設計」を日本語で作成してください。

用途: ユーザーリサーチの実務で「ユーザーインタビュー質問設計」を短時間で作る

## 入力
- 調査目的: [ここに記入]
- 対象セグメント: [ここに記入]
- 検証したい仮説: [ここに記入]
- 既知のEvidence: [ここに記入]
- 避けたい誘導・制約: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 未来の意向や機能要望だけでなく、過去の具体行動・状況・代替手段を聞ける質問にしてください。

## 出力形式
1. 調査目的と対象
2. 質問フロー
3. 深掘り質問
4. バイアス・倫理上の注意
5. 分析方法と次の検証

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

A/Bテスト計画書プロンプト

用途: 指標分析の実務で「A/Bテスト計画書」を短時間で作る

主な出力: 主要指標、分析軸、SQL/イベント案、解釈、意思決定への接続

# A/Bテスト計画書プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、指標分析の実務で使える「A/Bテスト計画書」を日本語で作成してください。

用途: 指標分析の実務で「A/Bテスト計画書」を短時間で作る

## 入力
- 仮説: [ここに記入]
- 対象・randomization unit: [ここに記入]
- Primary metric: [ここに記入]
- Guardrail・Data Quality条件: [ここに記入]
- 期間・sample・停止条件: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 結果を見てから成功条件を変えず、SRM等のdata-quality異常と効果判定を分離してください。

## 出力形式
1. 仮説と対象
2. 割付・exposure設計
3. Primary・Guardrail・Data Quality指標
4. 事前のGo/No-Go・停止条件
5. 結果記録と再評価方法

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

経営・主要ステークホルダー向け進捗メールプロンプト

用途: ステークホルダーコミュニケーションの実務で「経営・主要ステークホルダー向け進捗メール」を短時間で作る

主な出力: 読み手別メッセージ、合意形成、リスク共有、次アクション

# 経営・主要ステークホルダー向け進捗メールプロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ステークホルダーコミュニケーションの実務で使える「経営・主要ステークホルダー向け進捗メール」を日本語で作成してください。

用途: ステークホルダーコミュニケーションの実務で「経営・主要ステークホルダー向け進捗メール」を短時間で作る

## 入力
- 読み手: [ここに記入]
- 伝えたい状況: [ここに記入]
- 決まっていること: [ここに記入]
- 未決事項: [ここに記入]
- 依頼したい判断: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 相手に必要な判断を先に置き、詳細は補足として整理してください。

## 出力形式
1. 要約
2. 読み手別メッセージ
3. リスク
4. 意思決定依頼
5. 次のアクション

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

詳細ユーザーペルソナ作成プロンプト

用途: ユーザーリサーチの実務で「詳細ユーザーペルソナ作成」を短時間で作る

主な出力: 調査目的、対象者、質問、分析観点、次の検証アクション

# 詳細ユーザーペルソナ作成プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ユーザーリサーチの実務で使える「詳細ユーザーペルソナ作成」を日本語で作成してください。

用途: ユーザーリサーチの実務で「詳細ユーザーペルソナ作成」を短時間で作る

## 入力
- 対象セグメント: [ここに記入]
- 観察・インタビューEvidence: [ここに記入]
- 達成したいJob: [ここに記入]
- 制約・代替行動: [ここに記入]
- 未確認の仮説: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 年齢や属性だけの架空人物にせず、観察Evidenceと推測を分離してください。

## 出力形式
1. 状況・Job
2. 行動・代替手段
3. Pain・制約
4. 判断基準・成功状態
5. Evidenceと未確認仮説

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

North Star型プロダクトビジョン作成プロンプト

用途: プロダクト戦略の実務で「North Star型プロダクトビジョン作成」を短時間で作る

主な出力: 戦略仮説、選択肢、判断基準、リスク、次の意思決定

# North Star型プロダクトビジョン作成プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、プロダクト戦略の実務で使える「North Star型プロダクトビジョン作成」を日本語で作成してください。

用途: プロダクト戦略の実務で「North Star型プロダクトビジョン作成」を短時間で作る

## 入力
- 対象市場・顧客: [ここに記入]
- 市場変化: [ここに記入]
- 顧客課題・代替手段: [ここに記入]
- 自社の強み・制約: [ここに記入]
- 事業目標: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 抽象的なスローガンだけで終えず、選択・非選択と、外れた場合に見直す前提を明示してください。

## 出力形式
1. 現状診断
2. 戦略・ビジョン仮説
3. 選択すること / 捨てること
4. 勝ち筋と前提
5. risk・検証・次の意思決定

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

開発着手可能な機能仕様書プロンプト

用途: 機能開発の実務で「開発着手可能な機能仕様書」を短時間で作る

主な出力: 要件、優先順位、受け入れ条件、実装・検証観点

# 開発着手可能な機能仕様書プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、機能開発の実務で使える「開発着手可能な機能仕様書」を日本語で作成してください。

用途: 機能開発の実務で「開発着手可能な機能仕様書」を短時間で作る

## 入力
- 対象ユーザー: [ここに記入]
- 解決したい課題と根拠: [ここに記入]
- 目的・非目的: [ここに記入]
- 既存仕様・制約: [ここに記入]
- 成功指標・計測: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 機能一覧ではなく、課題→目的→要件→成功条件が追跡できるようにし、非スコープと未決事項を明示してください。

## 出力形式
1. 背景・課題
2. 対象ユーザーと利用状況
3. スコープ・非スコープ
4. 要件・受け入れ条件
5. 成功指標・リスク・未決事項

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

プロダクト分析ダッシュボード設計プロンプト

用途: 指標分析の実務で「プロダクト分析ダッシュボード設計」を短時間で作る

主な出力: 主要指標、分析軸、SQL/イベント案、解釈、意思決定への接続

# プロダクト分析ダッシュボード設計プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、指標分析の実務で使える「プロダクト分析ダッシュボード設計」を日本語で作成してください。

用途: 指標分析の実務で「プロダクト分析ダッシュボード設計」を短時間で作る

## 入力
- 意思決定したいこと: [ここに記入]
- 対象ユーザー・segment: [ここに記入]
- 指標定義: [ここに記入]
- 利用できるdata・event: [ここに記入]
- 更新頻度・owner: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 見栄えのよい指標を増やさず、意思決定と定義が紐づく最小セットにしてください。

## 出力形式
1. 意思決定と主要指標
2. 指標定義・分母分子
3. segment・比較軸
4. 計測・data-quality要件
5. dashboard運用・見直し条件

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

カスタマージャーニーマップ作成プロンプト

用途: ユーザーリサーチの実務で「カスタマージャーニーマップ作成」を短時間で作る

主な出力: 調査目的、対象者、質問、分析観点、次の検証アクション

# カスタマージャーニーマップ作成プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ユーザーリサーチの実務で使える「カスタマージャーニーマップ作成」を日本語で作成してください。

用途: ユーザーリサーチの実務で「カスタマージャーニーマップ作成」を短時間で作る

## 入力
- 対象ユーザー: [ここに記入]
- 開始条件: [ここに記入]
- 主要な段階・接点: [ここに記入]
- 観察Evidence: [ここに記入]
- 達成したいOutcome: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 理想フローだけでなく、離脱・迂回・手作業・再開など実際の行動を含めてください。

## 出力形式
1. ジャーニー段階
2. 各段階の目的・行動・接点
3. 摩擦・感情・Evidence
4. 機会領域
5. 優先して検証する箇所

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

プロダクト開発振り返りプロンプト

用途: ステークホルダーコミュニケーションの実務で「プロダクト開発振り返り」を短時間で作る

主な出力: 読み手別メッセージ、合意形成、リスク共有、次アクション

# プロダクト開発振り返りプロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ステークホルダーコミュニケーションの実務で使える「プロダクト開発振り返り」を日本語で作成してください。

用途: ステークホルダーコミュニケーションの実務で「プロダクト開発振り返り」を短時間で作る

## 入力
- 当初の目的・仮説: [ここに記入]
- 実施内容: [ここに記入]
- 結果・指標: [ここに記入]
- 想定外の事象: [ここに記入]
- 関係者の観察: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 感想会にせず、Evidenceから再利用可能な学びと次の意思決定へつなげてください。

## 出力形式
1. 目的と結果
2. うまくいったこと
3. 失敗・想定外
4. 学び・前提更新
5. 継続・改善・停止の次判断

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

戦略OKR作成プロンプト

用途: プロダクト戦略の実務で「戦略OKR作成」を短時間で作る

主な出力: 戦略仮説、選択肢、判断基準、リスク、次の意思決定

# 戦略OKR作成プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、プロダクト戦略の実務で使える「戦略OKR作成」を日本語で作成してください。

用途: プロダクト戦略の実務で「戦略OKR作成」を短時間で作る

## 入力
- 事業・プロダクト目標: [ここに記入]
- 対象期間: [ここに記入]
- 現状値: [ここに記入]
- 変えたいOutcome: [ここに記入]
- 制約・非目標: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- Key Resultを施策一覧にせず、成果指標とInitiativeを分離してください。

## 出力形式
1. Objective
2. Key Resultsと定義
3. 現状値・目標値の根拠
4. Initiative候補
5. Guardrail・レビュー方法

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

ユーザーフィードバック分析プロンプト

用途: ユーザーリサーチの実務で「ユーザーフィードバック分析」を短時間で作る

主な出力: 調査目的、対象者、質問、分析観点、次の検証アクション

# ユーザーフィードバック分析プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ユーザーリサーチの実務で使える「ユーザーフィードバック分析」を日本語で作成してください。

用途: ユーザーリサーチの実務で「ユーザーフィードバック分析」を短時間で作る

## 入力
- Feedback原文・source: [ここに記入]
- 顧客・segment context: [ここに記入]
- 期間: [ここに記入]
- 既存テーマ・request: [ここに記入]
- 判断したいこと: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 要望数をそのまま優先順位にせず、原文へのtraceabilityと顧客contextを残してください。

## 出力形式
1. Raw Feedbackと要約
2. Problem・Theme分類
3. 重複・反証・segment差
4. Evidence強度
5. 次の調査・意思決定

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

マルチチャネル機能告知戦略プロンプト

用途: ステークホルダーコミュニケーションの実務で「マルチチャネル機能告知戦略」を短時間で作る

主な出力: 読み手別メッセージ、合意形成、リスク共有、次アクション

# マルチチャネル機能告知戦略プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ステークホルダーコミュニケーションの実務で使える「マルチチャネル機能告知戦略」を日本語で作成してください。

用途: ステークホルダーコミュニケーションの実務で「マルチチャネル機能告知戦略」を短時間で作る

## 入力
- 対象ユーザー・読み手: [ここに記入]
- 変更内容: [ここに記入]
- ユーザー価値: [ここに記入]
- 既知の制約・risk: [ここに記入]
- 公開範囲・日時・support情報: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 機能一覧の羅列ではなく、読み手ごとに「何が変わり、何をすべきか」を先に示してください。

## 出力形式
1. 対象別メッセージ
2. 何が変わるか・価値
3. 利用方法・移行
4. risk・既知の制約
5. CTA・問い合わせ・次アクション

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

戦略ロードマップ作成プロンプト

用途: プロダクト戦略の実務で「戦略ロードマップ作成」を短時間で作る

主な出力: 戦略仮説、選択肢、判断基準、リスク、次の意思決定

# 戦略ロードマップ作成プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、プロダクト戦略の実務で使える「戦略ロードマップ作成」を日本語で作成してください。

用途: プロダクト戦略の実務で「戦略ロードマップ作成」を短時間で作る

## 入力
- Strategy・Objective: [ここに記入]
- 候補initiative: [ここに記入]
- Evidence・confidence: [ここに記入]
- 依存関係・capacity: [ここに記入]
- 変更・再評価条件: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- featureの納期表にせず、Outcome・Evidence・確度と、判断が変わる条件を残してください。

## 出力形式
1. Outcome / Theme
2. initiativeと理由
3. Evidence・confidence
4. 依存関係・確度
5. 変更履歴・再評価条件

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

バリュープロポジションキャンバス生成プロンプト

用途: プロダクト戦略の実務で「バリュープロポジションキャンバス生成」を短時間で作る

主な出力: 戦略仮説、選択肢、判断基準、リスク、次の意思決定

# バリュープロポジションキャンバス生成プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、プロダクト戦略の実務で使える「バリュープロポジションキャンバス生成」を日本語で作成してください。

用途: プロダクト戦略の実務で「バリュープロポジションキャンバス生成」を短時間で作る

## 入力
- プロダクト名: [ここに記入]
- 対象市場: [ここに記入]
- 事業目標: [ここに記入]
- 競合・代替手段: [ここに記入]
- 制約条件: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 抽象論で終えず、捨てる選択肢と検証すべき前提を明示してください。

## 出力形式
1. 戦略仮説
2. 選択肢比較
3. 判断基準
4. リスク
5. 次の意思決定

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

バグ優先順位づけプロンプト

用途: 機能開発の実務で「バグ優先順位づけ」を短時間で作る

主な出力: 要件、優先順位、受け入れ条件、実装・検証観点

# バグ優先順位づけプロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、機能開発の実務で使える「バグ優先順位づけ」を日本語で作成してください。

用途: 機能開発の実務で「バグ優先順位づけ」を短時間で作る

## 入力
- 候補施策: [ここに記入]
- 対象ユーザー・Reach根拠: [ここに記入]
- 期待Impact: [ここに記入]
- Confidenceの根拠: [ここに記入]
- Effort・制約: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- スコアを最終判断そのものにせず、各入力値の根拠、反証、戦略・依存関係を別に残してください。

## 出力形式
1. 評価前提
2. 比較表・スコア
3. 不確実性・感度
4. スコア外の制約・戦略適合
5. 推奨順位と見直し条件

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

スプリント計画最適化プロンプト

用途: 機能開発の実務で「スプリント計画最適化」を短時間で作る

主な出力: 要件、優先順位、受け入れ条件、実装・検証観点

# スプリント計画最適化プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、機能開発の実務で使える「スプリント計画最適化」を日本語で作成してください。

用途: 機能開発の実務で「スプリント計画最適化」を短時間で作る

## 入力
- Sprint Goal: [ここに記入]
- 優先候補と根拠: [ここに記入]
- team capacity: [ここに記入]
- 依存関係・blocked item: [ここに記入]
- 既知のrisk・carry-over: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- velocityを生産性目標にせず、Sprint Goalに必要な最小scopeと途中で削る条件を先に決めてください。

## 出力形式
1. Sprint Goal
2. commit候補と理由
3. capacity配分
4. 依存関係・risk
5. de-scope条件と確認ポイント

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

プロダクト分析SQL生成プロンプト

用途: 指標分析の実務で「プロダクト分析SQL生成」を短時間で作る

主な出力: 主要指標、分析軸、SQL/イベント案、解釈、意思決定への接続

# プロダクト分析SQL生成プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、指標分析の実務で使える「プロダクト分析SQL生成」を日本語で作成してください。

用途: 指標分析の実務で「プロダクト分析SQL生成」を短時間で作る

## 入力
- 意思決定したいこと: [ここに記入]
- 対象ユーザー・segment: [ここに記入]
- 指標定義: [ここに記入]
- 利用できるdata・event: [ここに記入]
- 更新頻度・owner: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 見栄えのよい指標を増やさず、意思決定と定義が紐づく最小セットにしてください。

## 出力形式
1. 意思決定と主要指標
2. 指標定義・分母分子
3. segment・比較軸
4. 計測・data-quality要件
5. dashboard運用・見直し条件

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

機能終了コミュニケーション計画プロンプト

用途: プロダクト戦略の実務で「機能終了コミュニケーション計画」を短時間で作る

主な出力: 戦略仮説、選択肢、判断基準、リスク、次の意思決定

# 機能終了コミュニケーション計画プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、プロダクト戦略の実務で使える「機能終了コミュニケーション計画」を日本語で作成してください。

用途: プロダクト戦略の実務で「機能終了コミュニケーション計画」を短時間で作る

## 入力
- プロダクト名: [ここに記入]
- 対象市場: [ここに記入]
- 事業目標: [ここに記入]
- 競合・代替手段: [ここに記入]
- 制約条件: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 抽象論で終えず、捨てる選択肢と検証すべき前提を明示してください。

## 出力形式
1. 戦略仮説
2. 選択肢比較
3. 判断基準
4. リスク
5. 次の意思決定

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

価格戦略設計プロンプト

用途: プロダクト戦略の実務で「価格戦略設計」を短時間で作る

主な出力: 戦略仮説、選択肢、判断基準、リスク、次の意思決定

# 価格戦略設計プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、プロダクト戦略の実務で使える「価格戦略設計」を日本語で作成してください。

用途: プロダクト戦略の実務で「価格戦略設計」を短時間で作る

## 入力
- 対象segment: [ここに記入]
- 提供価値・代替: [ここに記入]
- 現行価格・cost: [ここに記入]
- 利用・支払Evidence: [ここに記入]
- 制約・事業目標: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 競合価格の模倣だけで決めず、価値・支払意向・unit economics・移行riskを分けて検証してください。

## 出力形式
1. pricing hypothesis
2. package / metric候補
3. segment別trade-off
4. 検証方法
5. guardrail・見直し条件

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

技術的負債優先順位マトリクスプロンプト

用途: 機能開発の実務で「技術的負債優先順位マトリクス」を短時間で作る

主な出力: 要件、優先順位、受け入れ条件、実装・検証観点

# 技術的負債優先順位マトリクスプロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、機能開発の実務で使える「技術的負債優先順位マトリクス」を日本語で作成してください。

用途: 機能開発の実務で「技術的負債優先順位マトリクス」を短時間で作る

## 入力
- 候補施策: [ここに記入]
- 対象ユーザー・Reach根拠: [ここに記入]
- 期待Impact: [ここに記入]
- Confidenceの根拠: [ここに記入]
- Effort・制約: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- スコアを最終判断そのものにせず、各入力値の根拠、反証、戦略・依存関係を別に残してください。

## 出力形式
1. 評価前提
2. 比較表・スコア
3. 不確実性・感度
4. スコア外の制約・戦略適合
5. 推奨順位と見直し条件

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

オンボーディング改善プロンプト

用途: 機能開発の実務で「オンボーディング改善」を短時間で作る

主な出力: 要件、優先順位、受け入れ条件、実装・検証観点

# オンボーディング改善プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、機能開発の実務で使える「オンボーディング改善」を日本語で作成してください。

用途: 機能開発の実務で「オンボーディング改善」を短時間で作る

## 入力
- 対象segment・新規ユーザー: [ここに記入]
- 最初に達成してほしいJob: [ここに記入]
- 現行funnel・離脱data: [ここに記入]
- 定性feedback: [ここに記入]
- 変更可能な導線・制約: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 登録完了を成功と決めつけず、ユーザーが最初の価値を得た行動をactivation候補として検証してください。

## 出力形式
1. activation仮説
2. 現行journeyと離脱点
3. 改善案と優先順位
4. 計測event・success metric
5. 実験・段階公開・見直し条件

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

顧客フィードバック収集戦略プロンプト

用途: ユーザーリサーチの実務で「顧客フィードバック収集戦略」を短時間で作る

主な出力: 調査目的、対象者、質問、分析観点、次の検証アクション

# 顧客フィードバック収集戦略プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ユーザーリサーチの実務で使える「顧客フィードバック収集戦略」を日本語で作成してください。

用途: ユーザーリサーチの実務で「顧客フィードバック収集戦略」を短時間で作る

## 入力
- Feedback原文・source: [ここに記入]
- 顧客・segment context: [ここに記入]
- 期間: [ここに記入]
- 既存テーマ・request: [ここに記入]
- 判断したいこと: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 要望数をそのまま優先順位にせず、原文へのtraceabilityと顧客contextを残してください。

## 出力形式
1. Raw Feedbackと要約
2. Problem・Theme分類
3. 重複・反証・segment差
4. Evidence強度
5. 次の調査・意思決定

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

GTM戦略作成プロンプト

用途: プロダクト戦略の実務で「GTM戦略作成」を短時間で作る

主な出力: 戦略仮説、選択肢、判断基準、リスク、次の意思決定

# GTM戦略作成プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、プロダクト戦略の実務で使える「GTM戦略作成」を日本語で作成してください。

用途: プロダクト戦略の実務で「GTM戦略作成」を短時間で作る

## 入力
- 対象segment: [ここに記入]
- 提供価値: [ここに記入]
- 競合・代替: [ここに記入]
- channel・販売motion: [ここに記入]
- launch目標・制約: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- チャネル一覧ではなく、誰に何をどの順で届け、どのsignalで次の投資判断をするかまで決めてください。

## 出力形式
1. ICP / segment
2. positioning・message
3. channel / motion
4. launch sequence
5. success metric・feedback loop

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

プロダクト実験設計プロンプト

用途: 指標分析の実務で「プロダクト実験設計」を短時間で作る

主な出力: 主要指標、分析軸、SQL/イベント案、解釈、意思決定への接続

# プロダクト実験設計プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、指標分析の実務で使える「プロダクト実験設計」を日本語で作成してください。

用途: 指標分析の実務で「プロダクト実験設計」を短時間で作る

## 入力
- 仮説: [ここに記入]
- 対象・randomization unit: [ここに記入]
- Primary metric: [ここに記入]
- Guardrail・Data Quality条件: [ここに記入]
- 期間・sample・停止条件: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 結果を見てから成功条件を変えず、SRM等のdata-quality異常と効果判定を分離してください。

## 出力形式
1. 仮説と対象
2. 割付・exposure設計
3. Primary・Guardrail・Data Quality指標
4. 事前のGo/No-Go・停止条件
5. 結果記録と再評価方法

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

アジャイルチーム憲章作成プロンプト

用途: ステークホルダーコミュニケーションの実務で「アジャイルチーム憲章作成」を短時間で作る

主な出力: 読み手別メッセージ、合意形成、リスク共有、次アクション

# アジャイルチーム憲章作成プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ステークホルダーコミュニケーションの実務で使える「アジャイルチーム憲章作成」を日本語で作成してください。

用途: ステークホルダーコミュニケーションの実務で「アジャイルチーム憲章作成」を短時間で作る

## 入力
- 読み手: [ここに記入]
- 伝えたい状況: [ここに記入]
- 決まっていること: [ここに記入]
- 未決事項: [ここに記入]
- 依頼したい判断: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 相手に必要な判断を先に置き、詳細は補足として整理してください。

## 出力形式
1. 要約
2. 読み手別メッセージ
3. リスク
4. 意思決定依頼
5. 次のアクション

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

PMF評価プロンプト

用途: ユーザーリサーチの実務で「PMF評価」を短時間で作る

主な出力: 調査目的、対象者、質問、分析観点、次の検証アクション

# PMF評価プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ユーザーリサーチの実務で使える「PMF評価」を日本語で作成してください。

用途: ユーザーリサーチの実務で「PMF評価」を短時間で作る

## 入力
- 対象市場・segment: [ここに記入]
- 提供価値: [ここに記入]
- 利用・継続data: [ここに記入]
- 定性Evidence: [ここに記入]
- 代替手段・競合: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 単一のsurvey scoreや主観でPMFを断定せず、継続利用・購入・紹介等の行動Evidenceと合わせてください。

## 出力形式
1. PMF仮説
2. 行動Evidence
3. 定性Evidence
4. 反証・不足Evidence
5. 次に検証するsegment・仮説

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

機能利用促進戦略プロンプト

用途: 機能開発の実務で「機能利用促進戦略」を短時間で作る

主な出力: 要件、優先順位、受け入れ条件、実装・検証観点

# 機能利用促進戦略プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、機能開発の実務で使える「機能利用促進戦略」を日本語で作成してください。

用途: 機能開発の実務で「機能利用促進戦略」を短時間で作る

## 入力
- 対象市場・顧客: [ここに記入]
- 市場変化: [ここに記入]
- 顧客課題・代替手段: [ここに記入]
- 自社の強み・制約: [ここに記入]
- 事業目標: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 抽象的なスローガンだけで終えず、選択・非選択と、外れた場合に見直す前提を明示してください。

## 出力形式
1. 現状診断
2. 戦略・ビジョン仮説
3. 選択すること / 捨てること
4. 勝ち筋と前提
5. risk・検証・次の意思決定

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

プロダクトローンチチェックリスト生成プロンプト

用途: ステークホルダーコミュニケーションの実務で「プロダクトローンチチェックリスト生成」を短時間で作る

主な出力: 読み手別メッセージ、合意形成、リスク共有、次アクション

# プロダクトローンチチェックリスト生成プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ステークホルダーコミュニケーションの実務で使える「プロダクトローンチチェックリスト生成」を日本語で作成してください。

用途: ステークホルダーコミュニケーションの実務で「プロダクトローンチチェックリスト生成」を短時間で作る

## 入力
- 対象ユーザー・読み手: [ここに記入]
- 変更内容: [ここに記入]
- ユーザー価値: [ここに記入]
- 既知の制約・risk: [ここに記入]
- 公開範囲・日時・support情報: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 機能一覧の羅列ではなく、読み手ごとに「何が変わり、何をすべきか」を先に示してください。

## 出力形式
1. 対象別メッセージ
2. 何が変わるか・価値
3. 利用方法・移行
4. risk・既知の制約
5. CTA・問い合わせ・次アクション

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

ユーザーリサーチ計画プロンプト

用途: ユーザーリサーチの実務で「ユーザーリサーチ計画」を短時間で作る

主な出力: 調査目的、対象者、質問、分析観点、次の検証アクション

# ユーザーリサーチ計画プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ユーザーリサーチの実務で使える「ユーザーリサーチ計画」を日本語で作成してください。

用途: ユーザーリサーチの実務で「ユーザーリサーチ計画」を短時間で作る

## 入力
- 意思決定したい問い: [ここに記入]
- 対象segment: [ここに記入]
- 既知Evidence: [ここに記入]
- 未確認仮説: [ここに記入]
- 期限・利用可能な手法: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 調査そのものを目的にせず、結果によって何の判断が変わるかを先に固定してください。

## 出力形式
1. Research Question
2. 対象・sample方針
3. 手法と理由
4. 収集Evidence・分析方法
5. 意思決定への接続と停止条件

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

プロダクト意思決定フレームワークプロンプト

用途: プロダクト戦略の実務で「プロダクト意思決定フレームワーク」を短時間で作る

主な出力: 戦略仮説、選択肢、判断基準、リスク、次の意思決定

# プロダクト意思決定フレームワークプロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、プロダクト戦略の実務で使える「プロダクト意思決定フレームワーク」を日本語で作成してください。

用途: プロダクト戦略の実務で「プロダクト意思決定フレームワーク」を短時間で作る

## 入力
- 決めること: [ここに記入]
- 選択肢: [ここに記入]
- 判断基準: [ここに記入]
- Evidence・前提: [ここに記入]
- 期限・decision owner: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 結論だけでなく、後から再評価できるよう当時のEvidence・前提・捨てた選択肢を残してください。

## 出力形式
1. decision statement
2. 選択肢比較
3. 採用理由・棄却理由
4. 前提・risk
5. revisit trigger・記録

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

インタラクティブプロトタイプテスト計画プロンプト

用途: ユーザーリサーチの実務で「インタラクティブプロトタイプテスト計画」を短時間で作る

主な出力: 調査目的、対象者、質問、分析観点、次の検証アクション

# インタラクティブプロトタイプテスト計画プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ユーザーリサーチの実務で使える「インタラクティブプロトタイプテスト計画」を日本語で作成してください。

用途: ユーザーリサーチの実務で「インタラクティブプロトタイプテスト計画」を短時間で作る

## 入力
- 検証したいprototype・flow: [ここに記入]
- 対象ユーザー: [ここに記入]
- 主要task: [ここに記入]
- 観察したい仮説: [ここに記入]
- テスト環境・制約: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 好みを聞くだけでなく、task達成・迷い・迂回・誤操作を観察し、発言と行動を分けて記録してください。

## 出力形式
1. テスト目的
2. task scenario
3. 観察項目・成功条件
4. 質問・probe
5. 記録方法・分析・次の設計判断

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

リリースノート生成プロンプト

用途: ステークホルダーコミュニケーションの実務で「リリースノート生成」を短時間で作る

主な出力: 読み手別メッセージ、合意形成、リスク共有、次アクション

# リリースノート生成プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ステークホルダーコミュニケーションの実務で使える「リリースノート生成」を日本語で作成してください。

用途: ステークホルダーコミュニケーションの実務で「リリースノート生成」を短時間で作る

## 入力
- 対象ユーザー・読み手: [ここに記入]
- 変更内容: [ここに記入]
- ユーザー価値: [ここに記入]
- 既知の制約・risk: [ここに記入]
- 公開範囲・日時・support情報: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 機能一覧の羅列ではなく、読み手ごとに「何が変わり、何をすべきか」を先に示してください。

## 出力形式
1. 対象別メッセージ
2. 何が変わるか・価値
3. 利用方法・移行
4. risk・既知の制約
5. CTA・問い合わせ・次アクション

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

プロダクトバックログ整理戦略プロンプト

用途: 機能開発の実務で「プロダクトバックログ整理戦略」を短時間で作る

主な出力: 要件、優先順位、受け入れ条件、実装・検証観点

# プロダクトバックログ整理戦略プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、機能開発の実務で使える「プロダクトバックログ整理戦略」を日本語で作成してください。

用途: 機能開発の実務で「プロダクトバックログ整理戦略」を短時間で作る

## 入力
- 対象市場・顧客: [ここに記入]
- 市場変化: [ここに記入]
- 顧客課題・代替手段: [ここに記入]
- 自社の強み・制約: [ここに記入]
- 事業目標: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 抽象的なスローガンだけで終えず、選択・非選択と、外れた場合に見直す前提を明示してください。

## 出力形式
1. 現状診断
2. 戦略・ビジョン仮説
3. 選択すること / 捨てること
4. 勝ち筋と前提
5. risk・検証・次の意思決定

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

顧客アドバイザリーボード設計プロンプト

用途: ユーザーリサーチの実務で「顧客アドバイザリーボード設計」を短時間で作る

主な出力: 調査目的、対象者、質問、分析観点、次の検証アクション

# 顧客アドバイザリーボード設計プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ユーザーリサーチの実務で使える「顧客アドバイザリーボード設計」を日本語で作成してください。

用途: ユーザーリサーチの実務で「顧客アドバイザリーボード設計」を短時間で作る

## 入力
- 意思決定したいテーマ: [ここに記入]
- 対象顧客segment: [ここに記入]
- 候補企業・role: [ここに記入]
- 既存顧客Evidence: [ここに記入]
- 頻度・期間・利益相反条件: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 声の大きい顧客を市場全体の代表とみなさず、CABの意見を他の定量・定性Evidenceと分けて扱ってください。

## 出力形式
1. CAB目的・非目的
2. 参加者選定rubric
3. session agenda・問い
4. feedback記録とproduct decisionへの接続
5. 代表性・利益相反・継続運用guardrail

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

プロダクトドキュメント戦略プロンプト

用途: ステークホルダーコミュニケーションの実務で「プロダクトドキュメント戦略」を短時間で作る

主な出力: 読み手別メッセージ、合意形成、リスク共有、次アクション

# プロダクトドキュメント戦略プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ステークホルダーコミュニケーションの実務で使える「プロダクトドキュメント戦略」を日本語で作成してください。

用途: ステークホルダーコミュニケーションの実務で「プロダクトドキュメント戦略」を短時間で作る

## 入力
- 対象市場・顧客: [ここに記入]
- 市場変化: [ここに記入]
- 顧客課題・代替手段: [ここに記入]
- 自社の強み・制約: [ここに記入]
- 事業目標: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 抽象的なスローガンだけで終えず、選択・非選択と、外れた場合に見直す前提を明示してください。

## 出力形式
1. 現状診断
2. 戦略・ビジョン仮説
3. 選択すること / 捨てること
4. 勝ち筋と前提
5. risk・検証・次の意思決定

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

Feature Flag導入戦略プロンプト

用途: 機能開発の実務で「Feature Flag導入戦略」を短時間で作る

主な出力: 要件、優先順位、受け入れ条件、実装・検証観点

# Feature Flag導入戦略プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、機能開発の実務で使える「Feature Flag導入戦略」を日本語で作成してください。

用途: 機能開発の実務で「Feature Flag導入戦略」を短時間で作る

## 入力
- 対象機能: [ここに記入]
- target population: [ここに記入]
- default behavior: [ここに記入]
- rollout・kill条件: [ここに記入]
- owner・expiry: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- rolloutとExperimentを混同せず、異常時のproduct behaviorと削除条件を明示してください。

## 出力形式
1. flag目的・lifecycle
2. targeting・evaluation context
3. fallback・default
4. rollout・monitoring・kill switch
5. cleanup条件

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

プロダクトKR・ヘルスメトリクス設計プロンプト

用途: 指標分析の実務で「プロダクトKR・ヘルスメトリクス設計」を短時間で作る

主な出力: 主要指標、分析軸、SQL/イベント案、解釈、意思決定への接続

# プロダクトKR・ヘルスメトリクス設計プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、指標分析の実務で使える「プロダクトKR・ヘルスメトリクス設計」を日本語で作成してください。

用途: 指標分析の実務で「プロダクトKR・ヘルスメトリクス設計」を短時間で作る

## 入力
- 意思決定したいこと: [ここに記入]
- 対象ユーザー・segment: [ここに記入]
- 指標定義: [ここに記入]
- 利用できるdata・event: [ここに記入]
- 更新頻度・owner: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 見栄えのよい指標を増やさず、意思決定と定義が紐づく最小セットにしてください。

## 出力形式
1. 意思決定と主要指標
2. 指標定義・分母分子
3. segment・比較軸
4. 計測・data-quality要件
5. dashboard運用・見直し条件

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

デザインシステム要件定義プロンプト

用途: 機能開発の実務で「デザインシステム要件定義」を短時間で作る

主な出力: 要件、優先順位、受け入れ条件、実装・検証観点

# デザインシステム要件定義プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、機能開発の実務で使える「デザインシステム要件定義」を日本語で作成してください。

用途: 機能開発の実務で「デザインシステム要件定義」を短時間で作る

## 入力
- 対象ユーザー: [ここに記入]
- 解決したい課題と根拠: [ここに記入]
- 目的・非目的: [ここに記入]
- 既存仕様・制約: [ここに記入]
- 成功指標・計測: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 機能一覧ではなく、課題→目的→要件→成功条件が追跡できるようにし、非スコープと未決事項を明示してください。

## 出力形式
1. 背景・課題
2. 対象ユーザーと利用状況
3. スコープ・非スコープ
4. 要件・受け入れ条件
5. 成功指標・リスク・未決事項

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

Voice of Customerプログラム設計プロンプト

用途: ユーザーリサーチの実務で「Voice of Customerプログラム設計」を短時間で作る

主な出力: 調査目的、対象者、質問、分析観点、次の検証アクション

# Voice of Customerプログラム設計プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ユーザーリサーチの実務で使える「Voice of Customerプログラム設計」を日本語で作成してください。

用途: ユーザーリサーチの実務で「Voice of Customerプログラム設計」を短時間で作る

## 入力
- 候補施策: [ここに記入]
- 対象ユーザー・Reach根拠: [ここに記入]
- 期待Impact: [ここに記入]
- Confidenceの根拠: [ここに記入]
- Effort・制約: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- スコアを最終判断そのものにせず、各入力値の根拠、反証、戦略・依存関係を別に残してください。

## 出力形式
1. 評価前提
2. 比較表・スコア
3. 不確実性・感度
4. スコア外の制約・戦略適合
5. 推奨順位と見直し条件

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

Engineering-PM協働憲章プロンプト

用途: ステークホルダーコミュニケーションの実務で「Engineering-PM協働憲章」を短時間で作る

主な出力: 読み手別メッセージ、合意形成、リスク共有、次アクション

# Engineering-PM協働憲章プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ステークホルダーコミュニケーションの実務で使える「Engineering-PM協働憲章」を日本語で作成してください。

用途: ステークホルダーコミュニケーションの実務で「Engineering-PM協働憲章」を短時間で作る

## 入力
- 仮説: [ここに記入]
- 対象・randomization unit: [ここに記入]
- Primary metric: [ここに記入]
- Guardrail・Data Quality条件: [ここに記入]
- 期間・sample・停止条件: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 結果を見てから成功条件を変えず、SRM等のdata-quality異常と効果判定を分離してください。

## 出力形式
1. 仮説と対象
2. 割付・exposure設計
3. Primary・Guardrail・Data Quality指標
4. 事前のGo/No-Go・停止条件
5. 結果記録と再評価方法

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

アクセシビリティ要件定義プロンプト

用途: 機能開発の実務で「アクセシビリティ要件定義」を短時間で作る

主な出力: 要件、優先順位、受け入れ条件、実装・検証観点

# アクセシビリティ要件定義プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、機能開発の実務で使える「アクセシビリティ要件定義」を日本語で作成してください。

用途: 機能開発の実務で「アクセシビリティ要件定義」を短時間で作る

## 入力
- 対象画面・主要task: [ここに記入]
- 対象platform・入力手段: [ここに記入]
- 既知の利用者ニーズ: [ここに記入]
- 現行実装・design system: [ここに記入]
- 適用する基準・検証範囲: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 自動checkerだけで適合を断定せず、適用するWCAG等の基準版・levelを明示し、主要taskはmanual testも計画してください。

## 出力形式
1. アクセシビリティ要件
2. 主要task別の受け入れ条件
3. keyboard・focus・semantic要件
4. contrast・text・error要件
5. manual / automated検証計画と未確認事項

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

プロダクトローカライゼーション戦略プロンプト

用途: プロダクト戦略の実務で「プロダクトローカライゼーション戦略」を短時間で作る

主な出力: 戦略仮説、選択肢、判断基準、リスク、次の意思決定

# プロダクトローカライゼーション戦略プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、プロダクト戦略の実務で使える「プロダクトローカライゼーション戦略」を日本語で作成してください。

用途: プロダクト戦略の実務で「プロダクトローカライゼーション戦略」を短時間で作る

## 入力
- 対象市場・顧客: [ここに記入]
- 市場変化: [ここに記入]
- 顧客課題・代替手段: [ここに記入]
- 自社の強み・制約: [ここに記入]
- 事業目標: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 抽象的なスローガンだけで終えず、選択・非選択と、外れた場合に見直す前提を明示してください。

## 出力形式
1. 現状診断
2. 戦略・ビジョン仮説
3. 選択すること / 捨てること
4. 勝ち筋と前提
5. risk・検証・次の意思決定

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

JTBDインタビュースクリプトプロンプト

用途: ユーザーリサーチの実務で「JTBDインタビュースクリプト」を短時間で作る

主な出力: 調査目的、対象者、質問、分析観点、次の検証アクション

# JTBDインタビュースクリプトプロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ユーザーリサーチの実務で使える「JTBDインタビュースクリプト」を日本語で作成してください。

用途: ユーザーリサーチの実務で「JTBDインタビュースクリプト」を短時間で作る

## 入力
- 調査目的: [ここに記入]
- 対象セグメント: [ここに記入]
- 検証したい仮説: [ここに記入]
- 既知のEvidence: [ここに記入]
- 避けたい誘導・制約: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 未来の意向や機能要望だけでなく、過去の具体行動・状況・代替手段を聞ける質問にしてください。

## 出力形式
1. 調査目的と対象
2. 質問フロー
3. 深掘り質問
4. バイアス・倫理上の注意
5. 分析方法と次の検証

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

部門横断プロダクトレビュー設計プロンプト

用途: ステークホルダーコミュニケーションの実務で「部門横断プロダクトレビュー設計」を短時間で作る

主な出力: 読み手別メッセージ、合意形成、リスク共有、次アクション

# 部門横断プロダクトレビュー設計プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ステークホルダーコミュニケーションの実務で使える「部門横断プロダクトレビュー設計」を日本語で作成してください。

用途: ステークホルダーコミュニケーションの実務で「部門横断プロダクトレビュー設計」を短時間で作る

## 入力
- 読み手: [ここに記入]
- 伝えたい状況: [ここに記入]
- 決まっていること: [ここに記入]
- 未決事項: [ここに記入]
- 依頼したい判断: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 相手に必要な判断を先に置き、詳細は補足として整理してください。

## 出力形式
1. 要約
2. 読み手別メッセージ
3. リスク
4. 意思決定依頼
5. 次のアクション

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

プロダクトポートフォリオ戦略プロンプト

用途: プロダクト戦略の実務で「プロダクトポートフォリオ戦略」を短時間で作る

主な出力: 戦略仮説、選択肢、判断基準、リスク、次の意思決定

# プロダクトポートフォリオ戦略プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、プロダクト戦略の実務で使える「プロダクトポートフォリオ戦略」を日本語で作成してください。

用途: プロダクト戦略の実務で「プロダクトポートフォリオ戦略」を短時間で作る

## 入力
- 対象市場・顧客: [ここに記入]
- 市場変化: [ここに記入]
- 顧客課題・代替手段: [ここに記入]
- 自社の強み・制約: [ここに記入]
- 事業目標: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 抽象的なスローガンだけで終えず、選択・非選択と、外れた場合に見直す前提を明示してください。

## 出力形式
1. 現状診断
2. 戦略・ビジョン仮説
3. 選択すること / 捨てること
4. 勝ち筋と前提
5. risk・検証・次の意思決定

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

開発者体験リサーチ計画プロンプト

用途: ユーザーリサーチの実務で「開発者体験リサーチ計画」を短時間で作る

主な出力: 調査目的、対象者、質問、分析観点、次の検証アクション

# 開発者体験リサーチ計画プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ユーザーリサーチの実務で使える「開発者体験リサーチ計画」を日本語で作成してください。

用途: ユーザーリサーチの実務で「開発者体験リサーチ計画」を短時間で作る

## 入力
- 意思決定したい問い: [ここに記入]
- 対象segment: [ここに記入]
- 既知Evidence: [ここに記入]
- 未確認仮説: [ここに記入]
- 期限・利用可能な手法: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 調査そのものを目的にせず、結果によって何の判断が変わるかを先に固定してください。

## 出力形式
1. Research Question
2. 対象・sample方針
3. 手法と理由
4. 収集Evidence・分析方法
5. 意思決定への接続と停止条件

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

Feature Canvas作成プロンプト

用途: 機能開発の実務で「Feature Canvas作成」を短時間で作る

主な出力: 要件、優先順位、受け入れ条件、実装・検証観点

# Feature Canvas作成プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、機能開発の実務で使える「Feature Canvas作成」を日本語で作成してください。

用途: 機能開発の実務で「Feature Canvas作成」を短時間で作る

## 入力
- 機能名: [ここに記入]
- 対象ユーザー: [ここに記入]
- 解決したい課題: [ここに記入]
- 既存仕様・制約: [ここに記入]
- リリース期限: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 機能追加を前提にせず、削る案・段階公開・失敗時の扱いも含めてください。

## 出力形式
1. 要件
2. 受け入れ条件
3. 優先順位
4. 実装上の論点
5. 検証方法

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

データに基づく意思決定プロンプト

用途: 指標分析の実務で「データに基づく意思決定」を短時間で作る

主な出力: 主要指標、分析軸、SQL/イベント案、解釈、意思決定への接続

# データに基づく意思決定プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、指標分析の実務で使える「データに基づく意思決定」を日本語で作成してください。

用途: 指標分析の実務で「データに基づく意思決定」を短時間で作る

## 入力
- 決めること: [ここに記入]
- 選択肢: [ここに記入]
- 判断基準: [ここに記入]
- Evidence・前提: [ここに記入]
- 期限・decision owner: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 結論だけでなく、後から再評価できるよう当時のEvidence・前提・捨てた選択肢を残してください。

## 出力形式
1. decision statement
2. 選択肢比較
3. 採用理由・棄却理由
4. 前提・risk
5. revisit trigger・記録

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

QBRテンプレート作成プロンプト

用途: ステークホルダーコミュニケーションの実務で「QBRテンプレート作成」を短時間で作る

主な出力: 読み手別メッセージ、合意形成、リスク共有、次アクション

# QBRテンプレート作成プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ステークホルダーコミュニケーションの実務で使える「QBRテンプレート作成」を日本語で作成してください。

用途: ステークホルダーコミュニケーションの実務で「QBRテンプレート作成」を短時間で作る

## 入力
- 読み手: [ここに記入]
- 伝えたい状況: [ここに記入]
- 決まっていること: [ここに記入]
- 未決事項: [ここに記入]
- 依頼したい判断: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 相手に必要な判断を先に置き、詳細は補足として整理してください。

## 出力形式
1. 要約
2. 読み手別メッセージ
3. リスク
4. 意思決定依頼
5. 次のアクション

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

プロダクトグロース戦略プロンプト

用途: プロダクト戦略の実務で「プロダクトグロース戦略」を短時間で作る

主な出力: 戦略仮説、選択肢、判断基準、リスク、次の意思決定

# プロダクトグロース戦略プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、プロダクト戦略の実務で使える「プロダクトグロース戦略」を日本語で作成してください。

用途: プロダクト戦略の実務で「プロダクトグロース戦略」を短時間で作る

## 入力
- 対象市場・顧客: [ここに記入]
- 市場変化: [ここに記入]
- 顧客課題・代替手段: [ここに記入]
- 自社の強み・制約: [ここに記入]
- 事業目標: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 抽象的なスローガンだけで終えず、選択・非選択と、外れた場合に見直す前提を明示してください。

## 出力形式
1. 現状診断
2. 戦略・ビジョン仮説
3. 選択すること / 捨てること
4. 勝ち筋と前提
5. risk・検証・次の意思決定

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

プロダクト危機対応プレイブックプロンプト

用途: ステークホルダーコミュニケーションの実務で「プロダクト危機対応プレイブック」を短時間で作る

主な出力: 読み手別メッセージ、合意形成、リスク共有、次アクション

# プロダクト危機対応プレイブックプロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ステークホルダーコミュニケーションの実務で使える「プロダクト危機対応プレイブック」を日本語で作成してください。

用途: ステークホルダーコミュニケーションの実務で「プロダクト危機対応プレイブック」を短時間で作る

## 入力
- 事象・影響範囲: [ここに記入]
- severity判断材料: [ここに記入]
- 顧客・事業への影響: [ここに記入]
- 利用可能なrollback・mitigation: [ここに記入]
- 意思決定者・連絡先: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 原因が未確定なら推測を事実として伝えず、復旧・安全確保とcommunicationを原因究明から分離してください。

## 出力形式
1. severityと初動
2. 役割・decision owner
3. mitigation / rollback
4. 顧客・社内communication cadence
5. 復旧条件・postmortem・follow-up

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

デザインスプリント計画プロンプト

用途: 機能開発の実務で「デザインスプリント計画」を短時間で作る

主な出力: 要件、優先順位、受け入れ条件、実装・検証観点

# デザインスプリント計画プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、機能開発の実務で使える「デザインスプリント計画」を日本語で作成してください。

用途: 機能開発の実務で「デザインスプリント計画」を短時間で作る

## 入力
- Sprint Goal: [ここに記入]
- 優先候補と根拠: [ここに記入]
- team capacity: [ここに記入]
- 依存関係・blocked item: [ここに記入]
- 既知のrisk・carry-over: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- velocityを生産性目標にせず、Sprint Goalに必要な最小scopeと途中で削る条件を先に決めてください。

## 出力形式
1. Sprint Goal
2. commit候補と理由
3. capacity配分
4. 依存関係・risk
5. de-scope条件と確認ポイント

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

カスタマーサポート示唆分析プロンプト

用途: ユーザーリサーチの実務で「カスタマーサポート示唆分析」を短時間で作る

主な出力: 調査目的、対象者、質問、分析観点、次の検証アクション

# カスタマーサポート示唆分析プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ユーザーリサーチの実務で使える「カスタマーサポート示唆分析」を日本語で作成してください。

用途: ユーザーリサーチの実務で「カスタマーサポート示唆分析」を短時間で作る

## 入力
- 調査目的: [ここに記入]
- 対象ユーザー: [ここに記入]
- 既存仮説: [ここに記入]
- 利用できる発言・ログ: [ここに記入]
- 意思決定期限: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- ユーザーの要望をそのまま解決策にせず、背景・行動・制約を分けてください。

## 出力形式
1. 調査設計
2. 質問または分析観点
3. 避けるべきバイアス
4. 示唆の整理表
5. 次に検証する仮説

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

PLG戦略プロンプト

用途: プロダクト戦略の実務で「PLG戦略」を短時間で作る

主な出力: 戦略仮説、選択肢、判断基準、リスク、次の意思決定

# PLG戦略プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、プロダクト戦略の実務で使える「PLG戦略」を日本語で作成してください。

用途: プロダクト戦略の実務で「PLG戦略」を短時間で作る

## 入力
- 対象市場・顧客: [ここに記入]
- 市場変化: [ここに記入]
- 顧客課題・代替手段: [ここに記入]
- 自社の強み・制約: [ここに記入]
- 事業目標: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 抽象的なスローガンだけで終えず、選択・非選択と、外れた場合に見直す前提を明示してください。

## 出力形式
1. 現状診断
2. 戦略・ビジョン仮説
3. 選択すること / 捨てること
4. 勝ち筋と前提
5. risk・検証・次の意思決定

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

競争優位性・Moat評価プロンプト

用途: プロダクト戦略の実務で「競争優位性・Moat評価」を短時間で作る

主な出力: 戦略仮説、選択肢、判断基準、リスク、次の意思決定

# 競争優位性・Moat評価プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、プロダクト戦略の実務で使える「競争優位性・Moat評価」を日本語で作成してください。

用途: プロダクト戦略の実務で「競争優位性・Moat評価」を短時間で作る

## 入力
- 自社・対象市場: [ここに記入]
- 比較対象: [ここに記入]
- 対象segment: [ここに記入]
- 比較したいJob: [ここに記入]
- 一次情報・調査期限: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 機能表だけで終えず、sourceと更新日を残し、確認できない情報を推測で埋めないでください。

## 出力形式
1. 比較対象とsource
2. segment / Job別比較
3. 強み・弱み・代替
4. 差別化仮説
5. 追加調査・不確実性

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

Sales・CSイネーブルメント計画プロンプト

用途: ステークホルダーコミュニケーションの実務で「Sales・CSイネーブルメント計画」を短時間で作る

主な出力: 読み手別メッセージ、合意形成、リスク共有、次アクション

# Sales・CSイネーブルメント計画プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ステークホルダーコミュニケーションの実務で使える「Sales・CSイネーブルメント計画」を日本語で作成してください。

用途: ステークホルダーコミュニケーションの実務で「Sales・CSイネーブルメント計画」を短時間で作る

## 入力
- 仮説: [ここに記入]
- 対象・randomization unit: [ここに記入]
- Primary metric: [ここに記入]
- Guardrail・Data Quality条件: [ここに記入]
- 期間・sample・停止条件: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 結果を見てから成功条件を変えず、SRM等のdata-quality異常と効果判定を分離してください。

## 出力形式
1. 仮説と対象
2. 割付・exposure設計
3. Primary・Guardrail・Data Quality指標
4. 事前のGo/No-Go・停止条件
5. 結果記録と再評価方法

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

プロダクトセキュリティ要件定義プロンプト

用途: 機能開発の実務で「プロダクトセキュリティ要件定義」を短時間で作る

主な出力: 要件、優先順位、受け入れ条件、実装・検証観点

# プロダクトセキュリティ要件定義プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、機能開発の実務で使える「プロダクトセキュリティ要件定義」を日本語で作成してください。

用途: 機能開発の実務で「プロダクトセキュリティ要件定義」を短時間で作る

## 入力
- 対象ユーザー: [ここに記入]
- 解決したい課題と根拠: [ここに記入]
- 目的・非目的: [ここに記入]
- 既存仕様・制約: [ここに記入]
- 成功指標・計測: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 機能一覧ではなく、課題→目的→要件→成功条件が追跡できるようにし、非スコープと未決事項を明示してください。

## 出力形式
1. 背景・課題
2. 対象ユーザーと利用状況
3. スコープ・非スコープ
4. 要件・受け入れ条件
5. 成功指標・リスク・未決事項

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

ユーザー行動分析プロンプト

用途: ユーザーリサーチの実務で「ユーザー行動分析」を短時間で作る

主な出力: 調査目的、対象者、質問、分析観点、次の検証アクション

# ユーザー行動分析プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ユーザーリサーチの実務で使える「ユーザー行動分析」を日本語で作成してください。

用途: ユーザーリサーチの実務で「ユーザー行動分析」を短時間で作る

## 入力
- 調査目的: [ここに記入]
- 対象ユーザー: [ここに記入]
- 既存仮説: [ここに記入]
- 利用できる発言・ログ: [ここに記入]
- 意思決定期限: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- ユーザーの要望をそのまま解決策にせず、背景・行動・制約を分けてください。

## 出力形式
1. 調査設計
2. 質問または分析観点
3. 避けるべきバイアス
4. 示唆の整理表
5. 次に検証する仮説

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

プロダクトプラットフォーム戦略プロンプト

用途: プロダクト戦略の実務で「プロダクトプラットフォーム戦略」を短時間で作る

主な出力: 戦略仮説、選択肢、判断基準、リスク、次の意思決定

# プロダクトプラットフォーム戦略プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、プロダクト戦略の実務で使える「プロダクトプラットフォーム戦略」を日本語で作成してください。

用途: プロダクト戦略の実務で「プロダクトプラットフォーム戦略」を短時間で作る

## 入力
- 対象市場・顧客: [ここに記入]
- 市場変化: [ここに記入]
- 顧客課題・代替手段: [ここに記入]
- 自社の強み・制約: [ここに記入]
- 事業目標: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 抽象的なスローガンだけで終えず、選択・非選択と、外れた場合に見直す前提を明示してください。

## 出力形式
1. 現状診断
2. 戦略・ビジョン仮説
3. 選択すること / 捨てること
4. 勝ち筋と前提
5. risk・検証・次の意思決定

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

UXライティングスタイルガイド作成プロンプト

用途: ステークホルダーコミュニケーションの実務で「UXライティングスタイルガイド作成」を短時間で作る

主な出力: 読み手別メッセージ、合意形成、リスク共有、次アクション

# UXライティングスタイルガイド作成プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ステークホルダーコミュニケーションの実務で使える「UXライティングスタイルガイド作成」を日本語で作成してください。

用途: ステークホルダーコミュニケーションの実務で「UXライティングスタイルガイド作成」を短時間で作る

## 入力
- 読み手: [ここに記入]
- 伝えたい状況: [ここに記入]
- 決まっていること: [ここに記入]
- 未決事項: [ここに記入]
- 依頼したい判断: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 相手に必要な判断を先に置き、詳細は補足として整理してください。

## 出力形式
1. 要約
2. 読み手別メッセージ
3. リスク
4. 意思決定依頼
5. 次のアクション

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

リプラットフォーム判断プロンプト

用途: 機能開発の実務で「リプラットフォーム判断」を短時間で作る

主な出力: 要件、優先順位、受け入れ条件、実装・検証観点

# リプラットフォーム判断プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、機能開発の実務で使える「リプラットフォーム判断」を日本語で作成してください。

用途: 機能開発の実務で「リプラットフォーム判断」を短時間で作る

## 入力
- 現行platformとpain: [ここに記入]
- 移行候補: [ここに記入]
- 重要要件・SLO: [ここに記入]
- data・integration依存: [ここに記入]
- 期限・予算・team capacity: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 新技術採用を目的化せず、移行中の二重運用・data整合・rollback可能性と、移行しない選択肢も比較してください。

## 出力形式
1. 移行目的と非目的
2. 選択肢比較
3. migration wave・依存関係
4. data validation・rollback計画
5. Go/No-Go基準・運用移管

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

顧客開発インタビューガイドプロンプト

用途: ユーザーリサーチの実務で「顧客開発インタビューガイド」を短時間で作る

主な出力: 調査目的、対象者、質問、分析観点、次の検証アクション

# 顧客開発インタビューガイドプロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ユーザーリサーチの実務で使える「顧客開発インタビューガイド」を日本語で作成してください。

用途: ユーザーリサーチの実務で「顧客開発インタビューガイド」を短時間で作る

## 入力
- 調査目的: [ここに記入]
- 対象セグメント: [ここに記入]
- 検証したい仮説: [ここに記入]
- 既知のEvidence: [ここに記入]
- 避けたい誘導・制約: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 未来の意向や機能要望だけでなく、過去の具体行動・状況・代替手段を聞ける質問にしてください。

## 出力形式
1. 調査目的と対象
2. 質問フロー
3. 深掘り質問
4. バイアス・倫理上の注意
5. 分析方法と次の検証

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

技術実現性評価プロンプト

用途: 機能開発の実務で「技術実現性評価」を短時間で作る

主な出力: 要件、優先順位、受け入れ条件、実装・検証観点

# 技術実現性評価プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、機能開発の実務で使える「技術実現性評価」を日本語で作成してください。

用途: 機能開発の実務で「技術実現性評価」を短時間で作る

## 入力
- 機能名: [ここに記入]
- 対象ユーザー: [ここに記入]
- 解決したい課題: [ここに記入]
- 既存仕様・制約: [ここに記入]
- リリース期限: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 機能追加を前提にせず、削る案・段階公開・失敗時の扱いも含めてください。

## 出力形式
1. 要件
2. 受け入れ条件
3. 優先順位
4. 実装上の論点
5. 検証方法

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

プロダクト分析実装ガイドプロンプト

用途: 指標分析の実務で「プロダクト分析実装ガイド」を短時間で作る

主な出力: 主要指標、分析軸、SQL/イベント案、解釈、意思決定への接続

# プロダクト分析実装ガイドプロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、指標分析の実務で使える「プロダクト分析実装ガイド」を日本語で作成してください。

用途: 指標分析の実務で「プロダクト分析実装ガイド」を短時間で作る

## 入力
- 意思決定したいこと: [ここに記入]
- 対象ユーザー・segment: [ここに記入]
- 指標定義: [ここに記入]
- 利用できるdata・event: [ここに記入]
- 更新頻度・owner: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 見栄えのよい指標を増やさず、意思決定と定義が紐づく最小セットにしてください。

## 出力形式
1. 意思決定と主要指標
2. 指標定義・分母分子
3. segment・比較軸
4. 計測・data-quality要件
5. dashboard運用・見直し条件

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

リモートユーザーリサーチ運用プロンプト

用途: ユーザーリサーチの実務で「リモートユーザーリサーチ運用」を短時間で作る

主な出力: 調査目的、対象者、質問、分析観点、次の検証アクション

# リモートユーザーリサーチ運用プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ユーザーリサーチの実務で使える「リモートユーザーリサーチ運用」を日本語で作成してください。

用途: ユーザーリサーチの実務で「リモートユーザーリサーチ運用」を短時間で作る

## 入力
- 調査目的: [ここに記入]
- 対象ユーザー: [ここに記入]
- 既存仮説: [ここに記入]
- 利用できる発言・ログ: [ここに記入]
- 意思決定期限: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- ユーザーの要望をそのまま解決策にせず、背景・行動・制約を分けてください。

## 出力形式
1. 調査設計
2. 質問または分析観点
3. 避けるべきバイアス
4. 示唆の整理表
5. 次に検証する仮説

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

PM面接評価フレームワークプロンプト

用途: ステークホルダーコミュニケーションの実務で「PM面接評価フレームワーク」を短時間で作る

主な出力: 読み手別メッセージ、合意形成、リスク共有、次アクション

# PM面接評価フレームワークプロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ステークホルダーコミュニケーションの実務で使える「PM面接評価フレームワーク」を日本語で作成してください。

用途: ステークホルダーコミュニケーションの実務で「PM面接評価フレームワーク」を短時間で作る

## 入力
- 対象role・level: [ここに記入]
- 評価したいcompetency: [ここに記入]
- job context: [ここに記入]
- 候補者Evidence: [ここに記入]
- 面接時間・panel: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 印象やculture fitだけで決めず、job-relatedなEvidenceと同じrubricで比較してください。

## 出力形式
1. 評価rubric
2. 質問と深掘り
3. 良いEvidence / red flag
4. scorecard
5. 判定時のbias check

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

機能廃止戦略プロンプト

用途: 機能開発の実務で「機能廃止戦略」を短時間で作る

主な出力: 要件、優先順位、受け入れ条件、実装・検証観点

# 機能廃止戦略プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、機能開発の実務で使える「機能廃止戦略」を日本語で作成してください。

用途: 機能開発の実務で「機能廃止戦略」を短時間で作る

## 入力
- 対象市場・顧客: [ここに記入]
- 市場変化: [ここに記入]
- 顧客課題・代替手段: [ここに記入]
- 自社の強み・制約: [ここに記入]
- 事業目標: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 抽象的なスローガンだけで終えず、選択・非選択と、外れた場合に見直す前提を明示してください。

## 出力形式
1. 現状診断
2. 戦略・ビジョン仮説
3. 選択すること / 捨てること
4. 勝ち筋と前提
5. risk・検証・次の意思決定

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

PM会議テンプレート作成プロンプト

用途: ステークホルダーコミュニケーションの実務で「PM会議テンプレート作成」を短時間で作る

主な出力: 読み手別メッセージ、合意形成、リスク共有、次アクション

# PM会議テンプレート作成プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ステークホルダーコミュニケーションの実務で使える「PM会議テンプレート作成」を日本語で作成してください。

用途: ステークホルダーコミュニケーションの実務で「PM会議テンプレート作成」を短時間で作る

## 入力
- 目的・決めること: [ここに記入]
- 参加者・role: [ここに記入]
- 事前Evidence: [ここに記入]
- 時間: [ここに記入]
- 未決事項・対立点: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 会議開催を成果にせず、終了時に何が決まり何が未決かを明示できる設計にしてください。

## 出力形式
1. agenda
2. 事前準備
3. facilitation step
4. decision / parking lot
5. owner・期限つきnext action

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

ユーザー導入ファネル分析プロンプト

用途: 指標分析の実務で「ユーザー導入ファネル分析」を短時間で作る

主な出力: 主要指標、分析軸、SQL/イベント案、解釈、意思決定への接続

# ユーザー導入ファネル分析プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、指標分析の実務で使える「ユーザー導入ファネル分析」を日本語で作成してください。

用途: 指標分析の実務で「ユーザー導入ファネル分析」を短時間で作る

## 入力
- プロダクト領域: [ここに記入]
- 見たい指標: [ここに記入]
- 利用できるデータ: [ここに記入]
- 比較期間: [ここに記入]
- 意思決定したいこと: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 相関と因果を混同せず、データ不足と追加計測案を分けてください。

## 出力形式
1. 主要指標
2. 分析軸
3. イベントまたはSQL案
4. 解釈
5. 次アクション

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

データに基づくロードマップ優先順位プロンプト

用途: プロダクト戦略の実務で「データに基づくロードマップ優先順位」を短時間で作る

主な出力: 戦略仮説、選択肢、判断基準、リスク、次の意思決定

# データに基づくロードマップ優先順位プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、プロダクト戦略の実務で使える「データに基づくロードマップ優先順位」を日本語で作成してください。

用途: プロダクト戦略の実務で「データに基づくロードマップ優先順位」を短時間で作る

## 入力
- 候補施策: [ここに記入]
- 対象ユーザー・Reach根拠: [ここに記入]
- 期待Impact: [ここに記入]
- Confidenceの根拠: [ここに記入]
- Effort・制約: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- スコアを最終判断そのものにせず、各入力値の根拠、反証、戦略・依存関係を別に残してください。

## 出力形式
1. 評価前提
2. 比較表・スコア
3. 不確実性・感度
4. スコア外の制約・戦略適合
5. 推奨順位と見直し条件

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

プロダクトナレッジベース戦略プロンプト

用途: ステークホルダーコミュニケーションの実務で「プロダクトナレッジベース戦略」を短時間で作る

主な出力: 読み手別メッセージ、合意形成、リスク共有、次アクション

# プロダクトナレッジベース戦略プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ステークホルダーコミュニケーションの実務で使える「プロダクトナレッジベース戦略」を日本語で作成してください。

用途: ステークホルダーコミュニケーションの実務で「プロダクトナレッジベース戦略」を短時間で作る

## 入力
- 対象読者・利用場面: [ここに記入]
- 扱う情報domain: [ここに記入]
- 既存source・重複: [ここに記入]
- 更新頻度・owner候補: [ここに記入]
- 検索・権限制約: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 記事数を成果にせず、source-of-truth・owner・更新期限を定義し、古い情報が残る経路を最初から設計してください。

## 出力形式
1. 情報architecture
2. source-of-truth方針
3. 作成・review・expiry workflow
4. 検索・tag・権限設計
5. 鮮度・利用状況の運用metric

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

機能検証ユーザーインタビューガイドプロンプト

用途: ユーザーリサーチの実務で「機能検証ユーザーインタビューガイド」を短時間で作る

主な出力: 調査目的、対象者、質問、分析観点、次の検証アクション

# 機能検証ユーザーインタビューガイドプロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ユーザーリサーチの実務で使える「機能検証ユーザーインタビューガイド」を日本語で作成してください。

用途: ユーザーリサーチの実務で「機能検証ユーザーインタビューガイド」を短時間で作る

## 入力
- 調査目的: [ここに記入]
- 対象セグメント: [ここに記入]
- 検証したい仮説: [ここに記入]
- 既知のEvidence: [ここに記入]
- 避けたい誘導・制約: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 未来の意向や機能要望だけでなく、過去の具体行動・状況・代替手段を聞ける質問にしてください。

## 出力形式
1. 調査目的と対象
2. 質問フロー
3. 深掘り質問
4. バイアス・倫理上の注意
5. 分析方法と次の検証

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

ステークホルダー巻き込み戦略プロンプト

用途: ステークホルダーコミュニケーションの実務で「ステークホルダー巻き込み戦略」を短時間で作る

主な出力: 読み手別メッセージ、合意形成、リスク共有、次アクション

# ステークホルダー巻き込み戦略プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ステークホルダーコミュニケーションの実務で使える「ステークホルダー巻き込み戦略」を日本語で作成してください。

用途: ステークホルダーコミュニケーションの実務で「ステークホルダー巻き込み戦略」を短時間で作る

## 入力
- 対象市場・顧客: [ここに記入]
- 市場変化: [ここに記入]
- 顧客課題・代替手段: [ここに記入]
- 自社の強み・制約: [ここに記入]
- 事業目標: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 抽象的なスローガンだけで終えず、選択・非選択と、外れた場合に見直す前提を明示してください。

## 出力形式
1. 現状診断
2. 戦略・ビジョン仮説
3. 選択すること / 捨てること
4. 勝ち筋と前提
5. risk・検証・次の意思決定

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

Early Adopterプログラム設計プロンプト

用途: プロダクト戦略の実務で「Early Adopterプログラム設計」を短時間で作る

主な出力: 戦略仮説、選択肢、判断基準、リスク、次の意思決定

# Early Adopterプログラム設計プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、プロダクト戦略の実務で使える「Early Adopterプログラム設計」を日本語で作成してください。

用途: プロダクト戦略の実務で「Early Adopterプログラム設計」を短時間で作る

## 入力
- プロダクト名: [ここに記入]
- 対象市場: [ここに記入]
- 事業目標: [ここに記入]
- 競合・代替手段: [ここに記入]
- 制約条件: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 抽象論で終えず、捨てる選択肢と検証すべき前提を明示してください。

## 出力形式
1. 戦略仮説
2. 選択肢比較
3. 判断基準
4. リスク
5. 次の意思決定

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

インクルーシブデザイン原則作成プロンプト

用途: 機能開発の実務で「インクルーシブデザイン原則作成」を短時間で作る

主な出力: 要件、優先順位、受け入れ条件、実装・検証観点

# インクルーシブデザイン原則作成プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、機能開発の実務で使える「インクルーシブデザイン原則作成」を日本語で作成してください。

用途: 機能開発の実務で「インクルーシブデザイン原則作成」を短時間で作る

## 入力
- 機能名: [ここに記入]
- 対象ユーザー: [ここに記入]
- 解決したい課題: [ここに記入]
- 既存仕様・制約: [ここに記入]
- リリース期限: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 機能追加を前提にせず、削る案・段階公開・失敗時の扱いも含めてください。

## 出力形式
1. 要件
2. 受け入れ条件
3. 優先順位
4. 実装上の論点
5. 検証方法

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

プロダクトナラティブ設計プロンプト

用途: ステークホルダーコミュニケーションの実務で「プロダクトナラティブ設計」を短時間で作る

主な出力: 読み手別メッセージ、合意形成、リスク共有、次アクション

# プロダクトナラティブ設計プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ステークホルダーコミュニケーションの実務で使える「プロダクトナラティブ設計」を日本語で作成してください。

用途: ステークホルダーコミュニケーションの実務で「プロダクトナラティブ設計」を短時間で作る

## 入力
- 対象読者: [ここに記入]
- 現状の課題・変化: [ここに記入]
- 伝えたい主張: [ここに記入]
- 根拠Evidence: [ここに記入]
- 期待する行動: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 魅力的な表現のために根拠のない断定を足さず、主張とEvidenceを対応させてください。

## 出力形式
1. core narrative
2. problem → change → value
3. 根拠・proof point
4. 反論・誤解への対応
5. 読者別CTA

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

行動分析実装計画プロンプト

用途: 指標分析の実務で「行動分析実装計画」を短時間で作る

主な出力: 主要指標、分析軸、SQL/イベント案、解釈、意思決定への接続

# 行動分析実装計画プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、指標分析の実務で使える「行動分析実装計画」を日本語で作成してください。

用途: 指標分析の実務で「行動分析実装計画」を短時間で作る

## 入力
- 意思決定したいこと: [ここに記入]
- 対象ユーザー・segment: [ここに記入]
- 指標定義: [ここに記入]
- 利用できるdata・event: [ここに記入]
- 更新頻度・owner: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 見栄えのよい指標を増やさず、意思決定と定義が紐づく最小セットにしてください。

## 出力形式
1. 意思決定と主要指標
2. 指標定義・分母分子
3. segment・比較軸
4. 計測・data-quality要件
5. dashboard運用・見直し条件

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

ユーザー中心KPI設計プロンプト

用途: 指標分析の実務で「ユーザー中心KPI設計」を短時間で作る

主な出力: 主要指標、分析軸、SQL/イベント案、解釈、意思決定への接続

# ユーザー中心KPI設計プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、指標分析の実務で使える「ユーザー中心KPI設計」を日本語で作成してください。

用途: 指標分析の実務で「ユーザー中心KPI設計」を短時間で作る

## 入力
- 意思決定したいこと: [ここに記入]
- 対象ユーザー・segment: [ここに記入]
- 指標定義: [ここに記入]
- 利用できるdata・event: [ここに記入]
- 更新頻度・owner: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 見栄えのよい指標を増やさず、意思決定と定義が紐づく最小セットにしてください。

## 出力形式
1. 意思決定と主要指標
2. 指標定義・分母分子
3. segment・比較軸
4. 計測・data-quality要件
5. dashboard運用・見直し条件

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

プロダクトサイト改善戦略プロンプト

用途: プロダクト戦略の実務で「プロダクトサイト改善戦略」を短時間で作る

主な出力: 戦略仮説、選択肢、判断基準、リスク、次の意思決定

# プロダクトサイト改善戦略プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、プロダクト戦略の実務で使える「プロダクトサイト改善戦略」を日本語で作成してください。

用途: プロダクト戦略の実務で「プロダクトサイト改善戦略」を短時間で作る

## 入力
- 対象市場・顧客: [ここに記入]
- 市場変化: [ここに記入]
- 顧客課題・代替手段: [ここに記入]
- 自社の強み・制約: [ここに記入]
- 事業目標: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 抽象的なスローガンだけで終えず、選択・非選択と、外れた場合に見直す前提を明示してください。

## 出力形式
1. 現状診断
2. 戦略・ビジョン仮説
3. 選択すること / 捨てること
4. 勝ち筋と前提
5. risk・検証・次の意思決定

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

部門横断協働憲章プロンプト

用途: ステークホルダーコミュニケーションの実務で「部門横断協働憲章」を短時間で作る

主な出力: 読み手別メッセージ、合意形成、リスク共有、次アクション

# 部門横断協働憲章プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ステークホルダーコミュニケーションの実務で使える「部門横断協働憲章」を日本語で作成してください。

用途: ステークホルダーコミュニケーションの実務で「部門横断協働憲章」を短時間で作る

## 入力
- 仮説: [ここに記入]
- 対象・randomization unit: [ここに記入]
- Primary metric: [ここに記入]
- Guardrail・Data Quality条件: [ここに記入]
- 期間・sample・停止条件: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 結果を見てから成功条件を変えず、SRM等のdata-quality異常と効果判定を分離してください。

## 出力形式
1. 仮説と対象
2. 割付・exposure設計
3. Primary・Guardrail・Data Quality指標
4. 事前のGo/No-Go・停止条件
5. 結果記録と再評価方法

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

B2B顧客アドバイザリーボード設計プロンプト

用途: ユーザーリサーチの実務で「B2B顧客アドバイザリーボード設計」を短時間で作る

主な出力: 調査目的、対象者、質問、分析観点、次の検証アクション

# B2B顧客アドバイザリーボード設計プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ユーザーリサーチの実務で使える「B2B顧客アドバイザリーボード設計」を日本語で作成してください。

用途: ユーザーリサーチの実務で「B2B顧客アドバイザリーボード設計」を短時間で作る

## 入力
- 意思決定したいテーマ: [ここに記入]
- 対象顧客segment: [ここに記入]
- 候補企業・role: [ここに記入]
- 既存顧客Evidence: [ここに記入]
- 頻度・期間・利益相反条件: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 声の大きい顧客を市場全体の代表とみなさず、CABの意見を他の定量・定性Evidenceと分けて扱ってください。

## 出力形式
1. CAB目的・非目的
2. 参加者選定rubric
3. session agenda・問い
4. feedback記録とproduct decisionへの接続
5. 代表性・利益相反・継続運用guardrail

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

機能検証実験計画プロンプト

用途: 機能開発の実務で「機能検証実験計画」を短時間で作る

主な出力: 要件、優先順位、受け入れ条件、実装・検証観点

# 機能検証実験計画プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、機能開発の実務で使える「機能検証実験計画」を日本語で作成してください。

用途: 機能開発の実務で「機能検証実験計画」を短時間で作る

## 入力
- 仮説: [ここに記入]
- 対象・randomization unit: [ここに記入]
- Primary metric: [ここに記入]
- Guardrail・Data Quality条件: [ここに記入]
- 期間・sample・停止条件: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 結果を見てから成功条件を変えず、SRM等のdata-quality異常と効果判定を分離してください。

## 出力形式
1. 仮説と対象
2. 割付・exposure設計
3. Primary・Guardrail・Data Quality指標
4. 事前のGo/No-Go・停止条件
5. 結果記録と再評価方法

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

プロダクトデモ台本作成プロンプト

用途: ステークホルダーコミュニケーションの実務で「プロダクトデモ台本作成」を短時間で作る

主な出力: 読み手別メッセージ、合意形成、リスク共有、次アクション

# プロダクトデモ台本作成プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ステークホルダーコミュニケーションの実務で使える「プロダクトデモ台本作成」を日本語で作成してください。

用途: ステークホルダーコミュニケーションの実務で「プロダクトデモ台本作成」を短時間で作る

## 入力
- 読み手: [ここに記入]
- 伝えたい状況: [ここに記入]
- 決まっていること: [ここに記入]
- 未決事項: [ここに記入]
- 依頼したい判断: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 相手に必要な判断を先に置き、詳細は補足として整理してください。

## 出力形式
1. 要約
2. 読み手別メッセージ
3. リスク
4. 意思決定依頼
5. 次のアクション

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

ユーザーリサーチリポジトリ設計プロンプト

用途: ユーザーリサーチの実務で「ユーザーリサーチリポジトリ設計」を短時間で作る

主な出力: 調査目的、対象者、質問、分析観点、次の検証アクション

# ユーザーリサーチリポジトリ設計プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ユーザーリサーチの実務で使える「ユーザーリサーチリポジトリ設計」を日本語で作成してください。

用途: ユーザーリサーチの実務で「ユーザーリサーチリポジトリ設計」を短時間で作る

## 入力
- 調査目的: [ここに記入]
- 対象ユーザー: [ここに記入]
- 既存仮説: [ここに記入]
- 利用できる発言・ログ: [ここに記入]
- 意思決定期限: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- ユーザーの要望をそのまま解決策にせず、背景・行動・制約を分けてください。

## 出力形式
1. 調査設計
2. 質問または分析観点
3. 避けるべきバイアス
4. 示唆の整理表
5. 次に検証する仮説

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

PLGメトリクス設計プロンプト

用途: 指標分析の実務で「PLGメトリクス設計」を短時間で作る

主な出力: 主要指標、分析軸、SQL/イベント案、解釈、意思決定への接続

# PLGメトリクス設計プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、指標分析の実務で使える「PLGメトリクス設計」を日本語で作成してください。

用途: 指標分析の実務で「PLGメトリクス設計」を短時間で作る

## 入力
- 意思決定したいこと: [ここに記入]
- 対象ユーザー・segment: [ここに記入]
- 指標定義: [ここに記入]
- 利用できるdata・event: [ここに記入]
- 更新頻度・owner: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 見栄えのよい指標を増やさず、意思決定と定義が紐づく最小セットにしてください。

## 出力形式
1. 意思決定と主要指標
2. 指標定義・分母分子
3. segment・比較軸
4. 計測・data-quality要件
5. dashboard運用・見直し条件

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

PMキャリア開発フレームワークプロンプト

用途: ステークホルダーコミュニケーションの実務で「PMキャリア開発フレームワーク」を短時間で作る

主な出力: 読み手別メッセージ、合意形成、リスク共有、次アクション

# PMキャリア開発フレームワークプロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ステークホルダーコミュニケーションの実務で使える「PMキャリア開発フレームワーク」を日本語で作成してください。

用途: ステークホルダーコミュニケーションの実務で「PMキャリア開発フレームワーク」を短時間で作る

## 入力
- 現在role・level: [ここに記入]
- 目標role・期間: [ここに記入]
- 期待competency: [ここに記入]
- 現在のEvidence: [ここに記入]
- 制約・機会: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 抽象的な自己啓発にせず、実務Evidenceが残る行動と観測可能な成長signalへ落としてください。

## 出力形式
1. 現状と目標gap
2. competency別Evidence
3. 90日action
4. stretch assignment / learning
5. check-in指標と見直し条件

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

プロダクトローンチマーケティング計画プロンプト

用途: プロダクト戦略の実務で「プロダクトローンチマーケティング計画」を短時間で作る

主な出力: 戦略仮説、選択肢、判断基準、リスク、次の意思決定

# プロダクトローンチマーケティング計画プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、プロダクト戦略の実務で使える「プロダクトローンチマーケティング計画」を日本語で作成してください。

用途: プロダクト戦略の実務で「プロダクトローンチマーケティング計画」を短時間で作る

## 入力
- 対象ユーザー・読み手: [ここに記入]
- 変更内容: [ここに記入]
- ユーザー価値: [ここに記入]
- 既知の制約・risk: [ここに記入]
- 公開範囲・日時・support情報: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 機能一覧の羅列ではなく、読み手ごとに「何が変わり、何をすべきか」を先に示してください。

## 出力形式
1. 対象別メッセージ
2. 何が変わるか・価値
3. 利用方法・移行
4. risk・既知の制約
5. CTA・問い合わせ・次アクション

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

AIプロダクト倫理フレームワークプロンプト

用途: プロダクト戦略の実務で「AIプロダクト倫理フレームワーク」を短時間で作る

主な出力: 戦略仮説、選択肢、判断基準、リスク、次の意思決定

# AIプロダクト倫理フレームワークプロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、プロダクト戦略の実務で使える「AIプロダクト倫理フレームワーク」を日本語で作成してください。

用途: プロダクト戦略の実務で「AIプロダクト倫理フレームワーク」を短時間で作る

## 入力
- プロダクト名: [ここに記入]
- 対象市場: [ここに記入]
- 事業目標: [ここに記入]
- 競合・代替手段: [ここに記入]
- 制約条件: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 抽象論で終えず、捨てる選択肢と検証すべき前提を明示してください。

## 出力形式
1. 戦略仮説
2. 選択肢比較
3. 判断基準
4. リスク
5. 次の意思決定

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

プロダクトサポートプレイブックプロンプト

用途: ステークホルダーコミュニケーションの実務で「プロダクトサポートプレイブック」を短時間で作る

主な出力: 読み手別メッセージ、合意形成、リスク共有、次アクション

# プロダクトサポートプレイブックプロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ステークホルダーコミュニケーションの実務で使える「プロダクトサポートプレイブック」を日本語で作成してください。

用途: ステークホルダーコミュニケーションの実務で「プロダクトサポートプレイブック」を短時間で作る

## 入力
- 読み手: [ここに記入]
- 伝えたい状況: [ここに記入]
- 決まっていること: [ここに記入]
- 未決事項: [ここに記入]
- 依頼したい判断: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 相手に必要な判断を先に置き、詳細は補足として整理してください。

## 出力形式
1. 要約
2. 読み手別メッセージ
3. リスク
4. 意思決定依頼
5. 次のアクション

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

プロダクトコンテンツ戦略プロンプト

用途: 機能開発の実務で「プロダクトコンテンツ戦略」を短時間で作る

主な出力: 要件、優先順位、受け入れ条件、実装・検証観点

# プロダクトコンテンツ戦略プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、機能開発の実務で使える「プロダクトコンテンツ戦略」を日本語で作成してください。

用途: 機能開発の実務で「プロダクトコンテンツ戦略」を短時間で作る

## 入力
- 対象市場・顧客: [ここに記入]
- 市場変化: [ここに記入]
- 顧客課題・代替手段: [ここに記入]
- 自社の強み・制約: [ここに記入]
- 事業目標: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 抽象的なスローガンだけで終えず、選択・非選択と、外れた場合に見直す前提を明示してください。

## 出力形式
1. 現状診断
2. 戦略・ビジョン仮説
3. 選択すること / 捨てること
4. 勝ち筋と前提
5. risk・検証・次の意思決定

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

Customer Success指標設計プロンプト

用途: 指標分析の実務で「Customer Success指標設計」を短時間で作る

主な出力: 主要指標、分析軸、SQL/イベント案、解釈、意思決定への接続

# Customer Success指標設計プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、指標分析の実務で使える「Customer Success指標設計」を日本語で作成してください。

用途: 指標分析の実務で「Customer Success指標設計」を短時間で作る

## 入力
- 事業model・契約単位: [ここに記入]
- customer lifecycle: [ここに記入]
- 利用・契約・support data: [ここに記入]
- renewal / expansion定義: [ここに記入]
- segment・観測期間: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- health scoreを万能な単一数値にせず、retention・expansion・adoption・support等の定義と観測粒度を明示してください。

## 出力形式
1. CS outcomeと主要指標
2. 指標定義・分母分子・grain
3. health signalと先行/遅行分類
4. segment・cohort比較
5. action threshold・owner・data-quality注意

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

PMオンボーディング計画プロンプト

用途: ステークホルダーコミュニケーションの実務で「PMオンボーディング計画」を短時間で作る

主な出力: 読み手別メッセージ、合意形成、リスク共有、次アクション

# PMオンボーディング計画プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、ステークホルダーコミュニケーションの実務で使える「PMオンボーディング計画」を日本語で作成してください。

用途: ステークホルダーコミュニケーションの実務で「PMオンボーディング計画」を短時間で作る

## 入力
- 対象segment・新規ユーザー: [ここに記入]
- 最初に達成してほしいJob: [ここに記入]
- 現行funnel・離脱data: [ここに記入]
- 定性feedback: [ここに記入]
- 変更可能な導線・制約: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 登録完了を成功と決めつけず、ユーザーが最初の価値を得た行動をactivation候補として検証してください。

## 出力形式
1. activation仮説
2. 現行journeyと離脱点
3. 改善案と優先順位
4. 計測event・success metric
5. 実験・段階公開・見直し条件

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

プロダクト導入成熟度モデルプロンプト

用途: プロダクト戦略の実務で「プロダクト導入成熟度モデル」を短時間で作る

主な出力: 戦略仮説、選択肢、判断基準、リスク、次の意思決定

# プロダクト導入成熟度モデルプロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、プロダクト戦略の実務で使える「プロダクト導入成熟度モデル」を日本語で作成してください。

用途: プロダクト戦略の実務で「プロダクト導入成熟度モデル」を短時間で作る

## 入力
- プロダクト名: [ここに記入]
- 対象市場: [ここに記入]
- 事業目標: [ここに記入]
- 競合・代替手段: [ここに記入]
- 制約条件: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 抽象論で終えず、捨てる選択肢と検証すべき前提を明示してください。

## 出力形式
1. 戦略仮説
2. 選択肢比較
3. 判断基準
4. リスク
5. 次の意思決定

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項

プロダクトビジョンキャンバス作成プロンプト

用途: プロダクト戦略の実務で「プロダクトビジョンキャンバス作成」を短時間で作る

主な出力: 戦略仮説、選択肢、判断基準、リスク、次の意思決定

# プロダクトビジョンキャンバス作成プロンプト

あなたは経験豊富なプロダクトマネージャーです。以下の入力をもとに、プロダクト戦略の実務で使える「プロダクトビジョンキャンバス作成」を日本語で作成してください。

用途: プロダクト戦略の実務で「プロダクトビジョンキャンバス作成」を短時間で作る

## 入力
- 対象市場・顧客: [ここに記入]
- 市場変化: [ここに記入]
- 顧客課題・代替手段: [ここに記入]
- 自社の強み・制約: [ここに記入]
- 事業目標: [ここに記入]

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 入力が不足していても推測で穴埋めせず、作れる範囲を作ったうえで不足を分離する
- 抽象的なスローガンだけで終えず、選択・非選択と、外れた場合に見直す前提を明示してください。

## 出力形式
1. 現状診断
2. 戦略・ビジョン仮説
3. 選択すること / 捨てること
4. 勝ち筋と前提
5. risk・検証・次の意思決定

## 最後に、あなた自身の回答としてこの3項目を必ず書いてください（これは入力欄ではありません）
- 重要な前提: 今回の回答で置いた前提
- 不足情報: 判断・完成度を上げるために不足している情報
- 次に人間が確認すべきこと: 採用・共有・実行前に確認する事項