プロダクトマネージャー Advent Calendar 2022 ならびに、
Showcase Gig Advent Calendar 2022 17日目の記事です。

今回は、「スタートアップ、冬の時代」などと言われて早半年ほどになりますが、プロダクトマネジメントにおいてこの状況をどう捉え、変えていくべきなのかについて、ここ半年近くで考え取り組んできたことについて振り返る記事です。

スタートアップ、冬の時代の到来

だいぶ出過ぎたタイトルをつけてしまったなと思いつつ、タイトルは以下の記事より拝借させていただいております。
(もっといえば、ポール・グレアムのエッセイなんでしょうが)

こちらの記事は2022年6月16日に公開されており、さらに言えばセコイア・キャピタルのAdapting to Endureについては2022年5月16日です。

つまり、この記事が出てから半年が経過したことになりますが、世界を見回すと以下のようなニュースが出てきています。

このように、Tech企業を中心としたレイオフの波が押し寄せているのが実情です。

私自身、これらの話について特段詳しいわけでも無いので私見は述べないものの、外部環境は大きく変わり、企業/事業に対して十分な影響を与えている状態にあることは火を見るより明らかです。

さて、このように大きな外部環境の変化が発生している状況において、プロダクトマネジメントを従来と同じような考え方で進めて良いはずはなく、この波を乗りこなせるよう適切に舵取りを変えていく必要があるでしょう。

成長性重視から、収益性重視へ

ゲームチェンジの要点としては、先程の「死なないために」の冒頭の文章に記載されている4点で表されます。

また、以下の記事も合わせて読むことで、より詳細に状況を捉えることができるでしょう。

裏を返せば、もともと成長率と利益創出がバランスするような戦略を取っていた場合は、従来通りのロードマップを遂行すれば大丈夫かもしれません。

一方で、以下のような場合については、一度立ち止まって全面的にロードマップを再点検をするのが良いのではないでしょうか。

• 意図的に「成長率」にベットする戦略を取っていた

• 「成長率と将来的な利益創出の可能性のバランス」が取れているのかの検証が十分でない

この「成長率と将来的な利益創出の可能性のバランス」という話は、もちろん最上位である経営戦略上の大きなテーマになるでしょうが、アラインするよう各プロダクト戦略及びロードマップのUpdateを行う必要もあります。

踏まえて、プロダクトマネジメントにおいてはなにを意識すればよいか。
僕の中では以下の2点に収斂されると思っています。

1. Must haveであることの証明

2. 生産性の向上および優先順位づけ戦略の再考

1. Must haveであることの証明

このトピックスについては、以下の記事を一読いただくのがよいでしょう。

この市況において、コストカットが各社で行われていくことは必然であり、Nice to haveな製品はまっさきにこの対象となります。

そのため、Must haveであることを蓋然性ある形で証明できることが重要となります。意味のないものを作っていると思っている人は誰一人いないでしょうから、大事となるのは買い手視点であり、定量/定性双方からの裏付けです。

もう「ARR / 契約企業数が伸びているから大丈夫！」といったトップライン指標のみで語る時代ではありません。

• セグメンテーション/ターゲティングに見直すべき点はないか？

• 既存の顧客に対しては本当にPMF出来ているのか？

• 効率性や継続性を示す指標に課題は生じていないか？

といった検証を、原点に立ち返り実行することが重要となるでしょう。

2. 生産性の向上および優先順位づけ戦略の再考

「タダだった資本」の時代においては「成長性のみ」が重視されており、その実現のためであれば一定の赤を掘るような戦略実行も許容される風土がありました。

そのため、積極的な資本投下を前提に、事業価値を最大化するようなプロダクトマネジメントの実行を行うシーンも多かったように思います。

これが「成長率と将来的な利益創出の可能性のバランス」を重視する時代となり、以下のような変化が生じました。

• 「タダだった資本」を活用した積極的な資本投下による生産力の最大化
  → 資本は高価になり「生産性」が重要に

• プライオリティの基準は「成長性のみ」
  → 「成長率と将来的な利益創出の可能性のバランス」が重要に

目指す頂は同じであっても、無尽蔵の体力がある場合と、そうでない場合の山の登り方は大きく異なります。

ここからは、「生産性」や「成長率と将来的な利益創出の可能性のバランス」という言葉について、解像度をあげていきます。

開発投資が収益化されるフローより「生産性」を定義する

まずは、ソフトウェアビジネスにおける「Invest: 投資」および「Return: 効果」がどういう関係性にあるのかを整理します。

なお、ここからの説明にあたっては、以下のnoteにおけるP/L⇔B/S⇔G/Pというモデルを前提に進めていきます。

ソフトウェア企業は「開発投資」を適正に行い、事業価値を最大化するような「資産」を積み上げ、これを滞りなく「収益」へと転換していく一連の活動を継続的に行っていきます。

この一連の活動を以下のようにモデル化したうえで、用語を定義します。

資本がタダの時代においては、「総生産力(G/P)」を上げる手段として、採用等の「開発投資」を増やすという手段が有効であったが、資本が高価な時代においては「開発生産性」を高めることが求められます。

このような背景より、Four Keysなど用いたパフォーマンス計測の取り組みは、これを定量化し改善へとつなげる有効な手段として、より一層重要となってくるでしょう。

