mcpField
T
tool-foundation-sprint-founding-hypothesis

tool-foundation-sprint-founding-hypothesis

github.com/product-on-purpose生産性769627 回インストール4 日前に更新
リポジトリ

tool-foundation-sprint-founding-hypothesis について

製品チームがFoundation Sprintの2日目を締めくくるためのスキルです。スプリントの決定事項を、厳格なテンプレートに沿った検証可能な仮説、仮定スコアカード、次の検証案にまとめます。

主な機能

  1. 015項目の厳格な仮説テンプレート
  2. 02仮定の確信度スコアカード
  3. 03根拠とリスクの整理
  4. 04次の検証テストの提案
  5. 05Deciderによる承認チェックポイント

活用シーン

  1. 012日目のスプリント決定事項の集約
  2. 02検証すべき仮定の特定
  3. 03次の検証方法の選定

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/product-on-purpose/pm-skills --skill tool-foundation-sprint-founding-hypothesis

インストール後、Claude Code で/tool-foundation-sprint-founding-hypothesisを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

HISTORY.md
references/
EXAMPLE.md
TEMPLATE.md

詳細

Foundation Sprintの創業仮説

Foundation Sprintの2日目の終わりです。チームは、スプリントの成果全体を、正規の1文と検証可能なスコアカードに集約します。これがこのスプリントの成果物です。このスキルより前の作業はすべて準備でした。承認可能な創業仮説がなければ、スプリントは失敗です。

ファミリー契約:docs/reference/skill-families/foundation-sprint-skills-contract.md。このスキルはfoundation-sprint-skillsのメンバーです。

使用するタイミング

  • Foundation Sprintの2日目の終わり。
  • Magic Lensesが承認され、第一候補と予備案が決まっている。
  • チームには2日目に30〜45分が残っており、慎重に文を書くための余力がある。

使用しないタイミング

  • Magic Lensesで明確な第一候補が決まらなかった場合。Magic Lensesに戻ってください。第一候補が定まらないままでは、創業仮説を安定させられません。
  • チームが「仮説は後で磨けばよい」と考えている場合。仮説は2日目の終わりまでに承認されなければなりません。そうでなければ、スプリントの成果は未完成です。後で磨くということは、議論を蒸し返すことになり、スプリントの目的が損なわれます。
  • チームが「スプリントを終わらせるため」に曖昧な仮説を承認しようとしている場合。曖昧な仮説は、仮説がないよりも悪いものです。誤った自信を与え、検証に失敗したときに信頼を損ないます。

このスキルが作成するもの

次の5つのセクションからなる、ひとまとまりの成果物です。

  1. 創業仮説の記述:唯一の正規の1文(厳密なテンプレートを使い、言い換えない)。
  2. 前提条件のスコアカード:仮説から抽出した5〜7個の前提条件。それぞれに、現在の確信度と次に実施する最適なテストを付けます(3〜10個を許容し、推奨範囲は5〜7個です)。
  3. これを信じる理由:根拠となる証拠を挙げる箇条書き3〜5項目。
  4. 仮説を覆し得るもの:リスクを挙げる箇条書き3〜5項目。このセクションでは、チームが仮説に惚れ込んでいるのか、それとも適切に調整された確信度で仮説を捉えているのかを確かめます。
  5. 推奨する次の検証ステップ:Design Sprint、顧客調査、実験、ランディングページテストなどを推奨します。具体的なテスト、担当者、スケジュールを明記します。

正規のテンプレートについてはreferences/TEMPLATE.mdを、Brainshelfの例についてはreferences/EXAMPLE.mdを参照してください。

正規のテンプレート(厳守)

If we help [target customer] solve [important problem]
with [approach], they will choose it over [competitors or alternatives]
because our solution is [differentiators].

このテンプレートはv0.1.0で厳守します(承認済み仕様の決定に基づきます)。言い換えは認められません。「XのためにYを支援することで……」のようなバリエーションや、2つのスロットを1つにまとめる表現(「[アプローチ]で[問題]を解決する」など)は、このスキルでは却下されます。この厳格さには意図があります。テンプレートを厳密にすることで、チームがすべてのスロットを具体的に埋めるよう促します。

5つのスロットは次のとおりです。

スロット参照元確認事項
対象顧客Basicsの対象顧客の記述具体的であること(セグメントではなく、識別の手がかりを示す)
重要な問題Basicsの重要な問題の記述乗り換えを促すほど深刻であること
アプローチMagic Lensesの第一候補第一候補そのものであり、弱めた案ではないこと
競合または代替手段Basicsの競合マップそこに挙げられている場合は「何もしない」も含めること
差別化要因選定した2つの差別化要因一方だけではなく、両方の差別化要因を含めること

いずれかのスロットが曖昧な場合、このスキルは仮説を却下し、修正を求めます。

優れた創業仮説とは

品質意味
具体的実在する顧客と実在する課題を挙げます。「ユーザー」や「不満」ではありません
比較できる何もしないことも含め、顧客が現在何を選んでいるかを説明します
差別化されている単に勝つべきだと述べるのではなく、このソリューションが勝つべき理由を示します
検証可能スコアカードの質問や実験に落とし込めます
シンプル顧客が約束の内容をすぐに理解できます
有用なほど気まずい誰も異議を唱えず、気まずさも感じないなら、仮説が曖昧すぎる可能性があります

