11.1 ディスカバリーパイプライン

概要と動機

ディスカバリーパイプラインは、デリバリーの前に、そして並行して、何を築くか、なぜかを決め、成功がどう見えるかを定義する仕事のフローです。デリバリーパイプライン(11.2章)が検証されたアイデアを動くソフトウェアに変えるのに対して、ディスカバリーパイプラインは、問題、証拠、戦略を、優先順位づけされテスト可能な意図した成果の集合に変えます。現代の実践では、二つは順次の段階としてではなく、しばしばデュアルトラック開発と呼ばれる形で、継続的に並行して走ります。ディスカバリーはデリバリーに、リスクが下げられよく枠づけられた仕事の用意された供給を与え続け、デリバリーはディスカバリーに、現実の成果データをフィードバックし続けます。

大きなチームにとって、弱いディスカバリーパイプラインは、ソフトウェアで最も高くつく失敗の様式です。優れたデリバリーと貧しいディスカバリーを持つチームは、間違ったものを効率的に築きます。速く出荷し、ベロシティの目標を達成し、それでもどの事業指標も動かしません。そのコストはエンジニアリングのダッシュボードでは見えず、貸借対照表では莫大です。ディスカバリーパイプラインは、そのコストを可視にする方法です。大きな投資をコミットする前に、目標が明示的で、測定可能で、反証可能であることを強います。

企業と政府の文脈は、賭け金を引き上げます。企業は共有の戦略に対して数十のチームを調整するので、ずれた局所的な目標は無駄にされたポートフォリオへと複合します。政府のプログラムは、法定の義務づけに対して複数年の公的資金をコミットし、成果(仕えられた市民、減った待ち時間、防がれた不正)が実現しないなら、「契約が言ったものを築いた」は弁明になりません。目標、尺度、明示的な品質要件を通じて表現される規律あるディスカバリーパイプラインは、どちらにとっても意図を監査可能に保つ方法です。

主要原則

アウトプットよりアウトカム。 出荷する機能ではなく、ユーザーと事業のために生む変化を測定します。
意図を明示的で測定可能にする。 測定できない目標は、管理できない意見です。
築く前にリスクを下げる。 最も安い実験が、最も自信のある意見に勝ります。
ディスカバリーとデリバリーは、順次のゲートではなく、継続的に並行して走る。
品質特性は後付けではなく要件である。 信頼性、セキュリティ、アクセシビリティは、願うのではなく、発見され仕様化されます。
整合は局所最適に勝る。 入れ子の目標が、チームの仕事を戦略につなげます。
ループを閉じる。 届けられた成果は、ディスカバリーに再び入る証拠です。

推奨事項

OKRで方向を枠づける

戦略をチームの実行につなげるために、目標と主要な結果(OKR)を使います。目標は、望む終状態の定性的で鼓舞する記述です(「初めてのオンボーディングを楽にする」)。主要な結果は、目標が達成されつつあることを証明する、少数(通常2–4)の測定可能な成果です(「7日間のアクティベーションを40%から60%に上げる」「オンボーディングのサポートチケットを30%減らす」)。主要な結果は成果を表現し、タスクではありません。「新しいウィザードを出荷する」は、結果を装ったタスクです。

OKRを命令ではなく整合でカスケードします。リーダーシップは少数の会社の目標を設定し、チームはそれらに積み上がる主要な結果と自分の目標を提案します。定期的な周期(年次の枠のもと、通常は四半期)で設定し、サイクルの途中でレビューし、最後に誠実に採点します。人事評価とは別に保ちます。報酬のために採点されるOKRは、すぐに甘く設定されます。OKRがポートフォリオとプログラムの管理にどうつながるかは、10.1章を参照してください。

KPIで健全性を監視する

重要業績評価指標(KPI)をOKRから区別します。OKRはこの期間に望む変化を記述し、KPIは、何を変えているかにかかわらず維持しなければならない継続的な健全性(稼働率、コンバージョン率、取引あたりのコスト、顧客満足)を記述します。指標はその両方でありえます(積極的に動かそうとしているKPIは主要な結果になります)が、ほとんどのKPIは、向かってスプリントする目標ではなく、監視するガードレールです。

すべての重要な指標を、先行(今予測的で対処可能。トライアルのサインアップなど)か遅行(確認的で遅い。年間収益など)かに分類します。ディスカバリーは、遅行指標が確認する前に舵を取るために、先行指標に頼ります。確実に上がるが何も予測しない虚栄の指標(生のページビュー、登録ユーザー総数)に注意し、ゲーム化に強い比率やコホートの指標を好みます。これらの尺度の背後の分析と実験の仕組みは、7.3章と7.4章を参照してください。

