mcpField
T
tool-foundation-sprint-basics

tool-foundation-sprint-basics

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

tool-foundation-sprint-basics について

Foundation Sprint初日午前に、戦略フレームを定めるチーム向けのスキルです。対象顧客、重要課題、チームの優位性、代替手段を一体として整理し、Deciderの承認に向けて意思決定の経緯も記録します。

主な機能

  1. 01対象顧客と重要課題を明確化
  2. 02チーム固有の優位性を整理
  3. 03競合と代替手段をマッピング
  4. 04各判断の議論と投票を記録
  5. 05Decider承認用の統合フレームを作成

活用シーン

  1. 01Foundation Sprintで戦略の方向性を決定
  2. 02製品の対象者と主要な課題を明確化
  3. 03チームの優位性と既存の代替手段を比較
  4. 04後続の差別化検討に共通の土台を用意

インストール

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

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

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

同梱ファイル

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

HISTORY.md
references/
EXAMPLE.md
TEMPLATE.md

詳細

Foundation Sprint Basics

Foundation Sprint の 1 日目の午前です。チームは、4 つの基礎となる選択を明確にします。製品の対象者、解決する重要な問題、このチームが勝てる根拠、そして顧客が現在代わりに何をしているかです。成果物は、切り離せる 4 つの決定ではなく、ひとつの一貫した戦略的な枠組みです。

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

使用する場合

  • Foundation Sprint の 1 日目の午前で、ブリーフへの署名が完了している場合。
  • 準備状況の判定によると、チームが十分な顧客および市場の知識を持ち、情報に基づいた選択ができる場合。
  • 4 つのサブ決定すべてが未決、または意見が分かれており、チームがいずれについても事前に合意していない場合。
  • Decider がその場にいて、昼食前に一括成果物を承認する用意がある場合。

使用しない場合

  • チームに、対象顧客を選ぶ、または重要な問題を特定するための顧客知識が十分にない場合。まず顧客調査または問題のフレーミングを行い、準備状況の基準 3 を満たしてから再検討してください。
  • チームがすでに特定の顧客と問題の組み合わせにコミットしており、それを検証したいだけの場合。より軽量な検証ツールを使用してください。Basics は、形だけの追認ではなく、実質的な意思決定のためのものです。
  • 1 日目の午前が午後にずれ込んだ場合。差別化は Basics の完了を前提としています。昼食までに Basics で一貫した枠組みが作れなかった場合は、差別化を始めないでください。枠組みを作り直すか、延期してください。

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

以下の 5 つのセクションから成る、一括成果物を 1 つ作成します。

  1. 対象顧客の説明:属性(人口統計、行動、状況)を示す指標を含む、具体的に特定された顧客。
  2. 重要な問題の説明:代替手段からの乗り換えを促すほど強い、顧客が感じている痛み。
  3. チームの優位性一覧:このチームがその問題に対して信頼に足る存在となる能力、知見、人脈、データ、タイミング上の優位性。
  4. 競合および代替手段のマップ:直接の競合、代替ワークフロー、手作業による回避策、社内ツール、そして最も有力なベースラインである「何もしない」こと。
  5. Note-and-Vote の記録:検討した代替案や Decider の判断理由を含む、各サブ決定の決定方法の記録。

この成果物は、別々の 4 つの成果物ではなく、ひとつの一貫した成果として扱います。チームは、個々の要素を切り離してではなく、一括した枠組みを承認します。標準構成については references/TEMPLATE.md を、Brainshelf の例については references/EXAMPLE.md を参照してください。

4 つのサブ決定

各サブ決定では tool-note-and-vote(サイレント・アイデア出し+投票+Decider によるスーパーボートのプロトコル)を使用します。このスキルは一連の進め方を構成しますが、意思決定プロトコル自体は単独の note-and-vote ツールです。

1. 対象顧客(25〜35 分)

チームは、サイレント・アイデア出しで顧客候補の説明を 3〜7 件作成し、投票した後、Decider がスーパーボートで 1 件を選びます。選ばれる顧客は具体的でなければなりません(「SaaS の PM」ではなく、「エンジニアが 20〜100 人いる Series-B の SaaS 企業の PM」)。このスキルは曖昧なセグメントを退け、チームが誰なのかを認識できるほど明確になるまで、指標を追加するよう促します。

2. 重要な問題(20〜30 分)

チームは、選ばれた顧客が経験する痛みの候補を 3〜7 件挙げます。投票した後、Decider がスーパーボートで 1 件を選びます。選ばれる問題は、現在の行動(何もしないことを含む)からの乗り換えを促すほど深刻でなければなりません。軽度の不満は重要な問題ではありません。このスキルでは、「顧客は現在何をしていて、なぜそれをやめて私たちのソリューションを選ぶのでしょうか」と明示的に尋ねることで、この基準を徹底します。

3. チームの優位性の洗い出し(20~30分)

