根拠に基づくSaaSポジショニングステートメントのテンプレート

タグラインより先にポジショニングがある

タグラインは、読み手が目にする短い表現です。ポジショニングはその背景となる文脈を与えます。つまり、顧客、顧客が検討する代替手段、あなたに関連する違い、そしてその違いが生み出しうる価値です。洗練されたタグラインを書けても、間違った種類の製品と比較されてしまうことはあります。

April Dunford のポジショニング演習は、完成したステートメントを完成したポジショニングと取り違えないよう注意を促しています。彼女のガイダンスは、製品の違い、その価値、それを重視する顧客、そして市場の文脈を順に検討していきます。本記事のワークシートは、この区別に着想を得た Soloop 独自の編集ツールであり、Dunford のテンプレートではありません。

買い手が実際に使っている代替手段から始める

買い手が前回そのタスクを終えようとしたときに何が起きたかを尋ねましょう。代替手段は別のSaaS製品かもしれませんし、スプレッドシート、代行サービス、あるいは何もしないことかもしれません。あなたが一目置く企業が、そのまま買い手の期待を形づくる代替手段であるとは限りません。

小さな根拠記録を残しましょう。確認した製品の挙動、情報源のURLまたは許可を得たメモ、その日付、そしてまだ分かっていないことです。見込み顧客の説明は伝聞の根拠であり、自分で見たデモは観察した根拠です。何かがなぜ重要なのかというあなたの説明は、関係する人や行動がそれを裏づけるまでは推論にすぎません。

競合分析ガイドでそうした事実を集め、ICP（理想的な顧客像）ワークシートで比較の対象となる人を定義しましょう。このページが扱うのはその次の判断です。つまり、事実のどの解釈がポジションとして検証する価値があるほど有用か、という判断です。

具体例：1つの製品、2つのポジショニング仮説

ReviewQueue と以下のすべての記録は、説明用の架空の例です。メモ、機能、ステートメントはすべて創作であり、実際の顧客の根拠でも Soloop のタスクの出力でもありません。同じ架空の製品は GTM ガイドにも登場するため、製品を変えずにポジショニングとセールスモーションの判断を比較できます。

デモ記録 D1 では、承認待ちの成果物リスト、共有可能なレビューリンク、記録されたクライアントの決定が確認できたとします。また、請求書発行、支払い回収、工数記録、汎用的なタスク依存関係の機能がないことも確認されています。架空のインタビューメモ I1 には、ある代理店のオペレーション責任者がチャットとスプレッドシートで承認状況を確認していると記録されています。I1 からは、状況の見落としがどれほど頻繁に起きるのか、またこの責任者がそのワークフローを置き換えるために費用を払うかどうかは分かりません。

根拠で裏づけられないベネフィットを削除する

初期の架空の草稿には「ReviewQueue を使えば代理店は2倍の速さで入金を受けられる」と書かれています。この一文は削除しましょう。D1 には支払い機能が一切なく、創作した記録のどれも、請求書、支払いのタイミング、因果関係を測定していません。承認から請求、そして支払いへと続くもっともらしい連鎖は、この主張の根拠にはなりません。

根拠を示せる製品説明はもっと狭いものです。「ReviewQueue は承認待ちのクライアントレビューを表示し、承認の決定を成果物ごとに記録します。」D1 はこれらの機能を裏づけています。「承認の催促にかかる時間を節約できる」は、ワークフローが変わるかどうか、そしてそれによってどんな別の作業が生じるかを観察するまでは仮説のままです。

すべての形容詞と比較について同じ確認を行いましょう。「最速」には、定義された比較対象と根拠が必要です。「より簡単」には、タスクとユーザーが必要です。「独自」には、確認済みの代替手段のセットが必要です。根拠がない場合は、機能をそのまま説明するか、ベネフィットを検証すべきものとして明記しましょう。

両方のステートメントを書いてから、検証するものを選ぶ

ワークシートを埋めたら、次の構成を使いましょう。「[具体的な状況にある顧客] にとって、[製品] は [裏づけのある機能または根拠のあるベネフィット] を提供する [市場の文脈] です。[実際の代替手段] と比べて、[情報源に裏づけられた関連する違い] があります。」公開するコピーに載せない場合でも、情報源、未知の点、判断を覆す条件はステートメントの横に残しておきましょう。

仮説 A：チャットとスプレッドシートでクライアントの承認を管理している代理店のオペレーション責任者にとって、ReviewQueue は承認待ちのレビューを表示し、クライアントの決定を成果物ごとに記録するクライアント承認ワークスペースです。報告された代わりのやり方との違いとして提案するのは、決定をレビュー項目に紐づけたままにできる点です。D1 は機能を裏づけ、I1 は代わりのやり方を示していますが、買い手の好みは不明です。

仮説 B：クライアントプロジェクトを調整する代理店のオペレーション責任者にとって、ReviewQueue はレビューステータスを中心とした軽量なプロジェクト管理ツールです。これは完結した別の仮説ですが、現時点で公開する選択としては適していません。D1 はより広いカテゴリーに寄せられるであろう期待を裏づけられず、I1 もプロジェクト管理を置き換えるニーズを示していないからです。

理解度チェックには A を選び、主張はデモで示された挙動に限定しましょう。B は、却下した理由とともに判断記録に残しておきます。後の根拠が別のカテゴリーを示した場合は、あらゆる場所で見出しを変える前に、まずポジションを見直しましょう。

2仮説のポジショニングワークシートをコピーする

表をドキュメントにコピーし、同じ現行製品について2つのポジションを比較しましょう。アカウントは不要です。日付付きの情報源IDを使い、空欄を魅力的な主張で埋めるのではなく、未知の点は未知のまま残してください。モバイルでは横にスクロールすると両方の仮説を比較できます。

人に理解度を確認してから、判断を見直す

できあがったメッセージを関係する人に見せ、その製品が何をするものか、誰のためのものか、何と比較するかを尋ねましょう。あなたが意図した解釈を説明する前に、まず相手に答えてもらいます。誤解や欠けている期待も、同意と同じくらい丁寧に記録しましょう。

その検証方法は、下のメッセージ検証ガイドで取り上げています。文を理解することと、製品を好むこと、使うこと、お金を払うことは別の問題です。読み手が承認ツールにプロジェクト計画の機能を一貫して期待するなら、文脈を見直しましょう。理解はしているものの今の代わりのやり方で十分だという場合は、タグラインを何度も書き直すのではなく、ニーズを調べましょう。

根拠と2つの仮説を Soloop に持ち込む

次の書き出しを会話にコピーしてください。「私の製品は [URL] で、[役割とワークフロー] 向けです。現在の機能は [情報源付きの事実] です。買い手は現在 [代替手段。根拠または不明] を使っています。これらのポジション [A] と [B] を比較し、裏づけのある主張と仮定を分け、次に探すべき反対の根拠を1つ挙げてください。」

ワークシートはご自身で完成させることができます。外部の根拠の欠けている部分についてさらに調査が必要な場合は、範囲を限定した競合調査タスクについて相談し、承認する前に提案された範囲とコストを確認してください。生成されたステートメントや、シミュレーションした買い手の反応では、ポジションを検証できません。Soloop の公開エントリーはこのワークシートを引き継がないため、ご自身でコピーし、使用する権限のある資料だけを共有してください。