前回の投稿で、一般的に語られているProduct Marker Fitに向けた活動はB2Cを想定したものであり、B2B SaaSの場合は若干事情が異なるのではないかとの問題意識を書きました。その上で、B2B SaaSの場合、ユーザーの日常業務との関係で、プロダクトの実際の使用シーンや導入インパクト等を考慮した検証が必要になると述べました。

今回はより具体的にPMF検証に向けた活動を考察したいと思います。具体的には、B2B SaaSは上記内容のPMF検証を行うために、B2B SaaSはある程度のプロダクトの準備と完成度が必要になります。そのためにPMF検証は効率的に進める必要があります。その進め方に関して述べたいと思います。

B2B SaaSのPMF検証には、ある程度の完成されたプロダクトが必要

まず、PMF検証に入るためのプロダクトの完成度について考えましょう。

様々な本やウェブサイトで書かれているとおり、ユーザーが直面する課題や事業の価値を検証できる必要最小限のプロダクト（Minimum Viable Product = MVP）を出来る限り早く作り、検証サイクルを高速に回すことが、PMF検証の定石とされています。典型例として挙げられるのが、伝説的なウェブサイト1ページで構成されたAirBnBのプロトタイプで、裏側の機能が実装されておらず創業者のマンパワーで運営されていました。B2B SaaSに関しても、一般論としてはこの定石があてはまります。

しかしながら、B2B SaaSの場合、そのMVPとして、ある程度まで開発が進んだプロダクトが必要です。最近、「 売ることができる最小限のプロダクト」といいう意味のMSP（Minimum Sellable Product)という言葉があります。B2B SaaSでは、PMF検証を行うためには、このMSPレベルのプロダクトが必要となります。

この理由は、余りにシンプルなプロダクトですと、B2B SaaSのPMF検証で重要な、どのように日常業務に入り、プロダクトが貢献できるのかに関する検証が出来ないからです。既にユーザーは（アナログを含む）何らかの代替手段を取り、プロダクトの業務目的を達成しています。シンプルなプロダクトですと、単に劣ったプロダクトに過ぎず、ユーザーの業務目的を達成できないのです。

例えば、クラウド会計ソフトを考えてみましょう。クラウド会計ソフトを使う前に、企業がパッケージの会計ソフトを使っていました。その中で、機能が実装されていない会計ソフトを作り、ユーザーに見せたところで、その価値検証が出来るでしょうか？ PMF検証のためには、一通りのクラウドで記帳や仕分け、帳票作成レベルが出来るプロダクトが必要だったのではないでしょうか？

つまり、B2B SaaSにおけるMVPとは、ユーザーの日常業務に入り、ユーザーの事業に対してプロダクトが与える影響を検証が出来る最小限のプロダクトであると言えます。具体的には、ユーザーストーリーマップの中でユーザー体験が最初から最後までつながる機能が最低限一通り実装され、プロダクトの利用を通じて、ユーザーが「このプロダクトの新しい価値は何か？」を認識出来る状態まで完成させる必要があります。ここまで出来ていれば、UX/UIは未完成の状態であったり、機能がまだまだ不十分・未完成であったり、挙動が不安定だったりしても問題がありません。

KARTEの事例
KARTEでは、2014年4月前後にユーザーによる検証が開始しました。その段階では、管理画面、解析、セグメンテーション、ポップアップの作成・配信という、KARTEのユーザー体験に必要な機能を一通り実装していました。一方で挙動は不安定でしたし、解析の精度も低く、UIも未完成で、さまざまなプロダクト上の問題も発生していました。初期メンバーが裏で顧客に代替して「運用」し、プロダクトの「実績」を作っていました。

B2B SaaSでPMF検証を効率的に進める方法

このようにB2B SaaSでは、PMF検証の準備段階のプロダクト開発に時間がかかります。一方で、各種本やウェブサイトが指摘するように、プロダクトを完成させたものの、その仮説が的外れで時間切れとなる自体を回避しなければなりません。何よりも検証のサイクルを素早く何回も回すことがPMF到達の最短ルートです。

この両者の要請を充足させるためには、 (1)仮説検証項目を明確にし、可能な範囲で検証を進める方法と、(2)Product User Fitを分けて検証する方法があると考えています。

PMF検証を効率的に進める方法1： 仮説検証項目を明確にし、可能な範囲で検証を進める

これはPMFに向けて検証が必要な項目と、それが可能になる条件・時期を明確にし、段階を分けて検証とプロダクト開発を進めることです。

前回書きましたB2B SaaSのPMF検証の項目には、順序や優先順位があります。例えば、ユースケースの創出の前に、「実際にプロダクトが解決しようとする課題やユーザーのペインポイントが存在するか？」の検証が不可欠です。どの程度までプロダクトの開発が進めば、どのような検証に入れるのか？ スケジュールは事前に意識して進める必要があります。

B2B SaaSの場合、プロダクトが解決しようとするユーザーの課題やペインポイントは、早い段階から明確になるケースが多いでしょう。そこから、プロダクトの提供価値自体は早期に検証可能です。なぜならば、B2B SaaSは、企業活動に直結するプロダクトですので、既にユーザーは何らかの代替手段を取っています。それは、売上や生産性の向上、コスト削減や業務効率化の関係で、比較的容易に理解可能だからです（特に、最近増えている、その業界出身の方がSaaSを始めるケースでは、起業家が明確に課題意識を持っている場合も多いでしょう。）。このユーザーの課題やペインポイントの解像度が高ければ、プロダクトの提供価値が明確になり、的外れなプロダクトになる可能性が低くなります。

