pm-discovery

プロダクトディスカバリーのスキル

このスキルの動作 (最初にお読みください)

これは生成的なスキルであり、「ディスカバリーをやる」という言葉にはいくつかのデフォルトの罠が潜んでいます。本能的な動きとは、ディスカバリーを構築前の一度きりの調査フェーズとして扱う (そして二度と見直さない)、すぐにソリューションや機能へ飛びつく、何が実際に賭かっているかに見合った厳密さもなく一般的な「数人のユーザーにインタビュー + アンケート送信」という計画を実行する、何が変わったかではなく何を出荷したかで成功を測る、そしてユーザーに「これを使いますか?」と尋ねる (誰もがはいと言う) ことです。その結果は、忙しいけれど学びのない機能工場です。優れたディスカバリーは継続的で、問題優先で、アウトカム志向で、リスクに見合ったエビデンスに基づくものです。そこでこのスキルは次をゲートします:

1. どのリスクを低減しようとしているのか、そしてその意思決定にどれだけの確実性が必要かを明確にする — 価値、ユーザビリティ、実現可能性、事業実現可能性のリスク。安価で可逆的な判断は、高価で不可逆的な賭けよりもはるかに少ないエビデンスで済みます。
2. 常に真である中核を適用する — 継続的なケイデンス、アウトプットよりもアウトカム、ソリューションより問題を先に、仮説よりも過去の行動、リスクに見合ったエビデンス、検証済みの問題から生まれるソリューション、倫理的なリサーチ。
3. 文脈依存の意思決定を明らかにする (問題リサーチかソリューションリサーチか、定性か定量か、軽量か深掘りか、DIY か専門家か、コミット前にどれだけの確実性が必要か) とトレードオフを提示する。

その後、検証のために pm-assumption-rigor-audit、pm-okr-metric-validity-audit、pm-prioritization-rigor-audit へ引き継ぎます。特定の仮説に対する実際のテスト/実験設計は生成的な pm-assumption-testing スキルに属します — ディスカバリーは何を学び、それがどれほど重要かを決め、仮説テストはテストを設計します。

---

ステップ 0 — ディスカバリーを計画する前に文脈を確立する

不明な場合は尋ねてください。回答なしで進める場合は仮定を明示してください:

• 4つのリスクのうち、最も不確実なのはどれか? 価値 (誰かがそれを欲しがるか?)、ユーザビリティ (彼らはそれを使えるか?)、実現可能性 (我々はそれを構築できるか?)、事業実現可能性 (それは事業に適合するか?)。ディスカバリーは最も高いリスクを解消するために存在します — 活動を選ぶ前にそれを名指ししてください。
• あなたは問題空間にいますか、ソリューション空間にいますか? 「誰かがこの問題を気にかけているか?」は、「このソリューションは機能するか?」とは異なる問いであり、異なる手法を要します。問題が検証される前にソリューションのディスカバリーへ飛ばないでください。
• これが情報を与える意思決定はどれほど可逆的で、どれほど高価か? これが購入すべき確実性の量を決めます。一方通行の扉のような可逆的な微調整を過剰に調査するのは四半期の無駄であり、不可逆的で高価な賭けを過少に調査するのは、チームが間違ったものを出荷する原因です。
• 誰が関与し、どのようなケイデンスで進めるか? プロダクトトリオ (PM + デザイナー + エンジニア) とクロスファンクショナルなパートナー。これは継続的な習慣か、単発の調査か? デフォルトでは継続を志向してください。

---

常に適用されるコア（あらゆるディスカバリー活動に当てはまる真理）

