10.14 プロダクトマネジメントとディスカバリー

概要と動機

プロダクトマネジメントとは、何を、なぜ築くかを決め、それが機能するかに説明責任を負う規律です。プロダクトマネージャーは、問題、顧客、成果を所有します。スケジュール、チケットのキュー、利害関係者から降りてきた機能のチェックリストは所有しません。その区別が、この章の全体を一文にしたものです。プロダクトマネジメントがプロジェクトの調整や注文取りに崩れると、チームはフィーチャーファクトリーになります。絶えず出荷し、ベロシティの数字を達成し、どの事業指標も動かさない。この役割はまさにそれを防ぐために存在します。

大きなチームにとって、弱いプロダクトマネジメントは、静かに存在する中で最も高くつく失敗の様式です。エンジニアリングが見事で、デリバリーが速く、機械全体が、それでも1年を、間違ったものを大いなる効率で築くことに費やしえます。そのコストはエンジニアリングのダッシュボードには決して現れません。横ばいの収益、離れた顧客、誰も使わないが今や全員が保守しなければならない機能の積み残しとして現れます。良いプロダクトマネジメントは、目標が明示的で、測定可能で、本物の顧客の問題に結びついていると主張することで、お金をコミットする前にそのリスクを可視にします。

企業と政府の設定は、賭け金を引き上げ、仕事の形を変えます。企業はますます、プロジェクトの運営モデル(プロジェクトに資金を出し、出荷し、チームを解散する)から、プロダクトの運営モデル(何年もかけて成果を所有する持続するチームに資金を出す)へと移り、社内のプラットフォームを本物の顧客を持つプロダクトとして扱っています。政府は、ユーザー中心設計の旗印のもとで同じ教訓を学んでいます。プロジェクトではなくサービスに資金を出し、市民が実際に仕えられているかを測る。この章は、その転換を本物にする心構えと仕組みについてです。パイプラインの仕組みを詳述する11.1章(ディスカバリーのパイプライン)と密接に対になっており、ここでは役割、戦略、ディスカバリーの日々の習慣に焦点を当てます。

主要原則

何を、なぜを所有する。 プロダクトマネージャーは、タスクの調整ではなく、成果に説明責任があります。
アウトプットよりアウトカム。 出荷はコストであって、結果ではありません。結果は、変化した顧客あるいは事業の指標です。
誰よりも顧客と問題を知る。 顧客との接触のない戦略は推測です。
ディスカバリーは段階ではなく継続的である。 デリバリーと並行して、毎週顧客と話します。
優先順位づけの枠組みは判断の助けであって、神託ではない。 数字は判断に情報を与えますが、判断を下しません。
ロードマップは日付つきの約束ではなく、意図の表明である。 問題にはしっかりと、解決策には緩やかにコミットします。
トリオに権限を与える。 プロダクト、デザイン、エンジニアリングが一緒に決めます。プロダクトマネージャー一人の決定は悪い。

推奨事項

何を、なぜを所有し、どうやってはチームに所有させる

プロダクトマネジメントが健全かの最も明確なテストは、誰がどの問いを所有するかです。プロダクトマネージャーはどの問題を解いているかとなぜそれが今重要かを所有します。デザインは、ユーザーにとってどう感じられるべきかを所有します。エンジニアリングはどう築くかを所有します。プロダクトマネージャーが解決策、期限、実装を指示し始めたとき、彼らはプロダクトの肩書きを着たプロジェクトマネージャーになり、権限を与えられたチームを有効にするまさにその自律を取り去りました(5.1章がデザインとの協働を、10.7章がアジャイルのデリバリーモデルを扱います)。

権限を与えられたプロダクトチーム、時にプロダクトトリオと呼ばれるものは、プロダクト、デザイン、エンジニアリングが一緒に働き、築く機能ではなく解く問題を与えられます。それが「新規ユーザーの30日間リテンションを上げる」と「3月までに通知センターを築く」の違いです。前者は、チームが最良の解決策を見つける権限を与え、結果に責任を持たせます。後者は、チームをデリバリーの腕に貶め、間違っているリスクを、要件を書いた人に静かに移します。アウトカムへの説明責任が欲しいなら、アウトプットの制御を手放さなければなりません。

顧客に根ざしたプロダクトのビジョンと戦略を設定する

