死なないための、プロダクトマネジメント
プロダクトマネージャー Advent Calendar 2022 ならびに、
Showcase Gig Advent Calendar 2022 17日目の記事です。
今回は、「スタートアップ、冬の時代」などと言われて早半年ほどになりますが、プロダクトマネジメントにおいてこの状況をどう捉え、変えていくべきなのかについて、ここ半年近くで考え取り組んできたことについて振り返る記事です。
スタートアップ、冬の時代の到来
だいぶ出過ぎたタイトルをつけてしまったなと思いつつ、タイトルは以下の記事より拝借させていただいております。
(もっといえば、ポール・グレアムのエッセイなんでしょうが)
こちらの記事は2022年6月16日に公開されており、さらに言えばセコイア・キャピタルのAdapting to Endureについては2022年5月16日です。
つまり、この記事が出てから半年が経過したことになりますが、世界を見回すと以下のようなニュースが出てきています。
このように、Tech企業を中心としたレイオフの波が押し寄せているのが実情です。
私自身、これらの話について特段詳しいわけでも無いので私見は述べないものの、外部環境は大きく変わり、企業/事業に対して十分な影響を与えている状態にあることは火を見るより明らかです。
さて、このように大きな外部環境の変化が発生している状況において、プロダクトマネジメントを従来と同じような考え方で進めて良いはずはなく、この波を乗りこなせるよう適切に舵取りを変えていく必要があるでしょう。
成長性重視から、収益性重視へ
ゲームチェンジの要点としては、先程の「死なないために」の冒頭の文章に記載されている4点で表されます。
・タダだった資本は今や高価に
・資本がタダの時代はより多くの資本を消費する会社がベストだった
・資本が高価になった今はこれらの会社はワーストな会社になった
・1ドル1ドルが以前よりもより大切になった時、優先順位をどうかえていくのか
また、以下の記事も合わせて読むことで、より詳細に状況を捉えることができるでしょう。
1. 投資基準の厳格化
昨年までは市場全体のカネ余り状態だったため、SaaS企業の時価総額は「成長率」主体に引っ張られる状態でした。VCもTiger Globalのようなクロスオーバー投資家の参入により、投資検討プロセスを極端に短くして、「成長可能性」だけを評価して投資を進めていました。しかし金融引き締めによって、環境は一転。「成長率のみ」から「成長率と将来的な利益創出の可能性のバランス」にシフトしました。正常化したといった方が正しいかもしれません。
この「成長と利益のバランス」を評価することは、VCでの評価の難易度は格段に上がります。粗利やキャッシュフローサイクルなど数多くの財務指標のみならず、市場の分散・寡占性、市場でのポジショニング、業界の商習慣など、考慮する点は多くなります。またPMFを本当に実現しているかどうかも、よりシビアに見られるようになったと思います。このように、VCの投資基準の変化が選別の一因になったと考えられます。
裏を返せば、もともと成長率と利益創出がバランスするような戦略を取っていた場合は、従来通りのロードマップを遂行すれば大丈夫かもしれません。
一方で、以下のような場合については、一度立ち止まって全面的にロードマップを再点検をするのが良いのではないでしょうか。
意図的に「成長率」にベットする戦略を取っていた
「成長率と将来的な利益創出の可能性のバランス」が取れているのかの検証が十分でない
この「成長率と将来的な利益創出の可能性のバランス」という話は、もちろん最上位である経営戦略上の大きなテーマになるでしょうが、アラインするよう各プロダクト戦略及びロードマップのUpdateを行う必要もあります。
踏まえて、プロダクトマネジメントにおいてはなにを意識すればよいか。
僕の中では以下の2点に収斂されると思っています。
Must haveであることの証明
生産性の向上および優先順位づけ戦略の再考
⚠️ 先に予防線をはっちゃいますが、特段なにか新しい概念などは出てきません。従来よりコストコントロールを意識した戦略を取っていた場合には、明日につながる学びはたぶん無いと思います。どこまでいっても、当たり前のことを当たり前にやりましょうということに尽きますね。予防線おしまい。
1. Must haveであることの証明
このトピックスについては、以下の記事を一読いただくのがよいでしょう。
Must have —— ユーザーにとって「ないと不便」なプロダクト・サービス
Nice to have — ユーザーにとって「あったら便利」なプロダクト・サービス
この市況において、コストカットが各社で行われていくことは必然であり、Nice to haveな製品はまっさきにこの対象となります。
そのため、Must haveであることを蓋然性ある形で証明できることが重要となります。意味のないものを作っていると思っている人は誰一人いないでしょうから、大事となるのは買い手視点であり、定量/定性双方からの裏付けです。
もう「ARR / 契約企業数が伸びているから大丈夫！」といったトップライン指標のみで語る時代ではありません。
セグメンテーション/ターゲティングに見直すべき点はないか？
既存の顧客に対しては本当にPMF出来ているのか？
効率性や継続性を示す指標に課題は生じていないか？
といった検証を、原点に立ち返り実行することが重要となるでしょう。
2. 生産性の向上および優先順位づけ戦略の再考
「タダだった資本」の時代においては「成長性のみ」が重視されており、その実現のためであれば一定の赤を掘るような戦略実行も許容される風土がありました。
そのため、積極的な資本投下を前提に、事業価値を最大化するようなプロダクトマネジメントの実行を行うシーンも多かったように思います。
これが「成長率と将来的な利益創出の可能性のバランス」を重視する時代となり、以下のような変化が生じました。
「タダだった資本」を活用した積極的な資本投下による生産力の最大化
→ 資本は高価になり「生産性」が重要にプライオリティの基準は「成長性のみ」
→ 「成長率と将来的な利益創出の可能性のバランス」が重要に
目指す頂は同じであっても、無尽蔵の体力がある場合と、そうでない場合の山の登り方は大きく異なります。
ここからは、「生産性」や「成長率と将来的な利益創出の可能性のバランス」という言葉について、解像度をあげていきます。
⚠️ 以降、BtoBやSaaSのモデルを前提に記載している箇所が多くなります。
開発投資が収益化されるフローより「生産性」を定義する
まずは、ソフトウェアビジネスにおける「Invest: 投資」および「Return: 効果」がどういう関係性にあるのかを整理します。
なお、ここからの説明にあたっては、以下のnoteにおけるP/L⇔B/S⇔G/Pというモデルを前提に進めていきます。
ソフトウェア企業は「開発投資」を適正に行い、事業価値を最大化するような「資産」を積み上げ、これを滞りなく「収益」へと転換していく一連の活動を継続的に行っていきます。
この一連の活動を以下のようにモデル化したうえで、用語を定義します。
PM: 「生産力ベースのROI」を最大化
EM: 「開発投資」対「総生産力(G/P)」を最大化
GTM Unit: プロダクト(資産)を活用した「収益」の最大化
資本がタダの時代においては、「総生産力(G/P)」を上げる手段として、採用等の「開発投資」を増やすという手段が有効であったが、資本が高価な時代においては「開発生産性」を高めることが求められます。
このような背景より、Four Keysなど用いたパフォーマンス計測の取り組みは、これを定量化し改善へとつなげる有効な手段として、より一層重要となってくるでしょう。
プロダクトマネージャーの立場としては、やはりモノを生み出す速度は事業速度に直結してしまう依存関係があるため、エンジニアリングマネージャーと密に連携したうえで、これを最大化すべく必要な取り組みを明確化していくのがよいのではないでしょうか。
OUTPUTとOUTCOMEのベクトルと速度
先程のモデルは主に「生産性」にフォーカスしていましたが、ここからは資本投下→収益化のサイクルとその阻害要因(= Issue)の関係性について以下のように図示をします。
ざっくり図の説明をすると、
・「開発組織」の「総生産力(以降、G/P)」が、「プロダクト」を生み出す源泉→ これがOUTPUT
・「プロダクト」はB/Sのように「資産」もあれば「負債」もある
・資産の例: 提供価値の向上, UI/UXの向上
・負債の例: 技術的負債, デザイン負債, あたりまえ機能の不足…
・「プロダクト」を市場投入し、利用されることで「価値」「収益」が生まれる→ これがOUTCOME
最速の事業成長を目指していくためには、
OUTPUT: 資産を生み出す速度
OUTCOME: 資産を収益に転換する速度
の双方が同じベクトルを向いた状態で、共に速度を最大化することが重要です。が、現実的にはどこかしらに歪み(=Issue)は生じ続けており、内ソフトウェアで解決できるものについては開発を行うことで解決をしていきます。
ベルトルを揃える話については組織論やマネジメント等のお話となりますのでここでは触れませんが、速度の話については優先度づけにも関わってくるためケース別に整理をしておきます。
OUTPUT > OUTCOME のケース
開発が先行していて、収益化が追いついていないという状態。
資本がタダの時代であれば、「成長のための先行投資」もしくは「OUTCOME人員の増強」などと解釈ができるため問題はないですが、資本が高価な時代においては、特にOUTCOMEの速度に寄与するような内部工数削減等のタスクの優先度を上げていくことを検討するのがよいでしょう。
(もちろん、そもそも作るべきものが間違っている場合も考えられますが。)
OUTPUT < OUTCOME のケース
収益化が先行していて、開発が追いついていないという状態。
この状態は、ビジネスとしては順調であるともいえますが、一方で開発側に負荷がかかり続けている状態であり、技術的負債が生まれやすい状況でもあります。資本がタダの時代であればエンジニアを採用することが最善手でしたが、資本が高価な時代においては、先述の通り「開発生産性」を高めていくための課題の洗い出しを進め、一時的に運用開発のウェイトを高めるorタスクフォースを組成するなどの取り組みを検討すると良いかもしれません。
こういった不均衡を生み出すIssueを見つけ出し、1つ1つ潰しこむことを各部門と連携していくことで、全体のサイクルを加速させていきましょう。
「成長率と将来的な利益創出の可能性のバランス」を評価
ここまでは主に「総生産力(G/P)」や「生産性」にフォーカスしてきましたが、ここからはG/Pを活用していく話に移ります。
先述の通り、プロダクトマネージャーは「生産力ベースのROI」を最大化するための役割を担っており、G/Pの振り分け方 = 優先順位づけというのは重要な仕事の1つと言えるでしょう。
そして、冒頭で触れていたように優先順位づけは、
「成長性だけ」 → 「成長率と将来的な利益創出の可能性のバランス」
へとシフトさせる必要があります。
これを示す指標はビジネスモデルによって大きく異なるため一般化は難しいですが、例えばSaaSの場合は以下のような指標が候補となります。
成長性: MRR/ARR, TAM/SAM
将来的な利益創出の可能性: Unit Economics, Payback Periods
これらをバランスさせながら成長するようにEpicやStoryに対して優先順位づけをしなくてはならないので、この難度がぐっとあがったというのは想像に難くないでしょう。
2の内容を踏まえ、実際に行ったこと
ここまでは概念的な話が中心でしたが、ここからは実際にどのような取り組みを行ったのかについて紹介をしていきます。
大きく3つのテーマに分類し、それぞれ見直しをかけています。
OUTPUT速度の向上: G/Pの計測と改善
OUTCOME速度の向上: GTMプロセスの見直し
OUTPUTをOUTCOMEへと転換:
リソース(G/P)の分配方針を明確化
優先度策定のロジックを変更
⚠️ BtoB(toC) SaaSを前提としており、以降はSaaS色が強まります。
1. G/Pの計測と改善
これについては、弊社EMの記事にてFour Keysに関する取り組みが触れられておりますので、ぜひご覧になってください。
2. GTMプロセスの見直し
従来はプロダクト体系としてもシンプルであり、チームとしても長いメンバーが多かったため、よくも悪くも阿吽の呼吸で回っていました。
ですが、直近ではプロダクトや組織も成長し、またリリースの頻度も高くなったことで、認識齟齬や取りこぼしが発生しやすい状況になっていました。
そこで、GTMフェーズでやるべきことを定形化し、同時期に組成したOpsチームに協力をいただきながら、これを開発と並行する形で常に回し続けるという取り組みをはじめました。
このプロセスを定めてから半年弱となりますが、ようやく安定して回りつつあるかな…といった現在地です。
ですが、着実に顧客に対して価値が届く範囲も速度も改善されている実感は得られているので、引き続きここは洗練させていきたいですね。
3-1. リソース(G/P)の分配方針を明確化
上記のnoteにて、以下のようなことを書いておりました。
優先順位づけには大きく2つのアプローチが取りうるでしょう。
1. 要求元毎に優先順位付けし、リソース比率でコントロール
2. 複合的な重み付けのルールを定め、スコアに応じた優先順位付けを行う
弊社では1,2をミックスするような形を採用しています。
プロダクト(B/S)由来のものを「資産」と「負債」に分解したうえで、大きく2つに分割をします。
運用開発: Outputに影響するもの + プロダクト(負債)
→「総生産力(G/P)」の観点から優先度を定める
新規/導入開発: Outcomeに影響するもの + プロダクト(資産)
→「成長性/収益性」の観点から優先度を定める
※ 「新規/導入開発」とひとまとめにしていますが、導入のために必要となる開発が一定以上発生することが予期されている場合は、「新規開発」と「導入開発」のように分離しておくのが良いでしょう。
そして、これらに対してG/Pをどのように差配するかの割合について関係各位と合意を取りましょう。ここはしっかりと握りましょう。大事です。
(e.g. 成長フェーズであれば8:2、運用フェーズであれば3:7など。)
これによって「開発プロセス」におけるリソースを事前に割当てることができ、それぞれで「優先度の決定」を行えるようになるため議論を単純化することが出来ます。
💡余談にはなりますが、このような切り方で工数管理をすることで、資産計上 or 研究開発費といった管理も楽になるのではないでしょうか。
3-2. 優先度策定のロジックを変更
ここからは先程の分類に基づき、それぞれ優先度を決定していきます。
上図のようなIssueのなりたちを踏まえて、優先度の意思決定を行うメンバーをそれぞれ定めます。
運用開発: 「総生産力(G/P)」の観点から優先度を定める
・CTO / Engineering Manager… : Outputを最大化する責務を持つ
・Product Manager: 「生産力ベースのROI」を最大化する責務を持つ
新規/導入開発: 「成長性/収益性」の観点から優先度を定める
・Sales / CS / Marketing / PR… : Outcomeを最大化する責務を持つ
・Product Manager: 「生産力ベースのROI」を最大化する責務を持つ
そして、それぞれに比較軸を設定し、優先順位の評価を行います。
運用開発: 「総生産力(G/P)」の観点から優先度を定める
→ 定量化しづらいものが多く含まれるため、基本的に相対評価。
新規/導入開発: 「成長性/収益性」の観点から優先度を定める
→ Epic単位でICEスコアリングを用いて評価。
Impactについては、「成長性/収益性」の双方の指標をそれぞれ入力。
ただし、「導入開発」に類するものについては導入企業単位で扱う。
また、Business Objectiveというラベルを追加し、収益化までの時間軸で分類することで、目的を明確化しつつ評価項目を多少変動させている。
・Profit: 直近の売上向上を目的とする。P/L Hitの確実性を重視し評価。
・Growth: 現在の売上の伸長を目的。メトリクスを重視し評価。
・Driver: 将来的な売上向上を目的。マーケット分析等の結果で評価。
このように全体を再整理したことで、「成長率と将来的な利益創出の可能性のバランス」を折り込みつつ、比較的リーズナブルな形での運用が実現出来るようになったかなと思っていますが、いかがでしょうか。
⚠️ 「優先度の決定方法」の部分については、自分の中の理想もあれば他の部門の理想もあるため、実際にはまだまだ道半ばです。
今回は、あくまで最終的に着地させたい理想形を書いておりますので、そういう意味ではだいぶ盛っていますね、がんばります。
おわりに
全部読んでいただいた方には申し訳ないくらいに、実際にやったことはシンプルでありサプライズはなかったかと思います。
改めて凡事徹底を大切に、もし甘い部分が見えた場合は早急に見直しをかけることで、未来の障壁を事前に回避できる良い機会でもあるかと思います。
アプローチは1つではないですが、なにか少しでも参考になる点があれば幸いです。また、もし他にこういうことをやったよ！みたいなお話があればぜひTwitter (@yukagil) などで教えていただけるととても嬉しいです。
それでは、みなさま良いお年を🎍
いいなと思ったら応援しよう！