システムの品質特性を明示的に仕様化する

機能要件は、システムが何をするかを述べます。システムの品質特性(「-ility」:信頼性、パフォーマンス、スケーラビリティ、セキュリティ、アクセシビリティ、保守性、運用性)は、それがどれだけうまくしなければならないかを述べます。これらは日常的に十分に発見されません。全員が想定し、誰も仕様化せず、本番のインシデントとして表面化します。それらを第一級のディスカバリーの出力として扱います。各取り組みについて、アーキテクチャ上重要な要件(アーキテクチャを実質的に形づくる品質の要求)を特定します。それらを定量化します(「現在の10倍の負荷でp99レイテンシが200ミリ秒未満」「WCAG(ウェブコンテンツアクセシビリティガイドライン)2.2 AA」「復旧時間目標15分」)。そして可能な所では、デリバリーパイプラインがチェックできる自動のフィットネス関数(品質特性を継続的に検証する実行可能なチェック)としてそれらを符号化します。これは、3.1章(アーキテクチャの基礎)と3.5章(スケーラビリティ、パフォーマンス、レジリエンス)のディスカバリー側の補完です。

すべての目標をSMARTにする

主要な結果、受け入れ基準、品質目標のいずれを書くときも、SMARTのテストを適用します。

Specific(具体的): 一つの明確で曖昧でない成果を名指しする。
Measurable(測定可能): 指標と真実の源を持つ。
Achievable(達成可能): 制約と証拠に照らして現実的。
Relevant(関連性): より高い目標とユーザーの価値に積み上がる。
Time-bound(期限付き): 期限あるいは見直し日を持つ。

「パフォーマンスを改善する」はすべての文字に失敗します。「Q3の終わりまでに、モバイルユーザーのチェックアウト時間の中央値を8秒から3秒に減らす。リアルユーザーモニタリングで測定」は五つすべてに合格します。SMARTの基準は、曖昧な野心を、ディスカバリーがテストでき、デリバリーが検証できる反証可能な主張に変えます。

継続的で証拠に基づくディスカバリーを行う

ディスカバリーを、一回限りの段階ではなく、繰り返し可能なパイプラインとして構造化します。

感知する。 シグナルを集めます。ユーザー調査、サポートデータ、分析、市場とコンプライアンスの入力。
枠づける。 機会を地図にします(機会ソリューションツリーは、望む成果を、それを動かしうるユーザーのニーズと候補の解決策につなげます)。
仮説を立てる。 前提を反証可能な主張として述べます。「[変更]が[セグメント]に[成果]を引き起こすと信じ、[尺度]が動けばそれがわかる」。
実験する。 最もリスクの高い前提を最も安いテストで検証します。インタビュー、プロトタイプ、フェイクドアのテスト(まだ築かれていない機能を宣伝して本物の需要を測る)、A/B実験(二つのバリアントの無作為化された比較、7.4章)。
決める。 続行、転換、断念を決め、生き残ったものを、SMARTな成功基準を添えてデリバリーの積み残しに供給します。

ディスカバリーパイプラインの出力は機能の一覧ではありません。デリバリーの準備ができた、検証された測定可能な賭けの流れです。

トレードオフ: 長所と短所

アプローチ	長所	短所
アウトカムベースの目標(OKR)	チームをインパクトに揃える。どうやるかの自律を与える	うまく書くのが難しい。タスクで埋めたくなる。帰属が雑音混じり
アウトプット/機能のロードマップ	予測可能で、伝えやすく契約しやすい	出荷にインパクト以上に報いる。間違ったものというリスクを隠す
重い事前のディスカバリー	築く無駄を減らす。強い要件	開始が遅い。分析麻痺のリスク。前提は依然としてテストされない
継続的なデュアルトラックのディスカバリー	継続的にリスクを下げる。速いフィードバック	調査の容量と規律が必要。スケジュールしにくい
SMARTな目標としての明示的な品質特性	「-ility」の驚きを防ぐ。監査可能	定量化の労力。早期の探索を過度に制約しうる

中心的な緊張はコミットメント対学びです。企業、特に政府は、予算と契約のために確固たるコミットメントを必要とすることが多く、それがアウトプットのロードマップへと引っ張ります。良い成果には学ぶ余地が必要で、それがOKRと実験へと引っ張ります。こう解決してください。問題と成果にはしっかりとコミットし、解決策は緩やかに保つ。

