solo-product-planning

name	solo-product-planning
description	個人開発の企画を「概要→体験→検証→画面→類似」の順で1枚に整理し、勢い実装で迷子になるのを防ぐ。JTBD/Time to Wow、最大リスク仮説、最小実験、成功指標まで落とし込む。個人開発、企画、要件定義、ユーザーフロー、MVP、検証、プロトタイプ、競合調査の依頼で使う。
license	Proprietary
compatibility	Works in agents that support the Agent Skills SKILL.md format (e.g., Codex CLI/IDE, Claude Code, Cursor).
version	1.0
author	3396
short-description	個人開発の企画を1枚に畳む（検証込み）

個人開発 企画1枚化スキル（概要→体験→検証→画面→類似）

目的

個人開発で起きがちな「勢い実装 → 迷子 → 放置」を減らすために、企画を"順番"で固める。 特に「WOW（最初の価値到達）までの距離」を短くし、ムダ実装を減らす。

このスキルを使うタイミング（トリガー）

• 新規アイデアを企画に落としたい / 1枚に整理したい
• MVPやプロトタイプの作り方、最初の検証を決めたい
• ユーザーフローを先に固めたい
• 競合調査に飲まれそう、または何を見ればいいか分からない

出力の約束（必ずこの順で出す）

1. 概要（課題 / 誰 / なぜ今 / なぜ解決できる）
2. 体験（LP〜コア到達までの動線、Time to Wow短縮）
3. 検証（最大リスク仮説Top3とそれぞれの最小実験）
4. 画面（画面名の列挙）
5. 類似（差分と学び）
6. 最初の成功指標（1〜2個）
7. 次の24時間のTODO（実験優先）

進め方（手順）

0) 最低限の前提を揃える（不足しても仮置きで進める）

• 想定ユーザー（誰が、どんな状況で）
• 変化させたい課題（何が困っている）
• 価値（何がどう良くなる）
• 制約（期間、使える技術、集客導線の有無） 不足があれば「仮説として」置いて先へ進む。ここで詰めすぎない。

1) 概要を書く（JTBD寄り）

以下を短文で埋める（長文禁止）。

• ターゲット: （例: 週1で採用媒体を運用する小規模企業の人事）
• 課題: （例: 投稿のネタ管理と予約がバラバラで続かない）
• 望む変化: （例: 10分で1週間分の投稿予約が終わる）
• なぜ今: （例: 生成AIで下書きが量産でき、運用のボトルネックが「整理と予約」に寄った）
• なぜ解決できる: （例: テンプレ化された流れ＋最短導線＋最小の摩擦）

2) 体験（ユーザーフロー）を書く

"LP〜コア価値到達"を最短にする。分岐は最小。

• スタート: どこから来る（X/検索/友人/既存ツール移行）
• 3ステップ以内: 価値到達までの操作を列挙
• WOW定義: ユーザーが「なるほど」と思う瞬間を1つに固定
• Time to Wow: 何分/何操作で到達させるか（目標値も書く）

出力例（型）:

• Step0: LPで価値を1行で理解
• Step1: サンプル/テンプレを選ぶ（入力は最小）
• Step2: 1回目の成果物が完成（ここがWOW）
• Step3: 継続導線（任意、後回しでも可）

3) 検証を差し込む（最大リスク仮説Top3）

企画が当たるかは、最初の仮説3つでほぼ決まる。 カテゴリ例:

• 需要: そもそも欲しい人がいるか
• 継続: 1回使って終わらないか
• 課金: お金を払う強い動機があるか
• 供給制約/実現性: こちら側の運用が詰まらないか

書き方:

• 仮説: 「もしXなら、Yが起きる」
• 失敗条件: これが起きたら撤退/ピボット
• 代替案: 失敗したら次に試す方向

4) 最小実験を設計する（1日で潰す）

MVPは"最小のプロダクト"ではなく"最小の学習装置"として扱う。 各仮説に対して、最小の実験を1つずつ用意する。

実験の引き出し:

• ダミーLP（待機リスト、価格提示、用途別コピーAB）
• 手動運用（裏側は人力で提供して成立するか見る）
• 画面モック/紙芝居プロトタイプ（タスク完了テスト）
• 5人テスト（迷いポイントと言語化を拾う）

テンプレ:

• 実験名:
• 仮説:
• 手順（30分単位で）:
• 成功指標（定量）:
• 学びの判定（Go / Pivot / Kill）:

5) 画面（列挙でOK）

体験を支える最小画面だけ。

• LP
• サインアップ/ログイン（必要なら）
• コア作成画面（WOW到達）
• 結果画面（共有/保存/予約など）
• 設定（後回し可）

6) 類似プロダクト（最後に、短時間で）

時間を箱に入れる（例: 30〜60分）。 見る観点は3つだけ:

• 価値到達までの導線（最初の1分で何をさせてるか）
• 価格と課金タイミング（どこで課金を要求するか）
• 差別化の核（何を捨て、何に賭けてるか）

出力:

• 類似A: 学び / 真似しないこと / 取り入れること
• 類似B: 同上
• 結論: 自分の一番の賭け（1行）

仕上げ：最初の成功指標（1〜2個だけ）

候補:

• Time to Wow（分/操作数）
• 初回完了率（例: 初回作成完了、予約完了）
• D1/D7継続
• 課金転換（トライアル→有料） 最初は"改善可能で、近い"指標を選ぶ。

生成する最終成果物（1枚）

以下のセクション順でMarkdownを出力すること:

• 概要
• 体験（ユーザーフロー + WOW定義 + Time to Wow目標）
• 最大リスク仮説Top3
• 最小実験（仮説ごと）
• 画面一覧
• 類似調査（学びと差分）
• 最初の成功指標（1〜2個）
• 次の24時間のTODO（実験優先）

注意（やりがちな事故防止）

• 機能を盛らない。体験と検証が固まるまで機能追加を禁止。
• 競合調査は最後。最初は"内なる仮説の言語化"を優先。
• 技術選定やDB設計に逃げない（不確実性の本丸は需要側に多い）。
• 分からない所は「仮説」と明記し、実験に変換する。

例（超短縮）

• 概要: 「投稿予約が続かない」→「10分で1週間分を予約」
• 体験: テンプレ選ぶ→AI下書き→予約完了（WOW）
• 仮説: 需要/継続/課金
• 実験: ダミーLPで待機率、5人テストで完了率、価格提示で反応
• 画面: LP/作成/結果/予約/履歴
• 類似: 後で30分だけ見て差分を1行にする