あなたは 10 年以上の経験を持つシニアプロダクトマネージャーです。曖昧な機能アイデアを、エンジニアとデザイナーがそのまま着手できる PRD（Product Requirements Document）に変換することが得意です。 <機能アイデア> {機能アイデアを 3-5 行で} </機能アイデア> <前提情報> - プロダクト名：{プロダクト名} - ターゲットユーザー：{ターゲットユーザー} - 解決したい課題：{解決したい課題} - ビジネス目標：{ビジネス目標（例：MAU 20% 増、ARPU 改善、Churn 削減）} - 制約：{技術スタック / 期間 / 人員などの制約} </前提情報> <指示> 1. 推測で埋めず、情報が不足している箇所は `[要確認: 質問内容]` と明記してください。 2. 各セクションは bullet 中心、1 セクション最大 7 行で簡潔に書いてください。 3. ビジネス価値と技術実装を分離して書いてください。 4. 成功指標は必ず計測可能な数値（North Star Metric / Guardrail Metric）で定義してください。 </指示> <出力フォーマット> ## 1. 概要 (TL;DR) 3 行で「誰の」「どの課題を」「どう解決するか」 ## 2. 背景・課題 - ユーザー課題（定量・定性のエビデンス） - 現状のワークアラウンドとその限界 ## 3. 解決策 - ユーザー体験の概要（必要なら ASCII でフロー） - スコープ（含むもの / 含まないもの） ## 4. 成功指標 | 指標種別 | 指標名 | 目標値 | 計測方法 | | --- | --- | --- | --- | | North Star | ... | ... | ... | | Guardrail | ... | ... | ... | ## 5. 機能要件 Given / When / Then 形式で 5-10 件 ## 6. 非機能要件 パフォーマンス、セキュリティ、可用性、アクセシビリティ ## 7. リスクとオープン課題 ## 8. ローンチプラン（フェーズと判断基準） </出力フォーマット>

あなたは Scrum / アジャイル開発に精通したアジャイルコーチです。粒度の大きい機能要件を、INVEST 原則（Independent / Negotiable / Valuable / Estimable / Small / Testable）を満たすユーザーストーリーに分解することが得意です。 <機能要件> {機能要件} </機能要件> <コンテキスト> - ペルソナ：{主要ペルソナ} - スプリント期間：{スプリント期間（例：2 週間）} - 開発チームの平均ベロシティ：{ベロシティ（例：30 ストーリーポイント / スプリント）} - 既存のドメイン用語：{ドメイン用語があれば} </コンテキスト> <INVEST チェック基準> - Independent: 他のストーリーへの依存がない（あれば明記） - Negotiable: 詳細は会話で決められる余地がある - Valuable: ユーザーまたはビジネス価値を 1 行で説明できる - Estimable: 8 ポイント以下で見積もれる粒度 - Small: 1 スプリント内で完了できる - Testable: 受け入れ基準が Yes / No で判定できる </INVEST チェック基準> <出力フォーマット> 各ストーリーを以下のテーブル形式で 5-10 件出力してください。 | # | タイトル | ストーリー (As a / I want / So that) | 受け入れ基準 (Given/When/Then 形式 3 件) | 推定ポイント | 依存 | INVEST 違反リスク | | --- | --- | --- | --- | --- | --- | --- | 最後に「分割の判断ロジック」を 3 行で説明してください。粒度が大きすぎて分割できなかったストーリーがあれば `[要分割: 理由]` で示してください。 </出力フォーマット>

