CB Insightsは毎年、スタートアップが失敗する理由の分析を発表しています。長年にわたって、第一位の理由は変わりません。それは「市場ニーズがなかった」というものです。実行力の問題でも、資金不足でも、チームの問題でもありません。プロダクトが、人々が行動を変えるほど重要な問題を解決していなかったのです。
この統計は、プロダクト開発にかけられる膨大な努力を考えると驚くべきことです。チームは何ヶ月も、時には何年も、システムの設計、コードの記述、アーキテクチャの議論、フローの改善に費やします。それでも最も多い失敗の原因は、それが本当の問題を解決しているかどうかを誰も確認しなかったことです。
人々が本当に求めるプロダクトを作ることは、才能ではありません。それは規律です。方法論があり、その方法論は学ぶことができます。
最も多いプロダクトの失敗は、問題を深く理解する前にソリューションに恋をしてしまうことです。これは初めての創業者にほぼ普遍的に見られ、経験豊富な創業者にも驚くほど多く見られます。パターンは常に同じです。誰かがアイデアを持ち、それを魅力的と感じ、作り始めます。顧客は後から考えること——理解すべき対象ではなく、説得すべき対象として扱われます。
解決策は複雑ではありませんが、規律が必要です。ソリューションを考える前に、適切だと思う以上の時間を問題に費やしてください。その問題を抱える人々と話してください。彼らが働く様子を観察してください。現在の回避策と、その回避策が不完全な理由を理解してください。そこで初めて、本当にフィットするものを設計するのに十分なコンテキストが得られます。
優れたプロダクト開発は一直線ではありません——それはループです。ループを一周するたびに、仮定を証拠に置き換えるチャンスがあります。人々が求めるプロダクトを作るチームは、このループを素早く、頻繁に回すチームです。
このループは形式的なものではありません。各ステージには特定のアウトプットがあり、それが次のステージへのインプットになります。ステージを飛ばすこと——最もよくあるのは、問題から直接「作る」へ進むこと——が、的外れなプロダクトを生む原因です。
すべての問題が解く価値があるわけではありません。良いプロダクトの問題には3つの特質があります。頻繁であること（稀ではなく、人々が頻繁に直面する）、強烈であること（人々がそれを十分に感じており、解決を望んでいる）、そして既存のソリューションが本当に不十分であること（あなたが作りたいものとわずかに違うだけでなく）。
よくある失敗は、最初の特質を最適化し、残りの2つを無視することです。「人々は会議で時間を無駄にしている」は頻繁です。しかし痛みが低ければ——人々が十分な回避策を見つけているなら——その問題は商業的に解く価値がないかもしれません。そして既に12のツールがあなたがやりたいことをやっているなら、あなたのものが選ばれる非常に具体的な理由が必要です。
リサーチはプロダクト業界で悪い評判を持っています——遅いコンサルタント会社、厚い報告書、誰も読まない調査結果と結びついています。これは実行の失敗であって、実践そのものの失敗ではありません。良いプロダクトリサーチは速く、具体的で、何を作るかを変えます。
リサーチの目的は問題が実在することを確認することではありません。それはリサーチに大きく投資する前にすでに信じているべきことです。目的は問題を十分に深く理解して、良いソリューションがどのようなものかを知ることです。具体的に誰が問題を抱えているか、どんな文脈で、これまでに何を試したか、それをどんな言葉で表現するか、そして「解決された」状態が彼らにとってどのようなものかを把握することです。
仮説とは、真実だと信じることについての具体的で反証可能な予測です。それは明確さを強制します。明確な仮説を書けないなら、まだ問題を十分に理解していないのでソリューションを作る準備ができていません。
有用なプロダクト仮説には3つの部分があります：
シグナルが最も重要な部分です——そして最もよく省略される部分です。事前に確定したシグナルがなければ、あらゆる実験が「まあまあうまくいった」になります。チームは曖昧なデータを好意的に解釈する方法を見つけます。反証条件のない仮説は単なる希望です。
「作る」フェーズは、ほとんどのチームが時間をかけすぎるところです。目標はプロダクトを作ることではありません——仮説についてシグナルを得るための最小のものを作ることです。これらは異なる目標であり、全く異なるアウトプットを生み出します。
ほとんどの初期段階の仮説にとって、最小のものはチームが考えるよりもはるかに小さいです。ソフトウェアがすることを手動で10人に対してやって、彼らが結果に価値を見出すかを検証できますか？新しいインフラを作る前に既存のツールをつなぎ合わせてワークフローをテストできますか？コードを書く前にプロトタイプをスケッチして5人のユーザーと試せますか？
ここでの規律は、何かを作る前に「何を学ぼうとしているか？」と「それを学ぶための最小のものは何か？」を問うことです。答えはほぼ常に、チームが作りたいものより小さいです。
ローンチ後——それがプロトタイプ、手動パイロット、デプロイされた機能であれ——計測フェーズはチームが最もよく自分を欺くところです。ユーザーに気に入ったかを聞きます。ユーザーはイエスと言います。チームは実験が検証されたとマークします。
感情はシグナルではありません。唯一の信頼できるシグナルは行動です。人々はそれをしましたか？また来ましたか？支払いましたか？誰かに話しましたか？
定量的な計測のために、ローンチ前に計装してください。追跡している具体的なアクションを把握してください。事前に閾値を設定してください——「Z日以内にX%のユーザーがYを完了すれば検証されたと見なす」。定性的な計測のために、オープンエンドの満足度調査ではなく、構造化されたフォローアップインタビューを実施してください。
学ぶフェーズは、ユーザーと問題についての精神的モデルを更新することであり、次に何を作るかを決めるだけではありません。このステップを飛ばすチームはデータを収集しますが、理解を積み重ねません。素早く実行しますが、時間とともに判断力は向上しません。
良い学習セッションでは次のことを問います。何を予測しましたか？実際に何が起きましたか？そのギャップは私たちの仮定について何を教えてくれますか？今最も知らなければならない重要なことは何ですか？
学ぶフェーズのアウトプットは、より鋭い問題定義、修正された仮説、または——実験が明らかに失敗した場合——全く異なる方向を追求する決断です。これらすべての結果は価値があります。最悪のアウトプットは曖昧さです。「いくつかのことを学んだが、次に何をすべきか分からない。」これは実験が十分に具体的でなかったサインです。
プロダクト開発がこのループを止める段階に到達することはありません。問いは変わります——初期は問題が本物かを検証しており、後期は特定のソリューション要素が機能しているかを検証しています——しかし構造は常に同じです。観察し、仮定し、検証し、学ぶ。
人々が求めるプロダクトを作るチームは、最も賢い初期洞察を持つチームではありません。ループを最も速く、最も誠実に回すチームです。出荷の速さではなく、学習の速さが競争優位性です。