プロダクト戦略とは、どの顧客に仕え、彼らのどの問題を解き、同じくらい重要なこととして、どれを拒否するかについての、少数の難しい選択です。ビジョンは、作ろうとしている世界の持続的な像で、通常2年から5年先です。戦略は、そこに至る一連の動きです。両方がなければ、優先順位づけは最も声の大きい者に退化し、ロードマップは全員のお気に入りの機能をホチキス留めした一覧になります。

戦略は、顧客と問題についての深い、直接の知識なしには不可能です。顧客が誰で、どんな仕事を片付けようとしていて、現在どこで苦労しているかを、具体的に詳しく説明できないプロダクトマネージャーは、何かの優先順位をつける準備ができていません。これは一度委託する調査ではありません。接触の常設の習慣です。最良のプロダクトのリーダーは、前四半期の調査資料ではなく、先週の顧客との会話を記憶から語れます。問題を完全に知っていれば、チームは意見ではなく証拠から推論できるので、優先順位づけの議論の多くは溶けます。

アウトカムで管理し、フィーチャーファクトリーから逃れる

フィーチャーファクトリーは、成功が「出荷した」と定義されたときに得られるものです。チームはベロシティを測り、リリースを数え、ローンチを祝う一方で、請求書を払う指標は横ばいのままです。解毒剤は、成功をアウトカム(顧客あるいは事業の行動の変化)として定義し、築く前にそれに尺度を付けることです。ここで、プロダクトマネジメントが目標と主要な結果(11.4章)に出会います。目標は望む変化を記述し、主要な結果はそれを測り、「機能Xをローンチする」と表現された主要な結果は、変装したタスクです。

兆候に注意してください。ロードマップがアウトカムの記載のない機能の一覧なら、出荷された機能がどの指標を動かしたかを誰も言えないなら、振り返りが「機能したか」ではなく「出荷したか」しか尋ねないなら、フィーチャーファクトリーにいます。そこから逃れることは、大部分が規律の問題です。誰かが問題と尺度を述べるまで、解決策として枠づけられた仕事を受け入れるのを拒否します。プロダクト分析と管理された実験(7.4章)は、本物のアウトカムと心地よい物語を見分ける計器盤を与えます。

デリバリーと並行して継続的なディスカバリーを行う

継続的なプロダクトディスカバリーとは、毎週、デリバリーと並行して、チームが顧客から学び、築く予定のものの背後の前提をテストしていることを意味します。モデルはデュアルトラックです。ディスカバリーのトラックがアイデアのリスクを下げる一方、デリバリーのトラックが検証されたものを築き、二つは順次の段階ではなく継続的に走ります(11.1章がパイプラインを詳述します)。その背後の実際的なコミットメントは小さく容赦ありません。忙しいときでも、特に忙しいときに、毎週顧客と話す。

これの有用な背骨は、機会ソリューションツリーです。望む成果から始め、それを動かしうる顧客の機会(ニーズ、困りごと、望み)に分岐し、各機会の候補の解決策へ再び分岐し、それから解決策が機能するかを教えてくれる前提のテストへ分岐します。ツリーは、ある機能がなぜテーブルにあるのかについてチームを誠実に保ち、最初の解決策に恋をするのではなく機会を比較させます。エンジニアリングをコミットする前に、最もリスクの高い前提を最も安い実験でテストします。インタビュー、プロトタイプ、フェイクドアのテスト、A/Bテスト。ディスカバリーの出力は機能の一覧ではありません。デリバリーの準備ができた、検証された測定可能な賭けの流れです。

優先順位づけの枠組みを、神託ではなく判断の助けとして使う

優先順位づけの枠組みは、散らかった決定に有用な構造をもたらしますが、その数字を真実として扱えば、どれも間違っています。RICEは各アイデアを、リーチ(何人のユーザー)、インパクト、確信、労力で採点し、(リーチ×インパクト×確信)/労力で順位づけます。重み付けスコアリングは、選択肢を重み付けされた複数の基準に対して評価します。遅延のコストは、待つ毎週がいくらかかるかを尋ね、順序づけにはしばしば最も鋭いレンズです。カノモデルは、機能を基本的な期待、性能のニーズ、魅力的品質に分類し、すべての満足が線形ではないことを思い出させます。

