continuous-discovery

継続的なプロダクトディスカバリー

顧客フィードバックを定期的な雑務から、プロダクトに関する意思決定を促す高頻度の原動力へと変えます。

Lenny's Podcast と Newsletter に登場した23人のゲストや投稿から得られた知見を活用し、継続的なプロダクトディスカバリーを支援します。

支援方法

1. 現在の顧客との距離を監査する - チームとユーザーが直接やり取りする頻度と質を評価し、既存のゲートキーパーを特定します。
2. ディスカバリーの習慣を定める - インタビュー、デモデー、プロダクトトリオ全体が参加するサポート当番の定期的な実施サイクルを設定します。
3. 機会領域を構造化する - 生のフィードバックを、満たされていないニーズ、ペインポイント、希望を示す視覚的なマップへと整理できるよう支援します。
4. エビデンスの収集を加速する - 本格的な開発に着手する前に、プロトタイプや行動マッピングを通じて仮説を検証する軽量な手法を提案します。

基本原則

ニーズとソリューションを区別する

Teresa Torres：「機会とは、満たされていないニーズ、ペインポイント、あるいは希望だと言えます。それは素晴らしいことです。しかし、機会を書く人の98％は、それをソリューションとして書いているとも言えます。つまり、問題領域とソリューション領域の違いを区別することに、本当に苦労しがちなのです。」

真のディスカバリーには、あらかじめ決めた機能案ではなく、満たされていない顧客ニーズとして、すべての機会を厳密に定義する必要があります。

開発者とユーザーの間にある層を取り除く

Brian Tolkin：「顧客と毎日話していました。1対1のオンボーディングを担当したり、サポートチケットに対応したりしていました。中央集約型のサポートチームはなく、顧客に近い担当者もいませんでした。ですから、事業を動かすものを本当に理解し、顧客のすぐそばにいるという基盤は、実際、何を構築したいのかを考え、それをよりスケーラブルな技術的な形にしていくうえで、かなり有効な基盤だと思います。」

中央集約型のフィルターをなくし、プロダクトチームがオンボーディングやサポートに直接関わることで、深い共感が育まれます。

ディスカバリーを実行プロセスに組み込む

Itamar Gilad：「Googleは、私が『エビデンスに導かれる企業』と呼ぶものでした。つまり、顧客に注力し、多くのアイデアを出し、データを確認し、それらのアイデアが実際にどう機能したかを見ることを非常に重視していました。粗削りで不完全なベータ版などを公開することをためらわず、そこから学んでいました。そして、その結果に基づいて行動することを人々に期待していました。」

粗削りで不完全なバージョンをリリースし、実際の環境でデータを集めて、その結果をもとに方向転換するか、エンジニアリング作業を続けるかを判断します。

強いシグナルが得られる非公式な接点を優先する

Jeff Weinstein：「顧客がわざわざ問題について話しに来るほど強く感じていたとしたら、それはとてつもない贈り物です。相手に1通返信するためだけに、私は会議を抜けることもあります。5人か10人と気軽にテキストメッセージをやり取りできる関係を築ければ、伝染するほど多くの直接的なシグナルが得られます。」

テキストメッセージのように、意欲の高いユーザーと直接かつ非公式にやり取りすることは、構造化された調査よりも質の高いシグナルをもたらすことがよくあります。

リサーチを継続的なパートナーとして位置づける

Judd Antin：「私にとって、解決策はシンプルですが、簡単ではありません。リサーチをもっと全面的に組み込めるよう、プロダクトの作り方を再構築する必要があります。研究者とその仕事、そして彼らがもたらす知見が、最初から最後までプロセスの一部となるような、継続的な関係を築くのです。」

リサーチは、開発プロセスの最初にだけ利用する受け身のサービスではなく、その全体を通じて組み込まれるパートナーであるべきです。

直接観察して摩擦を特定する

「スタートアップを次々と生み出した、型破りなPalantirの原則」より：「この考え方を理解するには、自分自身がユーザーになる必要があります。『ユーザーのように考える』という精神論のことではありません。文字どおり、チームの一員として自社製品を使い、ユーザーと同じ仕事をして、そこから何を学べるか確かめるということです。」

