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

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- ユーザーの要望をそのまま解決策にせず、背景・行動・制約を分けてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

PRD作成プロンプト

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

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

# PRD作成プロンプト

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 抽象論で終えず、捨てる選択肢と検証すべき前提を明示してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 抽象論で終えず、捨てる選択肢と検証すべき前提を明示してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 機能追加を前提にせず、削る案・段階公開・失敗時の扱いも含めてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- ユーザーの要望をそのまま解決策にせず、背景・行動・制約を分けてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 相関と因果を混同せず、データ不足と追加計測案を分けてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 相手に必要な判断を先に置き、詳細は補足として整理してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- ユーザーの要望をそのまま解決策にせず、背景・行動・制約を分けてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 抽象論で終えず、捨てる選択肢と検証すべき前提を明示してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 機能追加を前提にせず、削る案・段階公開・失敗時の扱いも含めてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 相関と因果を混同せず、データ不足と追加計測案を分けてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- ユーザーの要望をそのまま解決策にせず、背景・行動・制約を分けてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 相手に必要な判断を先に置き、詳細は補足として整理してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

戦略OKR作成プロンプト

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

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

# 戦略OKR作成プロンプト

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 抽象論で終えず、捨てる選択肢と検証すべき前提を明示してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- ユーザーの要望をそのまま解決策にせず、背景・行動・制約を分けてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 相手に必要な判断を先に置き、詳細は補足として整理してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 抽象論で終えず、捨てる選択肢と検証すべき前提を明示してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 抽象論で終えず、捨てる選択肢と検証すべき前提を明示してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 機能追加を前提にせず、削る案・段階公開・失敗時の扱いも含めてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 機能追加を前提にせず、削る案・段階公開・失敗時の扱いも含めてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 相関と因果を混同せず、データ不足と追加計測案を分けてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 抽象論で終えず、捨てる選択肢と検証すべき前提を明示してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

価格戦略設計プロンプト

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 抽象論で終えず、捨てる選択肢と検証すべき前提を明示してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 機能追加を前提にせず、削る案・段階公開・失敗時の扱いも含めてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 機能追加を前提にせず、削る案・段階公開・失敗時の扱いも含めてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- ユーザーの要望をそのまま解決策にせず、背景・行動・制約を分けてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

GTM戦略作成プロンプト

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

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

# GTM戦略作成プロンプト

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 抽象論で終えず、捨てる選択肢と検証すべき前提を明示してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 相関と因果を混同せず、データ不足と追加計測案を分けてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 相手に必要な判断を先に置き、詳細は補足として整理してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

PMF評価プロンプト

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

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

# PMF評価プロンプト

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- ユーザーの要望をそのまま解決策にせず、背景・行動・制約を分けてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 機能追加を前提にせず、削る案・段階公開・失敗時の扱いも含めてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 相手に必要な判断を先に置き、詳細は補足として整理してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- ユーザーの要望をそのまま解決策にせず、背景・行動・制約を分けてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 抽象論で終えず、捨てる選択肢と検証すべき前提を明示してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- ユーザーの要望をそのまま解決策にせず、背景・行動・制約を分けてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 相手に必要な判断を先に置き、詳細は補足として整理してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 機能追加を前提にせず、削る案・段階公開・失敗時の扱いも含めてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- ユーザーの要望をそのまま解決策にせず、背景・行動・制約を分けてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 相手に必要な判断を先に置き、詳細は補足として整理してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

Feature Flag導入戦略プロンプト

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 機能追加を前提にせず、削る案・段階公開・失敗時の扱いも含めてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 相関と因果を混同せず、データ不足と追加計測案を分けてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 機能追加を前提にせず、削る案・段階公開・失敗時の扱いも含めてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- ユーザーの要望をそのまま解決策にせず、背景・行動・制約を分けてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 相手に必要な判断を先に置き、詳細は補足として整理してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 機能追加を前提にせず、削る案・段階公開・失敗時の扱いも含めてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 抽象論で終えず、捨てる選択肢と検証すべき前提を明示してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- ユーザーの要望をそのまま解決策にせず、背景・行動・制約を分けてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 相手に必要な判断を先に置き、詳細は補足として整理してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 抽象論で終えず、捨てる選択肢と検証すべき前提を明示してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- ユーザーの要望をそのまま解決策にせず、背景・行動・制約を分けてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

Feature Canvas作成プロンプト

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

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

# Feature Canvas作成プロンプト

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 機能追加を前提にせず、削る案・段階公開・失敗時の扱いも含めてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 相関と因果を混同せず、データ不足と追加計測案を分けてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 相手に必要な判断を先に置き、詳細は補足として整理してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 抽象論で終えず、捨てる選択肢と検証すべき前提を明示してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 相手に必要な判断を先に置き、詳細は補足として整理してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 機能追加を前提にせず、削る案・段階公開・失敗時の扱いも含めてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- ユーザーの要望をそのまま解決策にせず、背景・行動・制約を分けてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

PLG戦略プロンプト

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

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

