死んだ機能を防ぐディスカバリーと検証のフレームワーク

Turn this article into takeaways for your work.

Each assistant summarizes the article only for you and suggests best practices for your work.

木曜日の午後4時47分。CROがSlackメッセージを投げ込んできます。「大手のロゴが解約した。彼らはカスタムの承認ルーティングを望んでいた。これを第3四半期のロードマップに載せる必要がある。」金曜日のリーダーシップ同期までに、「カスタム承認ルーティング」はコミット済みの第3四半期の成果物になります。エンジニアが2人引き込まれます。6か月後にリリースされ、最初の60日間でアカウントの9%が触れ、そして実際にどんな問題を解決したのか誰も説明できません。

私はその機能をリリースしたことがあります。2回です。一度はワークフローツールで、一度はCRMで。どちらの場合も診断は同じでした。肩書きを持つ誰かが単一のデータポイントを戦略に変えたために、私たちはディスカバリーを飛ばしたのです。エンジニアリングの四半期はコストではありませんでした。コストは、チームが最も声の大きい顧客のお気に入りの機能を作るのに忙しかったために探索しなかった3つのオポチュニティでした。

誰も定着させないものをリリースし続けているPMなら、このガイドは、3年前に誰かが手渡してくれていたらと思うディスカバリースタックです。

なぜ最初のアイデアのリリースは失敗するのか

Pendoのプロダクトベンチマークは、10年間にわたって気が滅入るほど一貫しています。B2B SaaS製品の機能の60〜70%は、最初の6か月で15%未満の定着しか見られません。一部の調査では、死んだ機能の割合をさらに高く見積もっています。これは単一のチームのバグではありません。それは検証する前に作ることの基準率です。

これをありのままに呼びましょう。60日後に定着率15%未満 = 死んだ機能。 「もっとイネーブルメントが必要」ではありません。「GTMの動きがずれている」でもありません。死んでいるのです。それを必要としたコホートは引っ張らず、必要としなかったコホートは無視し、いまやあなたには永遠に維持すべき対象範囲があります。

死んだ四半期は12週間のエンジニアリング時間ではありません。それは12週間のエンジニアリング時間に加え、PMの時間、デザインの時間、QA、何年も背負うことになる技術的負債、そしてしなかった他の3つの賭けの機会費用です。4人のエンジニアのスクワッドが死んだ機能をリリースすると、フルロードコストでおよそ40万ドルを燃やします。そう何度もそれを許せるものではなく、いずれ財務の誰かがQBRで鋭い質問を始めます。

解決策は「もっとリサーチをする」ではありません。sprintとしてではなく、毎週回るディスカバリーの実践です。

オポチュニティ・ソリューション・ツリー(テレサ・トーレス)

テレサ・トーレスのオポチュニティ・ソリューション・ツリーは、私のプロダクトセンスに最も多くをもたらした唯一のアーティファクトです。その構造は残酷なほどシンプルです。

                Outcome
                   |
         +---------+---------+
         |         |         |
    Opportunity Opportunity Opportunity
         |         |         |
      +--+--+   +--+--+   +--+--+
      |     |   |     |   |     |
    Sol   Sol Sol   Sol Sol   Sol
      |
   Assumption tests

一番上のアウトカム:測定可能な一つのビジネスまたはプロダクトのアウトカム、たとえば「週次アクティブワークスペースを20%増やす」です。機能ではありません。ローンチでもありません。アウトカムです。

オポチュニティは、顧客の言葉で表現された顧客の問題であり、(解決されれば)アウトカムを動かすものです。「新しい管理者はどのプロジェクトが滞っているか分からない」はオポチュニティです。「プロジェクト健全性ダッシュボードを作る」は違います。それはソリューションです。

ソリューションはオポチュニティの下に、各オポチュニティにつき3〜5個あります。安価で、複数あり、互いに明示的に競合します。