顧客の実際の業務を一緒に行い、インタビューだけでは明らかにならない業務上の摩擦を見つけます。

顧客の職場に技術スタッフを配置する

Nabeel S. Qureshi：「現場に派遣する、ある種のエンジニアがいました。月曜日から木曜日まで、顧客が働く建物に実際に出向き、一緒に仕事をすることもありました。文字どおりそこにデスクを用意してもらい、そのエンジニアはフォワードデプロイドエンジニアと呼ばれるようになりました。」

価値の高いエンタープライズ向けの課題発見には、エンジニアが顧客のオフィスで働き、現場のボトルネックを特定するのが最も効果的です。

テンプレートとフレームワーク

• 継続的な課題発見とプロジェクト単位のリサーチ（Teresa Torres）- 課題発見をプロダクト業務にどう組み込むかを捉え直します。リリース前の一段階ではなく、リリースと並行して続ける習慣として考えます
• オポチュニティソリューションツリーフレームワーク（The Best of Lenny’s Newsletter 2023）- 継続的なプロダクト課題発見のためのTeresa Torresのフレームワークです。成果を機会、解決策、実験へとつなげます。
• プロダクトスクラップブック（Notionデータベース）（Product manager is an unfair role. So work unfairly.）- 戦略的な領域ごとに顧客の知見、フィードバック、根拠を集めて整理し、課題発見と計画立案を迅速化する、シンプルなNotionデータベースです。
• フォワードデプロイドエンジニアリング（FDE）モデル（スタートアップを次々と生み出した、型破りなPalantirの原則）- エンジニアが顧客の環境に長期間（数時間ではなく数か月）物理的に入り込み、実務を行う顧客課題発見・プロダクト開発のアプローチです。
• 接触時間（Guillermo Rauch）- Vercelにおいて、プロダクトのセンスと共感を育むための社内運営原則です。
• プロダクトトリオモデル（Teresa Torres）- プロダクトマネージャー、デザイナー、ソフトウェアエンジニアが対等な立場で協力し、課題発見とプロダクトの意思決定を行う働き方です。
• 全員が担うカスタマーサポート — 対応のリズム（What working at Figma taught me about customer obsession）- Figmaがサポートチケットから営業電話、偶然の会話まで、あらゆる顧客とのやり取りに用いた3段階のリズムです
• 一次情報に当たるためのチェックリスト（First-principles thinking）- 他者から聞いた憶測に頼らず、一次情報を得るための5つの方法です

詳細を含む全項目の一覧については、references/artifacts.mdを参照してください。

ユーザーに役立つ質問

• 「先週、チームは顧客が仕事をする様子を観察するのに何時間費やしましたか？」
• 「機能の開発中止や方向転換につながった、最も最近の顧客の知見は何ですか？」
• 「過去14日間に、エンジニアリングチームのうちユーザーと直接話したメンバーは誰ですか？」
• 「顧客の未充足ニーズを、機能リクエストの一覧とは別に記録していますか？」
• 「現在、開発者とユーザーの間にどのような社内のゲートキーパーや集中管理チームがありますか？」
• 「計画立案中にも参照できるよう、顧客から得た根拠を現在どのように保存・整理していますか？」

よくある指摘事項

• ディスカバリーをフェーズとして扱う - ディスカバリーは、提供開始前に一度だけ行うプロジェクトではなく、並行して継続的に取り組む習慣であるべきです。
• インセンティブよりも表明された立場を重視する - ユーザーは、実際の行動の根底にあるインセンティブを隠すような手順書や要求を提示することがよくあります。
• インタビュー中にソリューションに注目する - 初期のディスカバリーでは、具体的な機能案を提案するのではなく、根底にあるユーザーニーズを深く理解することに注力すべきです。
• 声の大きい少数派のために開発する - 最も声の大きいユーザーからのフィードバックを過度に重視すると、より広い市場のニーズを満たせないプロダクトにつながる可能性があります。

詳細

23 人のゲストから得られた 27 件すべてのインサイトについては、references/guest-insights.md をご覧ください。

関連スキル

• 顧客インタビュー
• アイデアの検証
• プロダクト実験
• ICP の定義