# PLG戦略プロンプト

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 抽象論で終えず、捨てる選択肢と検証すべき前提を明示してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 抽象論で終えず、捨てる選択肢と検証すべき前提を明示してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 相手に必要な判断を先に置き、詳細は補足として整理してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 機能追加を前提にせず、削る案・段階公開・失敗時の扱いも含めてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- ユーザーの要望をそのまま解決策にせず、背景・行動・制約を分けてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 抽象論で終えず、捨てる選択肢と検証すべき前提を明示してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 相手に必要な判断を先に置き、詳細は補足として整理してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 機能追加を前提にせず、削る案・段階公開・失敗時の扱いも含めてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- ユーザーの要望をそのまま解決策にせず、背景・行動・制約を分けてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 機能追加を前提にせず、削る案・段階公開・失敗時の扱いも含めてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 相関と因果を混同せず、データ不足と追加計測案を分けてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- ユーザーの要望をそのまま解決策にせず、背景・行動・制約を分けてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 相手に必要な判断を先に置き、詳細は補足として整理してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

機能廃止戦略プロンプト

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 機能追加を前提にせず、削る案・段階公開・失敗時の扱いも含めてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 相手に必要な判断を先に置き、詳細は補足として整理してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 相関と因果を混同せず、データ不足と追加計測案を分けてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 抽象論で終えず、捨てる選択肢と検証すべき前提を明示してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 相手に必要な判断を先に置き、詳細は補足として整理してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- ユーザーの要望をそのまま解決策にせず、背景・行動・制約を分けてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 相手に必要な判断を先に置き、詳細は補足として整理してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 抽象論で終えず、捨てる選択肢と検証すべき前提を明示してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 機能追加を前提にせず、削る案・段階公開・失敗時の扱いも含めてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 相手に必要な判断を先に置き、詳細は補足として整理してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 相関と因果を混同せず、データ不足と追加計測案を分けてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 相関と因果を混同せず、データ不足と追加計測案を分けてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

プロダクトサイト改善戦略プロンプト

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

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

# プロダクトサイト改善戦略プロンプト

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 抽象論で終えず、捨てる選択肢と検証すべき前提を明示してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

部門横断協働憲章プロンプト

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

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

# 部門横断協働憲章プロンプト

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 相手に必要な判断を先に置き、詳細は補足として整理してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

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

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

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

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

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- ユーザーの要望をそのまま解決策にせず、背景・行動・制約を分けてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

機能検証実験計画プロンプト

用途: 機能開発の実務で「機能検証実験計画」を短時間で作る

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

# 機能検証実験計画プロンプト

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 機能追加を前提にせず、削る案・段階公開・失敗時の扱いも含めてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

プロダクトデモ台本作成プロンプト

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

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

# プロダクトデモ台本作成プロンプト

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 相手に必要な判断を先に置き、詳細は補足として整理してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

ユーザーリサーチリポジトリ設計プロンプト

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

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

# ユーザーリサーチリポジトリ設計プロンプト

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- ユーザーの要望をそのまま解決策にせず、背景・行動・制約を分けてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

PLGメトリクス設計プロンプト

用途: 指標分析の実務で「PLGメトリクス設計」を短時間で作る

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

# PLGメトリクス設計プロンプト

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 相関と因果を混同せず、データ不足と追加計測案を分けてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

PMキャリア開発フレームワークプロンプト

用途: ステークホルダーコミュニケーションの実務で「PMキャリア開発フレームワーク」を短時間で作る

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

# PMキャリア開発フレームワークプロンプト

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 相手に必要な判断を先に置き、詳細は補足として整理してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

プロダクトローンチマーケティング計画プロンプト

用途: プロダクト戦略の実務で「プロダクトローンチマーケティング計画」を短時間で作る

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

# プロダクトローンチマーケティング計画プロンプト

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 抽象論で終えず、捨てる選択肢と検証すべき前提を明示してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

AIプロダクト倫理フレームワークプロンプト

用途: プロダクト戦略の実務で「AIプロダクト倫理フレームワーク」を短時間で作る

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

# AIプロダクト倫理フレームワークプロンプト

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 抽象論で終えず、捨てる選択肢と検証すべき前提を明示してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

プロダクトサポートプレイブックプロンプト

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

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

# プロダクトサポートプレイブックプロンプト

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 相手に必要な判断を先に置き、詳細は補足として整理してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

プロダクトコンテンツ戦略プロンプト

用途: 機能開発の実務で「プロダクトコンテンツ戦略」を短時間で作る

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

# プロダクトコンテンツ戦略プロンプト

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 機能追加を前提にせず、削る案・段階公開・失敗時の扱いも含めてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

Customer Success指標設計プロンプト

用途: 指標分析の実務で「Customer Success指標設計」を短時間で作る

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

# Customer Success指標設計プロンプト

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 相関と因果を混同せず、データ不足と追加計測案を分けてください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

PMオンボーディング計画プロンプト

用途: ステークホルダーコミュニケーションの実務で「PMオンボーディング計画」を短時間で作る

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

# PMオンボーディング計画プロンプト

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 相手に必要な判断を先に置き、詳細は補足として整理してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

プロダクト導入成熟度モデルプロンプト

用途: プロダクト戦略の実務で「プロダクト導入成熟度モデル」を短時間で作る

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

# プロダクト導入成熟度モデルプロンプト

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 抽象論で終えず、捨てる選択肢と検証すべき前提を明示してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと:

プロダクトビジョンキャンバス作成プロンプト

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

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

# プロダクトビジョンキャンバス作成プロンプト

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

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

## 作業ルール
- 事実、推測、不足情報を分ける
- 結論だけでなく、判断理由と前提を明示する
- 実務でそのまま使える粒度にする
- 不明点がある場合は、最後に確認質問を最大5つ出す
- 抽象論で終えず、捨てる選択肢と検証すべき前提を明示してください。

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

## 最後に必ず入れること
- 重要な前提:
- 不足情報:
- 次に人間が確認すべきこと: