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