チームで議論すべき問い

チームでは実際に誰がディスカバリーを所有していて、一回限りのスプリントではなく継続的に行う容量がありますか。 デュアルトラック開発は、四半期の初めだけでなく、毎週誰かがディスカバリーのトラックを開けておく場合にだけ機能します。大きな組織では、ディスカバリーに専任の所有者がいないことが多く、手の空いた誰かに崩れ、それは誰でもなく、チームは築くことに既定で向かいます。証拠を持ち込んでください。最後の十の機能のうち、築く前に文書化された仮説と安いテストを経た数と、まっすぐ積み残しに入った数を数えます。一つの不一致な取り組みが複数のチーム四半期を無駄にしうる企業と政府の設定では、感知、枠づけ、仮説、実験、決定のループに説明責任を負うプロダクトオーナーあるいはトリオ(プロダクト、デザイン、エンジニアリング)を名指ししてください。誰も所有していないなら、他の何かを議論する前に人員を置いてください。
現在の取り組みのうち、定量化したことのないアーキテクチャ上重要な要件を持つものはどれで、いずれかをフィットネス関数として符号化できますか。「-ility」(信頼性、パフォーマンス、セキュリティ、アクセシビリティ)は想定されて、本番のインシデントとして表面化します。各アクティブな取り組みを歩き、どの品質特性がアーキテクチャを実質的に形づくるかを尋ね、それぞれに数字と真実の源があるかを確認します。「10倍の負荷でp99が200ミリ秒未満」「WCAG 2.2 AA」「復旧時間目標15分」。企業と政府にとって、定量化されないアクセシビリティやセキュリティの要件は、直接の法的と監査の露出を生みます。持ち込むべきシグナルは最後の三つのインシデントです。誰も仕様化しなかった品質特性にさかのぼるものはいくつありましたか。目標をデリバリーパイプラインがチェックする自動のフィットネス関数に変えられる所では、そうしてください。仕様化されたが徹底されない目標はずれるからです。
最後に解決策にコミットしたとき、最もリスクの高い前提を最初にテストしましたか。それとも最も容易なものですか。 チームは、最も快適な前提を確実に検証し、実際にアイデアを殺しうるものを飛ばします。各取り組みについて、前提(望ましさ、事業性、実現可能性)を一覧にし、「ここで間違っていたらそのアイデアはどれだけ死ぬか」で順位づけ、その一覧の最上位に最も安いテストを向けてください。自信のある上級のチームは、四半期のエンジニアリングを検証されていない信念にコミットしえ、そのコストはローンチまで見えないので、規模ではこれが重要です。成果物を持ち込んでください。「[変更]が[セグメント]に[成果]を引き起こすと信じ、[指標]で測定する」と述べられた最後の仮説で、それをテストしたのか、単に築いたのかを尋ねます。最もリスクの高い前提を名指しできないなら、築く容量をコミットする準備ができていません。
主要な結果のうち、本物の成果はいくつで、成果の服を着たタスクや出荷日はいくつですか。 アウトカムベースの計画における最も一般的な失敗は、主要な結果を、その仕事が引き起こすはずの変化(「7日間のアクティベーションを40%から60%に上げる」)ではなく、すでに計画していた仕事(「新しいウィザードをローンチする」)で埋め戻すことです。規模では、これは要点全体を静かに無効にします。全員が出荷で自己採点しているので、どの事業指標も動かないまま、数十のチームが緑と報告します。相反する引力は本物で、アウトプットのロードマップは、伝えやすく、契約しやすく、予測しやすく、まさにそれゆえに忍び戻ってきます。現在のOKRの集合を持ち込み、各主要な結果を成果か成果物かに印を付け、それからOKRの採点が報酬と絡んでいないかを確認してください。報酬に結びついた結果はすぐに甘く設定されます。資金が述べられた目標に対してコミットされる企業と政府のポートフォリオでは、成果の尺度のない成果物のロードマップは、起こるのを待っている監査の指摘です。各取り組みが、問題と測定可能な成果にしっかりとコミットしながら、解決策は緩やかに保つよう主張してください。
製品が悪くなっていても上がり続けるKPIはどれで、積極的に動かそうとしている指標を何のガードレールが守っていますか。 目標に引き上げるすべての指標はグッドハートの法則を招きます。尺度が目標になると、人々はそれが表すはずだったものではなく、尺度を最適化します。虚栄の指標(生のページビュー、累積の登録ユーザー)は確実に上がり何も予測せず、ガードレールなしに追われる単一の主要な結果は、名指ししなかった何かを劣化させて達成されうるのです。緊張は、先行指標が早く舵を取れるが雑音が多くゲーム化されうる一方、遅行指標は信頼できるが確認が遅すぎて行動できないことです。先行か遅行か、目標かガードレールかで分類した指標の目録を持ち込み、「賢いチームが、製品を悪くしながらこの数字を達成するにはどうするか」と尋ねて、各目標をストレステストしてください。規制対象と公共の設定では、監督機関が見出しの指標しか見なければ、本物の公共の価値とゲーム化された数字を見分けられないので、ガードレールを目標と並べて公表してください。
デリバリーが何かを出荷したとき、現実の成果は実際にどうディスカバリーに再び入りますか。それともループは開いたままですか。 デュアルトラック開発は、届けられた成果が次のラウンドの証拠としてフローバックする場合にだけ複合します。ループが開いたままだと、チームは出荷し、祝い、賭けが報われたかを決して学ばないので、同じテストされていない前提が繰り返されます。大きな組織では、フィードバックの経路は責任が隙間に落ちる可能性が最も高い所です。デリバリーはリリースを所有し、分析はダッシュボードを所有し、約束された主要な結果と観察されたものを比較するのは誰も所有しません。最後の十の出荷された取り組みを持ち込み、それぞれについて、誰かが成果の指標を元のSMARTな目標に照らして確認したか、その確認が後の決定を変えたかを尋ねてください。複数年の資金をコミットする企業と政府のプログラムでは、指標を動かせなかった機能を退役させ、範囲を見直すための周期と所有者を名指ししてください。誰も見直さない出荷された機能は、説明責任のあるレビューなしの恒久的なコストになるからです。