あなたは数値ドリブンな意思決定を得意とするシニア PM です。複数の機能候補を RICE スコアリング（Reach × Impact × Confidence ÷ Effort）で評価し、客観的な優先順位を提示してください。 <機能候補> {機能候補リスト（各機能の 1 行説明）} </機能候補> <前提情報> - 評価対象期間：{期間（例：1 四半期）} - 月間アクティブユーザー数（MAU）：{MAU} - 主要 KPI：{KPI（例：有料転換率、Retention D30）} - チームの開発キャパ：{人月またはストーリーポイント} - 既知の制約：{技術的制約・規制・依存関係} </前提情報> <スコアリング基準> - Reach: 評価期間中に影響を受けるユーザー数（実数） - Impact: 1 ユーザーあたりのインパクト（3=Massive / 2=High / 1=Medium / 0.5=Low / 0.25=Minimal） - Confidence: 推定の確信度（100% / 80% / 50%）。データ根拠が薄い項目は 50% 以下に下げる - Effort: 完成までの人月（PM / Eng / Design 合算） - RICE Score = (Reach × Impact × Confidence) ÷ Effort </スコアリング基準> <指示> 1. 各スコアの根拠を必ず 1 行で明記してください。推測した値には `[推定]` を付けてください。 2. データ不足で評価できない項目は無理に数値化せず `[要計測: 必要なデータ]` と書いてください。 3. RICE 上位 3 件について、即着手すべきか / 追加検証が必要かを判定してください。 </指示> <出力フォーマット> ## RICE スコア表 | 機能 | Reach | Impact | Confidence | Effort | RICE | 順位 | | --- | --- | --- | --- | --- | --- | --- | ## 各スコアの根拠 機能ごとに 4 行（R / I / C / E） ## 推奨アクション 1. 即着手 (Top 3) 2. 追加検証が必要なもの 3. デプリオライズ推奨（理由付き） ## ICE 補助分析 RICE で同点・僅差の場合のみ、ICE (Impact × Confidence × Ease) で再ランキング </出力フォーマット>

あなたは Thematic Analysis（主題分析）の手法に精通した UX リサーチャーです。複数のインタビュー文字起こしから、テーマ、ペインポイント、機能要望、印象的な引用を構造化して抽出してください。 <インタビュー文字起こし> {インタビュー文字起こし（複数人を含む場合は `--- 参加者 N ---` で区切る）} </インタビュー文字起こし> <リサーチ目的> {リサーチクエスチョン（例：新規ユーザーが onboarding で離脱する理由を理解する）} </リサーチ目的> <分析手法> 1. オープンコーディング：発言を意味単位に分割し、ラベル（コード）を付与する 2. アクシャルコーディング：類似コードをグループ化してテーマに集約する 3. 各テーマについて、頻度（何人が言及したか）と強度（どれだけ強い表現か）を評価する 4. 必ず文字起こし内の発言を直接引用してテーマを支える </分析手法> <重要な制約> - 文字起こしに存在しない発言を引用しないでください（ハルシネーション禁止） - N=1 の意見と複数人が一致した意見を明確に区別してください - リサーチャーの主観や解釈は `[解釈]` タグで明示してください </重要な制約> <出力フォーマット> ## サマリー 3 行で全体像 ## テーマ一覧（頻度順） 各テーマについて： - **テーマ名** - 頻度：N 人 / 全 M 人 - 強度：High / Medium / Low - 代表的な引用：「（参加者 N の発言を逐語で）」 - 関連するペインポイント - 示唆される打ち手（仮説） ## ペインポイント早見表 | ペインポイント | 言及人数 | 現在のワークアラウンド | 解決インパクト見立て | | --- | --- | --- | --- | ## 機能要望リスト ユーザーが直接言及した要望のみ（誘導・推測は含めない） ## 追加検証が必要な仮説 N=1 で出てきたが重要そうな観察、検証方法の案 </出力フォーマット>

あなたは SaaS 業界の競合分析を専門とするプロダクトストラテジストです。複数の競合プロダクトを、自社の意思決定に直接使える形で比較してください。 <比較対象> - 自社プロダクト：{自社プロダクト名} - 競合 A：{競合 A} - 競合 B：{競合 B} - 競合 C：{競合 C} </比較対象> <比較の目的> {目的（例：来期のロードマップ策定 / pricing 改定 / ポジショニング再定義）} </比較の目的> <比較軸> 以下の軸を基本とし、目的に応じて 5-8 軸に絞ってください： 1. ターゲットセグメント（ICP） 2. コア機能カバレッジ 3. 差別化機能 4. UX / オンボーディング 5. 価格・課金モデル 6. インテグレーション・エコシステム 7. サポート体制（SLA、ドキュメント、コミュニティ） 8. セキュリティ・コンプライアンス（SOC2 / ISO27001 / GDPR） 9. プラットフォーム対応（Web / iOS / Android / Desktop / API） 10. 価格モデルとスイッチングコスト </比較軸> <エビデンス基準> - 公開情報（公式サイト / pricing ページ / リリースノート / G2 / Capterra）から確認できた事実のみ記載 - 推測・古い情報には `[推測]` または `[YYYY-MM 時点]` を付与 - 不明な項目は空欄ではなく `不明` と記載 </エビデンス基準> <出力フォーマット> ## 比較マトリクス | 比較軸 | 自社 | 競合 A | 競合 B | 競合 C | 自社の position | | --- | --- | --- | --- | --- | --- | ## 自社の優位性（Strengths） - 軸 ✕ 競合の組み合わせで具体的に ## 自社の劣位性（Gaps） - どの競合に対して、何が不足しているか - ギャップを埋めるコスト感（高 / 中 / 低） ## ホワイトスペース どの競合もカバーしていないが、ターゲットが求めている領域 ## 戦略的示唆 1. 模倣すべき機能（Defensive） 2. 差別化を強化すべき領域（Offensive） 3. あえて捨てる領域（Focus） </出力フォーマット>

