あなたの組織がプロダクトマネジメントを今すぐ始めるべき理由
これは、プロダクトマネージャの役割を持つ人材がいないスタートアップや、プロダクトマネージャを任されたが何をすればいいかよくわからない人、あるいは現にプロダクトマネジメントを担当しているがより仕事の質を高めたい人に向けた記事だ。
プロダクトマネジメントをしない開発形態
何か製品を作ってサービスを提供する組織において、プロダクトマネジメントというものをせずにサービス開発を行うことは、事実上可能だ。
アーリーステージ
アーリーステージでのプロダクトマネジメントをしない開発形態というのは、創業者が思いついたアイディアを勢いで創業者かエンジニアが実装して製品化したりするものだ。
その後のステージ
製品をゼロからつくるアーリーステージを超えて製品を改善する期間に入った開発形態でも、プロダクトマネジメントを行わずに製品開発を行うことが可能だ。その形態は、社内のカスタマーサクセス担当・セールス担当・エンジニア・デザイナが顧客の要望や、時に思いついたアイディアをベースに開発チケットを作成し、主にエンジニアが開発段階で仕様を考えていくというものだ。この形態においては、仕様に関しては明確なオーナーが定まっておらず、時にビジネス担当者がリクエストを行ったり仕様を指定したりする。これは、看板管理をしているような開発でよく見受けられる。
プロダクトマネジメントをしないことのリスク
アーリーステージ
アーリーステージにおけるプロダクトマネジメントをしないことの最大のリスクは、プロダクトがラーメン代を稼ぐ前に資金が切れることだ。創業者が思いついたアイディアを勢いで実装したものは、統計的に言ってはじめの段階ではまず売れることはない（知り合いや最初の数顧客に売れることはあっても、市場を大きく取ることはできない）。大小含めいろいろなピボットを繰り返すことでプロダクトマーケットフィットにたどり着くことができる。
プロダクトマネージャがいない組織の場合、プロトタイプをつくることなく勢いで実装したものを顧客に提供することになるが、これはピボットのコストが非常に高く、あとで顧客のニーズと違う事がわかってもこれを巻き戻すコストは計り知れない。結果、最後まで方向転換できず、資金切れ間近で大きなピボットを強いられることになる。
一方でプロトタイプというのは取り壊すことを前提にして作るので、実装前段階で高速に実験を回すことができる。良いPMは、最初の段階で売れないことを前提に製品開発をする。創業者が思いついたアイディアは、最初の段階では仮説に過ぎない。プロダクトマネージャはその仮説の体系だった検証方法を理解しているので、創業の段階で創業者はプロダクトマネージャに自分の思いついた仮説の検証を任せるべきだ。あるいは自分がプロダクトマネージャになるか。
その後のステージ
通常、アーリーステージを抜け一定の顧客やユーザーが獲得できた段階では、複数の異なるセグメントの顧客が混合している。セグメント・属性が異なれば当然ニーズが変わってくるが、基本的には一つのソリューションで複数の異なるセグメントを喜ばせることはできない。結果として、顧客が欲しがったものをただ作っていく体制だと、機能追加のフォーカスはどんどん散逸化し、結果としてどのセグメントにも刺さらない製品が出来上がる。
しかも、顧客は課題についてはプロフェッショナルだが、使用可能な技術やデザインに関する知識はなく、ソリューションに関しては大して深く考えていない。プロダクトマネージャは重要な課題を明らかにし、ひとつの課題に対して可能な複数のソリューションを考え、その中からベストなものが何か吟味しないといけない。これには利用実績の調査やユーザーへのヒアリングを必要とし、エンジニアが実装の片手間でできるようなものではない。このプロセスを省略すると、機能ごとの一貫性は失われ、どのセグメントにも刺さらず、プロダクトの重要指標を大して改善しない製品ができあがっていく。
プロダクトマネジメントを始めたらやること
プロダクトマネジメントを始めることと、プロダクトマネージャを採用することは同等ではない。プロダクトマネージャの肩書の人間がいてもプロダクトマネジメントができていない組織もあれば、その逆もある。プロダクトマネージャがいる場合もいない場合も、上のようなリスクを回避するために以下のことから始めるとよいだろう。
1. 製品のプロトタイピングを行う
これは主にアーリーステージのリスクを回避するために最も基本的なことだが、製品を本リリースするまえにモックを作ってニーズを検証することだ。ピボットは製品開発前に行うのが理想ということだ。これに関しては専門的に扱った文献があるので、そちらに委ねたい。
2. プロダクトのターゲットセグメントを明確化する
プロダクトマネジメントの教科書には「どの顧客を対象とするかを決めるべし」と書いていることが多いが、むしろセグメントを決める意味は、「どのセグメントには売らないか」を明確にすることにある。ターゲットセグメントでない顧客がほしいというものは、むしろ作ってはいけないのだ。
例えばエンジニア採用サービスであれば「エンジニアを採用したいITベンチャー企業」というざっくりとしたものであってはいけない。ポテンシャル層の人材を大量に採用したい企業と、優秀層をヘッドハンティングしたい企業では、当然提供するべきものも変わってくる。彼らの予算や、採用したい人材の像、他に使っている採用サービスなど、さまざまな要素の中で自社製品の利用の決め手となる要素を探さなければいけない。単純な固有属性（Bなら企業規模、Cなら年齢等）よりも、ニーズの違いが生じる特徴を探し出すことが重要だ。
3. 製品のKPIを定める
プロダクトマネジメントのいない開発形態だと、機能開発のフォーカスが散逸化してしまうため、劇的に数値改善することは稀だ。良いプロダクトマネージャは、ゴールを達成するのに重要と思われるプロダクトの特定の数字にフォーカスし、顧客が言っていないことでもそこのフォーカスめがけて仕様をつくる。これは受動的な製品開発では起こりにくいことだ。
このためには、製品のゴールから分解したKPIを定める必要がある。それに目標を設定して、優先度の評価をその指標ベースでやっていく。たとえば採用サービスであれば、毎月の面談数や、それに至る前の閲覧候補者数、あるいはセッション（訪問）あたりの閲覧候補者数などだ。
4. プロダクトロードマップを作る
プロダクトロードマップというのは、ビジネスニーズや全社的な戦略に合わせ、N年後にプロダクトがどうなっているのかというビジョンとそこに至るまでのマイルストンを定義したものだ。Nの数字としては3〜4年が妥当といわれるかもしれないが、自分としては半年、長くても1年で十分だと考えている。スタートアップにとっては半年後の未来は予想できず、不用意に先のことを考えてもどうせ変更することになるので、直近のプロダクト開発に関わることを考えれば十分だろう。
5. 顧客のPainの優先度を明らかにする
重要な課題にフォーカスするための方法は、ペインマップを作ることだ。ペインマップは顧客がゴール達成のために課題に感じている辛さ（Pain）を重要な順に並べ、それぞれの因果関係をまとめたものだ。
顧客のペインを可視化する前は、チーム内で重要な開発についての仕様に関して意見が割れていたり、機能開発の優先度の認識がずれることもしばしばあった。プロダクトマネージャはこれを統一し、チームのリソースを重要な課題に充てなければいけない。プロダクトマネジメントをしていなければこれはランダムな順番で解決されていくが、本当は上にある課題から解決していくべきなのだ。
6. 計測をし、機能開発の振り返りを行う
プロダクトマネジメントにおいては、開発した機能の効果計測を行い、それを次の仕様定義に活かすことは、仕様を定義して開発を行うこと以上に難しい。大きな組織ではこれについてABテスト基盤や検証基盤が整っていることもあるが、この基盤を整えるのはとてもむずかしい。しかし、これができなければ次に作る機能の仕様のクオリティを上げることや優先度づけの精度を改善することはできない。これに関しては非常に奥が深いので、別な機会に記事化しようと思う。
通常、これらを全部やるとなるとパートタイムのプロダクトマネジメントだとまかないきれず、少なくともフルタイムの一人が必要となる。これは到底エンジニアやデザイナの片手間ではまかないきれず、おろそかにすると初期の事業成長スピードを大きく損なう可能性がある。アーリーステージだからなどといわず、アーリーだからこそプロダクトマネジメントに時間を割くべきなのだ。後半に書いたことについてはここでは書ききれないことも多いので、別に掘り下げる記事を書く予定だ。