前提テストは各ソリューションの下にあります。これらは、そのソリューションが作られるかどうかを決める実際の実験(フェイクドア、プロトタイプ、コンシェルジュ型MVP)です。

ほとんどのチームがツリーで失敗する理由は構造ではなく、それを一度きりのアーティファクトとして扱うことです。Miroのボードに作り、四半期の計画会議で発表し、そして死なせます。ツリーは壁(物理的またはデジタル)に生き続け、毎週その前を通り過ぎるはずのものです。新しいインタビューが起きた?オポチュニティの枝を追加します。前提テストが失敗した?ソリューションを剪定します。アウトカムが変わった?サブブランチごと死にます。

私は毎週木曜日の朝、一人で30分かけてツリーをレビューします。その週に学んだことを追加し、意味をなさなくなったものを葬ります。これをしないと、ツリーは壁紙になります。

継続的ディスカバリー:週に少なくとも3件の顧客インタビュー

トーレスから盗んだルールがこれです。週に少なくとも3件の顧客インタビューをしていないPMは、ディスカバリーをしていない。

計算をするまでは過激に聞こえます。3件のインタビュー × 45週 = 年間135件の顧客との会話です。ほとんどのPMは30件です。パターン認識への複利効果は莫大です。1年目の終わりには、顧客が最初の5分で何を言おうとしているか予測でき、そのときに、漠然とした痛みを探るのではなく、特定の前提に圧力をかけて試すインタビューを実施し始めるのです。

四半期のリサーチsprintはこの正反対です。未知のものをまとめてバッチ化し、リサーチベンダーを雇い、40ページのデッキを受け取り、すでに半分コミットされたロードマップに知見を後付けしようとします。デッキが届くころには、世界は動いてしまっています。

週次のインタビューは3つのことを同時に解決します。

  1. 直近性。 先週聞いた痛みは、前四半期に聞いた痛みに勝ります。
  2. 反復。 昨日聞いたことに基づいてインタビューのスクリプトを調整できます。sprintではそれができません。
  3. ステークホルダーの信頼性。 CROが「顧客はXを望んでいる」と言うとき、あなたは過去3週間で9人と話しており、「実は、そのうち3人がXに触れましたが、より大きなパターンはYでした」と言えます。それは違う会話です。

CSMを燃え尽きさせずにインタビューを募る

募集の問題は現実です。質の順に並べた3つの確かなソースです。

  • アプリ内の募集プロンプト。 シンプルなバナー(「PMです。25分いただけますか?Amazonギフトカード50ドル」)は、B2Bでは週次アクティブのおよそ1〜2%で転換します。週次アクティブが1万人いれば、週に100〜200件の会話が利用可能です。ほとんどのPMは尋ねるのが怖くて、これを決して活用しません。
  • CSMの紹介。 CSMの月次目標に書き込まれたクオータ(「あなたの担当顧客から月に5件の紹介が必要」)を事前に交渉します。クオータがないと、これは3週目で崩れます。
  • 失注インタビュー。 あなたを評価して却下した人々と話します。彼らは現在の顧客が言わないことを話してくれます。失うものが何もないからです。

50ドルのギフトカードは、ほとんどのICPセグメントにとって適切な閾値です。それ以下だと、ただ雑談したいだけの冷やかしが集まります。100ドルを超えると、財務が質問を始めます。エグゼクティブのペルソナ(従業員500人超の企業のVP以上)には、通常150〜200ドルか慈善寄付が必要です。50ドルは彼らにとって侮辱になるからです。

何がインタビューに数えられるか

顧客インタビューはセールスのディスカバリーコール、CSMのチェックイン、デモではありません。PM主導のインタビューには一つの仕事があります。特定の過去の行動や痛みを理解することです。スライドを見せたり、デモをしたり、何かを売り込んだりしているなら、あなたはインタビューをしていません。売っているのです。一時停止して、やり直しましょう。

前提マッピング