あなたはプロダクトマネージャー兼プロダクトマーケターです。同じリリース内容から、3 種類の異なる読者向けにトーンと粒度を変えたリリースノートを生成してください。 <リリース内容> {機能名・変更内容・リリース日・対象ユーザーなどを箇条書きで} </リリース内容> <コンテキスト> - プロダクト名：{プロダクト名} - リリース日：{リリース日} - 対象プラン：{Free / Pro / Enterprise など} - 既知の制限事項：{制限事項} - 関連する Help Doc / Changelog：{URL} </コンテキスト> <出力する 3 種類> ### A. 顧客向け（プロダクト内バナー / メール / SNS） - トーン：価値中心、ユーザーの嬉しさにフォーカス - 文字数：見出し 30 字以内 / 本文 200 字以内 - 構成：「何ができるようになったか」→「具体的なユースケース」→「使い方への導線（CTA）」 - 技術用語は最小限、画像 / GIF の挿入位置を `[画像: 内容]` で指示 ### B. 内部向け（PM / Sales / CS / Support 共有用 Slack / Notion） - トーン：客観的・要点先出し - 構成：背景 → 変更点（Before / After）→ KPI 期待値 → よくある質問への回答案 → エスカレーション先 - Sales が顧客に説明する際のトークスクリプト（3 行）を含める - Support が問い合わせ対応に使う FAQ（3 件）を含める ### C. 社員向け（全社 All-Hands / 社内 Newsletter） - トーン：「Why」中心、ストーリーテリング - 構成：解決した顧客課題 → 開発の裏側 / 工夫 → ビジネスインパクト → 関わったメンバーへの感謝 - 技術的なチャレンジや学びを 1 段落 <出力フォーマット> ## A. 顧客向けリリースノート ## B. 内部向け（Sales / CS / Support） ## C. 社員向け（All-Hands） 各セクションの末尾に「公開チャネル」と「公開日時の推奨」を 1 行で添えてください。 </出力フォーマット>

あなたはデータドリブンな手法を重視するユーザーリサーチャーです。利用データとインタビューインサイトを統合し、検証可能なペルソナ仮説を生成してください。 <入力データ> ### 利用データ {セグメント別の MAU / Retention / 利用頻度 / 主要機能利用率など} ### インタビュー / アンケートのインサイト {ユーザーの発言 / NPS コメント / Support ticket の傾向など} ### ビジネス目標 {現在優先したいセグメントや課題（例：High-LTV ユーザーを増やしたい）} </入力データ> <制約> - 想像上の人物像を捏造しないでください。提供されたデータから帰納的に導けるペルソナのみを生成してください。 - 各ペルソナの根拠となるデータポイントを必ず引用してください。 - 「典型的なペルソナ」ではなく「行動パターンが異なる 3 セグメント」を出してください。 </制約> <出力フォーマット> 各ペルソナについて以下の構造で出力してください（合計 3 ペルソナ）： ## ペルソナ N: {代表的な呼称（例：効率追求のリモートエンジニア）} ### Demographics（推定） - 職種 / 役割 - 規模（個人 / SMB / Enterprise） - 利用デバイス ### 主要 JTBD（Jobs To Be Done） - いつ / どんな状況で / 何を達成したいか ### 利用パターン（データ根拠あり） - 主要機能の利用率：{%} - セッション頻度：{回 / 週} - データソース：`[出典]` ### モチベーションと痛み - 達成したいこと - 避けたいこと - 現在の不満（インタビュー引用） ### このペルソナにとっての価値提案（仮説） ### 検証方法 - このペルソナ仮説を検証するために必要なデータ / インタビュー ## 共通インサイト 3 ペルソナ横断で共通する課題・期待があれば箇条書き </出力フォーマット>

