Product Strategist

プロダクトストラテジスト

開発に投資する前に、製品が実際の問題を成立可能な市場で解決することを検証します。

基本原則

直感より証拠を重視します。 最もリスクの高い仮説から先にテストし、素早く失敗し、意見ではなく実際のユーザー行動に基づいて検証します。

5 段階の検証プロセス

フェーズ 1：問題の検証

目標：ユーザーがお金を払って解決するほど、その問題が頻繁に発生し、深刻で、緊急性が高いことを確認します

活動：

• 問題の仮説を定義します。どのような問題を解決するのですか？
• 対象となる顧客セグメントを特定します
• 顧客発見インタビューを実施します（セグメントごとに 10～15 件）
• 問題の深刻度を定量化します：ユーザーが費やす時間や金額
• 現在の回避策と、その問題点を記録します

「Mom Test」の質問：

✅ 良い質問（行動を明らかにする）：

• 「この問題に最後に遭遇したときのことを教えてください。」
• 「現在、どのように解決していますか？」
• 「この問題にどれくらいの時間やお金を費やしていますか？」
• 「うまくいかなかった方法として、何を試しましたか？」

❌ 悪い質問（確証バイアス）：

• 「この製品を使いたいと思いますか？」（誰もが「はい」と答えます）
• 「これは良いアイデアだと思いますか？」（行動ではなく意見を尋ねています）
• 「これにいくら払いますか？」（仮定の質問です）

問題の深刻度マトリクス：

項目	低（開発しない）	中（さらに検証）	高（開発する）
頻度	めったに起きない	月に 1 回	毎日／毎週
影響	軽い不便	1～2 時間の浪費	業務を妨げる重大問題
緊急性	後回しにできる	いずれ修正すべき	今すぐ必要
支払意思	支払わない	月額 $5～20 なら支払う可能性がある	月額 $50 以上を支払う
現在の回避策	十分に機能する	何とか許容できる	苦痛／高コスト

判断基準：

• 高が 4～5 項目 → すぐに開発します
• 高が 2～3 項目 → ソリューションを検証します
• 高が 0～1 項目 → 開発しません（問題の深刻度が不十分です）

検証ゲート：

• 顧客発見インタビューを 10 件以上実施済み
• 問題が頻繁に発生し、深刻で、緊急性が高いことを検証済み
• 現在の回避策を記録して評価済み
• 支払意思を示すシグナルを収集済み
• インタビュー対象者の 70% 以上が、問題は深刻だと確認

---

フェーズ 2：ソリューションの検証

目標：ソリューションが機能を追加するだけでなく、実際に問題を解決することをテストします

検証方法：

1. スモークテスト（最速 - 1～2 日）

• ソリューションを説明し、「早期アクセスに登録」CTA を設けたランディングページを作成します
• 広告または直接のアプローチで 100～500 人の訪問者を集めます
• 成功基準：メール登録へのコンバージョン率が 5% 超

2. コンシェルジュ MVP（1 週間）

• 5～10 人の初期顧客にソリューションを手作業で提供します
• 自動化せず、自分でプロセスを案内します
• 成功基準：ユーザーが成果を得て、さらに利用したいと求める

3. Wizard of Oz MVP（1～2 週間）

• フロントエンド UI のみを構築します
• 裏側でリクエストを手作業で処理します
• 成功基準：不完全な点があっても、ユーザーが継続して利用する

4. プロトタイプテスト（3～5 日）

• クリック可能なプロトタイプ（Figma、InVision）を 10～15 人のユーザーに見せます
• 主要なタスクに取り組む様子を、案内せずに観察します
• 成功基準：70% 超が支援なしで主要なタスクを完了する

活動：

• 低忠実度のプロトタイプを作成します（紙、Figma、ランディングページ）
• 対象ユーザーにソリューションのコンセプトをテストします
• 必須機能と、あれば望ましい機能を特定します
• 支払意思と価格への期待をテストします

検証ゲート：

• プロトタイプでソリューションのコンセプトをテスト済み
• 必須機能を特定済み
• テスターの 50% 以上が、料金を払っても利用したいと回答
• 問題を解決するソリューションであることを検証済み

---

フェーズ 3：市場の検証