チームは、能力、洞察、人脈、データ、技術、流通、タイミングなど、具体的な強みを列挙します。投票(複数投票)で上位2~3項目を浮かび上がらせ、デサイダーが確認します。このスキルは、「素晴らしいチーム」「情熱がある」といった一般的な優位性を退け、「Samは以前、Y社でXを構築した」「Rileyはターゲットセグメントに1万2,000人のネットワークを持っている」といった具体的な証拠を求めます。

4. 競合と代替手段のマップ作成(20~30分)

チームは、直接競合、代替ワークフロー、手作業による回避策、社内ツール、「何もしない」など、代替手段の全体像をマッピングします。それぞれについて、顧客が何に使っているのか、なぜ利用をやめるのか(あるいは使い続けるのか)を記録します。このスキルでは、「何もしない」ことも競合に含めるよう徹底します。現状維持が最も強力な代替手段であることを、多くのチームが見落とすためです。

推論の入力情報

入力スキルが入力情報をどう活用するか
スプリントブリーフDecision Targetを読み取り、対象となる顧客と課題の範囲を定めます。範囲外の候補は投票前に指摘されます
顧客・市場コンテキストパケットこれまでに挙がった候補を無言のアイデア出しボードに事前入力し、チームが同じ候補を一から考え直さずに済むようにします
競合に関する知識すでに把握している競合を代替手段のマップに事前入力します。チームは何もないところから始めるのではなく、候補を追加して議論します
チームの優位性に関するメモチームがすでに行った自己評価を提示します。投票によって内容を整理し、優先順位を付けます

よくある落とし穴

  • 顧客像が曖昧。 「SaaSのPM」や「読者」はターゲット顧客ではありません。特定の人物像を挙げられるまで、このスキルは目印となる特徴を尋ねます。
  • ちょっとした不便を深刻な課題と取り違える。 顧客が何もしない状態や有料の代替手段から乗り換えないのであれば、その課題は十分に深刻ではありません。このスキルはこれを明示的に検証します。
  • チームの優位性が一般論にとどまる。 「優秀なエンジニア」は優位性ではありません。「SamはPocketの最初の同期エンジンを構築し、オフラインファーストのパターンを熟知している」なら優位性です。このスキルは具体性のない優位性を退け、証拠を求めます。
  • 「何もしない」ことを競合として無視する。 最もよくある見落としです。競合とは名前のある製品だと考えて、多くのチームがこれを省きます。このスキルは必ず含めるよう求めます。
  • 4つの小さな意思決定を切り離して考える。 重要な課題がチームの優位性によって解決できないターゲット顧客は、選ばれません。このスキルが承認するのは、各要素ではなく、ひとまとまりの成果物です。各要素に一貫性がなければ、チームは再検討します。
  • 記録と投票の履歴を省く。 意思決定の節目は、後続の議論を支える重要な基盤です。記録がなければ、1日目午後の差別化は不確かな土台から始まり、別の呼び名で基礎の議論を蒸し返すことになりかねません。

デサイダーの役割

基礎の議論におけるデサイダーの役割は、次のとおりです。

  1. 4つの小さな意思決定それぞれの枠組みを示す(またはファシリテーターの枠組みを承認する)。
  2. 無言のアイデア出しや投票の議論では、独占せずに話を聞く。
  3. デサイダーの最終投票がチームの最多得票と異なる場合は、明確な理由を添えて各項目に投票する。
  4. 差別化を始める前に、ひとまとまりの成果物が一貫した戦略的な枠組みになっていることを承認する。

異議を唱えず何でも承認するデサイダーは価値を加えていません。理由なく覆すデサイダーは信頼を築けません。

主要な出典

  • Character Capital。「Foundation Sprint guide」。基礎のアジェンダと意思決定の順序。
  • Knapp, J., and Zeratsky, J. Click。1日目午前の進行順序。
  • Knapp, J., and Zeratsky, J.「Introducing the Foundation Sprint」。Lenny's Newsletter。ターゲット顧客と重要な課題の枠組み。

スキル間の利用

前提条件:tool-foundation-sprint-brief。Brief の Decision Target によって、このスキルで対象とする顧客課題の領域が指定されます。

このスキルでは、tool-note-and-vote を4回(各サブ決定につき1回)呼び出します。各呼び出しで個別の決定記録が作成され、4つのトレースがまとめられて、バンドル成果物になります。

スプリントで次に呼び出すスキル:Day 1 の午後、昼食の直後に tool-foundation-sprint-differentiation を呼び出します。

決定者チェックポイント

このスキルは、references/TEMPLATE.md にある決定者チェックポイントで終了します。決定者は、各コンポーネントを個別に承認するのではなく、一貫した戦略的枠組みとしてバンドル成果物を承認します。承認がない場合、入力内容について協議が続いているため、Differentiation を円滑に開始できません。

コメント