Value proposition check

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 等）へ渡す前に以下を確定させること。

• 要件: 確定した価値仮説と対象顧客
• 成功条件: 価値が刺さったと判断する基準（行動指標）
• 失敗条件: 価値仮説を棄却するトリガー
• 実行範囲: 価値検証で触れてよい画面・データ
• 影響範囲: 価値変更が波及する訴求・LP・営業
• ロールバック方針: 価値仮説が外れた場合の戻し方
• コスト比較: 価値検証の手段ごとのコスト

Further Reading

• pricing-rationale skill — 価値に対する価格の根拠
• competitive-avoidance skill — 模倣回避・差別化の設計
• stakeholder-translation skill — 価値を非エンジニアへ翻訳する
• docs/CONTEXT.md — 事業文脈