初めまして @shota_kohara です。BtoB SaaS の soeasy buddy をローンチして2年ほど経過、導入後の成功事例や売り上げにつれ、市場へのフィット感を得てきました。振り返りの頃合いと見て記事を書きます。

この記事は、BtoBのプロダクトをスタートする上で立てた仮説と走り出して実際感じたことをPdMの目線で纏めたものになっています。BtoBプロダクトの立ち上げに興味がある人にとって良い情報になれば幸いです。

※ 念のためここで語る、BtoB, BtoC, CtoC サービスは自分の関わってきたサービスの話で、必ずしも一般化できるものではないので主語が大きくなり誤解を招く表現になってしまったらすいません。

価値の一貫性がプロダクトの中長期成長を支える

今までずっと、BtoC のメディアや CtoC プラットフォームの立ち上げからPMF、その後のグロースを経験してきました。

これらのサービスは、ユーザーがセルフサーブで利用開始、評価するものでした。プロダクト上の体験の中でほとんど全てのことが決まるので、価値はわかり易くコンパクトにプロダクトの中で伝える必要があって、価値の一貫性や体験の必要十分条件を見極め磨きぬくことが重要でした。

そういったプロダクトの一貫性を保ち続けるためには、プロダクトを作るチームが自分たちの価値観を貫く信念を保ち続ける必要があります。そういう価値観を持つためには、己のエゴなどによるプロダクトへの感情的な納得感と、冷徹に数値や反応に向き合って保証される理性的な納得感を保つことが今までは有効でした。いや、逆にこういった意志や客観性を欠いたプロダクトがトレンドに乗って成功したのち、緩やかに衰退していく様子を見たり聞いたりしてきました。

もちろん立ち上げでトレンドは必要不可欠ですが、その後の中長期の成長を支えるのは、意志と客観性による価値の一貫性だというのが今までの学びでした。

BtoBでクライアントを前に意志や一貫性を保つには工夫が必要

BtoBのプロダクト開発は初めてでしたが、今までの学びは生きると考えていました。ただBtoBはサービス利用者が企業になり、今までと同じやり方がそのまま通用するとは考えませんでした。

特に難しそうだと思ったのはプロダクトの意志を保ち続けることです。例えば案件が取れるか取れないかで揺れた時、クライアントワーク的なニュアンスを消すのは難しいと思います。またそもそもで利用者の意見や要望は最大限、糧にした方が良いと考えています。

しかし、要望の捉え方にも注意が必要で、考えなしに言われたことをやるなら、判断基準が他者(クライアントの要望)に依存している事と等価です。客観性を失うと意思決定の辻褄も合わずに意志は崩壊して、先の負けパターンループに落ち着くだろうと考えました。特にBtoBはクライアントとの距離も近く意見は耳に入りやすいのでその傾向は強いのかなと考えていました。

理想のプロダクト像を判断基準とすることで意思決定の一貫性を保つ

なので折衷案を考える必要があります。プロダクトの至上命題は利用を通してクライアントの利益を最大化する事なので、判断基準はクライアントにとっての価値に依存します。

クライアントの利益最大化のためには、意思と客観性で価値の一貫性を保ちプロダクトを理想的な状態にすれば良いと学んできました。なのでこの理想の状態を予め想像し尽くしてクライアントの要望をフィードバックすることにしました。

理想のプロダクトを描くために、成し遂げたい世界観を定義したあと、その世界を達成するために必要なUXを逆算して、特にプロダクトを構成する抽象的な概念は大枠から将来拡張が不要なクオリティで完全に思い描きました。また、そのための具体的な機能も予想を外してもいいので思いつく限りは上げておきました。この時できた体系的で膨大なTODOリストを要望の会話の際に判断基準として利用しました。

課題解決のスケールの拡張や方向性は後から変えるが難しいので事前に想定する

この時、プロダクトの抽象的な概念を後から風呂敷を広げ直すのは、デザイン or 開発が大変なケースが多いので、その覚悟を持って絵を描き尽くしておいたほうが良いと考えています。逆に、具体的な機能とか詳細の詰めは各論で、後から変更可能なものであることが多いので、適切な程度で留めておけば良いと考えていました。もちろん概念に応じて出せるだけ出せばチームでイメージが共有できるので良いですが、力の掛け方として。

