クソデカプロダクト組織で、小さいプロダクトチームを生き残らせる方法
こんにちは、米国SaaS企業でプロダクトマネージャーをしています、ハヤカワです。
先日呟いた、こちらについてサクッと書いてみます。
年末書きたいnoteテーマメモ
— kaz☁product (@kzkHykw1991) December 22, 2022
「クソデカプロダクト組織で、小さいプロダクトチームを生き残らせる方法」
小さく早く作る、成功顧客を示す、数字を示す、徐々に広げる、偉い人捕まえる、目立つ
前提
B2B SaaSプロダクト組織において、
プロダクト数が100を超え、
プロダクトマネージャーが100-1000人いる組織
での話になります。
クソデカプロダクト組織
私の会社のことを、クソデカプロダクト組織と称したわけですが、前提のような規模の組織になります。
ざっくり表現すると、6-7階層くらいあるプロダクト組織って感じです。
ただ、これ社内的な役職だったり、階級だったりでかなり複雑(曖昧)に分かれています。
お客さんから見たイメージを左に追加しました。
具体的なプロダクト組織の話をすると、KPIとか、関係性とか、協業とかいろんな話をしたいので、いつかまた話したいと思います。
今回は、こんなクソデカなプロダクト組織で1からプロダクトチームを作り上げる流れを考察していきたいと思います。
※ここからの話は、もちろん私一人で体験したものではなく、実際には私のマネージャーとチームで一緒にやってきたことをまとめた話になります。
クソデカプロダクト組織で、小さいプロダクトチームを生き残らせる方法
全体の流れ。
小さく早く作る
数字を示す
成功顧客を示す
徐々に広げる
偉い人を捕まえる
目立つ、を繰り返す
1. 小さく早く作る
大きなプロダクト組織では、①トップダウン、②ボトムアップ、二つのアプローチで新規プロダクトを開発します。
どっちが正しいということはなく、状況や扱うもの、不確実性や戦略性に基づいて、両方のアプローチが取られると思います。
①トップダウンアプローチは、エグゼクティブの意思決定や、市場動向に基づく将来予測、競合他社,協業企業との戦略的な動き、など私には分からない様々な手法があるので、ここでは書きません。
②一方ボトムアップとしては、1プロダクトチームや、プロダクトマネージャーが提案し、上に上げることがあります。この時の流れを大まかに書きます
既に担当しているプロダクトを通して顧客の声を集める
既存プロダクトではカバーできない要望が見つかる
その要望が、数、ビジネスインパクトともに、強い要望だとわかる
その要望の確らしさを見るために、UXリサーチチームとリサーチする
リサーチ結果をもとに、新プロダクトの可能性ある領域を発見する
既存プロダクトで持っている予算でやりくりして、0バジェットで新プロダクトのMVPを作ってみる
この流れは一般的な新プロダクトのDiscovery(発見)フェーズと同じだと思いますが、これを既存チーム内で0バジェットで行う必要があります。
0と言っても、ボランティアでやるわけではなく、既に持っているプロダクトチームの予算範囲内で挑戦します。
特に、ステップ6では、既存のエンジニアチームのEM(Engineering Manager)と合意することも大事です。彼らも含めて新領域への期待、 Opportunityを求めて、新規プロダクトを作ろう！となります。
また、UXリサーチを行うと、未開拓の3-5つのソリューション領域が見つかります。全部やりたいと思う一方で、MVPとしては、
①最もビジネスインパクトがあるもの
②現在のチームがレポーティングしている組織のKPIに最も影響力を与えるもの
の掛け算で選択し、それを満たす最小で最大の価値のある機能から着手します。
1)エンジニアリングリソース、2)UXリサーチ結果、3)MVPのPRD、この3つをもとに小さく早く作ることが、クソデカプロダクト組織で新プロダクトを作る最初の一歩だと思います。
2.数字を示す
MVPを開発するときに、最終的に最も大事なのは「成功を数字で示すこと」です。このとき行うステップは
製品利用データ(instrumentation)が取れるように事前に開発していく
製品利用データはビジネスインパクト(お金＝価値)にできるだけ直結して換算できるものにする
成功顧客になっている顧客企業を見つけ、この数字を示してもらうようにする
ということです。
製品利用データは開発が始まる前に、一般的なプロダクトマネージャーとしても考えなければいけないことです。
とある製品Aがあった場合に、ただ作って終わりではなく、作った後にその製品が価値を届けているか？を計測するような以下のような製品利用データを取れるようにする必要があります。
アクセス数
ダウンロード数
有効化数 (Activation)
クリックやマウスオーバーなどの操作ログ
機能特有の何かしらの実行数 (最終的に価値を提供する部分)
今回のように0バジェットでMVPを作る場合は、有料ライセンスの販売にまでは至っていません。
つまり、ダウンロード自体は無料ライセンス (Freemium)だったり無償で顧客企業が使えるパイロットやベータ状態だったり、そもそも無料のアドオンや簡易ツールの可能性があります。
なので、成功を示すにあたっては、これだけのニーズが既にあるんだ！ということを事前に社内に訴える必要があります。
そのためには、アクセス数やダウンロード数は有効だと思います。しかし、それだけでは想像で終わってしまい、説得力に欠けます。
そこで重要なのが、その製品がもたらす顧客価値の定量化です。
例えば、顧客企業の生産性を向上するための機能だった場合は、製品利用データから、製品がもたらす価値を示せるようにしておく必要があります。
例として、生産性を向上するためのAIレコメンデーション機能だった場合。レコメンドしたコンテンツのクリック数が取れると、
[ビジネスインパクト = クリック数 x 削減作業時間 x ユーザー数]
という形で、この新機能を通して、企業が○○万円の年間の価値創出につながると示せます。
この数字は、有償化する際のプライシングの目安になりますし、今後本格開発をするときの予算配分にも影響します。
これらをまとめて、MVPリリース後このような社内メール(slack)を各チームに流すことで、数字によって新プロダクトの成功を示していきます。
私たちのチームでは、新プロダクトXXXXを先月パイロットリリースしました！
このプロダクトは、既存顧客の[…]という課題を解決するために、[…]という目的で開発を開始しました。
リリース後、1ヶ月で顧客企業5社に利用してもらいました！
これらの企業は、年間で約X,000万円の生産性向上をこの製品を通して達成できます。
製品が[…]人に平均[…]だけ使われることで、[…]の生産性向上が期待できるからです。
このようなアナウンスを他チームやExecutiveに送りつけます。
しかし、ただ数字を示すだけでは、少し冷たい、プロダクトの温度感が伝わりませんよね？そこで、次のステップです。
3.成功顧客を示す
この成功を示すために統計的な数字も有効ですが、初期は顧客数があまり多くはないため、全体で見ると既存製品の規模には敵いません。そこで、一企業あたりで見た時のインパクトにするために、良好な関係を持つ顧客企業の成功事例を、ユーザーの声を引用して伝えます。
例えば、先ほどの、アナウンスメント文の続きとして
この内の一社の企業[…]社の営業部長である[…]さんは、このように語ってくれています。
"このツールのおかげで、今までできていなかった[…]が、素早くできるようになりました"((顧客の声の引用)
このように、この新製品[…]を通して、今まで提供できていなかった新しい価値を提供することができました。
今後、私たちのチームでは、以下のロードマップをもとに開発を行います。
・[次のリリース]: […]を可能にする新機能A, […]を改善する新機能B
・[次の次のリリース]: […]を可能にする新機能C, […]を改善する新機能D
この製品へのフィードバックや質問がある場合はこちらのチャネルでお気軽にコメントを！
#xxxx-xxxx-xxx (slack)
かなり想像の範疇で書いてしまいましたが、要は「顧客の声を引用して示して」プロダクトの成功を顧客に代弁してもらうことが重要だと思います。
これこそ、クソデカプロダクト組織で、小さいプロダクトチームを生き残らせる最も重要な方法だと思います。
4.徐々に広げる
さて、MVPをリリースし、3ヶ月ほどして、成功顧客が2社、３社と増えたときに、次にすべきが他の領域にMVPを広げる、です。
ここで注意なのが、まだソリューションの検証が済んでいないので、リサーチで発見した、他のソリューション領域に手を出すのではなく、同じ価値の範囲内で、中身だけを変えて広げるのが大切だと思います。
例えば、MVPが既存製品Aと組み合わせて価値を発揮するものだった場合、類似する既存製品Bとの組み合わせをした機能を開発する、といった感じです。
そのようにして、MVPでありながらも同じ価値のベクトルの中で、機能ポートフォリオを広げていきます。
もし広げる余白がない場合は、ここは飛ばしてもいいと思います。
何度も言いますが、ポイントはステップ3「成功顧客を示す」で検証している課題とソリューションの仮説を逸脱した形での新領域にはまだ手を出さないことです。愚直に延長線上で機能範囲を伸ばしていきます。
無駄な機能を作らないよう注意しましょう。
5.偉い人を捕まえる
さて、半年ほど経ち、顧客企業が増え、機能を備わってきたところで、必要になってくるのが、社内のエグゼクティブスポンサーです。後押ししてくれる偉い人ですね。
ステップ1-3あたりでももちろんエグゼクティブスポンサーはうっすらといますが、エグゼクティブとしても絵に描いた餅を背負ってくれることは少ないと思います。
そこで、ステップ4あたりになりビジネスインパクトが明確になってきたときに、明確にバックアップしてもらいます。例えば、
社内Slackでよくメンションして、コメントをもらう
月次の定例とかでしゃべってもらう
全体会議で言及してもらう
社外イベントで言及してもらう
特に、会社のエグゼクティブが集うMTGで紹介してもらったり、資料や動画で残る形で言及してもらったら、それをお祭りのように盛り上げ、「俺たちのチームの新製品がスポットライトを浴びたぜ！」と社内に言いふらします。
このようにして、どうやらあのチームのあの製品がいい感じらしいというのを社内に伝えます (細かい数字やKPIの達成は、他チームからすると興味ないので、それよりもエグゼクティブがよく言及してくれる、方が社内インパクトがあります)
6.目立つ、を繰り返す
そして、最後のステップがここまでのステップを何度も繰り返して、社内的に目立っていくことだと思います。
成功顧客を毎月のように社内ニュースレターやSlackで流し、利用状況も発信し、エグゼクティブに言及してもらうように関係性を構築し、新しい機能を追加し、、、を繰り返していきます。
このようにして、来期の開発の予算をもらい、ヘッドカウント(人員をもらい)、新プロダクトを徐々に安定したプロダクトチームのものに昇格していきます。
失敗するパターン
ここまで成功パターンを書いてきましたが、そうはいかないこともあります。例えば、
今所属しているプロダクトチームのリーダーが持つKPIにそぐわない
普通にユーザーが増えない
エグゼクティブスポンサーが得られない (会社全体の戦略に合わないなど)
成功事例になってくれる顧客企業が増えない (利用者数は増えているがうまく使えていないかも)
開発が進まない (エンジニアチームの優先度を上げられていない)
このような理由で、うまくいかない場合は、素早くプロジェクトを閉じることも大切です。そのための、0バジェットプロジェクトのMVP開発になります。
そのほか
他にも書ききれない成功のための要素としては、
新プロダクトチームの紹介資料をいい感じに作る (まるでスタートアップのpitch deckみたいに)
社内から見てもわかりやすい価値をメッセージングする (通常のプロダクトが市場のユーザーにわかりやすい価値を提供するのと同じ)
既存のクソデカチームとの依存関係を製品上作る (APIや機能連携など、依存関係を作り彼らのデカプロダクトの小判鮫的な製品にする)
おわりに
いかがでしたでしょうか。あくまでも、N=1の私のとあるストーリーでしたが、要素としては、新規事業を立ち上げる際や、実際に大きな組織で一からプロダクトを提案していくときの参考にしてもらえるのではないでしょうか。
このnoteがいいと思った方は、 noteのスキとTwitterのフォローをお願いします！