• ディスカバリーを一過性のフェーズではなく、継続的なものにしましょう。 最初に一度だけ行うリサーチは、数か月で陳腐化します。軽量な顧客接点を週次のリズムに組み込みましょう — 短時間のインタビュー、サポートチケットのレビュー、サイレントオブザーバーとしての商談同席など — そしてスプリントプランニングと同様に、それを譲れないものとして扱いましょう。採用活動を自動化し（常設の予約リンク、プロダクト内でのインターセプトなど）、忙しい週でもそれが途絶えないようにしましょう。断続的なディスカバリーが生むインサイトは期限切れになりますが、継続的なディスカバリーは複利で効いてきます。
• アウトプットではなくアウトカムに目を向けましょう。 目指すユーザー行動の変化（プロダクトアウトカム、あなたが働きかけられる先行指標）を定義し、それがビジネスアウトカム（売上・継続率、遅行指標）につながるようにしましょう。「ヘルプセンターを立ち上げる」はアウトプットであり、「サポートチケットを15%削減する」はアウトカムです。虚栄の指標のテスト：「幸せで成功しているユーザーが、この行動を決して取らないことはあり得ますか？」 もし答えが「はい」なら、それは虚栄の指標です。これがビルドトラップに対する防御策です。
• 問題空間から始め、問題と症状を切り分けましょう。 機能リクエストや不満（「ユーザーがカートを放棄する」）は症状であり、根本的な問題（チェックアウトが分かりにくい？送料が後から高くなる？支払いへの不信？）こそが、あなたが設計で立ち向かう対象です。解決する前に、その問題が現実に存在し重要であることを検証しましょう。
• 仮説上の意向ではなく、過去の行動について尋ねましょう（マムテスト）。 「これを使いますか？」は礼儀としての「はい」を引き出します — これは誤検知です。「この件に前回対応したときのことを詳しく話してください」は検証可能な情報を引き出します。あなたのアイデアではなく、相手の生活について尋ねましょう。未来の仮説ではなく、過去の具体的な事実を。相手が提案する解決策ではなく、問題に耳を傾けましょう。相手が話し終えたら静かにしていましょう — その沈黙が本当のインサイトを浮かび上がらせます。
• 証拠を意思決定のリスクに合わせ、シグナルとノイズを見分けましょう。 「真実の曲線」：軽量な手法（アンケート、インタビュー、ペーパープロトタイプ）は安価ですが、あなたの判断を通してフィルタリングされます。実際の行動が最も強い真実です。この意思決定にとって十分な確実性を与える手法を選びましょう。リクエストは緊急性ではなくパターンでフィルタリングし（サポート＋営業＋インタビューをまたいで繰り返し現れるテーマは、最も声の大きい単一の顧客に勝ります）、ブロッカーか、あれば嬉しい程度かで見分けましょう。**定量的なもの（何が起きているか）と定性的なもの（なぜか）**をクロスチェックしましょう — 一致していればゴーサイン、矛盾していればコミットする前に別のテストを実行しましょう。
• 検証済みの問題から解決策を生み出しましょう — 複数案を出してから比較します。 問題が検証されたら、いくつかの異なる解決策の方向性を探り、望ましさ × 実現可能性 × 事業性で比較しましょう。それぞれがユーザーインサイトにひも付き、結論ありきではなく検証すべき仮説として枠組み化されているべきです。リクエストから直接ひとつの機能へ飛びつくのは、問題解決ではなく注文受けであり、機能の肥大化を招きます。
• 倫理的かつ包摂的にリサーチしましょう。 真のインフォームドコンセントを得ましょう（平易な言葉、いつでも撤回可能、細かな録音の選択肢、力関係への配慮）。都合のよいエコーチェンバーの外からも参加者を募りましょう（既存のパワーユーザーは問題の枠組みを偏らせます）。問題の枠組みにおけるバイアスに注意しましょう（「ユーザーはより速いチェックアウトを必要としている」は、すでにユーザーが誰であるかを前提としています）。文化的な配慮と、脆弱な集団に対する追加の保護措置を適用し、競合分析は誠実で公開された情報源にとどめましょう。
• ステークホルダーと継続的に足並みをそろえましょう — サプライズは禁物です。 ステークホルダーへの引き継ぎは、お披露目ではなく協働のチェックポイントとして扱いましょう。早い段階でリサーチセッションに彼らを参加させ、解決策の前に問題について合意し、トレードオフ（インパクト対工数）を見える化し、スライドを読ませるのではなく実際のユーザーが苦労する様子を彼らに見せましょう。証拠を目にしたステークホルダーは、ブロッカーではなく推進者になります。