セクター別の視点

スタートアップ。 小さなチームでわずかな滑走路なら、ディスカバリーパイプラインは意図して軽量ですが、決して飛ばされません。1日の顧客インタビューとフェイクドアのテストは、間違った構築が燃やす数週間に比べ、ほとんどコストがかかりません。中核の価値を代表する先行指標を一つ選び、各賭けを単一の反証可能な仮説として述べ、コードを書いた後ではなく書く前にアイデアを殺します。5人では正式なOKRは過剰です。サイクルごとに一つの誠実な測定可能な成果で、速度が進捗なき動きにならないように保つには十分です。

小規模事業者。 専任の研究者やプロダクト分析者はおそらくいないので、ディスカバリーを役割ではなく習慣として扱ってください。本物の顧客との少数の構造化された会話と、すでに集めている単純な指標。ほとんどの品質特性(信頼性、セキュリティ、アクセシビリティ)は、自分で仕様化して徹底するより、評判の良いベンダーから得るほうが安いので、築くか買うかの問いが支配的です。購入したツールや小さな構築が実際に成果を動かしたかがわかるよう、一つか二つのSMARTな目標を書き、誰も望むと検証していない機能に乏しい予算をコミットするのを避けます。

大企業。 規模はディスカバリーを、数十のチームにわたる調整の問題に変えます。共有のOKRの周期と「成果」の共通の定義がなければ、局所的な目標はずれて重複し、ずれた賭けは無駄にされたポートフォリオへと複合します。アーキテクチャ上重要な要件をどう定量化するかを標準化し、品質特性が想定ではなく統治されるよう、フィットネス関数として符号化します。ディスカバリーを、明示的な打ち切りの基準と、届けられた成果の指標を次のサイクルにフィードバックするループを伴うポートフォリオとして管理し、リーダーシップが機能の積み残しではなくインパクトで舵を取れるようにします。

政府。 調達と複数年の資金は確固たるコミットメントを要求し、それがアウトプットの契約へと強く引っ張りますが、公共の価値は成果に住みます。仕えられた市民、削られた待ち時間、減った負担。プログラムを測定可能な公共の成果と、交渉の余地のない品質特性(WCAGのアクセシビリティ、平易な言葉、セキュリティ)を軸に枠づけ、支援技術のユーザーでのユーザビリティテストを含むディスカバリーの証拠を、監督機関が監査できる記録の一部にします。成功を、納品されたモジュールではなく納税者や市民の成果として定義し、「契約が言ったものを築いた」が、実現しなかった結果の代わりには決してなれないようにします。

事例