それらを、決定を放棄するためではなく、前提をさらしてトレードオフを議論可能にするために使ってください。RICEの確信の項と重み付けスコアリングの見積もりは、算術に装った判断であり、偽の精度は、悪い賭けを客観的に見える順位づけの一覧に洗浄しえます。数字を計算し、それから順位づけが戦略と顧客の知識に合うかを尋ねます。合わなければ、判断を信じて入力を問いただします。枠組みは思考の助けで、正しくなければならないのは依然としてあなたです。

ロードマップを意図の表明として扱う

特定の機能を特定の四半期に約束する日付つきのロードマップは、全員が署名して誰も守れない作り話です。ディスカバリーが学び続けるはずのもの、つまり解決策を固定してしまうからです。今/次/後のロードマップを好みます。今取り組んでいること、次にありそうなこと、後で検討していることを、日付つきでコミットされた機能ではなく、問題とアウトカムとして表現します。これは、証拠が届くにつれて解決策を変える自由を保ちながら、方向を誠実に伝えます。

根底にある動きは、問題とアウトカムにしっかりと、解決策には緩やかにコミットすることです。日付が確実な機能のコミットメントを求める利害関係者は、通常、予測可能性を求めており、それは合理的です。まだ検証していない特定の機能の水準ではなく、アウトカムと時間枠の水準(「この半期にオンボーディングの離脱を意味ある形で減らす」)でそれを与えてください。厳格な日付を与えなければならないときは、それを価値あるアウトカムに結びつけ、10.6章がプロジェクトのデリバリーに推奨するのとまったく同じく、解決策の範囲を柔軟にします。

望ましさ、実現可能性、事業性、使いやすさを検証する

本物の投資をコミットする前に、プロダクトのアイデアは四つのリスクを越えなければなりません。望ましさ: 顧客は本当にそれを望むか。事業性: 事業にとって機能するか(法務、財務、ブランド、営業)。実現可能性: エンジニアリングは利用可能な時間と技術でそれを築けるか。使いやすさ: 人々は実際にそれを使えるか。トリオはこれらをカバーするように作られています。プロダクトが事業性を、デザインが使いやすさを、エンジニアリングが実現可能性を先導し、望ましさは全員の問題です。一つを飛ばすと、顧客が無視する、法務がブロックする、エンジニアリングが出荷できない、ユーザーが理解できないローンチとして戻ってきます。

これは築く、買う、提携するの決定の枠組みでもあります。能力があなたの差別化の中核なら、築きます。必要だが差別化されない(請求、認証、メール配信)なら、築くすべての機能が保守、セキュリティの面、認知的な負荷の永続的な尾を負うので、買うか提携することを強く好みます。最小実行可能プロダクト(MVP)は、出荷して忘れる簡素化されたバージョン1.0ではなく、最もリスクの高い前提をテストする最も安いものです。何をローンチするかだけでなく、何を学ぶかを尋ねて、誠実に保ってください。

プロダクトマーケットフィットを知り、プロダクトオペレーションに投資する

プロダクトマーケットフィットとは、プロダクトが強い市場の需要を満たす瞬間で、通常、証明できるようになる前に感じます。リテンション曲線がゼロへ減衰する代わりに平らになり、利用が口コミで増え、顧客がプロダクトを失ったら本当に動揺し、需要を生み出すのではなく需要に追いつくのに苦労する。フィットの前は、あなたの仕事はそれを見つけることで、ほとんど他のことは重要ではありません。フィットの後は、あなたの仕事は、それをスケールさせ守ることに変わります。二つの段階を混同すること(フィットを得る前にスケールする、あるいは得た後もまだ探している)は、古典的で高価な間違いです。

プロダクトチームの数が増えるにつれ、プロダクトオペレーションに投資してください。多くのチームが、それぞれが再発明せずにディスカバリーをうまく行えるようにする、共有の調査、データ、ツール、実践。プロダクトオペレーションは、顧客インタビューの周期に人員を置き、分析を信頼できるものにし、ロードマップの形式を一貫させ、OKRのリズムを回し続けます。プロダクトの運営モデルに移行する企業や、社内のプラットフォームが本物の社内の顧客を持つプラットフォーム・アズ・プロダクトの組織では、プロダクトオペレーションが、数十のチームにわたってモデルを一貫させ、局所的な習慣に断片化するのを防ぎます。

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