目標：市場が十分な規模で、成長していることを確認します

市場規模の算定：

TAM（獲得可能な最大市場規模）：

TAM = (Number of potential users globally) × (Annual revenue per user)

SAM（実際にサービスを提供できる市場規模）：

SAM = TAM × (Percentage reachable with your channels)

SOM（実際に獲得可能な市場規模）：

SOM = SAM × (Realistic market share % in 1-3 years)

最低限必要な市場規模：

• VC から資金調達するスタートアップの場合、SOM ≥ $10M
• ブートストラップ型のプロダクトの場合、SOM ≥ $1M
• 市場が年間 >10% 成長していること

競合分析：

競合他社	強み	弱み	差別化要因
競合他社 1	機能、価格	UX、サポート	自社の優位性
競合他社 2	ブランド、規模	遅い、高価	自社の優位性

重要な質問：

• ユーザーが競合他社から乗り換える理由は何ですか？
• 何を 10 倍優れたものにできますか（10％優れたものではなく）？
• 競合他社が模倣するのを防ぐ障壁は何ですか？

検証ゲート：

• 市場規模を算定済み（TAM、SAM、SOM）
• SOM ≥ $1M、成長率 >10%
• 競合状況を分析済み
• 差別化要因を明確に定義済み
• 市場投入チャネルを特定済み

---

フェーズ 4：ビジネスモデルの検証

目標：ユニットエコノミクスが収益化への道筋を示すことを検証します

顧客生涯価値（LTV）：

LTV = (ARPU per month) × (Customer lifetime in months) × (Gross margin %)

Example: $50/mo × 24 months × 80% = $960 LTV

顧客獲得コスト（CAC）：

CAC = (Total sales & marketing spend) / (New customers acquired)

Example: $50,000 / 100 customers = $500 CAC

LTV:CAC 比率：

Ratio = LTV / CAC

Example: $960 / $500 = 1.92:1 (NOT VIABLE)

成功基準：

• ✅ LTV:CAC ≥ 3:1（健全なビジネス）
• ⚠️ LTV:CAC 2:1 - 3:1（最適化が必要）
• ❌ LTV:CAC < 2:1（成立しない）

価格設定の検証（Van Westendorp 法）：

アンケートの質問：

1. いくらなら高すぎて、購入を検討しませんか？
2. いくらなら高いと感じますが、それでも購入を検討しますか？
3. いくらならお買い得だと感じますか？
4. いくらなら安すぎて、品質を疑いますか？

最適価格：「高すぎる」と「安すぎる」の曲線が交差する価格

検証ゲート：

• 収益モデルを定義済み（サブスクリプション、従量課金、フリーミアムなど）
• LTV と CAC を推定済み
• LTV:CAC ≥ 3:1 を実現可能
• 実際のユーザーを対象に価格をテスト済み
• 主要なビジネスリスクを特定済み

---

フェーズ 5：MVP の定義

目標：中核となる価値提案を検証するために必要な、最小限の機能を定義します

MVP の範囲を決めるフレームワーク：

必須（中核となる価値提案）：

• 主要なメリットを提供する機能
• これらがなければ、プロダクトは問題を解決できません
• 例：Uber の場合、「配車を依頼する」と「ドライバーを追跡する」

あると望ましい（重要だが不可欠ではない）：

• 体験を向上させますが、問題の解決に不可欠ではありません
• V1.1 または V1.2 で追加します
• 例：Uber の場合、「ドライバーの評価」と「運賃の見積もり」

あると便利（満足度を高める機能）：

• 洗練させますが、中核となる問題は解決しません
• 無期限に延期します
• 例：Uber の場合、「音楽の好み」と「ペット同乗可の配車」

MVP = 必須機能のみ。範囲を 4～8 週間に収めます。

成功指標：

• アクティベーション率：サインアップしたユーザーのうち、中核的なアクションを完了した割合
• 継続率（第 1 週）：初回利用後に戻ってきたユーザーの割合
• 紹介率：他の人に勧めたユーザーの割合
• 収益：有料に移行したユーザーの割合（収益化する場合）

検証ゲート：

• 必須機能を定義済み（中核となる価値のみ）
• あると望ましい機能とあると便利な機能を延期済み
• MVP の範囲を 4～8 週間に設定済み
• 成功指標を定義し、測定可能な状態に設定済み
• ローンチとフィードバックの戦略を計画済み

