【図解】Must have SaaSの方程式

Must have と Nice to have

「解約率が高まっている。自分たちのプロダクトはMust haveになれていないのではないか」

「Nice to haveからMust haveになるにはどうしたらよいか」

といった相談を受けることが最近増えています。投資家から「プロダクトがMust haveになりきれていない」という指摘をされたことのある起業家の方も少なくないのではないでしょうか。

不確実性が高い今、コスト削減を目的に、Must haveになりきれないプロダクトはユーザーから容赦無く解約されていきます。

——Must have SaaSの方程式とは

この記事では、私のSaaS事業立ち上げの失敗経験も交えながら「Must have と Nice to have の違い」を言語化し、Must haveのプロダクトに近づくための具体的なチェックポイントについてお伝えしていきます。

Must have と Nice to have

Must have、Nice to haveを把握する上で、まずは2つの状態の違いを正しく理解する必要があります。

Must have —— ユーザーにとって「ないと不便」なプロダクト・サービス
Nice to have — ユーザーにとって「あったら便利」なプロダクト・サービス

一見、両方とも便利なプロダクトでユーザーから必要とされているという印象を持ちますが、「ないと不便」と「あったら便利」の間には大きな差があります。私自身、SPEEDAアジア事業の立上げ時に、プレマーケティングでのユーザーフィードバックは良かったにも関わらず、いざ本ローンチで価格を提示したら、

「便利で個人的には導入したいのだけど、社内を説得できない」

「月〇〇円を支払うまでの価値は感じない」

「便利なのだけど利用頻度が・・・」

と、そのテストユーザーの誰一人も購入してくれなかったという苦い経験があります（結果、リカバリーに約半年を要しました）。後から、当時のプレマーケティングでのユーザーフィードバックを振り返ってみると、ほとんどが「SPEEDAは便利。あったら使う。」というものでした。

「あったら便利」

つまり、Nice to haveであったにもかかわらず、表面的なフィードバックだけをとらえ、ニーズがあると勘違いしてしまっていたのです。特にストレートな表現を避ける日本においては、表面的なフィードバックになりがちでMust haveかNice to haveかの判断があいまいになる環境であるといえるかもしれません。

——それでは、Must haveかNice to haveか、どう見分ければ良いのでしょうか？

私たちも決してプロダクトに手を抜いていたわけではありません。むしろ、ユーザベース では、創業期から「ユーザーの理想から始める」「Must have」「ユーザーが喉から手が出るほど欲しいと思うか」といったキーワードが日々飛び交い、強烈すぎるほどにプロダクト・コンテンツにこだわる文化がありました。

それでも、Nice to haveにおちいってしまう。

その理由は、ここまで開発したというサンクコストのバイアスが、ユーザーフィードバックをポジティブな方向に増幅させてしまうことにあったと思っています。そのバイアスを防ぎ、ユーザーのプロダクトに対する評価を客観視するためには”ユーザーのMust have状態を測る”チェックリストが必要です。

下記が、そのチェックリストの一例です。

このチェックリストは、私自身が投資検討の際にプロダクトを評価する基準にもしています。特に、

「ユーザーがプロダクトの価値を自分ごとのように語ることができる」

「ユーザーがプロダクトを周囲の誰かに紹介をしたくてたまらない」

という状態になればMust haveになっている可能性が高いといえます。

逆に、テスト・トライアル中にも関わらず、ユーザー自身がプロダクトの価値を明確に語ることが出来ない場合はNice to haveに留まっている可能性が高いことを疑いましょう。

Must have SaaS の方程式

これから新たにプロダクトを作る場合、もしくは既存のプロダクトがNice to haveに留まっている場合、どのような方程式を解けばMust have化するのか。私はMust have化に向けて、一般化できるポイントが大きく二つあるのではないかと考えています。

■ Must have = 継続的なユーザーの生産性向上