スタートアップ。 美容院向けのスケジューリングアプリを築く4人のシード段階のチームは、数人の声の大きいユーザーが求めたので、オンライン予約のウィジェットを築きたい誘惑にかられます。代わりに1週間のディスカバリーを行います。5人のオーナーへのインタビュー、マーケティングサイトの「オンラインで予約」のフェイクドアのボタン、一つの先行指標(無断キャンセルに終わる予約の割合)。インタビューとクリックのデータは、本物の痛みは予約ではなく無断キャンセルだと明らかにするので、SMARTな主要な結果を一つ書き(今四半期、パイロットの美容院で無断キャンセルを22%から10%未満に減らす)、小さな預り金とリマインダーの機能を先に出荷し、予約ウィジェットは1行も書く前に取りやめます。

大企業。 小売銀行の決済グループは、機能数のロードマップを三つの四半期OKRに置き換え、その一つが「日常の決済を瞬時に感じさせる」で、p95の送金確認時間、初回成功率、決済関連のサポート問い合わせの主要な結果を伴います。システムの品質特性は前もって仕様化され(99.99%の可用性、1秒未満の確認、PCI-DSS(Payment Card Industry Data Security Standard)の範囲の最小化)、フィットネス関数としてデリバリーに配線されます。ディスカバリーは、エンジニアリングをコミットする前に、毎週の顧客インタビューとフェイクドアのテストを行います。二つの候補機能が先行指標を動かせずにディスカバリーで取りやめられ(見積もり2四半期分の築く労力を節約)、一方、より小さく地味なレイテンシの修正が主要な結果を最も動かします。

政府。 オンライン申告を近代化する国の税務当局は、プログラムの目標を「一般の納税者の申告の負担を減らす」と設定し、SMARTな主要な結果を伴います。申告までの時間の中央値を45分から20分に削る、セルフサービスの完了成功を60%から85%に上げる、そして交渉の余地のない品質特性としてWCAG 2.2 AAと平易な言葉の標準を満たす。KPI(申告期間中の稼働率、コールセンターの量)はガードレールとして監視されます。ディスカバリーは、各リリースの前に、支援技術のユーザーを含む本物の納税者での司会付きユーザビリティテストを使います。成功が納品されたモジュールではなく納税者の成果として定義されるので、プログラムは単に支出ではなく、測定可能な公共の価値を監督機関に示せます。

ビジネスケース: 動機、ROI、TCO

ディスカバリーパイプラインの見返りは、避けられた無駄に支配されます。大きな技術企業での管理された実験のプログラムにも反響する業界の経験は、築かれた機能の大きな割合、しばしば半分以上と引用されるものが、測定可能な改善を生まない、あるいは対象の指標を積極的に害すると繰り返し見出しています。チームの築く容量の4分の1でさえ、ディスカバリーなら安く殺したはずのアイデアに向かうとします。するとパイプラインは何倍も元を取ります。1週間のユーザー調査とフェイクドアのテストは、エンジニアリングの1四半期と、使われない機能の継続的な保守の負担に比べ、ほとんどコストがかかりません。

総所有コスト(TCO)の枠づけが重要なのは、検証されない機能がローンチ後に無料でないからです。出荷されたすべての機能は、永続的なコストを負います。保守、テスト、セキュリティの面、サポート、認知的な負荷(10.4章)。ディスカバリーで悪いアイデアを殺すことは、築くコストだけでなく所有の尾全体を避けます。明示的な品質特性も同じ論理に従います。信頼性とアクセシビリティを前もってSMARTな目標として仕様化することは、停止、侵害、訴訟の後で後付けするよりはるかに安いのです。

リーダーシップに論拠を示すには、会話を「どれだけ出荷しているか」から「重要な指標をどれだけ動かしているか」にシフトし、何も動かさなかった高価な機能の具体例を二、三示してください。採用のコストは控えめです(調査の容量、OKRの周期、SMARTな基準を書く規律)。そして採用しないことの主なリスクは、静かで、数えられず、複合します。

アンチパターンと落とし穴

戦略を装った機能のロードマップ: 述べられた成果や尺度のないアウトプットの一覧。
タスクである主要な結果: 「YをZだけ改善する」ではなく「Xをローンチする」。
OKRの劇場: 書かれて、ファイルされ、見直されず採点もされない目標。
甘く設定された、あるいは英雄的なOKR: 100%を保証する(何も学ばれない)ように設定された目標、あるいは計画なしの空想的な野心。
仕様化されない品質特性: 定量化されず想定された信頼性、セキュリティ、アクセシビリティが、本番で発見されること。
虚栄の指標: 常に上がり何も予測しない尺度。
一回限りの段階としてのディスカバリー: 最初に「ディスカバリーのスプリント」があり、その後は検証が続かないこと。
前提をテストする前に解決策を築く: チームが自信を持っているために、最も安い実験を飛ばすこと。
指標への固執とグッドハートの法則: 尺度が目標になると、良い尺度でなくなります。ガードレールのKPIでバランスをとる。