すべてのプロダクトアイデアは、4つのバケツの前提の上に成り立っています。デイビッド・ブランドの前提マッピングフレームワークは、Testing Business Ideasで広まり、IDEOの古典的な望ましさ・実現可能性・成立性のレンズを借り、使いやすさを加えています。

前提のタイプ 質問
望ましさ 顧客は本当にこれを望んでいるか? 「マーケティングマネージャーはSlackネイティブの承認フローを望んでいる」
成立性 これはビジネスとして筋が通るか? 「ベースに上乗せして1席20ドルを課金できる」
実現可能性 実際に作れるか? 「8週間未満でSlackのエンタープライズグリッドと連携できる」
使いやすさ ユーザーは使い方を理解できるか? 「初回ユーザーはサポートなしでセットアップを完了する」

各前提について、2つの軸でスコアをつけます。

  • リスク。 この前提が間違っていたら、アイデア全体が崩壊するか?
  • 証拠。 いま、どれだけの実際の証拠があるか?(意見ではありません。「これについて話し合った」でもありません。証拠です。)

それらを2×2にプロットします。右上の象限(高リスク、低証拠)が、最初にディスカバリーの作業を集中させる場所です。アイデアを葬りうる最も安価なテストを最初に。 望ましさが揺らいでいるなら、何かを作る前にフェイクドアを実施します。実現可能性が決定打なら、6週間のMVPではなく2日のスパイクを作ります。

私は前提マップを、オポチュニティ・ソリューション・ツリーと同じMiroのボードの、一つ右のフレームに置いています。すべてのソリューションの枝が、その上位3つの前提を指しています。前提がテストされて反証されると、赤で線を引いて消し、ソリューションは格下げされるか葬られます。

フェイクドア / スモークテスト

フェイクドアは、私が回す中で唯一最もレバレッジの高いディスカバリーツールです。前提はこうです。機能の裏側を作らずに、機能への入口だけを作ります。誰かがクリックするか測定します。クリックしなければ、コードが1行も書かれる前にその機能は死にます。

実際にどう機能するか。

  1. 能力を約束するボタン、メニュー項目、またはアプリ内カードを追加します。たとえば「定期レポートのスケジュール設定」です。
  2. ユーザーがクリックしたら、メールアドレスと一行の「これを何に使いますか?」を取得する「近日公開、早期アクセスを希望しますか?」のフォームを表示します。
  3. それを見たコホートに対するクリックスルー率を追跡します。

私が実際に使う閾値

これらは3つの企業にわたって私が較正した数値です。あなたの結果は異なるでしょうが、出発点にはなります。

クリックスルー率 判断
露出ユーザーの5%以上 強いシグナル:プロトタイプ検証へ進む
2〜5% グレーゾーン:クリックした人々と話し、何を期待していたか突き止める
2%未満 葬る:需要がそこにない

5%の閾値が重要なのは、それが明確な痛みに対処する機能のエンジニアリング投資を正当化できるおおよその割合だからです。2%未満では、50人に1人の挙手者を追いかけており、たとえクリックした全員が転換しても、意味のあるビジネスのアウトカムを動かすにはコホートが大きくありません。

倫理的なガードレール

顧客に嘘をついてはいけません。「近日公開」のフォローアップ状態は必須で、例外はありません。さらに2つのルールです。

  • クリックした全員に必ずメールする。 たとえ答えが「これは作らないことに決めました」であってもです。代わりに何をしているか伝えます。これには20分かかり、あなたが今後実施するフェイクドアを守ります。
  • 決して作らないもののためにフェイクドアを実施しない。 純粋な好奇心の発掘をしているなら、インタビューをしましょう。フェイクドアは検証ツールであって、市場調査アンケートではありません。