抽象的な概念というのは、slackなら例えば、組織内のコミュニケーションを最適化するみたいな話で、これが大枠の概念だったと仮定すると、共有チャンネルみたいな組織と組織の繋がる(既存のsharad channel)機能とか、複数チームに属した個人が全チーム横断したAll Unread機能(これは未だ無い)とかはその枠からはみ出る概念で、もしあらかじめ想定できていなかったとしたら、後からの追加するには大きなコストがかかる(場合が多い)と考えています。

判断基準を明示することで一貫性を持った意思決定ができた

こういう概念や方向性が描けていると、要望をいただいた際に以下のような基準で、話は建設的にスムーズに進みました。

Q. クライアントの要望は想定してた機能で課題解決しうるか Yes/No
→ Yes: その機能の優先度をあげるべきかどうか
→ No: 概念の拡張、またはピボットしてまで本当に対応すべきか

展望を描き不測の意思決定を減らせたことで、大筋の開発計画やプロダクトの設計は安定しました。あと何しろ自分たちの想定の範囲内で計画が進んでいるという状態はチームに心の余裕をもたらしました。

未来を用意しておけば、クライアントの要望は不測の事態ではなく、計画の優先度や施策の解像度をあげる貴重な情報源となり、かなりポジティブにディスカッションすることができました。

クライアントはセールスの話を聞いて利用開始を判断。toCとは前提が大きく異なる。

toCプロダクトは一般的に、流入してきたユーザーが自分でサービスを利用開始してみて、利用継続の意思決定を行います。少なくとも今まで関わってきたプロダクトは全てそうでした。

ユーザーにサービスの価値を端的に伝えるためには、限られたユースケースを規定して、それを一点突破型で解決するシンプルで高品質な機能を提供するのが仮説を確かめる上で重要なポイントでした。

対して soeasy buddy はハイタッチセールスで始めました。ユーザーはセールスの話を聞いて、更にサポート付きでプロダクトを利用します。このようにプロダクトを取り巻く前提が大きく異なります。

セールスに仮説検証を寄せるため、多機能で説明自由度の高いβ版をローンチした

BtoBでは、サービスの価値をセールスを通して口頭で説明したりディスカッションすることができます。なのでプロダクトは分かりやすさよりも、様々なユースケースに対応する汎用性を取った方が、PMFを探っていく上での学びの効率が高いと考えました。

打ち手として、一本の武器を磨き上げるMVPな立ち上げではなく、多種多様な武器を初めから用意した多機能・網羅的なプロダクトで対応できる課題を増やし、セールスで顧客の本質的な課題を探りながら後から機能を淘汰していく方針にしました。機能は作り込まず敢えてクオリティを調整して、4ヶ月くらいでβ版をリリースしました。

スタートは想定外の hard things に躓き、セールスの方法はゼロベースで見つけ直すことに

立ち上げは初めから想像以上に洗礼を浴びることになりました。もともと立ち上げ前に色々ディスカッションしたりとco-creativeにプロダクトを立ち上げてきたつもりでしたが、見込み案件の多くは不成約に終わりました。

セールスでの 4つの「不」 とはよく言ったもので、立ち上げ時の提案で頂いた、「いいプロダクトだね！」というフィードバックはnice to have(あったら便利)であり、must to have(ないと困る)の水準に達していないものでした。これは利用開始のハードルが低かった今までのtoCプロダクトではあまりない経験でした。

なのでプロダクトローンチ後、ゼロベースに近い形でセールスを再開することになりました。

プロダクトの運用を自由に提案できることがバッファとなり、仮説検証はスムーズに進んだ

この時から、ピボットまでの仮説ライフポイントを削る戦いが始まりました。仮説ライフポイントとは繫がりのある提案先数と提案できるソリューションの掛け算で、検証できる仮説数をさしています。

幸い、仮説ライフポイントが尽きる前に解決すべき課題を具体的に理解することができました。また結果的に副作用で当初予想だにしていない領域でプロダクトを利用してもらう機会にも恵まれました。

