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

プロダクトディスカバリーは、何を作るべきかを決めるための探索活動です。単なるユーザーインタビューでも、アイデア出しの会でもありません。顧客の問題、解決策の仮説、事業上の意味、実現可能性を行き来しながら、作る前に不確実性を下げる活動です。

基本のループは、次の4つで考えると扱いやすくなります。

問題を見つける

最初に見るべきものは、顧客の要望ではなく顧客の状況です。要望は、顧客自身が考えた解決策であることが多いからです。「一覧をCSVで出したい」という要望の裏には、「社内報告に転記するのが面倒」「既存の承認フローから外れられない」「画面上では比較しづらい」といった別の問題が隠れているかもしれません。

問題を見つけるときは、次のように聞きます。

問題が見えてきたら、解決策をすぐに決めるのではなく、仮説の形にします。

「もし、請求前の確認作業を1画面に集約すれば、経理担当者の確認時間が短くなり、差し戻しが減るはずだ」

このように書くと、誰の、どの行動が、どう変わることを期待しているのかが見えます。検証すべき前提も明確になります。

検証は、必ずしも実装から始める必要はありません。プロトタイプ、手作業、モック、ランディングページ、既存データの分析、サポートログの確認など、仮説に応じて軽い方法を選びます。

重要なのは「作れるか」だけでなく、「使われるか」「価値があるか」「事業として続けられるか」を分けて見ることです。技術的には簡単でも、顧客が行動を変えないものはプロダクトの価値になりません。

ディスカバリーは、検証して終わりではありません。学びをロードマップ、バックログ、営業資料、サポート方針に反映してはじめて意味があります。

よいチームは、失敗した仮説も資産として残します。「なぜ作らなかったのか」「どの前提が外れたのか」が残っていると、同じ議論を何度も繰り返さずに済みます。

プロダクトディスカバリーは、開発の前工程ではなく、プロダクト開発そのものの一部です。