私はかつて、エグゼクティブチームが6か月間推していた機能をフェイクドアの段階で葬りました。「予測的リードスコアリング」のアップセルモジュールです。1,400人のミッドマーケットの管理者のコホートに入口をローンチし、セールスの逸話に基づいて少なくとも8〜10%のCTRを期待しました。結果は1.7%でした。23人のクリック者のうち14人は、「予測的リードスコアリング」が私たちが作ろうとしていたものとは全く違う意味だと思っていました。私たちは金曜日にその機能をロードマップから外し、スクワッドを別のオポチュニティに振り向け、新しい賭けは6か月後に定着率41%でリリースされました。フェイクドアにかかったのはデザインと開発の4日間でした。その機能なら四半期がかかっていたでしょう。

プロトタイプ駆動の検証

フェイクドアが5%のバーをクリアすると、需要を証明したことになります。ソリューションが機能することは証明していません。それはプロトタイプの仕事です。

私はテストしている前提にプロトタイプの忠実度を合わせます。

  • Figmaのクリックスループロトタイプ。 使いやすさと情報アーキテクチャをテストするため。Mazeの非モデレートテストでテストした5人のユーザーが、最も致命的なUXの問題のほとんどを浮かび上がらせます。コスト:デザインの1〜2日。
  • コンシェルジュ型MVP。 実現可能性やワークフローの前提が決定打のとき、5〜10人の顧客のために手作業で作業をします。顧客が自動化された競合分析レポートを望むなら、最初の10件を手で生成してメールします。3週目までに顧客がメールを開かなくなったら、根底にある価値はそこにありません。
  • オズの魔法使い。 フロントエンドは本物、バックエンドは人間です。本物のインフラを構築せずに行動データ(ユーザーは実際にファイルをアップロードするか?戻ってくるか?)を検証する必要があるときに有用です。
  • ハードコードされた垂直スライス。 本物だが狭い構築。一つのペルソナ、一つのワークフロー、醜いが機能的。10〜20社のデザインパートナーにリリースします。これは本物のエンジニアリング投資の前の、最後の安価なテストです。

レベルを飛ばさないでください。間にフェイクドアとプロトタイプを挟まずに、「CROが求めた」から「垂直スライス」へ飛ばないでください。飛ばした各レベルは、前提が間違っていた場合のあなたの被害半径の乗数になります。

マムテスト(証人を誘導しない)

ロブ・フィッツパトリックのThe Mom Testは、他のどの単一のリソースよりも私のインタビューの実践を直しました。前提はこうです。人々はインタビューであなたに嘘をつきます。特にあなたを気に入っているときに。あなたの仕事は、自分の母親からさえ真実を引き出す質問をすることです。

3つのルールです。

  1. あなたのアイデアではなく、彼らの生活について話す。 「月曜の朝の最悪の部分は何ですか?」は「月曜の朝を直すツールを使いますか?」に勝ります。最初の質問はおだてられません。2つ目はおだてられます。
  2. 未来についての一般論ではなく、過去の具体について尋ねる。 「これが最後に起きたときのことを教えてください」は「Xをしますか?」に勝ります。過去の行動はデータです。未来の意図は空想です。
  3. 話すより聞く。 良いインタビューは80%が相手、20%があなたです。あなたが自分のプロダクトを説明しているなら、それで終わりです。通話を終え、メモを取り、次回はもっとうまくやりましょう。

PMのインタビューで私が目にする最も有害なアンチパターンは、ディスカバリーを装ったデモです。「顧客から学ぶ」ために30分の通話を予約します。20分後、あなたはモックアップを3つ見せ、「これは役に立ちますか?」と尋ねています。相手はイエスと言います。礼儀正しいから、混乱しているから、通話を終わらせたいからです。あなたはメモに「検証インタビュー」と記録します。あなたは機能をリリースします。それは死にます。

ディスカバリーコール中にFigmaを開いている自分に気づいたら、電話を切ってやり直しましょう。それはインタビューではありません。売り込みです。

ディスカバリーのスレッドを葬るタイミング

