見出し画像

SaaS事業において初期ターゲット設定をきっちりとすると事業の進みがだいぶ早くなるかも、という話。

(以前まではMediumにブログを書いていましたが、noteにお引越ししてみました)

「スタートアップは自分たちのソリューションがばっちりと刺さるターゲットを限定し、そこにしっかりと焦点を絞って価値提供をしていきましょう。」

どんな書籍にも書いてある当たり前のセオリーです。しかし本当の意味で「ターゲット設定の重要性」に気づけるまでにはA1Aの場合、だいぶ時間がかかってしまいました。

それはなぜか。
弊社のソリューションが世の中にないものであり、多くの顧客の関心を引けるもので、かつ、たくさんのお引き合いを頂けているから。
そんな理由です。

要は「このソリューションは新しい、うちでも是非試してみたい」そんなありがたいお声を広範な企業様から頂いてしまったがゆえに「弊社はバーティカルSaaSではなくホリゾンタルSaaSである」という勘違いをしてしまったということ。

そこで、本ブログでは、

1. ターゲット企業の範囲を広げたことによるデメリット
2. ターゲット企業を絞ったことによる恩恵

の2点について記載してみたいと思います。

-----

1. ターゲット企業の範囲を広げたことによるデメリット

A1AではRFQクラウドという製造業購買部門向けの見積査定ソリューションを提供しています。要は、受領する見積をデータ管理し、原価低減余地の発掘をしていきましょう、というソリューションです。

2018年6月に創業し、2019年4月にβ版をリリース。
30社以上の企業様にβ版をご利用いただいております。

β版プロダクトはまだまだ完成度の低い、粗い状態でお客様に提供させていただいているのですが、そこででてくるのが「顧客要望(カスタマイズ要望)」です。突飛なカスタマイズ要望はないものの「さすがに業務で使うにはこの機能が必要です」というお声を多々頂く中で、「どこまで弊社として対応するのか」、また、「どのお客様を優先して対応するべきなのか」が不明瞭な状態になってしまったというわけです。

本来の想定ではβ版の導入を数社程度に止め、その企業様とじっくり製品の作り込みをしていく想定だったものの、想像以上の反響を頂き、

- 膨れ上がる要望リストとお客様の期待感
- 足りないリソース
- ひたすら毎日続く新規アポイント

と、幸いなことにてんやわんやの状態となっておりました。

β版プロダクトである以上、製品完成度の低い状況で機能要望を聞き入れることは、「この部分は多機能だけど、この部分は粗すぎて運用に耐えない」という状況を引き起こしうるし、実際にいくつかの企業様からは「まだ厳しいね、、」と率直な厳しい意見も頂戴しました。

加えて、自分たちが「SaaSの顔をした受託企業になっているのではないか」という現実にも突きつけられ、そのタイミングで方向性の転換を検討せざるを得ない状況となってしまったのです。

RFQクラウドという製品を作るにあたって、弊社では100人以上の現場購買担当者の方々にヒアリングをしてきました。こつこつLinkedIn経由でアポイントをとって、課題と業務をヒアリングしてきました。そこから得た知見をもとに製品設計をしているから、立ち上がりが好調なわけです。

でもそんなちっぽけな成功体験故に「顧客の意見を聞きすぎる」事業体になってしまった。機能開発の優先順位を決めるにあたっても「まずは顧客に聞いてから」という動き方になってしまっていた。

「顧客が欲しがるものを作る」というセオリーの解釈の誤りにより「顧客に欲しい物を聞かないとプロダクトを作れない」状態になってしまっていた。

下記は6月14日の社内Kibelaへの投稿

自分たちが納得できる、本当にお客様を成功させられるようなプロダクトを作っていくことこそ、僕らが長期に渡って提供できる価値ですよね。僕らには 「思想」 がなくなっていた。それに気づけていなかった。

みんなヒシヒシと感じているとは思うけど、うちのサービスには強いニーズが有る。
そこは、一番お客さんに会っている松原も自信を持って言えるポイント。

だったら、圧倒的に良いと思うもの、自分たちの思想を込めたサービスを作っていきましょうよ!良いと思うものを提供していきましょうよ!自分たちの思想に共感してくれるお客さんに使ってもらいましょうよ!!!うちが目指したいのは、全部盛りのサービスではない。

マーケットインは1年間やった。
だったら、プロダクトアウト側に踏み出してみましょうよ。A1Aの思想を追求していきましょうよ。そっちの議論のほうがおもしろい!!

そこで大きく逆の方向に舵を切ったわけです。
「思想を持ったものづくりをする」このキーワードをもとに、開発ロードマップの再策定に入りました。