アプローチ	長所	短所
権限を与えられたプロダクトチーム(アウトカム)	結果を所有。より良い解決策を見つける。意欲的	上級の人材と本物の信頼が必要。上から指示しにくい
フィーチャーチーム/注文取りのモデル	予測可能なアウトプット。管理と契約が容易	間違ったものを効率的に出荷。結果を誰も所有しない
継続的なディスカバリー	毎週賭けのリスクを下げる。速い学び。無駄が少ない	調査の容量と規律が必要。スケジュールしにくい
重い事前の要件	資金提供者に安心。明確なスコープ	前提がテストされない。遅いフィードバック。一斉のリスク
今/次/後のロードマップ	不確実性に誠実。学びを保つ	日付つきの機能のコミットメントを望む利害関係者を苛立たせる
日付つきの機能ロードマップ	予測可能に感じる。伝えやすい	知りえないことを約束する。アウトカムよりアウトプットに報いる
枠組みのスコアによる優先順位づけ	構造化され、議論可能で、政治を減らす	偽の精度。悪い賭けを客観的に見せて洗浄しうる

中心的な緊張はコミットメント対学びです。予算、契約、経営幹部は確固たるコミットメントを望み、それが日付つきの機能ロードマップと事前の要件へと引っ張ります。良いプロダクトには、発見する余地が必要で、それがアウトカムと継続的な実験へと引っ張ります。このガイド全体と同じやり方で解決します。問題、アウトカム、時間枠にしっかりとコミットし、特定の解決策は緩やかに保つ。それが、リーダーシップが実際に必要とする予測可能性(重要なものの測定可能な進捗)を、チームがまだ検証していない機能を約束することを強いずに与えます。

チームで議論すべき問い