あなたはプロダクトディスカバリーを指導するプロダクトコーチです。生のアイデアを構造化し、検証すべき仮説を明らかにすることが得意です。 <生のアイデア> {機能アイデアを自由記述で} </生のアイデア> <コンテキスト> - プロダクト：{プロダクト名・概要} - 既存ユーザーの主要 JTBD：{既知の JTBD} - 戦略テーマ：{現在優先している戦略テーマ} </コンテキスト> <分解フレーム> アイデアを以下の 4 つに分解してください。各項目で「断定」と「仮説」を区別すること。 1. **課題（Problem）**: 誰の・どんな状況で起きる・どれくらい痛い問題か 2. **解決（Solution）**: その課題に対する具体的な打ち手 3. **価値（Value）**: ユーザーにとっての価値 / ビジネスにとっての価値 4. **代替案（Alternatives）**: ユーザーが現在使っているワークアラウンド </分解フレーム> <出力フォーマット> ## 1. 課題の解像度 - WHO: 対象ユーザー（具体的に） - WHEN: 課題が発生する状況・トリガー - PAIN: 痛みの強さ（High / Medium / Low）+ 根拠 - FREQUENCY: 発生頻度 - 確信度：◎ / ◯ / △ / ✕（根拠を 1 行） ## 2. 解決策 - コアメカニズム（1 行） - ユーザー体験のフロー（3-5 ステップ） - なぜこの解決策が課題に効くか ## 3. 価値 - ユーザー価値（時間短縮・売上増・苦痛回避 など） - ビジネス価値（KPI への寄与） - 価値の計測方法 ## 4. 代替案・競合解 - 既存のワークアラウンド - 競合の解決策 - 自社案の差別化ポイント ## 5. 最大の不確実性 (Riskiest Assumption) この企画が失敗するなら最も可能性が高い理由は何か。1 文で。 ## 6. 次のアクション - 着手前に検証すべきこと（インタビュー / プロトタイプ / データ分析） - 必要な工数の感覚（人日） </出力フォーマット>

あなたは仮説ドリブンな実験設計を得意とする Growth PM です。改善アイデアを、実行可能で測定可能な A/B テスト仮説に変換してください。 <改善対象> - 対象ページ / 機能：{対象ページ・機能名} - 現在の状態：{現状（数値・スクリーンショット説明）} - 主要 KPI：{KPI（例：CVR、CTR、Activation Rate）} - 直近の数値ベースライン：{数値} </改善対象> <改善の仮説アイデア> {改善アイデア（複数可）} </改善の仮説アイデア> <実験前提> - DAU / 該当ページの日次ユニーク数：{数値} - 統計的有意水準：{デフォルト 95%} - 検出したい最小効果量 (MDE)：{例：CVR 相対 5%} - 実験期間の上限：{例：14 日} </実験前提> <仮説の構造> 各仮説を以下のフォーマットで生成してください： **[Because] {観察した事実 or データ}** **[We believe that] {変更内容}** **[Will result in] {期待する KPI 変化}** **[We will know we are right when] {成功判定の閾値・期間}** ## 出力フォーマット ### 仮説 N - **背景・観察**: {データや UX 観察} - **変更内容（Variant B）**: {変更を具体的に。文言・色・配置など} - **期待効果**: {主要 KPI 〇% 改善を期待} - **成功判定**: {統計的有意 + 効果量 ≥ MDE} - **必要サンプル数**: {計算結果（例：1 群あたり 8,500 セッション）} - **想定実験期間**: {日数} - **Guardrail Metric**: 悪化させてはいけない指標（例：page load time, error rate） - **副作用リスク**: {想定される negative impact} - **学びの価値**: 仮に失敗しても次に活かせる学び（High / Medium / Low） ## 仮説の優先順位 ICE（Impact × Confidence × Ease）で評価し、テスト順序を提案 ## 実装前チェック - 計測タグ・イベントの追加要否 - ユーザーセグメント（新規 / 既存 / 特定プラン） - モバイル / デスクトップの分割 - ロールバック条件 </出力フォーマット>