プロダクトデザイナーとしてのディスカバリー作業（PMの仕様をただ実行するのではなく）
あるフローに3日を費やしました。月曜日の午前9時にFigmaを開き、水曜日の午後までほぼ顔を上げませんでした。PMに1つのファイルを渡します。PMはちらっと見て「良さそうですね、リリースしましょう」と言って次に進みます。仕様の何も変わりません。ロードマップの何も変わりません。役立っているけれど見えていないと感じます。そして6か月後のパフォーマンスレビューには「実行力がある」と書かれ、「ロードマップを形成した」とは書かれません。
デザイナーがこれをPMのせいにするのを見てきました。PMは忙しい。PMはデザインを理解していない。PMには贔屓がいる。それらは実際の問題ではありません。実際の問題は渡した成果物です。1つのデザインは1つの判断を意味します。リリースするかしないか。PMは単一の選択肢を却下しません。スタンプを押すだけです。私はこれを1つの選択肢の罠と呼んでいます。ほぼすべての「実行のみ」デザイナーがそれに気づかずにはまっています。
解決策はより努力することではありません。彼らのデスクに届くものを変えることです。
なぜ2年前よりも今これが重要なのか
過去18か月で2つのトレンドが衝突しました。まず、ディスカバリーデザイナー（何が構築されるかを形成する人で、見た目だけを担う人ではない）は、同じレベルの実行デザイナーよりも意味のある報酬を得ています。最新の公開給与調査（Pencil & Paperの2025プロダクトデザイン給与レポート、Dribbble給与データベース、Read the Docsデザイン給与スレッド）によると、格差はミッドレベルで約18〜30%で、シニア以上ではさらに広がります。ロードマップの仕様形成に関わるシリーズBのシニアプロダクトデザイナーの総報酬は190,000ドルに近くなります。同じ肩書き、同じ会社、同じレベルで実行のみの場合は150,000ドルに近くなります。小さな差ではありません。車1台分の差です。
次に、PMはデザイナーなしでリリースするようになっています。Cursor、Linear、Lovable、v0、そしてAIデザインツールの波によって、センスのあるPMは自分でも十分なフローをリリースできます。この変化を生き残るデザイナーは、磨きの層ではなく問題定義の層で上流に貢献している人たちです。あなたの唯一の付加価値が「Figmaファイルをきれいに見せること」であれば、AIとの競争で下降線を辿ることになります。
これは悲観論ではありません。明確化です。仕事はディスカバリーに向かっており、すでにそのように動いているデザイナーはさらに先を行っています。彼らのやり方の仕組みは学ぶことができます。それがこのPlaybookの残りで説明することです。
ディスカバリーと実行フェーズ：本当のマインドセットの違い
実行フェーズモードは1つの問いに答えます。「これはどのように見えてどのように振る舞うべきか?」 問題、スコープ、制約を受け取ります。何かを作ります。渡し返します。
ディスカバリーモードは異なる問いに答えます。「これはそもそも解くべき正しい問題なのか?」 ブリーフを受け取り、Figmaを開く前に問い詰めます。顧客と話します。仕様に合わない代替案をスケッチします。会話にエビデンスを持ち込みます。
どちらのモードも重要です。間違いは実行フェーズの作業をすることではありません。実行フェーズはスタッフレベルでさえ、どのデザイナーの週のほとんどを占めています。間違いは実行フェーズのみの作業をして、サービスデスクのように扱われても驚くことです。
各モードでの具体的な行動：
実行フェーズモードのデザイナー：
- 仕様を受け取った瞬間にFigmaを開く
- 「空の状態はどう見えるべきか?」と聞く
- 1つのファイルを渡す
- ポートフォリオにリリースしたフローを記録する
- 上位への報告：「今四半期X、Y、Zをリリースしました」
ディスカバリーモードのデザイナー：
- 仕様を読んでから、ラップトップを閉じて散歩に出る
- 「誰のために構築していて、その人について何を知っているか?」と聞く
- トレードオフを伴う3つの選択肢を渡す
- 自分の作業が引き起こした仕様の変更を記録する
- 上位への報告：「Xへのアプローチを変えました。これが顧客エビデンスと結果です。」
使われる動詞に注目してください。ディスカバリーデザイナーは「変えた」「シフトした」「方向を変えた」と言います。実行フェーズデザイナーは「リリースした」「完了した」「デリバリーした」と言います。最初のセットはオーナーシップのように聞こえます。2番目のセットはスループットのように聞こえます。
3つのパスのルール
これが最も効果的な単一の機械的な変化です。デザインをPMに渡すときは常に3つの選択肢を渡してください。
- 安全なパス： PMが仕様に最も近いもの。最低リスク、最低リターン。彼らが期待していたもの。
- ストレッチパス： さらに2週間と少し広いスコープがあれば構築するもの。同じ問題、より野心的な解決策。
- 変わったパス： 異なる問題を解決するか、または誰も考えていない方法で同じ問題を解決する選択肢。通常は顧客インタビューや競合他社の側面攻撃からインスパイアされる。
各パスには3つのラベルが付きます。時間コスト、リスク、アップサイド。それだけです。10ページのNotionドキュメントではありません。3つのFigmaフレームと小さなテーブルの1ページです。
なぜ3つなのか? PMが実際にどう決定するかによります。1つの選択肢では、判断は二値です。リリースするか潰すか。PMはほぼ常にリリースします。それがスタンプループです。2つの選択肢では、偽の二値を作り出しました。PMはより安全な方を選び、毎回安全対リスクの選択を期待するよう訓練されてしまいます。3つの選択肢では、本物の会話が生まれます。PMは自分がなぜ1つを好むかを言語化しなければなりません。そしてその理由を言語化すると、「仕様を実行する」から「戦略を共同決定する」に移行します。
3パスのハンドオフを却下したPMはいませんでした。安全なパスを選んだPMはたくさんいました。でも会話は違います。磨きを承認するのではなく、トレードオフを議論しています。
私が使っている実用的なテンプレート：
問題：[1文。ユーザーのために何を達成しようとしているか]
パスA：安全（1週間）
内容：[PMが期待していたもの、きれいにデザインされたもの]
リスク：低
アップサイド：予定通りリリース、OKRを達成
パスB：ストレッチ（2週間）
内容：[同じ問題へのより野心的な解決策]
リスク：中（バックエンドの変更が必要）
アップサイド：Q3に必ず直面する2次的な問題に対処
パスC：変わった（3週間）
内容：[問題を完全に異なるフレーミングで解決する]
リスク：高（顧客が望むか不明）
アップサイド：正しければ10倍のインパクト、どちらにせよ学び
顧客エビデンス：[ここを指し示した顧客インタビューの名前]
これが1ページです。デザインの思考をした後に15分で書けます。1四半期の間すべてのハンドオフでこれを採用して、パフォーマンスレビューに何が起きるか見てください。
オポチュニティ・ソリューションツリー、デザイナー版
Teresa Torresのオポチュニティ・ソリューションツリーは、実行フェーズの上流にとどまるための最もすっきりしたフレームワークです。オリジナル版：上部に成果、中間に機会（顧客の痛みと欲求）、下部に各機会から分岐する解決策。
デザイナーの適応版：あなたの仕事は下層だけでなく中間の層も埋めること。 ほとんどのデザイナーは解決策の層（既知の機会を解決するものをスケッチ、プロトタイプ、磨く）に完全に住んでいます。PMは主に成果層（四半期のOKR、ビジネスメトリクス、エグゼクティブのナラティブ）に住んでいます。中間の層（実際の顧客の問題）が争われる領域です。それをうまく埋めた人がロードマップをオーナーします。
実際の例。アクティベーション率を向上させたいB2B SaaSのチェックアウトフローを担当していました。
成果層（PMの領域）： 30日アクティベーションを38%から50%に増加させる。
機会の層（本当の争い）：
- ユーザーが誰を招待すべきかまだわからないため、シートの割り当て中に離脱する
- ユーザーが任意だと思ってインテグレーションのステップをスキップする
- ユーザーがサインアップを完了するが、チームメートを招待するまでプロダクトが空に感じられるため戻ってこない
- ユーザーがチームメートを招待するが、件名が汎用的なためそのチームメートがメールを無視する
ジュニアデザイナーは「シート割り当て画面をリデザインして」と言われ、それをきれいにしていたでしょう。ディスカバリーの動きは、4つすべての機会をマッピングし、それからどれが実際に制約になっているかを見つけるための簡単なインタビューラウンドを実施することでした。（3番目の問題、プロダクトが空に感じられることで、残りの3つを合わせた4倍の規模でした。誰も仕様に書いていなかったのは、誰も尋ねていなかったからです。）
このための成果物はとてもシンプルです。FigJamを開きます。3行：成果、機会、解決策。付箋紙。ルールは、少なくとも1つの顧客との会話で検証されていない機会には解決策を結びつけないことです。そのルールだけでディスカバリーデザイナーと実行フェーズデザイナーを分けます。
顧客インタビューのリズム：週3回以上が最低限
デザイナーは「顧客へのアクセスがない」と言います。これはほぼ決して真実ではありません。通常は3つの実際の問題のうちの1つです。
- CSMチームにウォームイントロを求めたことがない（Slackで5分のメッセージ1通で済む）
- チャットをスケジュールするのにPMの許可が必要だと思っている（そうではない）
- PMの領域を踏み荒らすように見えることを心配している（以下で対処するが、これも誤解）
週3回の顧客との会話が最低限です。上限ではありません。Pencil & Paperの2025デザイナー調査では、シニア以上のデザイナーがアクティブなディスカバリー中に週5回のインタビューを行うことが中央値でした。3回がディスカバリーデザイナーと名乗るための最低限です。
実際にそこに到達する方法：
- CSMに一度Slackする。 「[問題エリア]について週3人の顧客と話そうとしています。インントロをキューに入れてもらえますか?」そのメッセージ1通で次の6〜8週間のインタビューが生まれます。CSMは顧客が話を聞いてもらえると感じるため喜びます。
- 既存のコールに便乗する。 セールスがディスカバリーコールをしたりCSがQBRをしたりするなら、週2回サイレントシャドーイングをお願いしてください。半分のインタビューはゼロよりも良い。
- アプリ内メッセンジャーで5人の顧客にDMする。 「Xに取り組んでいるデザイナーです。今週15分、何が壊れているかを教えてもらえますか?」プロダクトがユーザーとある程度の関係を持っていれば、返答率は30〜50%です。
- 解約後のサーベイを活用する。 チャーンが起きたとき、解約フォームは宝の山です。毎週すべてを読んでください。最も明確に述べられた5つの不満をツリーに取り込んでください。
すべてのインタビューのためにNotionページに保持し引き出すサンプル質問バンク：
- 最後に[タスク]をしようとしたときのことを教えてください。何が起きましたか?
- どこで詰まりましたか?
- このプロダクトの前に何を試しましたか?なぜそれはうまくいかなかったのですか?
- この機能を明日削除したら、代わりに何をしますか?
- これを毎日使うために何が必要ですか?
- あなたのチームの他に誰がこれを使いますか?彼らは何を違う方法でしますか?
- [問題エリア]に関連するあなたの週で最悪の部分は何ですか?
- このプロダクトが驚かせたこと（良いか悪いか）を教えてください。
- 魔法の杖があれば、何を変えますか?
- 聞くべきなのに聞かなかったことはありますか?
何が欠けているかに注目してください。あなたのデザインについての質問です。「このボタンの色が好きですか」とは聞いていません。彼らの世界について聞いています。デザインの質問はプロトタイプ検証で後から来ます。
プロトタイプ主導の検証：火曜日のプロトタイプ、木曜日のインサイト
機会をマッピングし、いくつかの解決策スケッチを持ったら、仕様が確定する前にプロトタイプをリリースしてください。私は火曜日のプロトタイプ、木曜日のインサイトと呼ぶサイクルを実施しています。
月〜火曜日： 最も有望な1〜2パスのFigmaプロトタイプを構築します。ピクセルパーフェクトでなくて良い。クリックスルーできる程度で十分。最大4〜8時間の作業。
水曜日： Maze、UserTesting、またはLoom + 「5分クリックして、何が起きると思うか教えてください」というSlack DMで5人の顧客に送ります。5人のユーザーで80%のパターンを見つけるのに十分です。ニールセンの古典的な研究は2024年にMazeが再検証した際にも有効でした。
木曜日： まとめます。3枚のスライド：うまくいったこと、壊れたこと、驚いたこと。PMチャンネルに投稿します。
金曜日： プロトタイプデータで3パスドキュメントを更新します。今のハンドオフは「3つの選択肢があります」ではありません。「3つの選択肢があり、選択肢Bは5人の顧客でテストされました。3人がタスクを完了し、2人が同じステップで詰まりました。こちらが録画です。」
それが会話を変えます。PMは意見とは議論します。5本の顧客が詰まっている録画とは議論しません。プロトタイプデータはあなたを「デザイナーがそう思う」から「顧客がそう言った」に変え、それは異なる種類の権威です。
これのための低コストツールスタック：
- Maze： 非モデレートの定量的プロトタイプテストに最適。月額約99ドル。
- UserTesting： モデレートされた定性的なものに最適。より高価だが高リスクのフローには価値がある。
- Loom + 5人の顧客へのSlack DM： 無料、驚くほど効果的。実際に送信を押すことだけが必要。
ポイントはツールではありません。仕様が確定する前にテストしたことです。それがディスカバリーです。仕様がロックされた後のすべては実行フェーズの磨きです。
「あなたはPMではない」：デザイナーを小さく保つ誤解
このことについてデザイナーをコーチするたびに、毎回同じ恐怖が浮かび上がります。「PMは私がでしゃばっていると思いませんか?」
ディスカバリー作業はあなたをPMにしません。より良いデザイナーにします。その区別は現実のものであり、保持する価値があります。PMは何を構築するかの決定をオーナーします。デザイナーは決定を形成するインプットをオーナーします。顧客エビデンス、3つの選択肢、プロトタイプデータを持ち込むことはPMの仕事を奪うことではありません。あなたの仕事を有能にやることです。
私の経験では機能するスクリプト：
避けるべき対立的なフレーミング： 「あなたが仕様に書いたものを構築すべきではないと思います。」（あなた対彼らの問題になっている。）
伝わるディスカバリーのフレーミング： 「一緒に選べるよう3つのパスをスケッチしました。パスCは、ブリーフとは異なる問題を描写した2人の顧客との会話から生まれました。見てみる価値はありますか?」
対立的： 「仕様が間違っています。」
ディスカバリー： 「火曜日に5人のユーザーで仕様をテストしました。3人がステップ2で詰まりました。こちらが録画です。どう思いますか?」
対立的： 「ロードマップミーティングに入るべきです。」
ディスカバリー： 「ロードマップ計画に顧客インタビューの結果を持ち込みたいと思っています。次のセッション用に5分のまとめを作りましょうか?」
パターン：意見を成果物に変え、対立を招待に変えます。PMは実際にはデザイナーと争いたくありません。一人で解決しなければならないことを減らしたいのです。選択肢、エビデンス、「一緒に決めましょう」という姿勢で現れると、あなたは彼らが持つ中で最も協力しやすい人になります。「私は同意しません」で現れると、最も難しい人になります。同じ内容、異なるフレーミング、まったく異なる評判。
ディスカバリーの成果を記録する。さもなければ存在しない
ほとんどのプロダクト企業のパフォーマンスレビューについての残酷な真実：文書化されなかった影響力は起きなかったも同然。 四半期に3つのロードマップを静かに形成したシニアデザイナーが、派手なローンチを2つリリースした同僚に昇進で先を越されるのを見てきました。同僚はストーリーを語りました。シニアデザイナーは語りませんでした。
ディスカバリーのログを管理してください。1つの成果につき1行。5つの列：
| 日付 | 変更された仕様/決定 | 顧客エビデンス | 結果 | PMによる確認 |
|---|---|---|---|---|
| 2026-02-14 | 空の状態の修正を優先してシート招待のリデザインを終了 | 8回のインタビューで5人がアクティベーション前の「孤独に感じる」を言及 | テストコホートでアクティベーション+9pt | 2/15のPriyaとのSlackスレッド |
| 2026-03-03 | 請求フローを1ステップのモーダルから2ステップに再定義 | Mazeテスト、5人のユーザー、3人が1ステップの最初で離脱 | ローンチ後のコンバージョン+4pt | ロードマップミーティングのメモ3/4 |
3つの列は記述的です。2つはエビデンスです。「PMによる確認」の列が重要です。Slackのスクリーンショット、Loomのコメント、ロードマップのドキュメント編集。日付があって追跡可能なもの。パフォーマンスレビューが来たとき、「価値を加えたと思います」と懇願するのではありません。領収書を見せます。
このログは週5分で管理できます。ほとんどのデザイナーは始めません。始めた人はパフォーマンスレビューで同僚とは異なる会話を持ちます。
機械的な変化
持ち帰ってほしいことはこれです。実行フェーズからディスカバリーへの移行は性格の変化ではありません。「より戦略的になる」ことについてでもありません。その言葉が何を意味するにせよ。機械的なことです。4つの成果物を変えます。
- 1つのデザインではなく3つのパスを渡す
- インタビューで埋めたオポチュニティ・ソリューションツリーを維持する
- 毎週、毎週3回以上の顧客インタビューを実施する
- すべての重要なフローで火曜日のプロトタイプ、木曜日のインサイトのループを実施する
- ディスカバリーの成果ログを管理してパフォーマンスレビューに持ち込む
5つの成果物。肩書きの変更も、マネージャーの許可も、新しい仕事も必要ありません。月曜日からすべてを始めることができます。PM関係は副作用として変わります。PMについてそれを話したからではなく、彼らのデスクに置くものが変わったからです。
それが全体のゲームです。
