SaaSをもう一度立ち上げるなら？
1年強を通じて、バーティカルSaaSの立ち上げに従事していたことがありました。
そんな経験を通じて、「もう一回やるなら、何をする/しない？」と他の方に聞いたこともあれば、逆に聞かれる機会があり、
どういった失敗があったか。逆に、次も継続するであろうことが何か振り返ってみます。
失敗したこと
顧客のジョブやペインの解像度が荒かった
インタビューを行い、業務フローを整理し、困っていると言われたこと/そう感じられるものに対する最低限の機能を作る...
と、一見それっぽく見える形でモノづくりをしていたのですが、いま思うと顧客の解像度がとっても荒い状態でした。
どんなお客様が、どんな時、どんなジョブを解決する必要があり、具体的な方法として●●を行っており、これを10倍以上よくできる....
ありありとシチュエーションが浮かぶようなヒアリング、業務整理、検証ポイントの明確化を行ってこそ、やっと最適なソリューションに落とし込めるなぁと痛感するところです。
仮に再度SaaSを立ち上げる際も、ユーザーインタビューや業務整理、一次情報の観察など行うと思いますが、1つ1つの精度・細かさ・引き出し方は全く違うものになると思っています。
ここは、場数や書籍でひたすらラーニングを行なって気付けたことでした。
当時参考になった本がこの辺りです。
プロダクトを作る前に、モックで売ってみる
見たことがないくらい高速で開発し「どんどん試して、ダメなら壊せばいい。」という気概を持ったエンジニアのおかげで、初期はどんどん作ってみようということが多かったです。
これ自体はものすごくよかったのですが、後々自分でも営業を初めてみて『本当に顧客のペインに深く刺さっている場合、モノがなくても売れるな...』と実感しました。
巷で言われる”Burning needs”というやつ。
プロダクトがないと検証ができないものもあれば、パワポのスライドやモックで検証できてしまうものも数多くあり、作らずに検証することができないか注意するきっかけになりました。
ナイストライな文化の醸成
既存事業と新規事業でチームが分かれていて動きやすかったものの、やはりキャッシュカウ事業から見ると「自分たちが稼いだお金が、、」と感じられてしまうものです。
チーム内では、早く試してFindingsを見つけることを重視していましたが、会社全体までその文化浸透はできていない印象でした。
それが故に協力を仰ぎづらいところも出てきてしまい、より一枚岩になり、さらに事業速度を早められたかも、、と感じるところです。
やって良かったこと
朝令暮改を許容し、役割を決めずに動く
出すべきスピードを出していれば、刻一刻と状況は変化し、新たな発見によって仮説が上書き続けていきます。
そんな状況下は、固執しすぎず、きちっとしすぎず、進捗を刻んでいくことが大切だと思いました。
実際、役割だけで言えば、ユーザーインタビュー → 仮説設定 → 仕様策定 → 検証 → デザイン → 営業 → CS → 全体のモニタリング設計....と、日・週単位でゴロゴロ変わっていました。
変に●●だけやる！と決めていたり、XXXと言ってしまったから、、と考えていたら、検証スピードは落ちていたなと思います。
徹底的なリサーチ。営業を受ける
可能な限り、国内外の競合サービスや似ているモデルのサービスを調べ、実際に使い倒しました。
また、実際に似たモデルの企業に問い合わせし、10社前後の企業から営業を受け、ペインの特定やサービスのコアバリューをどう紹介するか...を見極めていました。
自ら売る。サポートする。
楽天・リクルートの営業経験者から『 SPIN営業 』という手法を伺い、営業を行なっていました。
その過程で、お客さんの解像度・サービスの提供価値・届け方...様々なものを考慮できていないと売れないなと痛感すると同時に、
売れる・売れない体験を通じて、プロダクトに反映できる部分が多かったです。
さらに自ら顧客のサポートを行うことで、お電話やLINEを通じて問い合わせの背景を理解し、さらにこちらから質問するといった機会も増え、解像度をあげることにつながりました。
代行業務をしてみる
お客様の一部作業を請け負っていました。例えば、データ入力作業を代行してみると、お客様のデータを深く見て、さらに自社サービスの使い勝手を実感できます。
ずっと行い続けるものではないですが、特に初期はあえて自分で手を動かしてやってみることで解像度が上がりました。
UI/UXにこだわる
バーティカルSaaSの特性（？）かもしれないが、お客様がITに詳しいわけでもなく慣れているわけでもありません。
そんな中で、単に”機能要件を満たして課題解決できる”ことがMVPではなく、”何も考えずにコアなUse Caseで利用できる”ことが必須でした。
また、競合となることが多かったオンプレサービスの多くが決して使いやすいと言えない状態で、"LINEのように簡単に●●できます"という謳い文句が想像以上に好評でした。
早く検証を回し、ダメだと思えば壊して作り直す
特に立ち上げのタイミングは、”試してみないとわからない”、”提供してみてわかることの方がずっと多い”と思っています。
そのため、可能な限り早く検証をし、改善。さらに違うと思えば、変に間延びさせず、壊して作り直すくらいの気概で入れたことが、巡り巡って完成形に近づく道だったと思いました。
Howは任せる
デザインや開発、カスタマーサクセス、インサイドセールス...顧客のペインと仮説を共有し、細かな部分は担当メンバーにお任せしていました。
チームメンバーに恵まれていたことが大きいですが、やはり一番レバレッジがかかるポイントに集中した方が良く、担当領域は担当者が一番知見があり、深く思考していることが多いので、
Why, Whatをきちんと共有し、細かな部分はお任せがスピード早く、精度も高いなと。
数値を見過ぎない
全く見ないわけではないものの、数値改善云々以前にそもそも刺さっていなければしても利用はされず、そもそも利用がなければ細かな数値をみても意味がない。
ーーーー
以上、自分なりに手足を動かして得た知見でした。
細かなところ、血肉になり当たり前すぎて自分で気づけていないナレッジなんかもありそうで、定期的に更新必要そう。。
また思いついた時に更新してみます。
この記事が気に入ったらサポートをしてみませんか？