---

状況依存の判断 (表面化させ、自動適用しない)

それぞれをトレードオフと Step 0 に結びついた推奨事項とともに提示し、ユーザーに選ばせます。あらゆる質問に対してすべての手法を最大深度で実行することが失敗パターンです — その判断に必要な確実性だけを購入し、それ以上は求めません。

判断	適用する場面	避ける / 適応させる場面	デフォルトの推奨事項
問題の調査 vs. ソリューションのテスト	「誰かが気にかけるのか?」がまだ未解決のときの問題空間の手法 (インタビュー、観察、サポートログ)	根本的な問題が検証される前にソリューションの使いやすさをテストすること	まず問題を検証する。それが現実のものになって初めてソリューションテストへ移行する
定性的 vs. 定量的	なぜと初期シグナルには定性 (インタビュー、自由回答)。何と規模には定量 (アナリティクス、大規模サンプル、行動)	どちらか一方だけに頼ること — 純粋な定量はなぜを見逃し、純粋な定性は最も声の大きい意見を追いかける	両方をクロスチェックする。両者が矛盾するときは、決定する前に別のテストを実行する
継続的な軽量 vs. 定期的な深掘り調査	継続的なシグナルのための毎週のタッチポイント。大きな、あるいは不慣れな賭けのためのより深い専用調査	一度きりの調査を継続的な接触の代わりにすること、あるいは小さく可逆的な判断を過剰に調査すること	継続的なベースラインのケイデンス + 高リスクの判断のための的を絞った深掘り
DIY (PM/トリオ主導) vs. 専任リサーチャー	スピードとユーザーへの近さのための PM 主導の軽量リサーチ	専門家の厳密さを必要とする複雑、高リスク、規制対象、あるいは脆弱な集団の調査	習慣を自分で築く。厳密さが判断に不可欠なところには専門家を招く
コミットする前にどれだけの確実性が必要か	証拠を判断のリスクと可逆性に合わせて調整する (トゥルースカーブ)	可逆的な微調整を過剰に調査すること、不可逆的で高コストな賭けを過少に調査すること	その判断に必要な確実性だけを購入する。特定の前提のテストは pm-assumption-testing に渡す
誰の声を重み付けするか	複数の情報源にまたがるパターン。代表的かつ包摂的なリクルーティング。あったらいいものよりブロッカー	量や緊急性、あるいは最も声の大きい単一のクライアントによる重み付け。都合のよいエコーチェンバーのサンプル	ノイズではなく、パターンと代表性によって重み付けする

---

結果を検証する（オーケストレーション）

ハンドオフでは、各レンズをインストール可能なスキルの name で指定します。呼び出すのは、そのスキルがインストールされている場合のみです。インストールされていない場合、このスキル自体の中核がすでにこれらのルールを備えているため、ブロックせずにそのまま進めてください。

成果物を作成または改訂した後は、完了と宣言するのではなく、監査レンズに引き渡してください。これらは候補のレンズです — 姿勢は docs/orchestration-policy.md に従うか、成果物全体を pm-product-review にルーティングしてください。ここでは assumption-rigor が常に関連するレンズ（自動実行） であり、その他は成果物に実際に含まれる内容に応じて提示されます。ユーザーが特定の目的でこのスキルを呼び出した場合は、その範囲を尊重してください。

