プロダクトマネージャーが読みたい本: Escaping The Build Trap - ビルドトラップを避け、顧客に価値を届ける

Escaping The Build Trap は、Melissa Perriによって2018年に書かれた本で、顧客価値へのフォーカスを忘れ、単にプロダクトを作ることそのものにしか目が向かなくなってしまった状態＝Build Trapを避けるためにはどうすればいいか、ということがメインテーマの本です。

Build Trapとは何か

Build Trapにかかった組織は、アウトカム（成果）ではなくアウトプット（デリバリー）の数を成果としてしまい、行き詰まってしまいます。本来的にプロダクトそのものは無価値で、それが実際に顧客の課題を解決することではじめて価値を生むものですが、それを忘れひたすらデリバリーのみにフォーカスしてしまうと、企業は衰退します。

デリバリーが仕事だと思い込んでしまう

なぜBuild Trapに突入するのか？

その主要な理由のひとつとして、最初は顧客課題に向き合っていたはずが、次第にプロダクト数が増えて組織が拡大していくにしたがって、マネジメントが「機能を期日どおりにデリバリーする」という評価指標のみでプロダクトチームをコントロールしようとしてしまうことがあります。

デリバリーの期日 ＞ 顧客課題の解消

これはよく見るシーンで、なぜこういった管理が行われるのかというと、プロダクトチームを全速力で走らせたいからです。開発の速度こそが至上命題であるというメッセージです。

デリバリーの日付を守る、という目標管理。

デリバリーの期日に集中することの何が問題なのでしょうか。それは、組織全体が、自分たちの重要な仕事を、「機能のデリバリー」だと勘違いしてしまうことにあります。しかしながら、本質的に、デリバリー自体に価値はありません。

価値交換の実現：顧客の課題が解決した場合のみ、企業は対価を受け取れる

もしプロダクトチームが何かをリリースするやいなや、顧客の課題をちゃんと解決したかどうか確かめるまえに、次のプロジェクトにとりかかっているとしたら要注意です。

本来は顧客の課題がちゃんと解消するまでイテレーションを繰り返すことが必要なはずで、それがプロダクトマネジメントだからです。

顧客の課題が解消したことを見届けているか？

顧客はその機能を使っている？

最近、とある場面でチームに対して「デリバリーした機能の存在に、顧客はどうやって気づくのですか？顧客は使い方を理解できますか？ちゃんと顧客の課題が解消したことはどのように確認しますか？」と質問したところ、チームが答えに窮してしまうことがありました。

こういったことがもし意識の外にあるとしたら、どうやらBuild Trapにかかっている可能性がありそうです。

プロダクトの死のサイクル

OutputよりもOutcome

それでは、プロダクトチームを活性化しつつもBuild Trapに陥らない方法とは何か。それはアウトカムをコミュニケーションのベースにすることです。顧客にもたらしたい価値、およびその達成の定義をもとに目標を合意することです。

イニシアティブばプロダクトビジョンを達成するための具体的方法

戦略的意図とは、ビジョンの実現につながる現時点での重点分野を定義するもので、通常実現までに１年から数年を要するものです。それを実現するために必要なことをイニシアティブとして設定します。

マネジメントとプロダクトチームは、このイニシアティブの達成度合いを共通言語として会話すべきであり、そうすることでBuild Trapを避けることができます。

Build Trapをもたらしてしまう残念なPMとは？

ミニCEO

CEOのように広い視点もつことが悪いのではありません。本来PMは、チームや顧客の声に耳を傾け、自分のソリューションではなく顧客の問題に真摯に向き合うべきであり、自分の意見よりも具体的な証拠に目を向けるべきです。その逆を行っている人をミニCEOと呼びます。

根拠が確かではないのに、自分の感覚のみで何かを決断しようとする人、なるべくコミュニケーションを避けて密室で何かを決定しようとするPMなどは、恐らくそれにあたるのではないかなと思います。

ウエイター

何かを待っている

ビジョンも戦略もなく、単に社内やマネージャーに対する御用聞きに徹しているPMを指します。

彼らは、たくさんの「やること」の間でトレードオフを行うための明確な基準をもっていないので、声の大きなステークホルダーの言う順番で開発を行います。「なぜ」よりも「いつ」にフォーカスする”プロジェクト”マネージャーのように見えます。

これらの定義にはたびたびドキッとさせられます。なぜなら時として、自分がウエイタータイプのPMのように感じられる場合があるからです。そうならないためには、プロダクトビジョンや戦略的意図を常に意識し、顧客やビジネス・マーケット・組織といったことを理解し、常に「なぜ」ということに答えられるようにする必要があります。

Build Trapを避けるためにできること

Build Trapを読んで、すぐにでも行っていきたいこと、意識すべきことがいくつか思い浮かんだので、最後にリストアップしておきたいと思います。

バックログとロードマップをアウトカムベースに

なんといっても、私たちは顧客の課題（ないしはジョブ）を解決するために仕事をしているので、バックログやロードマップは課題ベースにした方が良いと思います。プロダクト・バックログというよりも”課題バックログ”と呼ぶほうがむしろ良いかもしれません。

そうすることによって、「完了＝課題の解消」という意識が自動的に生まれますし、マネジメントとのコミュニケーションも「期限どおりデリバリーするのか」から「顧客の課題はどの程度解消したのか」という建設的な方向に変わる期待が持てます。

Initiativeは少なく、明確に。

戦略的意図を実現するためのKey Initiativeは少なく明確であるべきで、それによってプロダクトチームが何を達成するために活動しているのかを理解できるようになります。

戦略的根拠がなかったり、定量的な目標がセットになっていなかったり、数が多すぎたり不明瞭になっていたりしないか、注意したいと思います。

Whyを常に考える

なぜそれをやるのか

なぜそれをやるのか、すべての活動においてちゃんと答えることができているか、背景を理解しないままとにかく実行することを決めていないか、Known Unknown（わからないことがわかっていること）を放置したままにしていないか、ということを常に自分に問いかけたいと思います。

UserやCustomerと話す

Unknown Unknownをセンシングするためにも、常に顧客やユーザーとのコミュニケーションを意図的に行いたい。Unknown Unknownとは未知の未知（知らないことを知らない）ということで、本の中でPMの本質的活動として位置づけられています。

まとめ

Build Trapに捉えられるのはとても簡単であり、常にそうなっていないかを意識しておく必要があります。組織が、顧客の課題を共通言語としたプロダクト主導組織の状態を目指すのであれば、マネジメントを含めて全員この本を読むことには価値があると思います。