- その人が今まさに対象の課題を経験しており、現在の回避策を説明できる。
- プロダクトを試すのに必要なワークフロー、データ、または決定権限にアクセスできる。
- その利用シーンが、次に下す必要のあるプロダクト上の判断と一致している。
- 最初の価値を観察し、フォローアップを行い、その人が再訪するかどうかを確認できる。
ユースケース日本語
最初の顧客を獲得する運用ループ
学習ループを絞り込み、SaaSで最初の10人の顧客を獲得する。
最初からすべてのチャネルに手を広げてはいけません。条件に合う顧客を一つ定義し、今まさにその課題を抱える少人数のグループを見つけ、役に立つ提案を一つ行い、返信・利用・再訪・支払いに次の一手を決めさせましょう。
適用の条件
10まで数える前に、誰を数に入れるかを定義する。
最初の顧客とは、登録してくれる人なら誰でもよいわけではありません。一つの適格性ルールを使い、10人の顧客から比較可能な証拠が得られるようにしましょう。
- 好奇心から幅広いウェイトリストに登録したものの、中核のワークフローを使えない人。
- 称賛が現在の課題と結びついていない、好意的な支援者。
- 要望がプロダクトを仮説から引き離してしまう、別のセグメントのユーザー。
- 現時点で誠実かつ安全に運用できないチャネルを通じて接触した連絡先。
最小限の完結したワークフロー
30 → 10 → 3 の顧客サイクルを一度回す。
これらの数字は計画上の制約であり、保証されたファネルではありません。目的は、すべての反応から学べるほどバッチを小さく保つことです。
- 01
顧客とトリガーを書き出す
役割、状況、切迫したイベント、現在の回避策、観察可能なコストを明記します。2人のリサーチャーがこの定義から似た人物を見つけられる状態にしましょう。
- 02
条件に合う30人のリストを作る
承認済みのリサーチを使い、課題の証拠が目に見える人を探します。各人物が条件に合う理由を記録してください。フィルタリングしていない連絡先リストをICPとして扱ってはいけません。
- 03
10件の個別の会話を準備する
具体的な文脈と役に立つ質問から始めます。何ができているか、どこがまだ粗いか、そしてこの人がなぜ関係しうるのかを説明します。断りやすくしておきましょう。
- 04
アウトリーチの内容を正確に承認する
受信者、文面、チャネル、アカウント、バッチサイズ、停止条件をレビューします。計画は、後から未知の内容を公開・送信してよいという許可ではありません。
- 05
絞り込んだ成果を一つ届ける
条件に合う回答者が、プロダクトの中核となる業務を完了できるよう支援します。再現可能なプロダクトが何をすべきかを学べるのであれば、手作業での支援も問題ありません。
- 06
三択で判断する
条件に合う人が価値に到達して再訪するなら継続。関心はあるのにワークフローが機能しないなら修正。課題や切迫性が存在しないなら、停止するかセグメントを変更します。
確認できるコントロール
承認カードの例：最初の会話バッチ
これは説明用のタスクカードであり、顧客の実績や完了した実験を示すものではありません。
- 目的
- ベータ版を公開している創業者主導のSaaSチームが、条件に合う初期ユーザーを募集し、そこから学ぶための再現可能な方法を必要としているかを検証する。
- 行動
- レビュー用に、X/Twitter での個別の返信またはダイレクトな会話の書き出しを5件準備する。個別に承認された項目のみを公開する。
- 対象
- プロダクトを公開しており、最近、初期ユーザー探しの難しさについて公に発言した創業者5人。
- 受け入れ基準
- すべての下書きが観察可能な文脈に言及し、役に立つ質問を一つ投げかけ、顧客獲得の保証や Reddit/メールの自動実行を主張していない。
- 停止条件
- 5件の下書きをレビューした時点、アカウント/認証の不一致があった時点、またはターゲットがICPに合わない証拠が見つかった時点で停止する。
修正却下この範囲で承認
再利用できるワークシート
30 → 10 → 3 の顧客ワークシートをコピーする。
見込み客ごとに1行を使い、適格性、アウトリーチ、プロダクト利用、再訪、支払いを分けて記録します。スプレッドシートかシンプルなドキュメントで十分です。
- ICPとトリガー
- 役割、状況、切迫したイベント、現在の回避策、観察可能なコスト。
- 出発点となる成果物
- 相手が確認したり試したりできるURL、デモ、リポジトリ、ランディングページ、またはワークフロー。
- 30人の適格性確認
- 名前、公開情報源、適合の証拠、確認した除外条件、そして課題が現在のものだと考えられる理由。
- 10件の会話バッチ
- 正確な文脈、最初の質問、チャネル、アカウント、バッチ番号、承認済みの最終文面。
- 承認の範囲
- 受信者、送信内容、コスト、数量、担当者、成功の確認方法、停止条件。
- 最初の価値
- 試みた絞り込んだ業務、提供した支援、完了の証拠、失敗した箇所。
- シグナル台帳
- 関連する返信、条件に合う会話、最初の価値、再訪、支払い、明確な「ノー」、そして証拠のURLまたはメモ。
- 判断
- 継続、修正、または停止。オーディエンス、約束、プロダクト、次のバッチで何を変えるかを記録します。
判断スコアカード
会社の判断を変えるシグナルをスコア化する。
注目度、適格性、プロダクト利用、収益を一つのコンバージョン数値にまとめてはいけません。
関連する返信
課題、タイミング、または現在の回避策を裏付ける。
条件に合う会話
その人がICPに合致し、対象のワークフローを試せる。
最初の価値
プロダクトが約束する絞り込んだ業務を完了する。
再訪
説得されなくても戻ってくる、またはワークフローを繰り返し使う。
支払い
継続的な価値に対してお金を払う。
明確な「ノー」
具体的な反対意見が、オーディエンス、約束、またはプロダクトの変更に役立つ。
現在のプロダクトの範囲
いま実際に動くものを前提に計画する。
このワークフローは、30人の見込み客から10人の顧客を得ることを約束するものではありません。バッチサイズは、範囲の限られた学習サイクルをつくるためのものです。結果は、課題、適格性確認、提案、信頼、プロダクト、そして創業者のフォローアップ次第です。
リサーチ
提供中Soloop は承認済みの市場・競合・見込み客リサーチを実行し、証拠をプロジェクトに返すことができます。
X / Twitter
提供中（OAuth が必要）承認済みの下書き、投稿、返信の収集を、接続したアカウントを通じて実行できます。
コールドメール
ベータ · Gmail が必要メール関連の作業には、接続済みの Gmail アカウントと、タスクに表示される承認フローが必要です。
Soloop はレビュー可能な文面を準備できますが、公開投稿のステップは創業者自身が行います。
広告
計画のみSoloop はこのチャネルについて議論し計画できますが、現時点では広告の購入や管理は行いません。
コーディング
承認後に提供サンドボックス内のコーディングで、承認されたタスクの範囲内でプロダクトを変更・テストできます。
ループを続ける
判断が変わったら、次のリソースを使う。
よくある質問
次の一手の前に確認したいこと。
最初の10人のSaaS顧客は、一つのニッチから獲得すべきですか？
多くの場合、そうです。最初のセグメントを絞り込むと反応を比較しやすくなり、同じ課題、トリガー、価値を実感する瞬間が繰り返し起きるかどうかを見極めやすくなります。パターンが明確になってから広げましょう。
無料のベータユーザーは顧客に含まれますか？
お金が動くまでは、条件に合うユーザーとして記録してください。そのユーザーの利用や再訪の行動は貴重な証拠ですが、支払いを分けて記録しておくことで、大勢の無料ユーザーを成立しているビジネスモデルと取り違えるのを防げます。
どの集客チャネルから始めるべきですか？
条件に合う人がすでに課題を表明していて、あなたが誠実に運用できる場所から始めましょう。Soloop は現在、承認済みのリサーチと提供中の X/Twitter に対応しています。コールドメールは Gmail を使ったベータ版、Reddit の公開は手動、広告は計画のみです。
最初のメールや Reddit の返信には何を含めるべきですか？
その人が条件に合う公開上の理由、その人が述べた課題、役に立つ質問を一つ、そして小さなお願いを一つ記録しましょう。Gmail ベータでは、承認フローの中で単一の受信者と最終的なメッセージをレビューします。Reddit では、コミュニティのルールを確認し、関連がある場合は自分との関係を開示し、レビュー済みの下書きを自分で投稿します。リサーチで見つけた連絡先は、顧客でも送信の許可でもありません。
間違ったオーディエンスを追いかけずに X を活用するには？
実際のプロダクト変更を一つ、そこから学んだこと、そして課題を抱える人に向けた具体的な質問を共有しましょう。公開を承認する前に、接続済みのアカウントと投稿内容を正確に確認してください。関連する返信とその後のプロダクト利用を、インプレッションや「いいね」とは分けて記録します。創業者からの注目だけでは、購入者の関心があるとは言えません。
いまあるプロダクトを持ってきてください
顧客に関する問いを一つ決めて始めましょう。
このブリーフをコピーし、角括弧の部分を置き換えてください。「プロジェクトから始める」を選ぶと Soloop のホームページが開くので、そこにブリーフを貼り付けてください。内容は自動では引き継がれません。リサーチタスクは実行前にレビューし、結果を確認してからアウトリーチを計画してください。
私のプロダクトは [URLまたはデモ] です。[具体的な役割] が [業務] を行うのを支援します。現在の代替手段は [回避策] です。顧客像を一つに絞り込み、公開情報を根拠にした小規模な見込み客リサーチのタスクを提案してください。各人物が条件に合う理由を説明し、情報源と不明点を示し、人数が足りない場合は正直に報告してください。リサーチを実行する前に、範囲を私のレビュー用に準備してください。誰にも連絡しないでください。プロジェクトから始める