そこで見えてきたのが、顧客要望が実はいくつかのグループに分類可能であるということ。加えて「ものの買い方(調達の業務フロー)」というグルーピングにて3つの分類にきれいに分けることが出来るということでした。

- 業界による分類
- 年商規模による分類
- 従業員規模による分類
- 課題感による分類

上記のような「よくあるグルーピング」は弊社には全く当てはまらず、「ものの買い方」がターゲッティングのための最重要分類項目だったのです。

ものの買い方3分類に基づき、頂いた機能要望を振り分け、再度開発ロードマップの策定に入ることで、改めて自分たちの向かう先を定義することが可能となりました。

とはいえ、やはりターゲットの絞り込みは本当にむずかしい。
セオリーは抑えていたし、ターゲット設定が重要なことは100%理解していたつもりだったけど、それでも出来ていなかった。

ここまで「弊社が犯した過ち」的な文章になってしまったけれども、一方で「ここまでβ版を真剣に使って頂き、お客様に本気で導入検討してもらったからこそ」の気付きであったような気もしています。

100社にヒアリングをして、その後プロダクトを担いで90社程度の企業に本気で営業&ご提案させていただいたからこそ、やっと絞り込みができた、というのも大きいのかなと思うわけです。

プロダクトを触ってもらって、解像度高く他社事例のお話をさせて頂き、そして、本気で導入検討をして頂く、このフェーズをしっかりと経たからこそ「ものの買い方」が重要なグルーピング手段であると気づけたのかもしれません。

モックを触ってもらうだけでは気づけなかった。やはり「製品を触ってもらって真剣に運用トライをしてもらうこと」が重要だと再認識したわけです。

我々は「思想を持ったプロダクトづくり」を実施していくにあたって、製品のリリースを数ヶ月後ろ倒ししました。採用計画にも、事業計画にも、そして資金調達にも影響を与えうる意思決定ではありましたが、数年先のスケーラビリティと成長率を考えると、プロダクト開発への注力期間を「今」数ヶ月伸ばすことが最重要だったわけです。

その結果、以下の恩恵を受けることが出来ました。

-----

2. ターゲット企業を絞ったことによる恩恵

ターゲットを絞ることによる恩恵は明確です。

①自分たちの作っていく世界観の解像度があがる
②顧客の納得感があがる
③でてくる顧客要望が極めて少なくなる
④顧客獲得時期が明確になる(事業計画の精度が上がる)
⑤必要なリソースが明確になる
⑥メンバーにミッションを与えやすくなる(動き方が明確になる)

挙げていけばキリがありません。多分もっともっとあるように感じています。

ターゲット企業を明確にするメリットは「将来の見通しがつきやすくなる」ここにつきます。それは経営視点からも開発視点からしても、そして顧客視点からもそうだと言えるかと思います。

①自分たちの作っていく世界観の解像度があがる
A1Aのビジョンは「B2Bの取引をワンランク上に」であり「取引にかかるコストを減らすこと」を目指しています。取引にかかるコストは、以下の3つに分類されるのですが、

-  探索コスト:意思決定の前提となる情報収集コスト
-  交渉コスト:当事者間の交渉や契約に伴うコスト
-  監視コスト:契約を遵守させるためのコスト

ターゲットを明確にすることで「どうすれば取引コストを下げることができるのか」について、はっきりとしたイメージを持つことが可能となりました。

②顧客の納得感があがる
これも非常に大きなメリットです。我々の製品開発ロードマップを、

- 〜9月末:分類①の企業群が業務を回すことができる機能
- 〜1月末:分類②の企業群が業務を回すことができる機能
- 〜3月末:分類③の企業群が業務を回すことができる機能

と明示することで、顧客企業が「いつからなら使い始めることができるのか」が明確になりました。顧客企業様との打ち合わせの中で、例えば分類③に属する企業様であれば「4月からは十分な機能が搭載されます。なので、4月から運用開始できるような導入スケジュールを組んでいきましょう」というお話をすることが可能になったというわけです。

③でてくる顧客要望が極めて少なくなる
上記の通り、ターゲット分類ごとに時期を区切って機能提供していくことを定めたこともあり、企業様からの独自の要望が「ほぼ」なくなってきました。これは相当数の企業様にヒアリングをさせてもらったことと、多くの企業様に本気のβ版運用をしていただいたことが要因と言えますが、「SaaSの顔をした受託企業」からの脱却に大きく寄与したことと思います。

