「早すぎる売上目標」の裏にあるリソース・アロケーションのジレンマ
estieがハマった落とし穴
「1年でX億円のARRを積む」
私たちはそんな「事業計画的なマイルストーン」を新規プロダクトの年間予算に書き込んでしまった1年がありました。結果は達成率40%弱。売上数字を追うほど顧客課題の解像度が下がり、営業効率の悪い状態が続き、PMFはむしろ遠のいたように感じる──これが私たちが経験した一番の落とし穴だったと言えます。
年間予算に売上を織り込んだことで学習速度が落ちる
当時の現象を時系列に置いたものは以下になります。
時系列 | 何が起きたか | 見えた副作用 |
---|---|---|
0~3か月 | 年間予算にARR X億円を計上 | 「売上を追う」ということが目的関数となってチームが動き始める |
4~6か月 | PoCを量産して早期 MRRを稼ぐ | PoCは増えたものの顧客セグメントが発散。機能要望がバラバラに。また、PoCの数が思ったより好調に増えたことで「うまくいっている」という錯覚に |
7~9か月 | MRRは増えるが利用ログが横ばい | 理想のユースケースは見つかり切らない。MRRは一定規模で増加するもののPoCから本導入への移行確率は低い |
10か月~ | ARR目標の達成率はもとより、営業の成約率が低い | 事業計画の再編とチーム体制やプロダクト体制の大幅見直し |
私たちがこの経験を通じて得た副作用の核心は以下の2つです。
- 売上を追うあまり、誰のどんな課題を解くかを深掘る前に複数セグメントへ営業を広げたこと
- その結果、プロダクト価値や成功条件があいまいになり、学習水準が下がったこと
予算計画を追うことで、本来プロダクトとして追うべき「顧客課題の解決」とそのための「検証および学習」が追及されず、PMFから遠ざかることになります。
新規プロダクトにおいて事業計画上の予算目標を設定するということは、そのプロダクトへの期待でもあります。
しかし、実際にそれを行ってよい企業は、「自社におけるPMFの型」ともいえるものを完成させた企業だけです。それも、同種のプロダクト特性やビジネスモデル、顧客基盤を取り扱うものに限られると考えています。なぜならば、プロダクト特性、ビジネスモデル、顧客のどれか1つが異なってもその成功確率はぐっと下がるからです。
そういった型がなく、十分な確率計算もできない状態で「予算に入れたい」と考えてしまうのは「経営的な要請」であり、いわばある種の誘惑と言えます。
それはプロダクトや顧客を起点とした意思決定ではありません。本当に顧客課題の解決とプロダクトの成功を願うならば、予算計画に入れずに、ひたすらにプロダクト価値を計る指標を追うべきだと今は確信しています。
複数セグメントを同時に追うリスク──「スケール欲」が招くフォーカスの乱れ
「複数セグメントを追ってしまい、プロダクト価値がブレる」
これは売上目標を追うことで起きる本質的な問題だと考えています。
私たちも当初は、比較的規模は小さいものの課題の深さが際立つニッチセグメントAに絞ってPoCを実施していました。検証は順調に進み、定量・定性の両面で手応えを確認できていたのですが、正式リリース後まもなく、より大きなセグメントBからも導入相談をいただくようになりました。
「今なら一気に市場を広げられるのではないか」という期待が高まり、両セグメントの要望を並行して取り込む方針を選んだことが、結果的にPMFまでの速度を遅くしてしまった要因です。
プロダクト要件の衝突で「帯に短し」に陥る
開発チームはスプリントごとに「今回はどちらを優先するか」を議論せざるを得ず、バックログがセグメント別の要望で細切れになりました。その結果、どちらのセグメントにとっても「あと一歩足りない」プロダクトとなり、利用率が伸び悩むことになります。
観点 | セグメントA | セグメントB | 衝突の結果 |
---|---|---|---|
コア課題 | 業務効率化に直結する具体的な機能を重視 | データ可視化や拡張性を重視 | どちらの課題も中途半端にしか解決できず、導入効果が見えづらくなる |
価格感 | 機能対価より導入の手軽さを重視 | 拡張性が高ければ多少高くても許容 | プライシングの根拠がぶれ、営業が説明しづらくなる |
オンボーディング | シンプルなフローを希望 | カスタマイズを前提 | オンボーディング手順が複雑化し、工数が二重に掛かる |
売上を重視した結果、事業効率性が下がる
- PoCから本導入への転換率が想定の6割程度にとどまりました。
- 成約率は当社の既存PMFプロダクトと比べておよそ半分に低下しました。
- 初期解約率も同期間比で上昇し、学習に必要なサンプル数がなかなか確保できませんでした。
数字が示すとおり、ペインの深さと機能の鋭さがかみ合わなくなったことが最大要因です。顧客からは「便利ではあるが、既存のフローを置き換えるほどではない」という声が多く寄せられ、PMFから遠ざかってしまいました。
フォーカスは「不確実性を不要に高めない手段」
セグメントが増えるということは、それだけプロダクト検証とユーザーフィードバックに対応する複雑性が増すことにつながります。それらは自己増幅型フィードバックループを描いており、次々に押し寄せ自ら複雑性を高めていきます。
そういった状態を引き起こさないためにフォーカスが必要であり、フォーカスを妨げてしまうような不要なKPI設計を行わないことが重要です。
絶えず生じるリソースアロケーションのジレンマ
新規プロダクトを予算計画に入れたくなる背景には、リソースアロケーションの問題が存在しています。企業経営の常ですが、「リソースが十分であり、余っている」ということはほとんどありません。
そういった環境を前提に「リソースを起点」として事業を見ると、新規プロダクトや新規事業の立ち上げを行うことに使うリソースを、既存事業のプロダクトに投ずることでその成長を加速させる選択肢もあります。
このリソースアロケーションの選択肢があることで、「本当に新規事業にこのリソースを投じてよいのか」という問いが生まれていきます。そうなると、新規事業に投じた分、十分なリターンがあるという証明や説明責任が必要となり、結果として「既存事業に負けない売上を作る→予算計画に入れる」という方向に議論が導かれることになります。
ここも経営としての胆力が試される場所になります。そもそも既存事業の成長と新規事業・新規プロダクトで得たい成長は時間軸が異なります。この時間軸の違いを許容し「連続的PMFを生むための十分な時間とリソースを投じられるか」という覚悟が問われているとも言えます。
私たちは、その問いを正面から受け、経営としては以下のような変化を生んでいきました。
# | 対応策 | 実際にやったこと | 効果 |
---|---|---|---|
1 | 顧客価値検証を最重視 | 売上KPIをチームから外し、顧客価値KPIのみを目標設定に変換 | 売上ではなく「学習進捗」を起点に運営 |
2 | 専用バジェット化 | 開発リソースをロックし、リソースアロケーション対象にしないことを決定。代わりに撤退期限を設定 | 明確な「時間」を決め、その中で最大の成果が出る形を担保 |
軌道修正を経て時間はかかりましたが、チャーンは少しずつ低下傾向に至り、PMFしているプロダクトセグメントの整理も進んでいます。まだ十分なゴールは遠い状態ですが、「売上より学習を守る」仕組みを入れることができています。
また、これ以降に立ち上げたプロダクトについては、少なくとも同じ穴に二度落ちることなく、いずれも6か月~9か月と短期でPMFへと至っており、経営としての失敗は繰り返さない再現性が生まれている状況です。