東京都

軌道に乗るまで2年半、ビジネスサイドとして顧客に向き合い続けた話

採用担当, 松田崇義 and 5 others

代表取締役 / ファウンダー

採用担当

エピックベース株式会社 /

松田崇義

エピックベース株式会社 / 代表取締役 / ファウンダー

Tsukasa Irihi

エピックベース株式会社 / エンジニア

Hiromi Otake

エピックベース株式会社 / カスタマーサクセス兼バックオフィス

Mari Okada

Epicbase, Inc. / 共同創業・プロダクトマネージャー

Takashi Nishizawa

エピックベース株式会社 / 取締役

Takayoshi Matsuda

エピックベース株式会社 / 代表取締役

on 2023-03-08

SaaSスタートアップ創業後の苦労

エピックベースを創業して早いもので2年半がたちました。
創業からビジネスサイドの最前線で爆走してきましたが、ようやく会社が軌道にのってきたので、軌道にのるまでの苦労話をまとめておこうと思います。

エピックベースってどんな会社？

弊社のことを知らない方も多いと思うので簡単に紹介します。

スマート書記という音声とAI文字起こしを活用した議事録サービスを開発、提供してる会社です。（ホリゾンタルのB2B SaaS）

議事録の自動作成なら「スマート書記」｜音声×AIが業務を効率化議事録の自動作成なら「スマート書記」。AIによる90%以上の高精度文字起こしで、議事録作成業務を劇的に効率化。すべてのWewww.smartshoki.com

創業メンバーは私含め3名でそれぞれが得意領域を持って経営してます。（私はビジネスサイド全般）
現在のステージはシードのスタートアップです。

2年半をざっくり振り返ってみるとこんな感じ

1年目「売れてはいるけど急成長とは言えず、顧客にも刺さってない」　→うん、もう1回1からプロダクト作り直そ！2年目「今までのプロダクトを売りながらも新プロダクトの準備」　→ランウェイ伸ばしながらも、新プロダクトを短期で軌道にのらせる！3年目「新プロダクトが軌道にのって未来をつくる！」　→今ここ

まずは創業～1年を振り返ります！

1年目「売れてはいるけど急成長とは言えず、顧客にも刺さってない」

創業当時プロダクトを売り始めて一番驚いたのはリードの数。
売れるプロダクトになるまでは極力販管費を抑えたかったので広告も1円もかけずリード獲得を行っていましたが、月100件近くのリードが入り、これはいけるぞ！と期待に胸を膨らましていました。（実際やってたのはLP作ったり、SEOの上位にある「文字起こし◯選」みたいなまとめ記事を掲載している会社にこちらから営業してうちのプロダクトをのせてもらうことくらい）

そしてまずは数だ！ととにかく営業！
デモして、トライアルをやってもらって、クロージングの毎日。
数ヶ月がたち、確かにMRRは増えたが、急成長とはいえない状況。
導入してくれたお客さんも今のプロダクトに惚れ込んで導入してくれた、と言うよりはまずは試験的にやってみようというお客さんがほとんど。
（メンバー全員、MRRは上がってるけど大丈夫かな・・・というなんとも言えない状況。）

そして数ヶ月がたち契約更新を迎えるお客さんが出てくると、

お客さん「試験的に導入してみましたが、まだうちには早かったようで解約します」（導入したけど価値が無かった、が真意だが、気を使っていただく解約理由のやつ・・・）

更新していただけるお客さんもいたが、

お客さん「もう少しトライしてみます！」
私「！？（価値感じてもらえてないやんけ・・・）」

よし、しっかりとお客さんに価値提供できるように、ビジネスサイドで短期で改善できることをやっていこう！と様々な施策を動かしました。

・サービス資料の改善
・営業トークやデモの改善
・営業時の期待値調整
・CS担当を作って導入時のオンボーディングやオンライン説明会の実施
・（文字起こしの精度を求めるお客さんが多かったので）精度が高くなるマイクが無いかいろんなマイクをひたすら検証

施策を動かすことで多少の改善はありましたが、「うちのサービスが無ければ困る！」というような熱心なお客さんは現れず、メンバー全員の中で「このままじゃマズイ・・・」という気持ちが。。。

そしてこの延長線上でプロダクトやオペレーションの改善を進めてもだめだと判断し、もう一度一からプロダクトを作り直すことを決めました。

2年目「今までのプロダクトを売りながらも新プロダクトの準備」

新プロダクトの開発を進めるにあたって以下の検証を丁寧に進めていくことを決めました。

Customer ⇔ Problem(Pain) Fit
Problem(Pain) ⇔ Solution Fit
Solution ⇔ Product Fit

この進め方だとどのくらいの時間軸で3まで到達できるかが読めず、つまりは新プロダクトとしていつキャッシュが入るか読めないというのが悩みの種でした。
なのでビジネスサイドとしては新プロダクトに向けたリソースに振り切ることはせず、必要最小限の人数でコストを極限まで抑え（元々人数は必要最小限だったのでシステム等のコストを削減）、これまでの営業活動は継続し、目の前のキャッシュを作りながらも新プロダクトに向けた準備を進めることにしました。

（この1年は体力的にも精神的にも本当にキツかったので、ここを一緒に乗り越えてくれたメンバーには本当に感謝しかありません涙）

そんなカツカツな状況でもこの新プロダクトを短期的に成功させるため、ビジネスサイドとしてはこんなことをやってました。

①日々どのようなお客さんと向き合っているのかをフィードバックする②課題の仮説が正しいかをお客さんに確認する③β版を"正しく"お客さんに使ってもらう④使った結果を価値（効果）にフォーカスしてヒアリングする