④顧客獲得時期が明確になる(事業計画の精度が上がる)
経営視点ではこれも大きなポイントです。フェーズを区切って機能提供していくことで、どのタイミングにどの企業様の運用が開始されるかが明確になってきました。逆に言えば機能実装フェーズに合わせてしか契約獲得ができなくなってしまったとも言えますが、それは短期的すぎる視点。ターゲットを明確にすることと、思想を持った開発ロードマップを設計することの間には強い相乗効果があるように思いますが、これにより「開発ロードマップを軸とした事業計画の精度アップ」が可能になると言っても過言ではないように感じます。

⑤必要なリソースが明確になる
当然、事業計画が明確になれば必要なリソースや打つべき施策も解像度の高いものになります。

⑥メンバーにミッションを与えやすくなる(動き方が明確になる)
そして何より大きかったのは

- ターゲットが定まる
- 開発ロードマップと事業計画が定まる
- 各人の動き方が明確になる

という理由から、各々のメンバーが自分のミッションを明確に持つことができるようになったということです。自分たちの思想を軸とした計画をひくことで「何をやりきればいいのか」が明確になると、各々のメンバーに課すミッションが明確になる。そうすることで、メンバー全体の生産性とアウトプットが大きく向上しました。

-----

ターゲットを定めることで視界が明瞭になり、経営の方向性の解像度があがることで、会社のアウトプットと生産性があがる。そして顧客満足度と獲得率が上昇する。なんて素晴らしい。

若干話しが派生しましたが、ターゲットを明確にするメリットはやはり大きい。

きっとマーケットインであるべきフェーズとプロダクトアウトであるべきフェーズは違うんだと思うんです。もっというと比重の置き方をかえるべきであると言えるかと思います。

 初期構想段階と課題抽出フェーズではマーケットに寄り添うべき、顧客の意見こそ最重要と考えるべきだと思います。一方で、製品開発フェーズ以後はプロダクトアウトの比重を高めるべき。自分たちの思想を形にして、「最低限の運用に耐えうる」プロダクトを顧客に使ってもらう。

特にB2Bではβ版やトライアル製品の運用開始までのハードルが著しく高いことを痛感しました。そこがB2CプロダクトのMVP的な発想をそのまま展開できない大変な点かと思います。そこに大きな課題があり、かつ、解決できるイメージをいかに持ってもらえるか、顧客との「課題と解決策の同意」が明確に必要であり、かつ、仮運用の承認を社内から得られる最低限以上のプロダクトがあって始めて検討の俎上に載せていただくことができるというのが、特にエンプラを狙うB2Bスタートアップの難しさであるように感じます。

だからこそ根っことなる「課題」の抽出には徹底的にマーケットに向き合う必要がある。一方で、ここまで書いてきたように、どこかのタイミングで「プロダクトアウト」のソリューション設計をしていかないと、SaaSの顔をした受託企業になってしまう。

行うべきは、課題を抽出しながら、その課題と特徴の共通項目をマッピングしていくこと。僕らがターゲット分類に時間がかかったのは「何らかしらの共通項目を持つ企業群は、近しい業務フローと課題、要望を持っている」ということを信じきれなかったこと。そこが大きなポイントだったのかなと感じています。

そんな今の僕らのプロダクト開発を明確に語っているのが以下の社内インタビュー記事。

Slerが顧客の課題に立脚して開発するB2Bサービス開発1.0だとしたら、顧客の要望を抽象化、一般化して普遍的な機能に落とし込んでいくSaaSの開発は、B2Bサービス開発2.0といえるでしょう。私はB2Bサービス開発には、この先があると思っています。即ち、顧客の課題に立脚した上で、B2BサービスにおいてもB2Cサービスのようなクリエイティブな発想を取り入れられないか?ということです。
例えば、先日ある顧客から「プロジェクト管理機能が欲しい」というご要望を頂きました。その要望をそのまま開発することもできますが、ふと思ったのです、「プロジェクト管理こそ、私たちwebエンジニアの中で独自の進化を遂げてきた分野じゃないか」と。プロジェクト管理については、様々な思想のもと様々なツールが開発されていますし、個々人がある種こだわりすら持っているように思います。そのエッセンスを少しでも取り入れられないかと考えたのです。
顧客の求めるものをそのまま開発するのではなく、顧客の課題を踏まえた上で、0ベースで何が理想かを考え提案することができれば、顧客が想像だにしなかった価値提供ができるかもしれません。何より、そちらのほうが、開発者である私たち自身が心からワクワクできると思うのです。そんな、いわばB2Bサービス開発3.0のような開発を目指しています。

弊社では、絶賛プロダクト磨き上げ中です。
思想を形にしていく0→1フェーズにご興味をお持ちいただける方は是非ランチでもご一緒させてください!

お待ちしております。

この記事が気に入ったらサポートをしてみませんか?