startup-positioning について
startup-positioningは、スタートアップの創業者やチーム向けに市場ポジショニングを検討するスキルです。April DunfordのフレームワークにJTBD調査とNeumeierのOnliness Testを組み合わせ、ポジショニング文書や関連分析を作成します。
主な機能
- 01ガイド付き情報収集と既存資料の確認
- 022段階の競合・市場調査
- 03Dunfordの5+1要素による統合
- 04NeumeierのOnlinessとメンタルラダーテスト
- 05ポジショニング文書と分析成果物
活用シーン
- 01直接・隣接・現状維持の代替案を整理
- 02顧客の課題と言葉を特定
- 03市場カテゴリーの候補を比較
- 04スタートアップのポジショニングを見直す
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ ferdinandobons/ startup-skill --skill startup-positioningインストール後、Claude Code で/startup-positioningを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
references/frameworks.mdhonesty-protocol.mdresearch-principles.mdresearch-scaling.mdresearch-synthesis.mdresearch-wave-1-alternatives.mdresearch-wave-2-market-frame.mdverification-agent.md詳細
スタートアップのポジショニング
完全なポジショニング文書、Moore + Neumeier によるポジショニングステートメント、競合代替案マップ、市場カテゴリー分析を作成する市場ポジショニング戦略です。April Dunford のフレームワークを基盤とし、JTBD ディスカバリーを加え、Neumeier の Onliness Test で検証します。
仕組み
INTAKE → RESEARCH (2 sequential waves) → POSITIONING SYNTHESIS
プロセス:製品と顧客を理解し、競合代替案と市場の状況を調査したうえで、Dunford の 5+1 コンポーネントを使ってポジショニングを構築します。一般的な所要時間は、Claude Code(並列エージェント)で 10~15 分、Claude.ai(順次実行)で 20~30 分です。
言語
デフォルトの出力言語は英語です。ユーザーが別の言語で記述するか、明示的に別の言語を指定した場合は、すべての出力にその言語を使用します。
フェーズ 0:再開の確認
まず、このスキルで作成された PROGRESS.md が作業ディレクトリまたはプロジェクトのサブディレクトリにあるか確認します(スキル名のフィールドは startup-positioning です)。存在する場合は読み込み、最後に完了していないフェーズから再開します。ユーザーに「前回のセッションの進捗が見つかりました。[フェーズ] を完了しています。[次のフェーズ] から再開します。」と伝えます。
進捗ファイルがない場合、または見つかったファイルが別のスキルのものの場合は、フェーズ 1 から開始します。
フェーズ 1:情報収集
質問は短く、焦点を絞ります。質問は 1~2 回にとどめます。競合代替案を調査し、ポジショニングを構築するのに十分な情報を得ることが目的です。
以前の作業を確認する
質問する前に、過去のセッションが完了しているか確認します。作業ディレクトリまたはサブディレクトリで、次のファイルを探します。
startup-design から:
00-intake/brief.md— 製品の説明と背景01-discovery/competitor-landscape.md— 競合プロファイル01-discovery/target-audience.md— 顧客ペルソナ、課題02-strategy/positioning.md— 初期のポジショニング作業
startup-competitors から:
intake.md— 製品と市場の背景competitors-report.md— 戦略的な競合分析battle-cards/— 競合ごとのプロファイルpricing-landscape.md— 価格分析
これらのファイルがあれば読み込み、データを出発点として活用します。
- 製品の説明、既知の競合、顧客の課題を抽出します
- 競合プロファイルとバトルカードを使って、競合代替案マップの土台を作ります
- 既存のポジショニング作業は、維持する結論ではなく検証する仮説として出発点にします
- 顧客の言葉や課題を、JTBD ディスカバリーに活用します
ユーザーに「前回のセッションのデータが見つかりました。ポジショニング分析の出発点として活用します。」と伝えます。
以前のデータが十分であれば、重複する情報収集の質問は省略します。すぐに調査を開始します。
質問する内容(以前のデータがない場合)
1 回目 — 基本情報:
- 製品は何ですか?(一文でかまいません)
- どのような問題を、誰のために解決しますか?
- 顧客は現在、あなたの製品を使わずに何をしていますか?(代替手段、回避策、何もしないこと)
- 既存顧客の中で最も適した顧客はどのような人ですか?(該当する場合 — 属性ではなく、その人たちについて説明してください)
2 回目 — 詳細確認(必要な場合のみ):
- 製品は、挙げていただいた代替手段とどのように異なりますか?
- これまでにポジショニングを試したことはありますか?うまくいかなかった点は何ですか?
- よく比較される競合はありますか?
質問しすぎないようにします。ユーザーが最初から明確に説明している場合は、調査に進みます。ポジショニングのプロセスを通じて、重要な点が明らかになります。
出力
製品、問題、代替手段、顧客の概要を {project-name}/intake.md に保存します。以前のセッションのデータを基にした場合は、使用したソースファイルを記載します。プロジェクト名は kebab-case にします(例:ai-email-assistant)。
次の情報を含む {project-name}/PROGRESS.md を作成します:プロジェクト名、スキル名(startup-positioning)、開始日、言語、調査モード(Live / Knowledge-Based)、フェーズのチェックリスト。各フェーズの完了後に更新します。以前のセッションの PROGRESS.md がすでに存在する場合は、最後に完了していないフェーズから再開します。
フェーズ 1.5:調査の深度評価
インテークの後、市場の複雑さを評価し、調査の深度に関する推奨案をユーザーに提示します。
参考: 複雑さの採点マトリックス、ティアの定義、ウェーブの構成、ユーザーへの伝達テンプレートについては、
references/research-scaling.mdを読んでください。
プロセス
- インテークから3つの要素を採点します:市場の広がり(1~3)、既知の競合他社(1~3)、対象地域の範囲(1~3)
- スコアを合計し(範囲:3~9)、ティアに割り当てます:ライト(3~4)、標準(5~7)、ディープ(8~9)
- 調査の深度を示す表をユーザーに提示します(正確なテンプレートについては
research-scaling.mdを参照) - ユーザーの回答を待ちます:推奨案を受け入れる場合は light、deep、または ok
- 選択されたティアを PROGRESS.md に記録します
選択されたティアによって、フェーズ 2 の各ウェーブのエージェント数と、エージェントごとの検索ラウンド数が決まります。ティアごとの正確なウェーブ構成については、research-scaling.md を参照してください。
フェーズ 2:調査
競合する代替手段と市場の背景を探る、2つの連続した調査ウェーブです。各ウェーブ内のエージェントは並行して実行され、ウェーブ 2 はウェーブ 1 の調査結果を踏まえて進めます。両ウェーブを通じて、Dunford の 5+1 のポジショニング要素を組み立てるための基礎資料を収集します。
環境の検出
Agent ツールが利用可能か確認します:
- Agent ツールが利用可能(Claude Code): 各ウェーブ内のエージェントをすべて並行して起動します。こちらのほうが高速です。
- Agent ツールが利用不可(Claude.ai、ウェブ): 同じテンプレートに従って、調査を順次実行します。深度は同じですが、時間がかかります。
ウェブ検索
このスキルでは、実際のデータを得るために WebSearch が必要です。WebSearch が利用できない、または拒否された場合は、知識ベースモードに切り替えます。トレーニングデータを使用し、すべての調査結果に [Knowledge-Based — verify independently] を付け、信頼度の評価を1段階下げます。モードを PROGRESS.md に記録してください。
参考: いずれかのウェーブを開始する前に、
references/research-principles.mdを読んでください。情報源の品質ティア、相互照合のルール、データの不足への対処方法が定められています。
ウェーブ 1:競合する代替手段と顧客の状況
参考: エージェントのテンプレートについては、
references/research-wave-1-alternatives.mdを読んでください。
2つのエージェント(または2つの順次実行ブロック):
A1:代替手段のマッピング(JTBD の視点) — 直接の競合他社だけでなく、競合する代替手段をすべてマッピングします。以下を含めます:直接の競合他社、同じ予算を取り合う隣接分野のツール、手作業のプロセス、スプレッドシート、誰かを雇うこと、何もしないこと/現状維持。それぞれについて、顧客がどの仕事を任せるためにそれを選ぶのか、どこに不足があるのか、何が乗り換えのきっかけになるのかを調べます。目標は、製品が置き換えるものをすべて洗い出すことです。
A2:顧客インテリジェンス — レビュー、フォーラム、コミュニティから顧客の声のデータを収集します。現在の代替手段に関する課題、顧客が実際に使う言葉、「より良い」とは顧客にとって何を意味するか、最適な顧客プロファイル(最も早く最大の価値を得る顧客)、乗り換えのきっかけ(誰かがついに変更を決断する要因)を抽出します。顧客が問題や望ましい結果を説明する際に使う言葉をまとめた言葉のマップを作成します。
ウェーブ 2:市場の枠組みとトレンド
参考: エージェントのテンプレートについては、
references/research-wave-2-market-frame.mdを読んでください。
2つのエージェント(または2つの順次実行ブロック):
B1:市場カテゴリー分析 — 候補となる市場カテゴリーを3~5個特定します。それぞれについて、購入者がそのカテゴリーに期待するもの、リーダー企業、競争の動向、市場の成熟度を調べます。Dunford のカテゴリータイプを適用します:正面からの競争(既存カテゴリー)、大きな魚が小さな池にいる状態(サブカテゴリー)、カテゴリーの創出。どの枠組みなら独自の強みを最も際立たせられるかを評価します。
B2:トレンドとタイミングの分析 — 技術の変化、行動の変化、規制の動向など、関連するトレンドを特定します。それぞれについて、実態があるのか単なる誇大宣伝なのか、購入者の期待にどう影響するのか、ポジショニングを強めるのか弱めるのかを調べます。タイミングを評価します。トレンドに対して早すぎるのか、適切なタイミングなのか、遅すぎるのかを判断します。購入者がソリューションを評価する方法に本当に影響するトレンドのみを含めてください。
調査後のチェックポイント
両方の調査ウェーブが完了したら、統合の前に、調査で判明したことを簡潔にユーザーに提示します。競合する代替手段の全体像(直接的、隣接的、現状維持のそれぞれがいくつあるか)、顧客が最も強く感じている課題、最も有望なカテゴリー候補を伝えます。次のように尋ねます。「これはご期待に沿っていますか?ポジショニングを統合する前に調整したい点はありますか?」
メッセージは1つにまとめます。これは簡単な認識合わせであり、詳細なレポートではありません。
フェーズ 3:ポジショニングの統合
参考資料: 統合の手順とダンフォードのプロセスの詳細については、
references/research-synthesis.mdをお読みください。
チェックポイントの後、ダンフォードの5+1要素に沿って、順番にポジショニングを構築します。この順序が重要です。各ステップは前のステップを土台にします。
ポジショニングは、空欄を埋める作業ではなく、推論の問題です。「唯一」という言葉がオンリネステストで成り立つには、それが真実でなければなりません。そして、それが真実であり、かつ価値あるものとなる切り口を見つけるには、深く考える必要があります。適切な買い手にとって、製品の強みが最も重要になる角度を探すのです。切り口を決める前に、候補となる各カテゴリーによって製品の比較対象がどう変わるのか、差別化がなお成り立つのかを十分に検討してください。モデルが拡張思考に対応している場合は、ここにその能力を使ってください。無理に作った、または一般的すぎるポジショニングは、ポジショニングがないよりも悪い結果を招きます。
5+1要素
-
競合する代替手段 — ウェーブ1の情報に基づきます。製品がなかったら、顧客は何を使うでしょうか?これは基準となる要素です。ポジショニングは常に相対的なものだからです。
-
独自の属性 — 代替手段にはなく、自社が持っているものは何でしょうか?具体的かつ誠実に挙げてください。機能、アーキテクチャ、チームの専門知識、ビジネスモデル、スピードなど、擁護できるものであれば何でも該当します。
⏸ 一時停止 — ユーザーの入力が必要です。 調査から導き出した属性をユーザーに提示します。バリューテーマに進む前に、確認、追加、削除を依頼してください。調査では明らかにならない能力を、創業者は把握しています。
-
バリューテーマ — 独自の属性を顧客が得る成果に置き換えます。属性から「それで何が変わるのか?」を考え、価値へとつなげます。関連する属性を2~3個のバリューテーマにまとめます。ウェーブ1の言葉遣いマップにある顧客の言葉を使ってください。
-
最適な顧客 — ウェーブ1の顧客情報に基づきます。バリューテーマを最も重視するのは誰でしょうか?デモグラフィックではなく、重視する理由となる特性に基づいて定義してください。こうした顧客は、アプローチ可能で、見分けがつき、支払う意欲があるべきです。
-
市場カテゴリー — ウェーブ2の情報に基づきます。価値が明確に伝わるカテゴリーの枠組みを選びます。トレードオフを添えて3~5個の選択肢を提示し、1つを推奨します。適切なカテゴリーは、適切な買い手の期待を喚起します。
-
トレンドの重ね合わせ(任意) — ウェーブ2の情報に基づきます。実際のトレンドによってポジショニングが強化される場合に限り、含めます。無理にトレンドと結び付けるのは、何も含めないよりも悪い結果を招きます。
検証
最終決定の前に、次の2つのストレステストを行います。
ノイマイヤーのオンリネステスト:
基本形:
「私たちの[製品]は、[差別化要因]を備えた唯一の[カテゴリー]です。」
拡張形(6要素 — WHAT/HOW/WHO/WHERE/WHY/WHEN):
「私たちの[製品]は、[状況]において[ニーズ]を抱える[対象]に向けた、[差別化要因]を備えた唯一の[カテゴリー]です。」
基本形を説得力をもって完成できない場合、「唯一」という主張に無理があると感じられる場合、ポジショニングが弱すぎます。繰り返し検討してください。
ライズ/トラウトのメンタルラダー:
- 覚えやすいほどシンプルですか?
- 明確な1つの段を主張していますか?
- その段は空いていますか(競合が占有していませんか)?
- 1文で説明できますか?
いずれかのテストに合格しない場合は、5+1要素を見直してください。弱いポジショニングのまま公開しないでください。
出力ファイル
すべての成果物ファイルは、標準ヘッダー # {Title}: {product} の後に *Skill: startup-positioning | Generated: {date}* を記載して開始する必要があります。すべての成果物は、Red Flags、Yellow Flags、Sources のセクションで終える必要があります(references/research-synthesis.md のテンプレートを参照)。
{project-name}/positioning-doc.md — 主な成果物:
- エグゼクティブサマリー(3文でポジショニングを説明)
- 根拠を添えた5+1の構成要素
- 構成要素ごとの強度評価(Strong / Moderate / Needs Work)
- 戦略的な提案と次のステップ
- データの不足と制約
{project-name}/positioning-statement.md — ステートメントとメッセージ:
- Mooreテンプレート:「[target] のうち [need] を抱える人にとって、[product] は [benefit] を実現する [category] です。[alternative] とは異なり、私たちは [differentiator] を提供します。」
- NeumeierのOnliness Statement(基本版+拡張版)
- エレベーターピッチ(30秒版)
- 「誤解される可能性」の列を含む、ストレステスト済みのタグライン候補
- チャネル別の一文紹介(GitHub、マーケットプレイス、ソーシャル、エレベーター)
- フリーミアムのポジショニング(該当する場合)
{project-name}/competitive-alternatives.md — 代替手段の全体像:
- すべての代替手段(直接的、隣接、手作業、現状維持)
- 代替手段ごとに、依頼される仕事、強み、弱み、乗り換えのきっかけを記載
- 各代替手段と比較した独自の属性
{project-name}/market-category-analysis.md — カテゴリー戦略:
- 購入者の期待を含む、3~5件のカテゴリー候補
- カテゴリータイプの評価(正面からの競争/サブカテゴリー/カテゴリーの創出)
- 理由を添えた推奨
- 実装(カテゴリー名、タグラインの方向性、購入者の期待との整合性)
- Red FlagsとYellow Flags
{project-name}/messaging-implications.md — ポジショニングからコピーへの橋渡し:
- メッセージの優先順位(最初、2番目、3番目に伝える内容)
- カテゴリー名(あらゆる場所で使う正確な表現)
- 価値の基準(カテゴリーとは別に、何と比較して価値を示すか)
- 顧客の言葉とカテゴリーの言葉の対応表(顧客が使う動詞とカテゴリーを表す名詞)
- 使用する言葉/避ける言葉
- ソーシャルプルーフのガイドライン
- フリーミアムのポジショニング(該当する場合)
生データ
各エージェントは、生の出力を {project-name}/raw/ に保存します。統合フェーズではこれらの生ファイルを読み込み、上記の洗練された成果物を作成します。エージェントは成果物のパスに直接書き込んではいけません。生の出力と統合後の出力は分けて管理します。
調査の生ファイル:
alternative-mapping.mdcustomer-intelligence.mdmarket-categories.mdtrends-timing.md
フェーズ3.5:調査の検証
すべてのポジショニング成果物を作成した後、検証を実施します。
参照:
references/verification-agent.mdを読み、検証プロトコル、共通チェック、スキル固有のチェックを確認してください。
手順
- エージェント V1:検証 を起動します。V1はすべての成果物ファイルを読み込み、ラベルのない主張、内部矛盾、確信度評価の一貫性、データの不足、フラグの不足、古いデータ、同一ソースに基づく誤った裏付けがないかを確認します
- V1はスタートアップ・ポジショニング固有のチェックも実施します。ポジショニングステートメントと調査データの整合性、JTBDと顧客インテリジェンスの整合性、成果物間の一貫性、検証テストの妥当性を確認します
- V1は
{project-name}/verification-report.mdを作成します - 重大な問題が見つかった場合: 作業を一時停止し、問題をユーザーに提示します。先に修正するか、そのまま進めるかを尋ねます
- 警告/情報のみの場合: 1行で要約して表示します
Claude.aiを使用する場合、またはAgentツールが利用できない場合は、同じプロトコルに従って、メインの会話内で自分で検証チェックを実施してください。
誠実性プロトコル
参照: プロトコル全体とアンチパターンの詳細については、
references/honesty-protocol.mdをお読みください。
ポジショニングは、誠実であってこそ有用です。基本ルール(主張にラベルを付ける、定量化する、ギャップを明示する)に加え、ポジショニング固有の追加事項があります。
- 願望に基づくポジショニングはしない。 目指す姿ではなく、現状の姿に基づいてポジショニングします。願望に基づくポジショニングは、最初の顧客との接点で崩れます。
- 「私たちは唯一無二だ」という主張を疑う。 オンリネステストは、真に説得力があるものでなければなりません。マーケティングの空疎な宣伝文句に見えるなら、練り直してください。
- ナラティブより調査を優先する。 顧客データがポジショニングに関する社内の考えと矛盾する場合は、データを優先します。
- カテゴリー創出のリスクを明示する。 ほとんどのスタートアップには、市場を啓蒙する余裕がありません。圧倒的な証拠がない限り、既存のカテゴリーを選びます。
| アンチパターン | その特徴 | 伝えること |
|---|---|---|
| 「誰もが対象です」 | ターゲットセグメントが定義されていない | 「誰もが対象なら、誰も対象ではありません。最も関心を持つのは誰ですか?」 |
| 機能ベースのポジショニング | 成果ではなく機能を前面に出す | 「顧客は機能を買うのではありません。どのような成果を得られますか?」 |
| 願望に基づくポジショニング | 「AI 搭載の〜になります」 | 「ロードマップではなく、今日提供しているものに基づいてポジショニングしてください。」 |
| 唯一無二のカテゴリー | 比較を避けるためにカテゴリーを作り出す | 「新しいカテゴリーには数百万の費用がかかります。既存の枠組みはありませんか?」 |
| 模倣的なポジショニング | 市場リーダーと同じメッセージ | 「本当に異なる立ち位置を見つけてください。リーダーを上回るポジショニングはできません。」 |
アンチパターン全体の表(7 項目)とプロトコルの詳細については、references/honesty-protocol.md を参照してください。
参照ファイル
現在のフェーズに必要なものだけをお読みください。
| ファイル | 読むタイミング | 約行数 | 目的 |
|---|---|---|---|
honesty-protocol.md | セッション開始時 | 約73 | アンチパターンを含む、誠実性プロトコル全体 |
research-principles.md | フェーズ 2 の開始前 | 約65 | 情報源の質、相互参照、データの不足 |
research-wave-1-alternatives.md | Wave 1 の実施時 | 約235 | 代替案と顧客情報のためのエージェントテンプレート |
research-wave-2-market-frame.md | Wave 2 の実施時 | 約210 | カテゴリーとトレンドのためのエージェントテンプレート |
research-synthesis.md | 両方の Wave の完了後 | 約419 | 統合プロトコル、Dunford のプロセス、検証テスト、メッセージングへの示唆 |
frameworks.md | フェーズ 3 の実施中 | 約132 | Dunford/Moore/Neumeier/JTBD/Ries の参考資料 |
research-scaling.md | インテーク後、フェーズ 2 の前 | 約96 | 複雑さのスコアリング、ティアの定義、Wave の構成 |
verification-agent.md | 統合後 | 約128 | 検証プロトコル、共通チェックとスキル固有のチェック |