- 課題：ターゲット顧客がその痛みを頻繁に経験し、しかも無視できない影響がある。
- オーディエンス：その課題ときっかけを共有する人を特定し、接触できる。
- ソリューション：現在のワークフローが、既存の回避策よりも前進を助ける。
- 交換：その成果のために、時間、アクセス、行動の変化、またはお金を提供してくれる。
ユースケース日本語
MVP後の検証ループ
頭の中のピッチではなく、実際に作ったSaaSアイデアを検証しましょう。
ランディングページ、デモ、リポジトリ、ピッチ資料、ウェイトリスト、または粗削りなプロダクトを持ってきてください。現在のプロダクトを無意味にする可能性が最も高い仮説を特定し、承認済みのテストを1つ実行して、実際の行動をもとに次の意思決定を見直しましょう。
適用の条件
創業者が混同しがちな4つの仮説を切り分けましょう。
プロダクトはある仮説には合格しても、別の仮説で失敗することがあります。テストを選ぶ前に、現在のリスクを診断しましょう。
- 需要の証明として提示される、一回限りのAIアイデアスコア。
- 接触可能な顧客が行動するという証拠のない、大まかな市場規模の統計。
- プロダクトを使えない、または使うつもりのない人からの褒め言葉。
- 明示された仮説や受け入れテストのない、さらなる機能スプリント。
最小限の完結したワークフロー
成果物から、反証可能なテスト1つへ進みましょう。
検証は証明書ではなく、意思決定の連続です。各サイクルで、次の投資を正当化しやすく、あるいは止めやすくする必要があります。
- 01
現在の成果物を点検する
プロダクトが今何をしているか、誰を対象としているか、約束する前進、最初の価値イベント、そして訪問者に求めるアクションを記述します。
- 02
仮説をテスト可能な文として書き出す
課題、オーディエンス、ソリューション、交換の各仮説を、観察可能な証拠によって反証されうる形で書きます。
- 03
最もリスクの高い仮説を選ぶ
不確実であり、かつ次の開発サイクルを無駄にしかねない仮説を選びます。なぜそれが他の仮説より優先されるのかを説明します。
- 04
意思決定の背景をリサーチする
出典リンク付きのリサーチで、現在の代替手段、顧客の言葉、コミュニティ、きっかけ、反証となる証拠を見つけます。需要の証明ではなく、背景情報として扱います。
- 05
最小の現実的なテストを設計する
適格な人に1つのアクションを依頼します：ワークフローを試す、データを共有する、フォローアップの予定を入れる、再訪する、誰かを紹介する、または支払う。しきい値と停止条件を先に定義します。
- 06
範囲を限定したアクションを承認して実行する
正確なターゲット、ペイロード、チャネル、コスト、受け入れ基準をレビューします。公開投稿、ダイレクトメッセージ、メール、コード変更、デプロイは、それぞれ実際の承認フローの中で扱います。
- 07
継続・修正・停止を選ぶ
行動が仮説を裏付けるなら継続し、オーディエンスやワークフローが近いものの的を外しているなら修正し、中核となる課題、アクセス、交換が存在しないなら停止します。
確認できるコントロール
承認カードの例：最もリスクの高い仮説のテスト
これは説明用のタスクカードであり、顧客の実績や完了した実験を示すものではありません。
- 目的
- 現在のランディングページの約束が、すでにプロダクトをリリースしたソロのSaaS創業者が繰り返し抱える課題と一致しているかをテストする。
- 行動
- 現在公開されている10件の課題の記述について承認済みのリサーチを実行し、その後、別途レビューするための5人分の対話リストを準備する。
- 対象
- 公開中のURLを持ち、ローンチ後の需要の課題を示す最近の証拠がある、英語を話すソロのSaaS創業者。
- 受け入れ基準
- 出典URL、課題の原文での表現、反証、5人の適格なターゲット、提案するテストを返す。リサーチでの出現頻度を、利用や支払いの意思の証明として扱わないこと。
- 停止条件
- 定義したオーディエンスときっかけに合致する情報源が3件未満の場合、または証拠がランディングページの約束とは異なる課題を示している場合は停止する。
修正却下この範囲で承認
検証の引き継ぎテンプレート
成果物から意思決定までの流れを点検可能にしましょう。
実際のプロダクトとテストから観察した証拠で、この引き継ぎ資料を記入してください。空欄や矛盾する項目は有用ですが、でっち上げた確実性は有用ではありません。
- 入力した成果物
- レビューした正確なURL、リポジトリのスナップショット、ピッチ資料、デモ、またはランディングページのバージョンへのリンク。
- 最もリスクの高い仮説
- 反証可能な課題、オーディエンス、ソリューション、または交換の仮説を1つ記述します。
- このリスクを選んだ理由
- その仮説が誤っていた場合に、なぜ次の開発サイクルが無効になる、または方向転換が必要になるのかを説明します。
- 承認済みのテスト
- ターゲット、アクション、ペイロード、チャネル、コスト、受け入れのしきい値、停止条件を記録します。
- 返ってきた証拠
- 観察された行動、直接の発言、無反応、失敗、反証、そしてまだ不明な点を分けて記録します。
- 意思決定
- 継続、修正、停止のいずれかを選び、その選択の根拠となる証拠と、次に許可されるアクションを明記します。
判断スコアカード
1つの混合スコアではなく、検証のはしごを使いましょう。
顧客が差し出す時間、アクセス、習慣、評判、お金が多いほど、証拠は強くなります。
背景
信頼できる情報源が、カテゴリ、代替手段、用語を裏付けている。
課題の証拠
適格な人が、頻度、影響、現在の回避策を説明している。
コミットメント
時間、データ、アクセス、紹介を提供する、または次のステップに同意する。
最初の価値
目標のワークフローを完了し、意図した前進を体験する。
再訪
最初のサポート付きの試行の後も、その行動を繰り返す。
支払い
価値を受け取り続けるために支払う。
現在のプロダクトの範囲
いま実際に動くものを前提に計画する。
どのリサーチレポートや自動評価ツールも、それ単独では需要を検証できません。検証結果は、テストしたオーディエンス、プロダクトの状態、オファー、チャネル、収集した証拠に限定されたものです。
リサーチ
提供中承認済みのリサーチでは、市場、競合、公開された不満、見込み顧客を調査し、出典リンク付きで出力できます。
X / Twitter
提供中（OAuth連携）承認済みの X/Twitter の作業では、連携したアカウントを通じて投稿し、返信を収集できます。
コールドメール
ベータ · Gmail が必要メールの実行は、Gmail とタスクに表示される承認モードに依存します。
リサーチとレビュー可能な下書きを活用し、公開投稿は創業者自身が行います。
広告
計画のみ広告の仮説は計画できますが、Soloop は現在キャンペーンの購入や運用を行いません。
コーディング
承認後に提供Coding Agent は、承認されたプロダクトの変更をサンドボックス内で実装・テストできます。
ループを続ける
判断が変わったら、次のリソースを使う。
よくある質問
次の一手の前に確認したいこと。
開発前にSaaSアイデアを検証できますか？
開発前でも、課題、オーディエンス、言葉、コミットする意思はテストできます。このワークフローは実際の成果物を持つ創業者に焦点を当てています。人は抽象的な説明よりも、具体的な約束やワークフローに対してのほうが反応できるからです。
ウェイトリストはアイデアが検証された証明になりますか？
なりません。ウェイトリストは関心を示し、連絡できる人を提供してくれますが、適格なユーザーによる利用、再訪、支払いのほうが強いシグナルです。それぞれを別々に追跡してください。
Soloop はSaaSの検証スコアを出しますか？
出しません。Soloop は魔法のアイデア採点ツールとして位置づけられていません。承認済みのリサーチと実行を構造化し、創業者が点検可能な証拠から意思決定できるよう支援します。
いまあるプロダクトを持ってきてください
検証すべき仮説を持ってきてください。
このブリーフをコピーして角かっこ内を置き換え、「プロジェクトから始める」を選択したうえで Soloop のホームページに貼り付けてください。このリンクはブリーフを自動では引き継ぎません。まずテストについて話し合いましょう。リサーチやその他のアクションには、それぞれ個別の承認フローが必要です。
これはすでに作ったプロダクトです：[URL、デモ、またはリポジトリ]。[具体的なオーディエンス] には [根拠] という理由で必要だと考えています。最も確信が持てない仮説は [仮説] です。小規模な行動テスト、自分の判断を変えるような結果、そして停止条件を選ぶのを手伝ってください。公開情報のリサーチと、実際の人から学ぶべきことを分けてください。どんな実行も、まず私のレビュー用に提案してください。プロジェクトから始める