成熟度モデル

レベル1、開始: 仕事はロードマップの機能として定義され、成功は「出荷した」です。明示的な成果の尺度も品質目標もなく、ディスカバリーは、あるとしても偶然に起こり、決定は最も声の大きい意見に駆動されます。
レベル2、発展: OKRとKPIは一部のチームにあり他にはなく、目標は述べられているがしばしばアウトプットの形をしていて、品質特性は名指しされているが定量化されていません。チームは一回限りの「ディスカバリーのスプリント」を行い、築き始めると検証をやめるかもしれないので、実践は本物だが組織全体で一貫していません。
レベル3、標準化: 戦略に揃った一貫したOKRの周期、SMARTな主要な結果、仕様化されテスト可能な品質特性が、文書化されて組織全体で期待されます。ディスカバリーは、仮説と実験を伴う、認められ人員のある活動で、アーキテクチャ上重要な要件は、想定されるのではなく各取り組みについて特定されます。
レベル4、管理: ポートフォリオはベースラインに対して測定されます。先行指標と遅行指標、ディスカバリーの的中率、出荷された各賭けが実際に動かした成果が、そのSMARTな目標に対して追跡され、仮説は証拠で採点されて打ち切りの基準が徹底され、フィットネス関数が品質特性への適合を継続的に報告するので、仕様化された信頼性、パフォーマンス、アクセシビリティの目標からのずれは、インシデントではなくデータで捉えられます。
レベル5、オーケストレーション: 継続的なデュアルトラックのディスカバリーが、ポートフォリオ、リスク、予算と統合されています。検証された賭けが着実にデリバリーに流れ、成果の指標が次のラウンドを導くよう自動的にループバックします。先行指標が投資を導き、組織は証拠に基づいて日常的に取り組みを退役させ、範囲を見直し、再均衡させ、市場と指標が移るにつれてパイプライン自体を適応させます。

議論のためのアイデア

現在のロードマップを見てください。測定可能な成果を述べている項目と、単に出荷する機能だけの項目は、いくつありますか。
チームの主要な結果のうち、実際には変装したタスクはどれで、どう書き直しますか。
あなたのプロダクトが依存するシステムの品質特性のうち、明示的に定量化されたことがないものは何ですか。
最後に失敗した機能を築く前に殺せたはずの、最も安い実験は何でしたか。
予算や調達が要求する確固たるコミットメントと、良い成果が必要とする学びの緊張を、どう解決しますか。
KPIのうち、製品が悪くなっていても上がり続けるのはどれですか。

要点

ディスカバリーパイプラインは何をとなぜを決め、デリバリーが資源をコミットする前に成功を定義します。
望む変化にはOKRを、維持する健全性にはKPIを使い、指標を先行か遅行かに分類します。
システムの品質特性を、想定ではなく、明示的で、定量化され、テスト可能な要件として扱います。
すべての目標、主要な結果、受け入れ基準をSMARTにします。
デリバリーと継続的に並行してディスカバリーを行い、最もリスクの高い前提を安く検証します。
支配的なROIは避けられた無駄です。築くコストと、使われない機能の永続的なTCOの両方。
ループを閉じます。届けられた成果の指標(11.2章)は、次のラウンドのディスカバリーの主な証拠です。

参考文献とさらなる読み物

Measure What Matters, by John Doerr (on OKRs).
Radical Focus, by Christina Wodtke (on OKRs in practice).
Continuous Discovery Habits, by Teresa Torres (opportunity-solution trees, dual-track discovery).
Inspired and Empowered, by Marty Cagan (product discovery and outcome teams).
Lean Analytics, by Alistair Croll and Benjamin Yoskovitz (leading indicators, vanity metrics).
The Lean Startup, by Eric Ries (build-measure-learn, validated learning).
Escaping the Build Trap, by Melissa Perri (outcomes over outputs).
Outcomes Over Output, by Joshua Seiden.
Software Architecture in Practice, by Bass, Clements, Kazman (quality attributes).
Doran, G. T., “There’s a S.M.A.R.T. way to write management’s goals and objectives” (Management Review, 1981): origin of SMART criteria.