PSF

一言でいうと

解こうとしている課題が実在し、用意した解決策に相手が対価を払うと確かめられた状態で、製品を作り始める前に置く最初の関門です。

提唱者と登場年

整理したのはAsh Mauryaです。『Running Lean』でリーンスタートアップの手順を実務向けに具体化し、スタートアップが最初に越えるべき関門はPMFではなくPSFだとしています。書誌で確認できるのはオライリー版（2012年）で、自費出版の初版はそれ以前に出ています。

理由は検証の順序です。PMFは市場に定着したかを問う基準で、判定には製品と一定の利用者が要ります。一方PSFは、製品を作る前でも判定できます。課題が実在するか、その解決策に相手が支払う意思を示すか。この2つが確かめられていないまま作り始めると、動くものはできても使われません。

Mauryaは、作ってから売るのではなく、デモを見せて売り、売れたら作るという順序を勧めています。国内でも新規事業の検証手順として、この段階を明示的に置く組織が増えています。

何を解決するか

解決したいのは、実在しない課題に開発費を投じてしまう事態です。要望として聞いた話が、実際には対価を払うほどの困りごとではない場合があります。作ったあとに気づくと、費やした期間がそのまま損失になります。

もうひとつは、解決策への思い入れが検証を歪める問題です。先に解決策があると、それが当てはまる課題を探す順序になり、課題の実在確認が省かれます。

実際の進み方

まず課題を特定します。想定顧客に話を聞き、いま何にどう対処しているかを聞き取ります。既存の代替手段が何もない領域は、課題が存在しないだけの可能性があります。

次に解決策を提示し、支払いの意思を確かめます。デモ、モックアップ、紙の資料でも構いません。確認するのは感想ではなく、契約の意思、事前入金、時間の確保といった負担を伴う行動です。「良いですね」は判定材料になりません。条件は2つあります。事業として成り立つ価格で払われること、そして1件で終わらず繰り返し起きることです。1社の内示をもって到達と宣言すると、次の相手で再現しません。

支払いの意思が集まらなければ、解決策ではなく課題設定に戻ります。ここで解決策の作り込みへ進むと、PSFを飛ばしたまま開発に入ることになります。

導入でよくある失敗

• 感想を根拠にする。ヒアリングの好意的な反応を需要と読み替えると、負担のない同意を検証結果として扱うことになります
• 既存顧客だけに聞く。すでに関係のある相手は否定しにくく、新規の市場では再現しない反応が返ります
• 解決策から始める。作りたいものが先にあると、それに合う課題を探す順序になり、課題の実在確認が抜けます

求人票にこの語がある場合に読み取れること

新規事業やゼロイチのフェーズであることが読み取れます。プロダクトマネージャーや事業開発の募集にこの語がある場合、決まった仕様を実装する仕事ではなく、何を作るかを確かめるところから任される可能性が高いといえます。国内では求人票に書かれるより、候補者の職務経歴書や面談での自己申告（「PSFまでやりました」）で出会う語です。

同時に、この段階の組織は方向転換が前提です。作ったものが白紙に戻る経験を許容できるかが、入社後の相性を分けます。

自社側では、どこまでを検証段階と見なすかの基準を先に決めておきます。あわせて、方向転換で職務内容が変わる前提の段階なので、求人時に明示する「業務の内容の変更の範囲」をどう書くかも決めておいてください（詳細は社労士に確認してください）。候補者には、検証の結果として当初案を捨てた経験を聞きます。あるとだけ答えられたら、何のデータで捨てたか、誰が決めたか、判断までにどれだけかけたかまで踏み込みます。

隣接手法との違い

関連キーワード

課題インタビュー / 支払い意思 / Lean Canvas / MVP / ピボット / 顧客開発 / 仮説検証