あなたのプロダクトマネージャーは、成果を所有していますか。それとも積み残しですか。 これは、チームが本当にどう動いているかについて、最も明らかにする唯一の問いです。プロダクトマネージャーがロードマップの出荷、利害関係者の要望の追いかけ、スプリントを満たし続けることで測られているなら、プロダクトの肩書きを着たプロジェクトの調整者がいて、仕事が指標を動かすかに実際に説明責任を負う人はいません。証拠を持ち込んでください。プロダクトマネージャーの最後の三つの成果物を見て、それぞれがどの顧客あるいは事業の成果を変えるはずだったか、誰かが確認したかを尋ねます。大きな組織では賭け金が複合します。アウトプットに向けられた単一のチームが、デモではよくテストされるが本番では何も変えない機能を築くのに、複数の四半期を燃やしうるからです。答えは、プロダクトマネージャーを何で測るかと、チームに解決策のどれだけの制御を与える意思があるかの両方を作り直すべきです。誰も成果を所有しないなら、ロードマップを議論する前にそれを直してください。
このチームの誰かが最後に顧客と話したのはいつで、それは今週でしたか。 継続的なディスカバリーはこの習慣で生きるか死ぬかが決まり、デリバリーの圧力が上がるときに最初に切られ、それはまさに最も必要なときです。顧客と話すのをやめたチームは、自分が盲目になったことに気づきません。単に内部の意見と古い調査から推論し始め、より確信を深め、より正しくなくなります。実際の記録を持ち込んでください。最後の十の機能のうち、文書化された前提と安いテストを築く前に経た数と、利害関係者の口からまっすぐ積み残しに入った数を数えます。一つの不一致な取り組みが多くのチームの四半期を無駄にし、公共部門では本物の公的信頼を無駄にしうる企業と政府のチームでは、毎週の顧客接触を生かし続ける説明責任を誰が負うかを名指ししてください。誠実な答えが「今週ではない」あるいは「わからない」なら、前提の上を飛んでいて、それを戦略と呼んでいます。
プロジェクトの運営モデルからプロダクトの運営モデルへ移るには何が必要で、何があなたを止めていますか。 多くの企業は依然として一時的なプロジェクトに資金を出し、人員を置き、出荷し、チームを解散し、それが、良いプロダクトの仕事が依存する、持続する所有と顧客の知識を破壊します。何年もかけて成果を所有する持続するチームへの移行は、社内のプラットフォームを本物の顧客を持つプロダクトとして扱うことを含め、単なる肩書きの変更ではなく、資金、組織設計、ガバナンスの変更です。証拠を持ち込んでください。現在の取り組みを一つ、どう資金を受け人員を置かれているかをたどり、プロジェクトが終わってチームが散るとき、蓄積した学びに何が起こるかを尋ねます。相反する考慮は本物で、年次のプロジェクト予算と調達規則は正当な説明責任の理由で存在し、無視するのではなく満たさなければなりません。答えは、ポートフォリオ全体を転換しようとする前に、モデルを証明する最小の具体的なステップ(安定した予算で一つの成果を所有する一つの持続するチーム)を特定すべきです(10.1章)。
優先順位づけの枠組みを動かすとき、それは決定に情報を与えていますか。それともすでに下された決定を追認しているだけですか。 RICE、重み付けスコアリング、遅延のコストは、前提を公にさらさせるからこそ有用で、数字が考えるのをやめる言い訳になった瞬間に有害になります。相反する考慮は本物です。枠組みは政治を減らし、大きな組織が本当に必要とする擁護できる証跡を与えますが、確信とインパクトの項は算術に装った判断であり、悪い賭けを客観的に見える順位に洗浄しえます。最近のいくつかの優先順位づけの決定を持ち込み、二つを確認してください。戦略や顧客の知識が食い違ったとき、誰かがスコアを上書きしたことがあるか、そして最も給与の高い人の選好が、順位づけを生んだ入力を静かに設定していないか。採点された積み残しが、運営委員会と監査人に示される成果物になりがちな企業と政府の設定では、誰がどんな根拠で数字を上書きしてよいかを名指ししてください。誰も覆せない枠組みは、思考の助けをやめて、ゴム印になったからです。
利害関係者に日付つきの機能として何を約束していて、信頼を失わずにそれらのコミットメントをアウトカムとして述べ直せますか。 日付つきの機能ロードマップは予測可能性に感じられ、たいてい作り話です。ディスカバリーが学び続けるはずの解決策を固定し、大きな組織では、そのような約束はどれも、依存するチーム、マーケティング計画、経営幹部の期待へと波及するからです。緊張は正当です。資金提供者と利害関係者は、予算と説明責任の理由から確実性を望むので、単にコミットを拒むことはできず、予測可能性を、検証されていない機能ではなく、アウトカムと時間枠の水準で与えなければなりません。現在のロードマップを持ち込み、各項目を、コミットできるアウトカムか、推測している特定の解決策かのどちらかに印を付け、それから推測を今/次/後の問題としてどう述べ直すかを下書きしてください。年次の予算と調達のマイルストーンに縛られる企業と公共部門のチームでは、どのコミットメントが本当に契約上のもので、単に習慣的なものかを特定してください。習慣的なものは偽の精度を誠実な方向と交換できる所で、契約上のものは、機能ではなくアウトカムへのコミットメントを交渉しなければならない所です。
差別化されない能力を築いていて、買うか提携することもできるのはどこで、誰が決めますか。 築くすべての機能は、保守、セキュリティの面、サポートの負荷の永続的な尾を負うので、請求、認証、メール配信を手作りすることは、あなたを差別化しない仕事に最も乏しい容量を費やします(10.4章)。相反する考慮は、「買う」が速度と低い所有コストと引き換えに制御と適合を渡すこと、そして商品だと想定した能力が実はあなたの優位性の中核であることがあるので、望ましさ、事業性、実現可能性、使いやすさのレンズを、選好の隠れ蓑としてではなく誠実に適用しなければならないことです。チームが現在社内で築いているものの目録を持ち込み、それぞれを中核の差別化要因か、差別化されない配管かに印を付け、配管の継続的な所有コストを、ベンダーの代替と見積もってください。企業と政府の文脈では、調達規則、データ所在地とセキュリティの要件、ベンダーのロックインと出口の条件を折り込んでください。そこでの築く、買う、提携するの決定は、単なるエンジニアリングのトレードオフではなく、コンプライアンスと説明責任の決定であり、それを所有する人は、選択を監査人に対して擁護できるべきだからです。

セクター別の視点

スタートアップ。 滑走路が乏しいので、ディスカバリーはプロセスではなく生存です。一人の創業者がプロダクトの帽子をかぶり、儀式なしに毎週顧客と話し、エンジニアの誰かを築くことにコミットする前に、可能な限り安いテスト(フェイクドアのボタン、5回のインタビュー)を行います。重い枠組みと日付つきのロードマップは飛ばしてください。会社全体が戦略を頭の中に保てるので、誰かが問題と指標を述べるまで、声の大きい要望を築くのを拒む規律に使います。

