value-proposition-checklisted

## Purpose 「作り手が良いと思う価値」と「顧客が金を払う価値」のズレを早期に発見する。 顧客課題・代替手段・差別化を突き合わせ、価値仮説の弱点を可視化する。 ## Use When - プロダクト・機能の価値仮説を立てるとき - 「刺さる訴求が定まらない」とき - LP・営業資料の前提となる価値を固めるとき - scope-design の後に、集中領域の価値を検証したいとき ## Inputs 以下を準備すること。不足している場合は推測せず、不足を明示する。 - **提供価値の仮説**: 誰に・どんな価値を届けるか - **顧客課題**: 解決する課題（できれば顧客の言葉で） - **代替手段**: 顧客が今使っている代替（競合・手作業・我慢） - **差別化仮説**: なぜ自分が選ばれるか ## Output Contract 以下の順で出力すること。順序を変えない。 1. **論点**: 価値仮説の最も弱い前提はどこか 2. **根拠**: その論点をそう判断した理由 3. **価値マップ**: 顧客課題 × 提供価値 × 代替手段の対応 4. **含意**: 価値が刺さらない場合に起きること 5. **改善案**: 価値を尖らせる・伝わる形にする修正 6. **代替案**: 別の顧客課題・別の価値の切り口 7. **判断材料**: 価値仮説の検証に必要な人間の確認事項 ## Review Lens - **目的妥当性**: 解く課題が顧客にとって本当に痛いか - **範囲の過不足**: 価値を広げすぎて曖昧になっていないか - **中長期リスク**: 模倣されやすい価値に依存していないか - **LAB全体との整合性**: LMS / 自動化 / B2B 展開と整合しているか - **非エンジニア理解可能性**: 価値を顧客の言葉で説明できるか - **他LLM移植耐性**: 判断が Claude 固有の解釈に依存していないか ## Instructions 1. 顧客課題を「痛みの強さ・頻度」で評価する 2. 各課題に対する現在の代替手段を書き出す 3. 提供価値が代替手段より明確に優れる点を特定する 4. 「あったら嬉しい��と「無いと困る」を区別する 5. 価値が刺さる前提（顧客像・状況）を明示する 6. 未検証の前提は推測せず、検証方法を提案する ## Guardrails - 作り手目線の「良い機能」を価値と混同しない - 顧客課題を推測で断定しない（検証を促す） - 「全員に価値がある」と広げない - 価値の確定・検証は人間に委ねる ## LAB Cross-Check | 観点 | 状態 | 備考 | |---|---|---| | 自動化フロー | — | 価値提供に必要な自動化を確認したか | | データ / 認証 / ログ | — | 価値検証に必要なデータを確認したか | | 実装 / 運用フロー | — | 価値を実装・運用で再現できるか | | 非エンジニア理解可能性 | — | 価値を顧客の言葉で説明できるか | | 会員共有 / 再利用耐性 | — | 価値仮説が他セグメントに転用できるか | | 他LLM移植耐性 | — | 判断が Claude 固有に依存していないか | 状態は OK / 注意 / NG / 対象外 で記入すること。 ## Handoff Notes 施工AI（Claude Code / Cursor 等）へ渡す前に以下を確定させること。