運用の自由度を持って、クライアントの課題を聞き出した上でその課題に対応するプロダクトの使い方を毎回提案していけたことが、仮説検証の速度を高めたと考えています。チームで想像力を詰め込んでプロダクトを立ち上げた結果の柔軟さは上手く機能した気がします。

反省は運用の自由度を加味した機能開発が甘かった事。意識次第で将来の負債は減らせていた。

反省として上記の方針でももっとうまいやり方はありました。プロダクト開発の話で、解決できる課題数を増やすためには、ただ機能数を増やすのではなく、運用の自由度を加味した機能を用意して対応するべきでした。例えばコミュニケーション的な機能であれば、情報発信する機能と質問する機能をそれぞれ別の機能として提供するのではなく、両方のシーンで使える掲示板みたいな機能を作れば一つの機能でも運用で様子を見ることができるみたいな話です。

様子を見て機能を後から分けることは出来ますが、一つにマージしたり削除するのは重い作業で、やはり機能は少ないに越したことは無くて、可能な限りは減らす工夫ができた方が良かったと反省しました。

多機能は必要なかった時は負債となるので、その前提でスタートの力を出していることは意識する必要があります。ただまあ、後でその負債に向き合う辛さと、立ち上げで出口の見えない絶望感では、後者の立ち上げの方がやっぱりしんどかった気がします。プロダクトが死んだら元も子もないので、その時ベストだと判断した方法を結局取ることになるのかなと思います。

後はもっと開発チームがもっと発信者となり、機能開発とセットで開発意図やカスタマーサクセスに関係する提案をできていれば、更に立ち上がりが早く提案の幅も広がっていた気がします。

(当たり前だけど)限られた時間の間で成果を出せなければ倒産する

将来の成功率を高めるためには、なるべく多くの仮説を吟味して、仮説ライフポイントが尽きるまで永遠に試して、確実に成功する一打を見つけていけば良いと考えていました。

ただ現実は資金ライフポイントというものがあって、これが尽きる前に、任意のタイムスケールの中で必ず成果を上げる必要があります。またそれができない場合会社は倒産します。

不確実性に怯え寿命を迎えるのではなく、生存を賭けて勇敢にチャレンジする

限られた時間の中で確実に成功する一打を見つけることは至難の技であり、手を尽くしても結局どこかには不確実性を抱えたまま可能性の吟味のフェーズから会社の生存を賭けた意思決定のフェーズに移行する必要がありました。

フェーズの移行は勇気が必要で、それが会社の命を賭けた選択であればなおさらです。ただ仮説検証で緩やかに資金ライフポイントを使い尽くすよりは、挑戦して可能性にかけたほうが良いのはその通りで、学びでした。

今までの経験上は、確実な一打を見つけるまで探し続け結局勝負に出ないまま緩やかに死んでいく(or 業務委託で食いつなぐ)サービスを見たり経験してきて、その思考を受け継いでいたので、良い発見でした。新規事業では確実性を求め続けて意思決定をロックする守りの姿勢も功罪あるなという感覚になりました。ベットする意味のある一定の可能性は必要ですけど。

あと資金ライフポイントが削れると、気にしてヒリついたり判断能力や精神衛生も蝕まれので、気持ちがポジティブなうちにどんどん意思決定して挑戦するのが良いのだろうとも考えました。

BtoB SaaSの面白さと、これから

soeasy buddy のようなハイタッチセールスのプロダクトでは、今までの toCプロダクトなどと比べると、運用とセットでプロダクトの導入を促すことができます。プロダクトやマーケティングだけではなく、カスタマーサクセスなどリアルの行動に直接的に影響を与えにいくことができます。

打ち手の次元数が増えて、今までプロダクトに閉じた世界では解決できなかったような課題を解決できる可能性を感じました。

さらに顧客と直接ディスカッションするような、プロダクトに対するフィードバックを得られる機会も格段に増えて、定性的な学習機会も非常に多いビジネスモデルだとも感じました。

元々自分は toC 系の事業が何となくクールで面白いと思っていたのですが、今回の経験を通して BtoB SaaS モデルのビジネスで提供できる深いコミットメントに魅力を感じました。

これからもプロダクト・運用など持ちうる全方面の手を尽くして、最高の体験ができるプロダクトを作っていきたいです。