小規模事業者。 専任のプロダクトマネージャーはいないので、プロダクトの思考は、オーナーあるいはリードエンジニアが他の職務と並行して担う習慣です。ほとんどの築くか買うかの判断を、買うに傾けて枠づけてください。予約、決済、メールのような差別化されない能力はベンダーのもので、乏しい注意は顧客を本当に勝ち取る一つか二つのものに向かいます。正式なロードマップではなく軽量な今/次/後の一覧を保ち、完全なOKRの仕組みではなく、単一の先行指標(リピート購入、無断キャンセル)を成果として扱います。

大企業。 仕事は、モデルを断片化させずに多くのプロダクトチームを調整することです。成果を所有する持続するトリオ、一貫したロードマップの形式、数十のチームにわたってインタビューの周期、分析、OKRのリズムを一貫させるプロダクトオペレーション。ガバナンスと監査は追跡可能性を望むので、委員会を満足させるがアウトプットにインパクト以上に報いる日付つきの機能の約束に戻るのではなく、成果、優先順位づけの根拠、打ち切りの決定を読み取れるようにします。組織設計と予算は肩書きよりゆっくり変わるので、プロジェクトの資金からプロダクトの運営モデルへの転換を意図して管理してください。

政府。 調達規則、透明性、公的な説明責任があらゆる選択を形づくります。固定スコープのプロジェクトではなく持続するサービスチームに資金を出し、成功を、監督機関が検証できる市民の成果(申請までの時間、セルフサービスの完了)として定義し、ユーザー中心設計とアクセシビリティの標準を、支援技術のユーザーを含む本物の申請者でテストされる固い要件として扱ってください。精査が公共の価値を見られるよう、成果と進捗を平易に公表し、築く、買うとベンダー契約を、データの可搬性と出口を軸に構造化して、今日の供給者の選択が10年のロックインにならないようにします。

事例

スタートアップ。 個人診療所向けのスケジューリングツールを築く6人のスタートアップは、三人の声の大きい顧客が求め続ける大きな「オンライン予約」機能を築きたい誘惑に抵抗します。創業者のプロダクトマネージャーは、代わりに1週間のディスカバリーを行います。5人の診療所オーナーへのインタビュー、マーケティングサイトのフェイクドアのボタン、一つの先行指標(無断キャンセルに終わる予約の割合)。証拠は、本物の痛みは予約ではなく無断キャンセルだと言うので、チームは単一の成果(今四半期、パイロットの診療所で無断キャンセルを10%未満に減らす)を枠づけ、最もリスクの高い前提をテストする小さな預り金とリマインダーのMVPを出荷し、予約機能は1行も書く前に取りやめます。ロードマップは日付つきの計画ではなく今/次/後の一覧で、チーム全員が先週の顧客との通話を記憶から語れます。

大企業。 小売銀行は、決済グループをプロジェクトモデルからプロダクトモデルへ移します。一つの持続するトリオ(プロダクト、デザイン、エンジニアリング)が、設立認可を受けたプロジェクトの連なりではなく、安定した年次予算を伴う常設の成果として「日常の決済が瞬時に感じられる」を所有します。チームは毎週の顧客インタビューを行い、機会ソリューションツリーを保ち、候補の解決策の順序づけにRICEを使いますが、遅延のコストの分析がレイテンシの修正のほうが重要だと示したとき、順位づけを上書きし、日付つきの機能の約束ではなく今/次/後のロードマップを利害関係者に公表します。二つの提案された機能が、先行指標を動かせずにディスカバリーで死に、見積もり2四半期分の築く労力を節約し、プロダクトオペレーションが、銀行の15のプロダクトチームにわたってインタビューの周期と分析を信頼できるものに保ちます。

政府。 給付の申請を近代化する国の機関は、デジタルサービスチームが提唱する公共部門のプロダクトの心構えを採用します。固定スコープのプロジェクトではなく持続するサービスチームに資金を出し、成功を、納品されたモジュールではなく、市民の成果(申請までの時間の中央値を40分から15分へ、セルフサービスの完了成功を55%から85%へ)として定義します。ユーザー中心設計は交渉の余地がありません。チームは、すべてのリリースの前に、支援技術のユーザーを含む本物の申請者で司会付きのユーザビリティテストを行い、アクセシビリティの標準を固い要件として扱います。ロードマップがアウトカムとして枠づけられ、チームが何年もサービスを所有するので、監督機関は支出の報告ではなく測定可能な公共の価値を見て、機関は一つの遠いゴーライブにすべてを賭けるのではなく、有用な能力を早期に出荷できます(11.1章、5.1章)。

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