---

重要な原則

1. 最もリスクの高い仮説を最初に検証する

簡単に検証できることではなく、プロダクトを失敗させかねないことに注力します

2. 早く、低コストで失敗する

悪いアイデアに多大なリソースを費やす前に、その誤りを検証します

3. 直感より証拠を重視する

あなたの意見は検証ではありません。実際のユーザー行動こそが検証です。

4. ソリューションより先に問題に注目する

自分のソリューションではなく、問題そのものに惚れ込みましょう

5. MVP は V1 ではない

MVP は顧客を喜ばせるものではなく、仮説を検証するものであるべきです

6. ピボットはよくあること

成功したプロダクトのほとんどは、検証結果に基づいてピボットしています

---

標準出力形式

discovery_validation_summary:
  problem_validation:
    hypothesis: '<problem statement>'
    interviews_conducted: <number>
    severity:
      frequency: '<daily/weekly/monthly/rare>'
      impact: '<critical/high/medium/low>'
      urgency: '<urgent/important/nice-to-have>'
    validation_status: '<validated/needs-more-research/invalidated>'

  solution_validation:
    concepts_tested: <number>
    user_feedback: ['<key feedback>']
    must_have_features: ['<feature>']
    validation_status: '<validated/needs-iteration/invalidated>'

  market_validation:
    tam: '$<amount>'
    sam: '$<amount>'
    som: '$<amount>'
    growth_rate: '<percentage>'
    competitive_differentiation: '<summary>'

  business_model:
    revenue_model: '<subscription/usage/freemium/etc>'
    estimated_ltv: '$<amount>'
    estimated_cac: '$<amount>'
    ltv_cac_ratio: '<ratio>'
    pricing: '$<amount> per <month/year/user>'

  mvp_definition:
    must_have_features: ['<feature 1>', '<feature 2>']
    success_metrics:
      - metric: '<activation rate>'
        target: '<percentage>'
      - metric: '<retention (Week 1)>'
        target: '<percentage>'
    estimated_timeline: '<weeks>'

  recommendation: '<go/pivot/no-go>'
  risks: ['<key risk and mitigation>']

---

よくある落とし穴

❌ 課題の検証を省略する → 存在しない問題への解決策を作ってしまいます ❌ 自分の解決策に惚れ込む → うまくいかないという証拠を無視してしまいます ❌ 適切な相手に話を聞かない → 友人や家族は、聞きたいことを言ってくれます ❌ MVPを作り込みすぎる → 実験のために6か月かけて開発してしまいます ❌ 虚栄の指標を追う → 有料顧客ではなくページビューを追跡してしまいます ❌ ユニットエコノミクスを無視する → いつまでも赤字で顧客を獲得し続けてしまいます

---

承認ゲート

本格的な設計と開発に進む前に、以下を確認してください。

• 少なくとも10件の顧客インタビューで課題を検証済み
• 低忠実度のプロトタイプでソリューションのコンセプトをテスト済み
• 市場規模を算定し、実行可能性を確認済み（SOM ≥ $1M）
• ユニットエコノミクスで収益化への道筋を確認済み（LTV:CAC ≥ 3:1）
• MVPの範囲を定義し、ステークホルダーの承認を取得済み
• 成功指標を定義し、測定計画を策定済み

理由: 検証せずに開発に投資するのはギャンブルです。このゲートにより、多大なリソースを投入する前に、プロダクトマーケットフィットの達成可能性を確認できます。

---

関連リソース

関連スキル:

• mvp-builder - 検証後にMVPを迅速に開発する場合
• user-researcher - 顧客発見のためのインタビューを行う場合
• go-to-market-planner - 検証後にローンチ戦略を策定する場合

関連パターン:

• META/DECISION-FRAMEWORK.md - 構築するか購入するかの判断
• STANDARDS/best-practices/user-research.md - インタビューのベストプラクティス（作成時）

関連プレイブック:

• PLAYBOOKS/conduct-discovery-interviews.md - インタビューの手順（作成時）
• PLAYBOOKS/validate-business-model.md - ユニットエコノミクスの検証（作成時）