• pm-assumption-rigor-audit （自動実行） — 最もリスクの高い前提が、心地よい前提ではなく、表面化され明示されているか？ ディスカバリーの役割は leap-of-faith な信念を露呈させることです。これはそれらが誠実に狙われているかをチェックします。（それぞれを解消するテストの設計には、pm-assumption-testing スキルを使用してください。）
• pm-okr-metric-validity-audit （提示 — 成果や成功指標に言及している場合） — ディスカバリーが目指すプロダクト／ビジネスの成果と成功指標：それらは本物の成果（虚栄やアウトプットの数ではなく）であり、反証可能で、チームの影響範囲内にあるか？
• pm-prioritization-rigor-audit （提示 — 問題や機会をランク付けしている場合） — ディスカバリーがどの問題／機会に取り組む価値があるかをランク付けするとき：そのランキングは証拠に基づき戦略と結びついているか、それとも機能工場的なバックログや HiPPO による選択ではないか？
• pm-decision-quality-audit （提示 — 重要で元に戻しにくい build/no-build の決定に行き着く場合） — 結果よりもプロセス、可逆性に見合った熟慮、プレモーテム。

構成（docs/orchestration-policy.md §9 に準拠）： このスキルはディスカバリーの計画とその洞察を生み出します。テスト／実験の設計（pm-assumption-testing）はそのサブパートを担うピアです（委譲）。問題定義の作成（pm-problem-statement）、ペルソナ／JTBD（pm-personas-jtbd）、競合／市場分析（pm-competitive-analysis）、詳細な優先順位付けフレームワーク（pm-prioritization）、ロードマップ作成（pm-roadmap）、指標／OKR の定義（pm-okrs-kpis）は下流です（次に生成することを提示し、自動生成はしない）。監査が矛盾を表面化させた場合（例：安価な手法では実際にはハイステークスのリスクを解消できない）、目の前の決定に向けて解決してください：ディスカバリーは決定に資するものです — うまく決定するのにちょうど十分なだけ学び、そして決定する。 アイデアから計画までの完全な構築には、pm-idea-to-plan が構成上のフロントドアであり、仕様の前にこの段を実行します — それは、PRD を急ぐデフォルトが飛ばしてしまう証拠のステップです。

---

よくある do/don't パターン

❌ 避けるべき	✅ 行うべき
最初に一度だけディスカバリーを実行し、それから構築する	毎週継続する習慣にする。忙しいスプリントでも途切れないよう、リクルーティングを自動化する
出荷した機能で成功を測る	ビジネス成果につながるプロダクト成果(行動変容)を定義する
機能リクエストからすぐに構築に飛びつく	リクエストの背後にある根本的な問題を見つけ、まずそれが実在するか検証する
「これを使いますか?」「20ドル払いますか?」	「この問題に最後に直面したときのことを詳しく聞かせてください」— 仮定ではなく過去の行動を聞く
最も声の大きいクライアントをロードマップとして扱う	パターンか逸話か、ブロッカーか nice-to-have かでフィルタリングする
定性か定量のどちらかを選び、それだけを信頼する	両方をクロスチェックする。矛盾があれば、コミットする前に別のテストを実行する
最初に現れた解決策にコミットする	複数を生成し、望ましさ × 実現可能性 × 実行可能性で比較し、仮説として位置づける
既存のヘビーユーザーだけをリクルーティングする	包括的で代表的なリクルーティングを行う。問題設定におけるバイアスに注意する
最後にステークホルダーへ調査結果を公開する	最初から彼らを巻き込み、問題について認識を合わせ、実際のユーザーの苦労を見せる
可逆的な判断を過剰に調査する / 不可逆的な判断を過少に調査する	判断のリスクに応じて確実性を合わせる。具体的なテストは仮説検証に引き継ぐ
計画を最終版として出荷する	仮説の厳密性 + okr-metric-validity + prioritization-rigor に引き継ぐ

---

出典レッスン(Uxcel)

• Intro to Product Discovery
• Continuous Discovery Mindset
• Business Outcomes vs. Product Outcomes
• Finding Problems to Solve
• Evidence-Based Product Discovery
• Ethics in Product Discovery & Definition
• Getting Closer to Customers
• Generating Strong, User-Centric Solutions