本物のプロダクトマネジメントの見返りは、避けられた無駄に支配されます。大きな技術企業での管理された実験のプログラムは、築かれた機能の大きな割合(しばしば半分前後と引用される)が、測定可能な改善を生まない、あるいは対象の指標を積極的に害すると繰り返し見出しています。チームの容量の4分の1でさえ、継続的なディスカバリーなら安く殺したはずのアイデアに向かうなら、規律は何倍も元を取ります。1週間の顧客インタビューとフェイクドアのテストは、エンジニアリングの1四半期と、誰も使わない機能の永続的な保守に比べ、ほとんどコストがかかりません。フィーチャーファクトリーの主なコストは、出荷する機能ではありません。動かさなかったアウトカムの機会費用です。

総所有コストでは、出荷されたすべての機能は常設の負債です。保守、テスト、セキュリティの面、サポートの負荷、そしてプロダクトを乗りこなさなければならない全員にかかる認知的な重み(10.4章)。プロダクトマネジメントは、二つの方法でそのコストを下げます。ディスカバリーで悪いアイデアを殺し、築くことだけでなく所有の尾全体を避けます。そして築く、買う、提携するの決定を、差別化されない能力を買う方向に導き、チームの有限の容量があなたを本当に差別化するものに向かうようにします。プロジェクトの運営モデルからプロダクトの運営モデルへの転換は、さらに微妙な見返りを加えます。持続するチームは、プロジェクトチームが解散して再編されるたびに捨てる顧客の知識とコードベースの文脈を保持します。

リーダーシップに論拠を示すには、会話を「どれだけ出荷しているか」から「重要な指標をどれだけ動かしているか」に変え、何も動かさなかった高価な機能の具体例を二、三示してください。採用のコストは控えめです。調査の容量、ディスカバリーの周期、アウトカムベースのロードマップ、築く前に成功を定義する規律。投資しないリスクは、静かで、数えられず、複合します。フィーチャーファクトリーは、事業が動いていないと気づくまで、生産的に見えるからです。

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

フィーチャーファクトリー: 成功が「出荷した」と定義され、ベロシティが祝われる一方で事業指標が横ばいのまま。
プロジェクトマネージャーとしてのプロダクトマネージャー: 問題と成果ではなく、スケジュールとチケットのキューを所有すること。
機能の秘書としてのプロダクトマネージャー: 問題も尺度も付けずに、利害関係者の要望を積み残しに書き写すこと。
日付つきの機能の約束としてのロードマップ: まだ検証できない特定の解決策を、特定の四半期にコミットすること。
一回限りの段階としてのディスカバリー: 最初にディスカバリーのスプリントがあり、その後は顧客との接触なしに何か月も築くこと。
HiPPO駆動の優先順位づけ: 最も給与の高い人の意見が証拠を上書きし、枠組みがそれを追認する劇場になること。
枠組みの崇拝: RICEや重み付けスコアを真実として扱い、偽の精度に悪い賭けを洗浄させること。
差別化されないインフラストラクチャを築く: ベンダーがより良く安く提供する請求や認証を手作りすること。
プロダクトマーケットフィットの前のスケール: 市場がまだ強く望んでいないプロダクトの成長にお金を注ぎ込むこと。
プロダクトオーナーのいない社内プラットフォーム: 社内の顧客が必要とするものではなく、自分たちが面白いと思うものを築くプラットフォームチーム。

成熟度モデル

