顧客から強い要望があった機能を、エンジニアと相談して2か月かけて作った。リリースして案内もした。ところが、数週間たっても使っている顧客はほんの一握りで、要望をくれた顧客さえ使っていない。こうした経験が一度や二度ではない、というプロダクトは少なくありません。
原因の多くは、開発の進め方ではなく、その手前にあります。「何を作るか」を決める段階で、課題が本当にあるのか、その解決策で本当に使われるのかを確かめないまま、開発に進んでしまっているのです。
この「何を作るかを決める前の検証」を、プロダクトマネジメントの世界ではプロダクトディスカバリーと呼びます。大きな組織では専任のチームを置くこともありますが、少人数のスタートアップでも、経営者がPdMを兼務しながら回すことは十分にできます。
本記事では、プロダクトディスカバリーの基本的な考え方を整理したうえで、少人数のチームで回すための4つのステップと、開発と並走させる週次の進め方を解説します。
プロダクトディスカバリーとは
プロダクトディスカバリーとは、作るべきものを見極めるための検証の活動です。対になる言葉として、決まったものを作って届ける活動を「プロダクトデリバリー」と呼びます。
| ディスカバリー | デリバリー | |
|---|---|---|
| 問い | 何を作るべきか、作るべきでないか | 決まったものを、どう作って届けるか |
| 主な活動 | インタビュー、データ分析、プロトタイプでの検証 | 設計、実装、テスト、リリース |
| 成果物 | 「作る・作らない・形を変える」の判断と、その根拠 | 動くプロダクト |
| 失敗したときのコスト | 小さい（数日〜数週間の検証） | 大きい（数週間〜数か月の開発） |
ディスカバリーの目的は、アイデアを「確からしい」状態にしてから開発に渡すことです。言い換えると、開発で数か月かけて失敗する前に、数日から数週間の検証で失敗しておくための活動です。
よく似た言葉にMVP（実用最小限の製品）やPMF（プロダクトマーケットフィット）の検証があります。MVPは検証の手段の一つ、PMFは事業全体として市場に受け入れられているかの状態を指します。プロダクトディスカバリーは、それらを含めて「日々の機能開発で、何を作るかをどう決めるか」という、もっと日常的な進め方の話です。
少人数のスタートアップで、ディスカバリーが抜け落ちる理由
経営者がPdMを兼務しているプロダクトでは、ディスカバリーが抜け落ちやすい構造があります。
- 経営者自身が顧客に一番近い：商談や顧客対応で直接話を聞いているため、「顧客の課題はもう分かっている」と感じやすくなります。実際にはその時点では仮説にすぎないことでも、確信に近い感覚で開発に進んでしまいます。
- 開発チームの手を止めたくない：エンジニアの手が空くと、次に作るものを急いで決めたくなります。検証に時間を使うより、何かを作っているほうが前に進んでいるように感じられます。
- 検証を担う人が決まっていない：開発はエンジニア、営業は営業担当と役割が分かれている一方で、検証は経営者の頭の中で行われるか、行われないかのどちらかになりがちです。
どれも、少人数で速く動いてきたからこそ生まれる状態です。だからこそ、ディスカバリーは「余裕ができたらやるもの」ではなく、開発と同じように、毎週の仕事として組み込むものとして扱う必要があります。
プロダクトディスカバリーを回す4つのステップ
ディスカバリーは、次の4つのステップで進めます。それぞれのステップで「次に進むか、前に戻るか」を判断しながら、行き来しつつ進めるのが基本です。
ステップ1：検証の起点となる「問い」を決める
最初に、今回のディスカバリーで何を明らかにしたいのかを1つの問いにします。起点になるのは、顧客からの要望、データの変化、経営としての目標など、さまざまです。
ここで大切なのは、「この機能を作るべきか」ではなく、「どの顧客の、どんな状況を良くしたいのか」という形で問いを立てることです。
- 悪い例：「CSVエクスポート機能を作るべきか」
- 良い例：「導入2か月以内の顧客が、社内への報告に手間取っている状況を減らせないか」
機能を起点にした問いは、答えが「作る・作らない」の二択になり、他の解決策を検討する余地がなくなります。顧客の状況を起点にすると、CSVエクスポート以外の解決策も比べられるようになります。
問いは、事業として今いちばん動かしたい指標とつながっているかも確認します。解約を減らしたい時期に、新規獲得にしか効かない問いから始めても、検証の結果が経営判断に活きません。
ステップ2：課題が本当にあるかを確かめる
次に、問いの中に含まれている課題が本当にあるのか、どのくらいの顧客にとって、どのくらい重要なのかを確かめます。
使う手段は主に2つです。
- ユーザーインタビュー：対象の顧客に、実際にどんな場面で、どう困っているかを聞きます。「その機能があったら使いますか」とは聞かず、「前回それをしたとき、どうやって対応しましたか」のように、過去の具体的な行動を聞くのが基本です。
- 利用データ：課題が起きていそうな場面で、実際の利用状況がどうなっているかを見ます。インタビューで聞いた話が一部の顧客だけのものか、広く起きていることかを確かめられます。
少人数のチームであれば、まずは5件程度のインタビューで十分です。同じ話が繰り返し出てくるようになれば、課題の輪郭は見えてきます。反対に、5件聞いても課題がはっきりしない場合は、ステップ1の問いの立て方に戻ります。
インタビューを重ねたら、発言を並べるだけで終わらせず、「どの顧客が、どんな状況で、何に困っているか」の形にまとめます。
📌 関連記事：ユーザーインタビューの分析・まとめ方｜発言を「使える示唆」に変える5ステップ（PdMを兼務する経営者向け）
ステップ3：解決策を小さく試す
課題が確かめられたら、解決策の候補を出し、作り込む前に小さく試します。ここでのポイントは、最初から解決策を1つに絞らないことです。少なくとも2〜3案を並べて比べると、最初に思いついた案に引きずられにくくなります。
試し方は、検証したいことに合わせて選びます。
- 紙やデザインツールで作った画面イメージを見せる：顧客が「自分の課題を解決してくれそうだ」と感じるかを確かめる
- 手作業で代わりに提供してみる：仕組みを作る前に、運営側が手作業で同じ価値を提供し、実際に使われるかを確かめる
- 既存機能の設定や使い方の案内で代替する：新しく作らなくても課題が解けないかを確かめる
このステップで検証するのは、主に次の2点です。
- 顧客にとって価値があるか（使いたいと思えるか、実際に使うか）
- 自社で実現できるか（エンジニアから見て、現実的な工数で作れるか）
2点目を確かめるために、このステップからエンジニアに加わってもらうことをおすすめします。解決策が固まってから見積もりを依頼すると、「その作りなら3倍かかる」「少し形を変えれば1週間でできる」といった重要な情報が、判断の後に出てくることになります。
ステップ4：「作る・作らない・形を変える」を判断し、開発に渡す
最後に、ここまでの検証をもとに判断します。選択肢は「作る」だけではありません。
- 作る：課題も価値も確かめられた。開発の優先順位に組み込む
- 作らない：課題はあったが、優先度が低い、または既存の手段で十分に解けると分かった
- 形を変える：課題はあるが、最初に考えた解決策ではない形のほうが良いと分かった
- 問いに戻る：課題そのものが想定と違っていた
「作らない」と判断できたことも、ディスカバリーの立派な成果です。開発の数週間を、より効果の大きいテーマに使えるからです。
「作る」と判断した場合は、検証で分かったことを開発チームに渡します。解決したい顧客の状況、検証で確かめたこと、まだ確かめられていないこと、の3点が伝われば、エンジニアは細部の判断を自分でできるようになります。
あわせて、判断の内容と理由を記録に残しておきます。「作らない」と決めたテーマに半年後に同じ要望が来たとき、前回なぜそう判断したかが分かれば、検証をやり直すべきかをすぐに判断できます。
開発と並走させる、週次の回し方
ディスカバリーを始めるとき、「検証している間は開発が止まるのでは」という心配がよく出てきます。実際には、ディスカバリーとデリバリーは同時並行で進めます。開発チームが今週作っているのは、数週間前にディスカバリーで確かめたものという状態をつくるのが理想です。
経営者がPdMを兼務している場合、次のような週次のリズムから始めると続けやすくなります。
| 曜日の目安 | ディスカバリーの活動 | かける時間の目安 |
|---|---|---|
| 週のはじめ | 今週確かめたいことを1つ決める | 30分 |
| 週の半ば | インタビュー2件、またはデータの確認 | 2〜3時間 |
| 週の終わり | 分かったことを数行でまとめ、次の一手を決める | 30分 |
週に合計3〜4時間程度です。この時間を確保できない週は、インタビューを1件に減らしてもよいので、「毎週、何か1つを確かめる」リズムを途切れさせないことを優先してください。まとめて時間を取ろうとすると、結局後回しになりがちです。
もう一つのポイントは、ディスカバリーの結果が開発の優先順位に反映される流れをつくっておくことです。週の終わりのまとめで「作る」と判断したものは、バックログの優先順位を見直すタイミングで候補として並べます。
よくある失敗
- 「使いますか」と聞いて、使うと言われたので作る：顧客は目の前で聞かれると、好意的に答えやすいものです。未来の意向ではなく、過去の行動を聞くことで、実際にどれほど困っているかが見えてきます。
- 声の大きい1社の要望で検証を終える：大口の顧客や熱心な顧客の意見は重要ですが、その1社にしか当てはまらない課題の可能性もあります。少なくとも複数の顧客で同じ課題が起きているかを確かめます。
- 検証の途中で結論を決めてしまう：経営者が最初から「作る」と決めていると、検証は結論を補強する材料集めになります。ステップ1で「どんな結果が出たら作らないか」を先に決めておくと、判断がぶれにくくなります。
- エンジニアを判断の後に呼ぶ：解決策が固まってから相談すると、実現性の観点での良い案が出てくる余地がなくなります。ステップ3の段階から、エンジニアに入ってもらいます。
- 検証の結果を残さない：インタビューで分かったことが経営者の頭の中にだけ残ると、後から採用したPdMやメンバーに引き継げません。
具体例：CSVエクスポートの要望から、別の解決策にたどり着いたケース
従業員12名、BtoB SaaSを提供する創業4年目のスタートアップを想定した例です。経営者がプロダクトの責任者を兼務しており、複数の顧客から「データをCSVで出力したい」という要望を受けていました。当初は、そのまま開発に入る予定でした。
ステップ1では、問いを「CSVエクスポートを作るべきか」ではなく、「顧客が、プロダクト内のデータを使って何をしようとしているのか」と置き直しました。
ステップ2で、要望をくれた顧客を中心に5社へインタビューしたところ、5社中4社が「毎月の社内会議で、利用状況を報告する資料を作るため」にデータを出したいと考えていることが分かりました。CSVを出した後は、表計算ソフトで同じ集計とグラフ作成を毎月手作業で行っていました。
ステップ3では、エンジニアも交えて3つの案を比べました。CSVエクスポートを作る案、報告用のレポート画面を作る案、そして毎月決まった形式のレポートをメールで届ける案です。画面イメージを見せながら顧客に聞いたところ、最も反応が良かったのは、手作業の集計そのものがなくなるレポート画面の案でした。エンジニアからは、既存のダッシュボードの部品を使えば、CSVエクスポートと大きく変わらない工数で作れるという見立てが出ました。
ステップ4で「形を変えて作る」と判断し、レポート画面を開発しました。リリース後は、要望をくれた顧客の多くが毎月の報告に使うようになりました。CSVエクスポートは、レポート画面では足りない顧客が一定数出てきた段階で、改めて検討することとしました。
もし最初の要望どおりCSVエクスポートを作っていれば、顧客の毎月の手作業は残ったままでした。ディスカバリーにかけた時間は約3週間でしたが、その間も開発チームは別のテーマの開発を進めていました。
よくある質問（FAQ）
Q1. すべての機能開発でディスカバリーをするべきですか。
いいえ。不具合の修正や、課題も解決策もはっきりしている小さな改善まで検証していると、かえって進みが遅くなります。目安として、開発に2週間以上かかるもの、または「なぜ作るのか」を一言で説明しにくいものを、ディスカバリーの対象にするとよいでしょう。
Q2. インタビューに協力してくれる顧客が見つかりません。
まずは、日頃やりとりのある顧客や、要望を寄せてくれた顧客に、30分程度の時間をお願いするところから始めます。経営者から直接お願いすると、応じてもらえることが多いものです。「今後の開発の参考にしたい」と目的を伝え、終わった後に検証の結果を共有すると、次の協力も得やすくなります。
Q3. 1人目のPdMを採用したら、ディスカバリーは任せてよいですか。
任せる方向で進めるのがよいでしょう。ただし、ステップ1の「どの問いに取り組むか」は事業の方向性に直結するため、最初は経営者と一緒に決めることをおすすめします。ステップ2〜3の検証の進め方から任せ、判断の感覚が擦り合ってきたら、問いの設定まで広げていく順序が安全です。
Q4. ディスカバリーにツールは必要ですか。
始める段階では、専用のツールは必要ありません。インタビューのメモと、週ごとの「分かったこと・次の一手」をまとめるドキュメントがあれば十分です。検証の件数が増え、複数人で進めるようになった段階で、必要に応じて検討してください。
まとめ
「作ったのに使われない」を繰り返さないために必要なのは、開発を速くすることではなく、何を作るかを決める前に確かめる習慣です。これがプロダクトディスカバリーです。
進め方は、(1)検証の起点となる問いを「顧客の状況」の形で決める、(2)インタビューとデータで課題が本当にあるかを確かめる、(3)複数の解決策をエンジニアと一緒に小さく試す、(4)「作る・作らない・形を変える」を判断して開発に渡す、の4つのステップです。
少人数のチームでは、週に3〜4時間程度の時間でも、毎週1つを確かめるリズムを続けることで、開発に渡すテーマの確からしさが変わってきます。まずは、今バックログの上位にある機能を1つ選び、「これは、どの顧客の、どんな状況を良くするためのものか」を言葉にするところから始めてみてください。
プロダクトマネジメントについてお気軽にご相談ください
プロダクトマネジメントの顧問支援や、1人目のPdM採用・育成のサポートを承っています。
「経営者が兼務してきたが、そろそろ限界かもしれない」という段階からでもお気軽にご連絡ください。
おおむね2営業日以内にご返信します。