プロダクトマネージャーの立場としては、やはりモノを生み出す速度は事業速度に直結してしまう依存関係があるため、エンジニアリングマネージャーと密に連携したうえで、これを最大化すべく必要な取り組みを明確化していくのがよいのではないでしょうか。

OUTPUTとOUTCOMEのベクトルと速度

先程のモデルは主に「生産性」にフォーカスしていましたが、ここからは資本投下→収益化のサイクルとその阻害要因(= Issue)の関係性について以下のように図示をします。

最速の事業成長を目指していくためには、

• OUTPUT: 資産を生み出す速度

• OUTCOME: 資産を収益に転換する速度

の双方が同じベクトルを向いた状態で、共に速度を最大化することが重要です。が、現実的にはどこかしらに歪み(=Issue)は生じ続けており、内ソフトウェアで解決できるものについては開発を行うことで解決をしていきます。

ベルトルを揃える話については組織論やマネジメント等のお話となりますのでここでは触れませんが、速度の話については優先度づけにも関わってくるためケース別に整理をしておきます。

こういった不均衡を生み出すIssueを見つけ出し、1つ1つ潰しこむことを各部門と連携していくことで、全体のサイクルを加速させていきましょう。

「成長率と将来的な利益創出の可能性のバランス」を評価

ここまでは主に「総生産力(G/P)」や「生産性」にフォーカスしてきましたが、ここからはG/Pを活用していく話に移ります。

先述の通り、プロダクトマネージャーは「生産力ベースのROI」を最大化するための役割を担っており、G/Pの振り分け方 = 優先順位づけというのは重要な仕事の1つと言えるでしょう。

そして、冒頭で触れていたように優先順位づけは、
「成長性だけ」 → 「成長率と将来的な利益創出の可能性のバランス」
へとシフトさせる必要があります。

これを示す指標はビジネスモデルによって大きく異なるため一般化は難しいですが、例えばSaaSの場合は以下のような指標が候補となります。

• 成長性: MRR/ARR, TAM/SAM

• 将来的な利益創出の可能性: Unit Economics, Payback Periods

これらをバランスさせながら成長するようにEpicやStoryに対して優先順位づけをしなくてはならないので、この難度がぐっとあがったというのは想像に難くないでしょう。

2の内容を踏まえ、実際に行ったこと

ここまでは概念的な話が中心でしたが、ここからは実際にどのような取り組みを行ったのかについて紹介をしていきます。

大きく3つのテーマに分類し、それぞれ見直しをかけています。

1. OUTPUT速度の向上: G/Pの計測と改善

2. OUTCOME速度の向上: GTMプロセスの見直し

3. OUTPUTをOUTCOMEへと転換: 

   1. リソース(G/P)の分配方針を明確化

   2. 優先度策定のロジックを変更

1. G/Pの計測と改善

これについては、弊社EMの記事にてFour Keysに関する取り組みが触れられておりますので、ぜひご覧になってください。

2. GTMプロセスの見直し

従来はプロダクト体系としてもシンプルであり、チームとしても長いメンバーが多かったため、よくも悪くも阿吽の呼吸で回っていました。
ですが、直近ではプロダクトや組織も成長し、またリリースの頻度も高くなったことで、認識齟齬や取りこぼしが発生しやすい状況になっていました。

そこで、GTMフェーズでやるべきことを定形化し、同時期に組成したOpsチームに協力をいただきながら、これを開発と並行する形で常に回し続けるという取り組みをはじめました。

このプロセスを定めてから半年弱となりますが、ようやく安定して回りつつあるかな…といった現在地です。

ですが、着実に顧客に対して価値が届く範囲も速度も改善されている実感は得られているので、引き続きここは洗練させていきたいですね。

3-1. リソース(G/P)の分配方針を明確化

上記のnoteにて、以下のようなことを書いておりました。

弊社では1,2をミックスするような形を採用しています。

プロダクト(B/S)由来のものを「資産」と「負債」に分解したうえで、大きく2つに分割をします。

そして、これらに対してG/Pをどのように差配するかの割合について関係各位と合意を取りましょう。ここはしっかりと握りましょう。大事です。
(e.g. 成長フェーズであれば8:2、運用フェーズであれば3:7など。)

これによって「開発プロセス」におけるリソースを事前に割当てることができ、それぞれで「優先度の決定」を行えるようになるため議論を単純化することが出来ます。

3-2. 優先度策定のロジックを変更

ここからは先程の分類に基づき、それぞれ優先度を決定していきます。

上図のようなIssueのなりたちを踏まえて、優先度の意思決定を行うメンバーをそれぞれ定めます。

そして、それぞれに比較軸を設定し、優先順位の評価を行います。

このように全体を再整理したことで、「成長率と将来的な利益創出の可能性のバランス」を折り込みつつ、比較的リーズナブルな形での運用が実現出来るようになったかなと思っていますが、いかがでしょうか。

おわりに

全部読んでいただいた方には申し訳ないくらいに、実際にやったことはシンプルでありサプライズはなかったかと思います。

改めて凡事徹底を大切に、もし甘い部分が見えた場合は早急に見直しをかけることで、未来の障壁を事前に回避できる良い機会でもあるかと思います。

アプローチは1つではないですが、なにか少しでも参考になる点があれば幸いです。また、もし他にこういうことをやったよ！みたいなお話があればぜひTwitter (@yukagil) などで教えていただけるととても嬉しいです。 

それでは、みなさま良いお年を🎍