レベル1、開始: プロダクトマネジメントは注文取りで反応的です。日付つきの機能ロードマップが降りてきて、成功はそれを出荷することです。述べられた成果も、定期的な顧客接触もなく、仕事が指標を動かしたかに説明責任を負う人はいません。
レベル2、発展: 基本的なプロダクトの実践が現れますが、チーム間で一貫していません。成果とOKRは一部のチームにありますが、目標はしばしばアウトプットの形をしていて、ロードマップは依然として機能の一覧です。ディスカバリーは時折、通常は最初の段階として起こり、優先順位づけは枠組みを使いますが、時に最も声の大きい人の隠れ蓑として。
レベル3、標準化: 権限を与えられたトリオが成果を所有し、実践は文書化されて組織全体で期待されます。ロードマップは今/次/後の意図の表明で、継続的なディスカバリーは文書化された前提のテストを伴う、人員のある毎週の習慣で、優先順位づけの枠組みは判断を置き換えるのではなく情報を与え、プロダクトマーケットフィットは局所的な習慣ではなく共有の標準として理解され追跡されます。
レベル4、管理: 実践が、ベースラインに対して測定され制御されます。各チームは述べられたベースラインに対して先行と遅行の成果指標を追跡し、ローンチ後はすべての機能が、意見ではなく証拠で徹底される打ち切りの閾値を伴う、事前登録された成功の指標に照らして確認されます。ディスカバリーの健全性も計装されます(インタビューの周期が守られているか、築く前に前提がテストされたか、ディスカバリーで殺されたアイデア対出荷されたもの)。リテンション曲線や「なくなったら残念」のスコアのようなプロダクトマーケットフィットのシグナルが定量化され、RICEの確信のような枠組みの入力は、賭けが実際にどうなったかに対して較正されます。
レベル5、オーケストレーション: プロダクトの運営モデルがポートフォリオ全体で動き、継続的に改善され、資金と戦略と統合されています。持続するチームが何年もかけて成果を所有し、社内のプラットフォームはプロダクトとして管理され、ディスカバリーとデリバリーは継続的にループし、成果のデータが投資を導いてポートフォリオを適応的に再均衡させ、プロダクトオペレーションが実践を規模で一貫させ、リーダーシップは成果のポートフォリオを管理して、証拠と市場が移るにつれて賭けを日常的に退役させ、範囲を見直し、優先順位を付け直します。

議論のためのアイデア

現在のロードマップを見てください。測定可能な成果を述べている項目と、単に機能と日付だけの項目は、いくつありますか。
チームの誰が、先週の会話を記憶から語れるほど顧客との関係を所有していますか。
最近の機能のうち、最もリスクの高い前提について安い実験を最初に行っていたら、どれを殺していましたか。
買うか提携できる差別化されない能力を築いているのはどこで、それは何を代価にしていますか。
プロダクトマーケットフィットはありますか。そして想定ではなく、実際にどうやってそれを知りますか。
プロダクトの運営モデルに向けて取れる最小のステップは何で、その邪魔をするガバナンス上の障害は何ですか。

要点

プロダクトマネジメントは何をとなぜを所有し、タスクの調整や要望の書き写しではなく、成果に説明責任を負います。
築く前に、顧客あるいは事業の行動の測定された変化として成功を定義することで、フィーチャーファクトリーから逃れます。
デリバリーと並行して継続的なディスカバリーを行います。毎週顧客と話し、最もリスクの高い前提を最も安い実験でテストします(11.1章)。
優先順位づけの枠組み(RICE、重み付けスコアリング、遅延のコスト、カノ)を、神託ではなく判断の助けとして使います。
ロードマップを意図の表明(今/次/後)として扱い、問題とアウトカムにしっかりと、解決策には緩やかにコミットします。
トリオに権限を与え、投資する前に望ましさ、事業性、実現可能性、使いやすさを検証します(5.1章)。
企業と政府では、プロジェクトの運営モデルからプロダクトの運営モデルへ移り、プロジェクトではなくサービスに資金を出し、プロダクトオペレーションに投資します(10.1章、11.4章)。

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

Marty Cagan, Inspired and Empowered (empowered product teams, the product operating model).
Marty Cagan and Chris Jones, Transformed (moving to a product operating model).
Teresa Torres, Continuous Discovery Habits (opportunity-solution trees, weekly customer contact).
Melissa Perri, Escaping the Build Trap (outcomes over outputs, product operations).
Roman Pichler, Strategise (product vision, strategy, and roadmaps).
C. Todd Lombardo, Bruce McCarthy, Evan Ryan, and Michael Connors, Product Roadmaps Relaunched (now/next/later roadmaps).
Dan Olsen, The Lean Product Playbook (product-market fit).
Eric Ries, The Lean Startup (minimum viable product, build-measure-learn).
Noriaki Kano et al., “Attractive Quality and Must-Be Quality” (Journal of the Japanese Society for Quality Control, 1984): origin of the Kano model.
Melissa Perri and Denise Tilles, Product Operations (scaling product practice).
U.S. Digital Service, Digital Services Playbook; UK Government Digital Service, Government Design Principles and Service Standard (public-sector, user-centred product delivery).