単なるツールに終わることなく、SaaSとしてユーザーと持続的な関係を築くには、ユーザーの生産性向上に貢献しつづけることが必須です。リリースしたSaaSサービス・プロダクトに手応えを感じない場合は、まず、下図の分母・分子を満たしているかを、チェックすることをおすすめしています。

「生産性を上げる＝ユーザーの非効率(ペイン)を改善する」というイメージを持ちがちですが、それだけでは不十分で、もう一段解像度を上げてとらえる必要があります。

生産性を計算式に分解してみると、生産性は、分母に投入時間、分子に付加価値という式で成り立っています。

つまり、ユーザーの生産性を高めるには、何か一つの業務に投入する時間を減らし（分母）、サービス提供によりこれまでに得られなかったインサイトを提供する（分子）必要があるということです。

片方を満たしていればよいのではなく、私はこの分母と分子の要素が両立してはじめてMust haveのプロダクトになりうると思っています。これまで、私が見てきたNice to haveのプロダクトは、この一方だけしか考慮されていないケースが多く見受けられます。

上図は、作業代替性（分母）・ユニークなインサイト（分子）のあり/なしをフレームワーク化しています。どちらか一方しか満たせていない場合は、競合によるリプレイスや利用頻度が低いことによる短期での解約のリスクが顕在化すると考えています。

■ 5つの代替性＝導入への必然性

前項の生産性の観点に加えて、Must have化に向けた、もうひとつ重要な点が「代替性」という観点です。Must haveの条件を満たすプロダクトをつくったとしても、ユーザーに購入してもらえないと意味がありません。

「自分のプロダクトは既存の何をリプレイスするのか」を明確にすることが、プロダクト導入を提案する上でのユーザーの納得感の醸成につながります。

1. 時間のリプレイス — ある業務を行う際の単位時間が減る
（例：データ分析に10時間かけていたのが1時間でできるようになる)

2.人のリプレイス —— 属人的な業務のクラウド化で人件費を削減
（例：今まで3名で担当していた業務が1名で可能になる)

3.価格のリプレイス — 既存のオンプレミス型のソフトウェア、SaaSよりも安価
（例：既存サービスが30万円/月に対し、同じ機能を10万円/月で提供)

4. 習慣のリプレイス — 日々の業務フローのインフラとして機能
（例：毎日の稟議・承認フローや勤怠記録など、毎日アクセスする状態）

5. 蓄積のリプレイス — 活用し続けることでデータが蓄積される
(例：ユーザーとのコミュニケーションがプロダクト上に蓄積され続ける)

上の5つのうち、1・2・3は導入時の必然性、4・5は契約更新時の必然性を高める要素です。

ユーザーへの新規提案、更新提案時には、

「自分たちのプロダクト・サービスはどのような価値提供をしてユーザーの生産性を高めるのか」

「ユーザーのこれまでの何を代替するのか」

という具体的な視点を織り込むことが、継続的な関係を築くポイントであると思っています。

---

いかがでしたでしょうか。今回は、Must haveとNice to haveの定義を明確にして、Must haveのプロダクト・サービスとなるためのチェックポイントについて掘り下げました。

「資金調達をしてアジア向けのプロダクトを１年間かけて開発してしまった」

「立ち上げのため海外に移住してしまった」

「日本から送り出してくれた皆からの期待を裏切れない」

という思いが重なり、ユーザーフィードバックを冷静かつ客観的に捉えることができなかったというのが私の失敗の本質です。
私の場合は、チームにも恵まれリカバリーすることができましたが、もっと早く軌道修正できていたらという後悔が今でも残ります。

今回、提示させていただいたフレームワークが、サンクコストのバイアスを排除して、プロダクトを客観視できる一助となればと思います。

——次回は、ユーザベース創業者の梅田 優祐との対談を通して、事業立ち上げの実体験を交えた、Must haveの考え方をより深くお伝えします。

---

執筆 ： 岩澤 脩 | ファーストライト・キャピタル 代表取締役・マネージングパートナー
2020.07.31