1つずつ具体的に書きます。

①日々どのようなお客さんと向き合っているのかをフィードバックする

1年目でこの領域は「リードが入る」つまりは「問い合わせしてでも解決したい課題を抱える人がいる」ということがわかっていたので、新プロダクトの方向性としては新しいお客さん層を捕まえにいくのではなく、まずは今入っているリード層に対して価値提供できるものを作っていくことを決めました。

ビジネスサイドが日々対峙しているお客さんがどのような状況かを開発メンバーにも理解してもらうために、毎週の開発メンバーを交えた定例会議で以下の情報を共有していきました。

・どのようなお客さんが商談化しているか（商談状況）
・受注したお客さんや失注したお客さんの理由
・どんなサービスとコンペになっているか

またこの情報はお客さんの"点"の情報をシェアしていくだけになってしまうので、"面"でイメージしてもらえるよう、新プロダクトの準備を始めてすぐに、こんなドキュメントを作り、情報をシェアしたりもしました。
（単にこういうお客さんが多い、という情報だけでなく、営業観点でこんなプロダクトになったら売れそう（価値提供できそう）という観点でもフィードバックできたら有意義かなーと）

②課題の仮説が正しいかをお客さんに確認する

顧客のイメージのすり合わせができたら、次は課題のすり合わせ。
うちに問合せをしてくれるお客さんの課題はほぼ「議事録作成時間がかかっていること」でした。
これだと解像度が低く、適切な解決策を考えることが難しいため、「そもそもお客さんはどのようなプロセスで議事録を作成し、どのプロセスに時間がかかっているのか」、という観点で課題のすり合わせを進めました。

まずはアンケートをとり、その中でも議事録作成に膨大な時間がとられているお客さんに対して開発メンバーが直接ヒアリング。
何が課題になっているかを直接お客さんに聞くのも大事ですが、こちらで課題の仮説が立てられるよう、この時点では現状の作成フローをとにかく細かくヒアリングしました。

そして開発メンバーのところでヒアリングしたお客さんのフローを体系化し、社内で検証していきました。
ここらへんは取締役でPdMのmarioが以下記事にまとめてくれてます。

https://www.wantedly.com/companies/company_7236249/post_articles/487297

社内で課題のすり合わせができ、次に考えたのは、「果たしてこの課題をもつお客さん（つまりはこの作成フローで議事録を作ってるお客さん）はどのくらいいるのか」。
この選択を誤ってしまうとリリース後の成長が鈍化してしまうため慎重に選んでいきましたが、これを検証する時間的な猶予も無いため、社内で優先順位を決め、その優先順位が本当に正しいかは、開発と並行して営業時にヒアリングしていくことにしました。

ヒアリングでは詳細の作業フローが聞きたいので、検討者や意思決定者だけでなく実際に議事録を作成している人にも同席してもらい、開発メンバーが作成したフローと比較できるよう以下のような形で情報を貯めて、優先順位が間違っていたら軌道修正できるよう進めました。

③β版を"正しく"お客さんに使ってもらう

課題のすり合わせができたら、次は解決策&プロダクトのすり合わせ。
これは社内α版として一定解決できるプロダクトになったタイミングで、β版としてミニマム構成のものを実際のお客さんに使ってもらいました。

このときお客さんに紹介する上で大事にしていたことは"正しく"使ってもらうこと。
ここで言う"正しく"使ってもらうというのは、こちらが意図している使い方で検証してもらうことです。

β段階ではミニマムの構成のため分かりづらい機能も正直あります。
それをわかりやすくするために機能を改善するよりも、営業が説明してお客さんに理解してもらったほうが開発メンバーはコアな機能にリソースが集中でき、圧倒的に開発スピードが上がります。

なのでβ提供するお客さんには必ず実際の作業者に対してオンラインでの一通りのレクチャーを行った上で利用してもらいました。
またこの説明はある意味価値訴求するための商談という位置づけになりますが、商談色は全く出さず、「操作説明」に完全に振り切り、検証後にフラットなフィードバックがもらえるよう進めました。
（ここで巧みな営業トークでお客さんを口説いたとしても、プロダクト本来の価値訴求からぶれてしまい、営業に依存するプロダクトになってしまうため）

④使った結果を価値（効果）にフォーカスしてヒアリングする

お客さんに使い始めてもらったら、次はフィードバックの収集。
β版検証で重視していたのは価値（効果）があるか。つまりはβ版のコアとなる機能が議事録作成時間を短縮できるかでした。

ですが何件かフィードバックをしてみると、実際の会議の議事録として検証してくれたお客さんはほとんどおらず、試しに触った上での機能の不具合等の感想レベルのものでした。

このままでは本質的な検証ができず、時間がかかりすぎてしまうため、すぐに以下テコ入れを行いました。

実際の会議で議事録作成の検証をしてくれることをβ版提供の条件に追加
β版提供開始タイミングでどのようなフィードバックが欲しいかを伝える（以下のスライドを説明資料に追加）

この変更により有意義なフィードバックをお客さんからいただけるようになりました。

また最初は限定してβ版を提供し、深くフィードバックを収集できるよう進めていましたが、次のステップでは広くフィードバックを収集するため、β提供数を増やしていき、フィードバックの数を増やしていきました。その際には全てのお客さんにヒアリングすることはできないため、コアとなる質問に絞ったアンケートを回収する形をとり、アンケート結果を見てインタビューする顧客を選定していきました。
アンケートとしてはこんな感じです。