SaaSセールス/CS向け、SaaSプロダクトの機能実装の考え方
SaaSのセリングは、現在の機能販売だけでなく、将来の機能実装や顧客の声に基づいて機能を実装してくれる期待値で、顧客はプロダクトを選択していただけます。
クラウドサインでも、過去・現在・将来の開発ロードマップを開示し、顧客がプロダクト選択する際の基準にしていただけるように工夫しています。将来の機能実装予定になければ、他社のプロダクトを選択できるようにもできますし、逆に近未来ではなくても、このようなプロダクトを育てていこうという姿勢に共感して、クラウドサインを選択していただける顧客も少なからずいます。
その際に重要なのが、顧客からの声をきちんと聞くことです。当然です。顧客が自分たちの課題を、最も知っているからです。クラウドサインでは、Slack上で特定のルールで書くと、自動的にフィードバックシートに記入できる仕組みを採用しています。びっくりくらいのフィードバック量を、日々受領しています。
そのとき大切なこととしてよく言われるのが、個別のカスタマイズ要望ではなく、多くの顧客に共通した課題を解決できる機能から実装することです。プロダクトロードマップの意思決定の際によく言われることです。
また、セグメント管理も重要です。
SMBセグメントからの顧客要望なのか、EBUセグメントからの顧客要望なのか、GBなのかMMなのかをきちんと把握することです。いくらEBUセグメントにプロダクト戦略を引いていても、SMBからすれば自分たちに役立つ機能実装が全くされなくも見えてしまいます。
セグメントの大方針は決めつつも、各セグメントの顧客を置いてけぼりにするような機能実装は基本的には好ましくありません（戦略として、そのセグメントを全く受注しないと決めてしまう場合は例外）。得てして、セールスからは大型受注になる大企業（EBU/GB）向けのフィードバックが増えがちにもなりますが、SMB等からのフィードバックを見逃さないように気をつけています。
機能実装についてプロダクト側とのズレ
今回特にお伝えしたいのが、機能実装タイミングへの考え方です。たまに聞こえてきがちなのが「これだけ作っていただければ、すぐ受注できますので早めでお願いします！」との声です。機能実装に対する考え方にズレが生じるのも無理がありません。
特にクラウドサインでは半期で細かい機能実装も含めて20-30くらいの機能アップデートを行なっていますので、本当に「すぐに実装」してしまうと大変なことになってしまいます。
例えば、「外国人の従業員がいるので、英語で契約締結ができるようにしたい。」との声が届きます。「シンプルな要件定義だ！英語で締結メールができるようになればいいんだ！」と考えたら、大間違いです。
まず、考えなければならないのが、顧客の手順を増やさないことです。
クラウドサインのそもそもの価値は「紙よりも便利に契約締結」できることです。そのために、そもそも導入しています。これが機能実装のたびに選択画面が増え、20秒で締結処理できたものが30秒、40秒……1分と、じりじりと締結までの時間がかかってしまっては、クラウドサインの最たる利便性がなくなってきます。
クラウドサインの解決方法
クラウドサイン では、こう解決しました。言語選択画面は設けず、「宛先追加」画面に実装。そしてプリセットでは「日本語」と記入することにしました。
そして、例外的に他の言語で送付する際にだけ、プルダウン形式で選択いただく仕様にしています。
よくよく顧客の声をヒアリングしてみると「英語での締結」を希望する顧客も、９割は日本語での締結を希望しており、英語での締結がデフォルトではありません。
そうすると、英語でメールが届き、
英語で合意できるようになります。
今後は英語での締結を管理画面上からデフォルト設定化したいとの機能実装、送信画面も英語化したい、との要望は届くことは見越して、現在はここまでの機能実装とすることにしました。
蓋を開けてみると、すごくシンプルなユーザー体験にできましたが、他にもUI上の考慮はありました。共有機能（ccに入れるような機能）や追加メッセージ機能（締結時に「先日の件で契約書をお送りいたします。」のようなメッセージを入れる機能）時に、言語選択をする選択肢もありました。
しかしながら、クラウドサイン はワークフロー的に利用もでき、日本人の上司に確認依頼をし、その後外国の従業員に同意をもらい、ccでは人事部を入れるなど、同一の契約書でも確認主体により言語が異なる場合もあることを想定しました。また、他にも、外国人従業員が締結後の契約書をどうやって確認するのか/そこは英語でのUIをどう実現するのかなどもあります。
そして英語の文面は、第一次翻訳者、法律を理解したネイティブチェックなど、安易な文言選択はできません。翻訳も大変です。
たった「英語で締結したい」という顧客要望だけで、これだけの要素があります。これがクラウドサインの場合、毎月毎月、機能実装しているのです。
簡単にセールス側が「シンプルな機能ですので、できれば●月までに実装をお願いしたいです！」とは決して言えません。顧客に向き合っている側と、モノづくりをしているプロダクト側のズレが生じる理由です。
安易な機能実装が、受注を減少させる理由
クラウドサインでは、１つの機能実装にこれだけの時間をかけていますが、これは初期のプロダクトとしては特殊と呼んでいいです。初期のプロダクトとしては機能実装スピードを優先して、ここまで時間をかけない企業が通常かもしれません。
しかし、それは結果的に受注を減少させてしまうと考えています。
確かに、目の前の顧客は機能実装が早いと一時的に受注できるでしょう。しかしながら、機能が複雑化しUI/UXの良さを維持しない実装をすると、どんどん本来あったシンプルさは失われてきます。
これが良くないSaaSの純増構造です。EBU向けに機能実装を進めた結果、SMBの純増が減り、そしてChurnが増加してしまう構造です。
シンプルなUI/UXが愛されている段階で、機能要望が増加し、本当に機能を次から次へと開発していったら、確かにEBUからの新規受注は増えたが、シンプルさがなくなり、ChurnRateが増加してしまう構造です。クラウドサインなら、「締結処理に時間がかかってしまう」です。
全体の純増MRRは、実装後の方が低くなる構造です。このとき、会社としては営業人員も増加しているので実装後の受注件数の方が増えているように見える場合もありますが、1人当たり純増MRR割合は減っていた、ということは避けなければなりません。
機能実装するたびに、利用体験が複雑になってしまった「Evernote」から学ぶべきことがあります。
３行まとめ
① 顧客要望はセグメントを分けよう（大企業だけが顧客じゃない）
② 機能実装で、本来のストロングポイントを消さないこと
③ 安易な機能実装は、セールスの純増MRRも減らしてしまうかも?
顧客の要望をプロダクトロードマップにどう反映するかの永遠の課題。自分もクラウドサインのセールスマネージャーを兼任していたときの経験から、顧客に向き合っている側と、モノづくりをしているプロダクト側のズレについて書いてみました。
クラウドサインは、モノづくり集団であることを志向しています。引き続き、エンジニア、デザイナーを募集していますし、モノづくりを大切にするクラウドサインを販売するセールス、マーケティング部門も人材を募集しています。
お読みいただきありがとうございます( ´ ▽ ` )ﾉ