また、プロダクトの提案書等を作り「プレ提案活動」を実施したり、ティザー等を作ることにより、ユーザーの反応を見ることが可能です。そこから、様々な検証やGo-To-Markeに向けた仮説の構築が可能になります。この活動を通じてある程度の仮説が得られるならば、実際のPMF検証は、ユーザーが実際にプロダクトを利用しなければ検証出来ない項目に絞ることが出来ます。具体的には、それはユーザーの日常業務との関係に入り込んだユースケース開発やUI/UXの検証です。

このように、B2B SaaSでは、検証が必要な項目を事前に洗い出すことにより、プロダクト開発と並行してPMFの検証を進めることが可能です。特に、プロダクト開発において最も重要なユーザーの課題やペインポイントは早期に検証することが可能ですので、ここは早期に検証することを推奨します。

PMF検証を効率的に進める方法2： Product User FitとProduct Market Fitを分ける

二つ目の手段が、Product Market Fitの前段階として、Product User Fitの検証を早期に行うという手段があります。

PMFとは、顧客を満足させる最適なプロダクトを最適な市場に提供出来ている状態を指します。多くのスタートアップでは、このPMFの前に、一部のユーザーに対してプロダクトの価値が刺さり、熱狂的に支持される状態があります。PMFの状態の前段階として、一部の特定ユーザーに対して、プロダクトの価値が深く刺さっている状態が、Product User Fit（PUF）です。AirBnBの創業者は「スケールしないことをやれ」「人気のあるものを作りたかったらそれを愛する100人を得ること。そうすればその100人が次に広げてくれる」と語っています。この100人に愛される状態を目指すのがPUFです。

特にB2B SaaSの場合、PMF検証を通じて「既存の業務オペレーションを変更し、今すぐこのプロダクトを使う理由は何か？」が明確になる必要があります。PUFの検証は、この「今すぐこのプロダクトを使う理由」を明らかにする活動ともいえます。

PUFとPMFの検証を分ける場合、それぞれの活動内容は以下になります。これは実質的には

■ Product User Fitの検証
開発初期段階から、少数のユーザー限定でプロダクトの価値の検証を実施。「今すぐこのプロダクトを使う理由」を明らかにし、熱狂的にプロダクトが支持される状態を目指す。

■ Product Market Fitの検証
PUF検証を通じてプロダクトを支持するようになったユーザーと共同で、ユースケースの開発やUI/UXの磨き込みを進める。そのユーザー属性からGo-to-Marektの仮説を構築する。

PUF検証段階では、ユーザー数を増やすのではなく、AirBnBの創業者が言うようにユーザーとの深い関係性の構築を重視した方が良いでしょう。そちらの方が、ユーザーの課題や業務に深く入り込んだプロダクトの価値検証と創造が出来ます。PUF検証を通じて、一番最初のプロダクトと顧客の基盤を強固に構築し、そこから拡大するのが一番の近道です。

またプロダクトも未完成の状態で問題ないです。最初に、プロダクトが未完であることを前提に、プロダクトが実現しようとしている価値・世界観に共感するユーザーにトライアルを依頼します。そして、そのユーザーと一緒に、プロダクトや事業を「共創」し、PUFやPMFを行う視点が必要であると考えます。

Product User Fit検証の事例： KARTEの事例

このProduct User Fitは新しい概念かもしれません。ですが、多くのB2B SaaSで実際にされている印象を持っています。KARTEも、今振り返ると、このPUFを通じてPMFに到達しました。KARTEの例をみてみましょう。

クローズドα版のリリース（2014年1月〜9月）
アパレルE-Commerceのスタートアップを中心にとトライアルを開始しました。この2社はプロダクトの構想を説明した際に共感をいただいたユーザーです。この時点ではプロダクトは全く完成しておらず、プロダクトの提供価値を中心に検証を実施しました。初期メンバーが「運用」を行い、プロダクトの提供価値を見せていました。この数社から、KARTEの提供価値が絶賛されたことから、この提供価値に対応する機能を今後開発できれば成功する確証が得られました。これがPUMの検証と言えるでしょう。

クローズドβ版をリリース以降（2014年10月）
初期段階の結果を受けて、大手アパレルのE-Commerceサイトでトライアルを開始しました。このユーザーも同様にプロダクトの構想を説明した際に共感をいただき、トライアルを進めました。上記PUF検証で得た仮説がこのECサイトでも通用することを確証し、そこから実際にどのように使われるのかの検証やユースケースの創出を実施しました。UXもプロダクトの挙動も不十分でしたので、その磨き込みも実施しました。

クローズド段階のユーザーは、KARTEが実現したい価値に共感いただいたプロダクトが未完であることを前提にトライアルと検証を進めました。KARTEの初期段階は、そのユーザーとの価値共創の側面があったと考えます。

次回は具体的にPUFやPMF検証の進め方に関して検討したいと思います。また、B2B SaaSの場合、どのような状態であればPMFに到達したと言えるかに関しても検証いたします。