プロダクトロードマップに関する書籍を探していたら、「Product Roadmaps Relaunched」に辿り着きました。未邦訳なので英語で読んでいったのですが、非常に良い本です。
アウトカムベースのロードマップ(Outcome Based Roadmap)
プロダクトマネジメントでは「アウトプット」と「アウトカム」がよく比較されます。アウトプットは出てきた機能に対して、アウトカムは提供価値であり、プロダクトマネージャーはアウトカムに着目すべき、という文脈です。
ロードマップについてもアウトカムをベースに考えることを提案しており、そのフレームワークが提供されています。
引用図の列が時間軸・行がアウトカムとリソース配分の割合です。私もアウトカムとテーマを意識したロードマップを前に紹介しましたが、実務上こちらのテンプレートでよりシンプルにできるのではとも思いました。
優先順位付け
開発の優先順位付けはプロダクトマネージャーとして重要な業務です。適切に優先順位付を行うためのフレームワークがいくつも紹介されていますが、特に数式を定義している点が興味深く感じました。
CN1が1つ目のカスタマーニーズ、CN2が2つ目のカスタマーニーズです。本文中で例に上がっている水撒きホースの製造会社にとって、CN1は「庭への安定的な水の供給」、CN2は「庭への安定的な草木への栄養供給」です。BOはビジネス上の目的で、「新規顧客の売上獲得」とか「アクセスできる市場(Addressable Market)の増加」とかがあたります。ValueをこれらCN/BOの足し算で表しています。
さらに、効率性の概念を入れるために、Effort(工数) があり、分母にして割っています。工数も様々あるのでE1とかE2とか分解します。工数が小さければ小さいほど優先度が高まります。
また、不確実性の概念を入れるために Confidence(自信)を変数に組み込んでおり、「今自分たちのチームが解決できる自信の程度」をかけたものを優先度としています。例えば実務上、予定されている法改正の対応機能などは法改正の方向性や具体内容が変わったりすることがあります。そうなると自分達の努力だけではどうにもならない、外部環境の不確実性が介在し、それを変数として入れる余地があります。また、内部起因でも技術的負債などによる不確実性がある場合はConfidenceは下がるでしょう。
各機能アイデアについて、CN, BO, Eについてスコアを振っていき、式によって算出される優先度を並べることで機能優先度を検討することができます。
本書にはこのフレームワーク以外にも優先度付フレームワークが載っており、常に優先度に悩むプロダクトマネージャーの手助けになります。
機能開発した後の継続的な工数
リリース後の工数についても触れられている点が良かったです。機能を開発すると新規顧客は獲得できますが、
などなどの仕事が発生し続けます。 はじめだけではなく、ずっと工数が発生し続けます。個人的にはサポート対応という観点に納得感があり、汎用的なカスタマイズが可能な機能などを作ると、それに応じてサポート対応も増えるということが頭に浮かびました。
加えて、テストは指数関数的に増加すると書いています。 機能数がNになると 2n -1 でテスト工数は増加します。 Aという機能があるときのテストケースは1つのみですが、AとBという2つの機能があるとき、テストケースの組み合わせはAを使う/使わないと、Bを使う/使わないの22=4通りになります。3機能だと23=9通り、4機能だと24=16通りで指数関数で増加します。
これは、一度作った機能をシナリオでテストするとき、ひたすら工数がかかっていくということになります。B2BSaaSの場合、機能が多くなるとアプローチできる市場カバレッジ(Total Addressable Market)は広がりますが、多いことによって継続的にかかる工数も増えていきます。
機能を増やさずシンプルにしていかに売れるかを考えるのがPMあるいはPMM(Product Marketing Manager)の役割とも思います。これを考えずにひたすら作る、ということはビルドトラップを引き起こす元にもなり得ます。
ビルドトラップ本
まとめ
「Product Roadmaps Relaunched」には上記紹介した内容以外にも多くの考え方やテクニックが載っており、私にはすぐに実務で使える内容もありました。プロダクトマネージャーの仕事は考えることや意思決定することが多く、そのために体系的な知識や引き出しを多く持っていると仕事を進める際の強力な武器になると思います。
洋書でも最近は自動翻訳技術が発達しており、不明な単語や文章はその場で調べられるので、最近はアクセスできる知識が増えたなと感じました。