「気まずさ」という品質を徹底するのが最も困難です。チームは無意識のうちに、承認を得やすくするため仮説を和らげます。このスキルでは、議論の段階で「このチームのメンバーでなかったら、この場で誰が異議を唱えるでしょうか?」と尋ねて対処します。沈黙は、仮説が無難すぎるサインです。

仮定のスコアカード

仮説を5〜7個の仮定に分解します(推奨。承認済みの仕様決定では3〜10個を許容)。各仮定について、以下を記入します。

項目記入する内容
仮定仮説の特定のスロットから導き出した一文
重要な理由この仮定が誤っていた場合に何が無効になるか
現在の確信度高/中〜高/中/中〜低/低
次に行う最適なテスト確信度を変える具体的なテスト

最もリスクの高い仮定(現在の確信度が最も低く、誤っていた場合の影響範囲が最も大きいもの)を、次の検証ステップ(多くの場合、デザインスプリント)で最初にテストします。

進行手順(45分)

ステップ1:仮説を起草する(10〜15分)

Deciderが、前回のスプリントの成果をもとに5つのスロットを埋め、正式な一文を起草します。チームで確認し、曖昧な点を見つけ、各スロットが具体的になるまで修正します。これはスプリントで最も重要な15分です。

ステップ2:スコアカードを作成する(15〜20分)

仮説を5〜7個の仮定に分解します。それぞれを評価し、最もリスクの高い仮定を特定します。

ステップ3:信じる理由/誤りを証明し得ること(5〜10分)

それぞれ3〜5項目の箇条書きにします。チームは両方を並行して書きます。2つ目のリスト(誤りを証明するもの)は、チームが確信度を適切に見極めながら仮説を捉えているかを試すものです。

ステップ4:次に推奨するテスト(5分)

Deciderが次の検証ステップを明示します。デザインスプリント、顧客調査、実験などが該当します。推奨するテストでは、スコアカードで特定した最もリスクの高い仮定を検証します。

ステップ5:承認(1分)

Deciderが署名します。スプリントは終了です。

よくある落とし穴

  • 顧客や課題が曖昧。「読者」や「不満」はスロットになりません。このスキルではそれらを認めません。
  • 反証できない仮説。「私たちは成功する」は仮説ではありません。「XのYを支援すれば、Xは私たちを選ぶ」は仮説です。このスキルでは構造を徹底します。
  • **仮説を戦略文書として扱う。**仮説はテスト対象であり、戦略計画ではありません。チームの戦略上の決定はミニマニフェストと意思決定の原則に記載します。仮説はテストするものです。
  • **スコアカードを省略する。**仮説が価値の半分を占め、テスト計画(スコアカード+次に推奨するテスト)が残りの半分を占めます。スコアカードがなければ、仮説は壁の飾りにすぎません。
  • **承認を得るために和らげる。**チームは、議論を呼びにくくするため、反射的に仮説を和らげます。このスキルでは「誰か異議を唱える人はいるか」という確認で対処します。
  • **後で磨き上げる。**仮説は2日目の終わりまでに承認する必要があります。後で磨き上げると議論の蒸し返しになり、スプリントの規律が崩れます。

Deciderの役割

創業仮説の作成中にDeciderが行うこと:

  1. 正式な一文を起草します(またはPMと共同で起草します)。
  2. 修正作業を主導し、曖昧なスロットには異議を唱えます。
  3. チームとともにスコアカードの仮定を評価し、確信度の評価が分かれた場合は決定投票を行います。
  4. 次に推奨する検証ステップを明示します。
  5. 一部のスロットの表現が不完全でも、2日目の終わりまでに仮説を承認します。以降の磨き上げは、仮説ではなくスコアカードを編集して行います。

代表的な情報源

  • Knapp, J., and Zeratsky, J. Click. Founding Hypothesis のテンプレートと根拠。
  • Character Capital. "Foundation Sprint guide." Founding Hypothesis のセクション。
  • Knapp, J., and Zeratsky, J. "Introducing the Foundation Sprint." Lenny's Newsletter. 具体例を用いた Founding Hypothesis の構成。

スキル間での使用

前提条件:tool-foundation-sprint-magic-lenses。最有力の賭け、次点案、判断の根拠が、重要な入力です。

このスキルは、Basics に含まれる成果物(ターゲット顧客、重要な課題、競合)と、Differentiation に含まれる成果物(選定した差別化要因)を引き継ぎます。5つの仮説スロットはすべて、前回のスプリントの成果から導き出されます。

スプリント外で次に呼び出すもの:推奨される次の検証ステップです。次のテストが Design Sprint の場合は、通常 tool-design-sprint-readiness です。スプリント以外のテストが適切な次の手段であれば、pm-skills:measure-experiment-design または pm-skills:discover-interview-synthesis を使用することもあります。

Foundation Sprint と Design Sprint をつなぐ正式なブリッジスキルはありません。移行に関する説明は、_workflows/foundation-to-design.md と両方のユーザーガイドに記載されています。

決定者チェックポイント

このスキルは、references/TEMPLATE.md の決定者チェックポイントで終了します。決定者は、仮説文、スコアカード、推奨される次のテストを承認します。この承認をもって Foundation Sprint が完了します。承認がなければ、スプリントの成果は不完全であり、チームは当初の目的を達成できていません。

コメント