BtoB SaaSのリリース直後にユーザを理解するためにやりがちな失敗

今日は、BtoB SaaSのプロダクトにおける初期の検証段階で「ユーザを理解するために起きがちな失敗（と、乗り越え方）」について書きたいと思います。自分自身いくつかのBtoB SaaSのプロダクトをリリースして数多くの失敗をしてきたので、私の失敗談だと思って読んでいただければと思います。

製品が提供する課題解決とズレたユーザを獲得してしまう

リリース直後のプロトタイプを試してくれたユーザ企業に対して「インタビューが取れない」という場合があります。「きっと相手は忙しいのだろう」と前向きに捉えたくもなるのですが、インタビューが取れない理由は、製品に対して「そもそもユーザの課題がズレている」か「ユーザの課題を十分に解決が出来ていない」のどちらかでしょう。
特にリリースと同時にメディア掲載され、広くアーリーアダプターにリーチした場合には「課題感がズレたユーザを多数獲得してしまう」という現象が起きやすいのではないかと思います。こうした場合には少数でも良いので製品が解決する課題とユーザが抱える課題がフィットするユーザの獲得からやり直すしかないです。

インタビュー結果を信じてしまう

首尾よくインタビューができると「ユーザの声を聞くこと」自体が嬉しく、興奮しますよね。でもユーザは言語化の達人ではないので、製品のコア機能が役に立たない理由を上手く說明してくれないだけでなく、「他に◯◯の機能もあると良い」といったフィードバックが頻発してしまいます。

インタビューは、「コア機能は本当にユーザの課題を解決しているのか？」という本筋に集中すべきであって、本筋から外れた要望やフィードバックを注意深く取り除く必要があります（自分自身、何度失敗したことか…）。

「使いにくさ」のせいにしてしまう

検証すべき本筋から外れたフィードバックとして最も典型的なのが「使いにくい」というものです。何を言ったらいいか分からなくなったユーザが最も安易に選択するフィードバックが「使いにくい」だと思った方が良いくらいだと思います。

初期のリリースでは「コア機能はユーザの課題を解決しているのか？」を検証しようとしているのであって「使いやすさ」を検証しているはずがないですよね。製品を試してみることができる程度の最低限の使いやすさがあれば十分なはず。でも少し気を抜くと「もう少し使いやすくすればコア機能の価値が伝わるのではないか…」とつい思ってしまうものです。

数字の確認を後回しにしてしまう

こうしたインタビューにまつわるバイアスを乗り越えるためには、実際にユーザのリテンションや製品内でのアクションの回数を数字で確認すべきだということにしばらく経ってから気がつきます。

数字を確認すればインタビューで「◯◯がすごく良かった」と言っている人が「実際には全くリテンションしていない」といったことが分かったり、インタビューではあまり手応えが無くても、実際には継続して頻繁に使ってくれている重要なユーザ企業が見つかる場合も多いんですよね。

しかし開発リソースが非常に貴重なため、製品の価値に直接貢献しない「製品利用状況を可視化するための開発」は優先順位を上げづらく、ともすれば「今、そんなことをしている場合ではない」とさえ思えてしまうという問題があります。

「製品の利用状況を数字で理解できていないままにインタビューだけを続けることで生じる損失」は「製品の利用状況が分かるようにするための開発工数」よりも遥かに大きい、ということにかなり後になってから気がつくことになります。

最小工数でBtoB SaaSの利用状況を把握するために

では「製品の利用状況を把握する方法を構築しよう」と思ったらどうすべきなのか。単純なWebサイトならば、GoogleAnalyticsさえあれば、確認したい数字のほとんどが確認できます。でもBtoB SaaSの場合にはそう簡単にはいかないですよね。

「企業ごと、ユーザごとに数字を集計したい」という場合や、「実際に製品上で処理されたデータの量や値を確認したい」といった場合など、SaaS製品の特性に応じて扱いたい数字は多種多様で、GoogleAnalyticsには不向きです。かといってSalesforceやTableauなどでダッシュボードを構築するほど大きな工数を投じる余裕はないですよね。

そこで「BtoB SaaSで把握したい様々なユーザの行動や製品の使われ方を最小限の工数で把握したい」という課題を解決するプロダクト「Vital（バイタル）」の検証を今まさに行っています。BtoB SaaSのプロダクトをリリースしたばかりの方や、現在の「製品の利用状況の把握方法」をより良いものに変えたいと考えている方はぜひ一度お話をさせてください。