自分のアイデアを葬ることは、プロダクトで最も難しいスキルです。3つのシグナルが、スレッドが死んでいることを教えてくれます。

  • 前提テストが3回連続で失敗。 フェイクドアが2%未満、5人でテストしたプロトタイプで3人が詰まった、コンシェルジュ型MVPで再利用が見られなかった。それは不運ではありません。宇宙があなたに止めろと告げているのです。
  • 6〜8回の会話の後、インタビューから引きがない。 ある問題について8人の顧客と話して、一人も「はい、これは私たちが対価を払って解決したい本物の痛みです」と自発的に言わなかったなら、オポチュニティはそこにありません。インタビュー対象者は1〜2回の会話では当たり障りなく話します。8回までには、パターンは正直になります。
  • オポチュニティのスコアが閾値を下回る。 私はツリー内のすべてのオポチュニティを3つの次元でランク付けします。頻度(痛みがどれだけ頻繁に起きるか)、深刻さ(起きたときどれだけ悪いか)、リーチ(ICPの何%が感じるか)です。1か月のディスカバリーの後、3つのうち2つが弱ければ、枝は死にます。

スレッドを葬るとき、私は1ページの葬りメモを書きます。政治のためではありません。6か月後の自分のためです。誰かがアイデアを蘇らせたときに、なぜそれを保留にしたか思い出す必要があるからです。テンプレートです。

Idea: [name]
Opportunity it was meant to address: [opportunity from tree]
Assumptions tested: [list]
Evidence collected: [bullets]
Reason killed: [the specific failure]
What we'd need to see to revisit: [the conditions]
Date: [YYYY-MM-DD]

葬りメモは、オポチュニティ・ソリューション・ツリーと同じNotionのフォルダに置きます。CROが6か月後に戻ってきて「予測的リードスコアリングはどうなった」と尋ねたら、私はそのメモを送ります。同じ議論を繰り返す2週間ではなく、2分の会話です。

私の週次ディスカバリーのリズム

出発点のテンプレートとして役立つかもしれないので、私が回しているリズムをご紹介します。

  • 月曜の朝。 その週の3つのインタビュー枠が予約されます。私はそれらを確認し、質問を準備し、インタビュートラッカーを更新します。募集はアプリ内プロンプト(継続的に実施)とCSMの紹介を通じて行われます。
  • 火曜〜木曜。 インタビューが各45分で行われます。メモはDovetailに入ります。ハイライトリール(記録ではなく5分のクリップ)がエンジニアとデザインに共有されます。エンジニアは実際にクリップを見ます。
  • 木曜の朝。 一人でのオポチュニティツリーのレビュー。30分。新しいオポチュニティを追加し、死んだ枝を剪定します。前提マップを更新します。
  • 金曜の午後。 sprintごとに1つの前提テストがリリースされます(フェイクドア、プロトタイプ、またはコンシェルジュ型MVP)。金曜は次のsprintのテストの仕様を書くときです。

それだけです。四半期のリサーチsprintはなし。40ページのデッキもなし。週に3件のインタビュー、一つのオポチュニティツリー、sprintごとに一つの前提テスト。退屈な規律は、劇的な努力に毎回勝ります。

私が最も尊敬するPMたちは、私たちより優れた直感を持っているわけではありません。彼らはより優れたディスカバリーの実践を持っています。彼らは今年135人の顧客と話し、26のフェイクドアを実施し、18のアイデアを葬り、生き残った4つをリリースしました。だから彼らの機能が40%の定着に当たる一方で、他のみんなは9%を見つめているのです。

より大きな予算や、より多くのリサーチャーは必要ありません。来週のカレンダーに3つのインタビュー枠と、四半期が騒がしくなってもそれを予約し続ける規律が必要です。そこから始めましょう。

さらに詳しく

About the author

Camellia

Camellia

Principal Product Marketing Strategist

Camellia is Principal Product Marketing Strategist at Rework, helping B2B buyers pick the right software with confidence. With 6+ years in product marketing and 150+ SaaS tools evaluated across CRM, project management, and sales engagement, Camellia turns competitive intelligence into clear, honest comparisons. Readers get vendor evaluations they can trust to cut through marketing noise and decide faster.