mcpField
S
solution-interview

solution-interview

github.com/guia-matthieuデザイン・UI150198 回インストール4 週間前に更新
リポジトリ

solution-interview について

確認済みの顧客課題を提案する解決策が満たすかを検証するプロダクト開発スキルです。MVPに着手する前に、プロトタイプの提示、インタビュー、適合度評価、支払い意向の確認を支援します。

主な機能

  1. 01ソリューションインタビューの台本
  2. 02プロトタイプデモの計画
  3. 03顧客の反応分析
  4. 04ソリューション適合度の評価表
  5. 05支払い意向の確認

活用シーン

  1. 01MVP開発前のコンセプト検証
  2. 02プロトタイプや機能へのフィードバック収集
  3. 03同じ課題に対する代替案の比較
  4. 04顧客の価格感の把握

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/guia-matthieu/clawfu-skills --skill solution-interview

インストール後、Claude Code で/solution-interviewを入力して読み込まれたか確認します。

詳細

ソリューションインタビュー

本格的な製品を構築する前に、ソリューションが検証済みの課題を実際に解決するかをテストします。コンセプトやプロトタイプを見せて、ソリューションが適合するかどうかについて率直なフィードバックを得る技術を身につけましょう。

このスキルを使うタイミング

  • 課題インタビューの後:ソリューションが検証済みの課題に対処できるかをテストします
  • MVP の構築前:中核となる価値提案を検証します
  • プロトタイプのテスト:コンセプトやモックアップへのフィードバックを得ます
  • 機能の検証:新機能が実際の課題を解決するかをテストします
  • ピボット:同じ課題に対する別のソリューションをテストします
  • 価格の把握:支払い意欲を理解します

方法論の基盤

項目詳細
出典Cindy Alvarez 著『Lean Customer Development』(2014年)、Steve Blank 著「Customer Development」
中核となる原則「語るのではなく、見せましょう。顧客が具体的なものに反応できるようにします。顧客の言葉ではなく、その反応が真実を明らかにします。」
重要な理由人は自分の行動を正確に予測できません。プロトタイプを見せて反応を観察することで、ソリューションが機能するかどうかについて、実際の反応を得られます。

Claude が行うことと、あなたが決めること

Claude が行うことあなたが決めること
制作ワークフローを構成する最終的なクリエイティブの方向性
技術的なアプローチを提案する機材とツールの選択
テンプレートとチェックリストを作成する品質基準
ベストプラクティスを特定するブランドや語り口の判断
台本の概要を生成する最終的な台本の承認

このスキルでできること

  1. ソリューションのデモを構成する - コンセプトを効果的に提示する方法
  2. 率直な反応を引き出す - 社交辞令ではない、本当のフィードバックを得る
  3. ギャップや問題を特定する - 不足している点や誤っている点
  4. 支払い意欲をテストする - 早期の価格検証
  5. ソリューションの適合性を測定する - 実際に課題を解決できるか
  6. 製品に関する洞察を得る - 何を構築し、何を見送るか

使い方

ソリューションインタビューの台本を準備する
I've validated this problem: [problem]
My proposed solution: [solution concept]
Create a solution interview script to test fit.
Include how to demo and what reactions to look for.
ソリューションインタビューの結果を分析する
I showed my prototype to [X] people. Here's the feedback: [summary]
Analyze solution fit. Should I proceed to MVP?
ソリューションインタビューのプロトタイプを作成する
Help me create the minimum viable demo for solution interviews:
Problem: [validated problem]
Solution concept: [idea]
What should I show? What level of fidelity is needed?

手順

ステップ 1:まず課題が検証済みか確認する
## Pre-Requisite Check

### Do NOT start solution interviews until:
- [ ] Completed 10+ problem interviews
- [ ] Problem validation scorecard passes:
  - [ ] >70% mentioned problem unprompted
  - [ ] Average severity >7/10
  - [ ] >30% actively seeking solutions
- [ ] Clear problem statement documented
- [ ] Target persona defined

### Why This Matters
If you test solutions without validated problems, you'll get:
- False positives ("sure, that looks nice")
- No ability to connect solution to real pain
- Wasted time building the wrong thing

### Problem Summary for This Interview
**Validated Problem:** ________________________________
**Severity Score:** __/10
**Who Has It:** [Persona description]
**What They Do Today:** [Current solution]

ステップ 2:ソリューションのデモを作成する
## What to Demo

### Fidelity Levels

| Level | What It Is | When to Use | Time to Create |
|-------|------------|-------------|----------------|
| **Concept** | Verbal description + whiteboard | Very early, exploring directions | 30 min |
| **Paper** | Sketches, wireframes | Early concept validation | 2-4 hours |
| **Clickable** | Figma/InVision prototype | Testing workflows and features | 1-2 days |
| **Wizard of Oz** | Human behind the curtain | Testing value prop before building | 1-3 days |
| **Concierge** | You do it manually for them | Testing if solution works at all | 1+ week |
| **MVP** | Basic working product | Testing if they'll pay | 2+ weeks |

### What to Show

**DO Show:**
- Core value proposition in action
- The main workflow/interaction
- How it solves their specific problem
- Just enough to get a reaction

**DON'T Show:**
- Every feature you plan to build
- Polished design (distracts from function)
- Pricing (usually—test separately)
- Your roadmap (creates false expectations)

### Demo Script Template

"Before I show you anything, let me make sure I understand your problem.
[Recap validated problem in their words]
Does that sound right? [Confirm]

What I want to show you is rough—it's not a real product yet.
I'm interested in your honest reaction, even if it's negative.
The worst thing you could do is be polite.

[Demo the core concept - 2-3 minutes max]

Now I want to understand your reaction..."

ステップ 3:ソリューションインタビューを実施する
## Solution Interview Structure (30-45 minutes)

### Part 1: Problem Recap (5 min)
"Last time we talked about [problem]. Since then, has anything changed?"
"What have you tried to solve this?"
Goal: Re-anchor to the problem, confirm it's still relevant

### Part 2: Solution Demo (5-10 min)
"I want to show you something we're exploring..."
[Demo core concept]
"What's your initial reaction?"
Goal: Present solution, capture immediate reaction

### Part 3: Feedback Deep Dive (15-20 min)
"What stood out to you?"
"What concerns you?"
"What's missing?"
"How would this fit into your current workflow?"
Goal: Understand fit, gaps, objections

### Part 4: Comparison to Current (5 min)
"How does this compare to what you do today?"
"Would this replace [current solution] or add to it?"
"What would have to be true for you to switch?"
Goal: Understand switching behavior

### Part 5: Commitment Testing (5 min)
"If this existed today, what would you do?"
"Would you be willing to try an early version?"
"What would it be worth to you if it worked?"
Goal: Test real interest with commitment asks

### Part 6: Next Steps (2 min)
"Can I follow up when we have something more complete?"
"Who else should I show this to?"
Goal: Get permission for follow-up, referrals

ステップ 4:インタビューの各段階で重要な質問をする
## Solution Interview Questions

### Reaction Questions (Initial)
- "What's your first reaction?"
- "What stood out to you?"
- "What surprised you?"
- "What concerned you?"

**Watch for:**
- Immediate positive vs. confused
- Questions they ask (what do they care about?)
- Body language (leaning in vs. back)

### Understanding Questions (Comprehension)
- "In your own words, what does this do?"
- "How would you explain this to a colleague?"
- "What problem does this solve?"

**Red flags:**
- They can't explain it = too complex
- They describe it differently than intended = messaging problem
- They describe features, not benefits = not connecting to their problem

### Fit Questions (Solution-Problem Fit)
- "Does this solve the problem we discussed?"
- "What would be different about your day/week if you had this?"
- "Where does this fit in your current workflow?"
- "What would you stop doing if you had this?"

**Strong signals:**
- They can immediately see where it fits
- They describe specific situations it would help
- They identify things they'd stop doing (replacing current behavior)

### Gap Questions (What's Missing)
- "What's missing?"
- "What would prevent you from using this?"
- "What would make this a no-brainer?"
- "What's the most important thing we should build first?"

**Listen for:**
- Must-have features vs. nice-to-haves
- Deal-breaker gaps
- Unexpected use cases

### Concern Questions (Objections)
- "What worries you about this?"
- "What could go wrong?"
- "What would your [boss/team/IT] think?"

**Listen for:**
- Technical concerns (security, integrations)
- Organizational concerns (adoption, approval)
- Personal concerns (learning curve, change)

### Comparison Questions (vs. Alternatives)
- "How does this compare to what you do today?"
- "How does this compare to [competitor]?"
- "What would make you switch from your current solution?"

### Commitment Questions (Action)
- "If this was available today, what would you do?"
- "Would you be willing to try an early version?"
- "Would you pay for this? How much would it be worth?"
- "Can I add you to our beta list?"

ステップ 5:ソリューションの適合性を評価する
## Solution Interview Scorecard

### Per Interview Assessment

**Interview #___**
**Participant:** _______________

| Criteria | Rating (1-5) | Notes |
|----------|--------------|-------|
| Understood what it does | | |
| Connected to their problem | | |
| Saw clear value | | |
| Would use/try it | | |
| Would pay (some amount) | | |
| Referred others | | |

**Reaction Type:**
- [ ] Excited ("When can I have this?")
- [ ] Interested (asking good questions)
- [ ] Neutral (polite but not engaged)
- [ ] Confused (didn't understand)
- [ ] Negative (specific concerns)

**Key Verbatim:**
"[Quote showing reaction]"

### Aggregate Analysis (After 10+ Interviews)

| Metric | Target | Actual | Status |
|--------|--------|--------|--------|
| Understood the solution | >90% | | |
| Said it solves their problem | >70% | | |
| Would try/use it | >60% | | |
| Would pay something | >40% | | |
| Made commitment (beta signup, referral) | >30% | | |

### Decision Framework

**VALIDATED - Proceed to MVP if:**
- [ ] 7+ of 10 said it solves their problem
- [ ] 6+ would try an early version
- [ ] 4+ expressed willingness to pay
- [ ] 3+ made real commitment (beta signup, referral, LOI)
- [ ] No critical gaps identified
- [ ] Clear must-have features identified

**ITERATE - Before MVP if:**
- [ ] Solution fit is partial (some love it, some don't)
- [ ] Critical feature gap identified
- [ ] Significant objection pattern emerged
- [ ] Need to test alternative approaches

**NOT VALIDATED - Pivot if:**
- [ ] Fewer than 5 said it solves their problem
- [ ] Widespread confusion about value
- [ ] No one willing to try it
- [ ] Unanimous critical concern

例

例 1:SaaS ソリューションインタビュー

入力:

「マーケティングマネージャーがチャネル横断のアトリビューションに苦労していることを検証しました(深刻度 8/10)。ダッシュボードのソリューションをテストしたいので、ソリューションインタビューの台本を作成してください。」

出力:

ソリューションインタビュー:マーケティングアトリビューションダッシュボード

インタビュー前の準備

検証済みの課題: マーケティングマネージャーは、チャネルを横断してキャンペーンの ROI を追跡できない 深刻度: 8/10 現在のソリューション: 手作業のスプレッドシート、複数のツールへのログイン、推測

デモの準備

見せるもの: 次の要素を含むダッシュボードの Figma プロトタイプ:

  • すべてのチャネルを表示する 1 画面
  • タッチポイントごとのアトリビューション
  • キャンペーンの ROI をひと目で確認

デモの所要時間: 最大 3 分


インタビュー台本

パート 1:課題の振り返り(5 分) 「先月お話ししたとき、マーケティングデータをまとめるのに週 6 時間かかっていて、CFO から質問されてもすぐに答えられないことがよくあるとおっしゃっていました。今も同じ状況ですか?」

[確認と最新情報を待ちます]

「その後、何か変わりましたか?新しいことを試しましたか?」


パート 2:ソリューションのデモ(5 分)

「現在取り組んでいるものをお見せしたいと思います。まだ粗削りで、実際の製品ではありません。率直な感想を聞かせてください。

[画面を共有して、プロトタイプを表示]

これがマーケティングダッシュボードだと想像してください。ログインすると、Google、LinkedIn、Facebook、メールなど、すべてのチャネルが一か所に表示されます。

[アトリビューションビューを指します]

ここでは、コンバージョンにつながったタッチポイントを確認できます。ラストクリックだけでなく、顧客の全行程がわかります。

[ROI を指します]

そして、キャンペーンの ROI が自動で計算されます。これを CFO に見せることもできます。

第一印象はいかがですか?」


パート 3:フィードバックの詳細確認(15 分)

反応:

  • 「どこが特に印象に残りましたか?」
  • 「気になる点はありますか?」

理解度:

  • 「これがどのように役立つか、ご自身の言葉で説明していただけますか?」

適合性:

  • 「これは、話し合った課題を解決できますか?」
  • 「月曜日の朝にこれを使うとしたら、どのように使うか順を追って説明してください……」
  • 「これがあれば、何をしなくなりますか?」

不足点:

  • 「何が足りませんか?」
  • 「導入を断念する決め手になるものは何ですか?」
  • 「最初に開発すべき最も重要なものは何ですか?」

懸念事項:

  • 「このアプローチで気になる点はありますか?」
  • 「新しいツールの追加について、IT 部門は何と言うでしょうか?」
  • 「チームがこれを使うのを妨げるものは何ですか?」

パート 4:比較(5 分)

  • 「これは、現在お使いのスプレッドシートと比べてどうですか?」
  • 「ほかのアトリビューションツールを検討したことはありますか?それと比べてどうでしょうか?」
  • 「現在のやり方から切り替えるとしたら、何が決め手になりますか?」

パート 5:意思確認(5 分)

  • 「これが今使えるとしたら、どうしますか?」
  • 「粗削りでも、初期バージョンを試してみてもらえますか?」
  • 「うまく機能するとしたら、いくら払いますか?大まかな範囲で構いません。」
  • 「早期アクセスリストに追加してもよろしいですか?」
  • 「チームのほかの誰に話を聞くとよいでしょうか?」

注目するポイント

強いシグナル:

  • 「これを使わせてもらえますか?」/「いつ完成しますか?」
  • 仕組みに関する具体的な質問
  • すでに使い方を考えている
  • 役立つ具体的な状況を挙げる
  • 促されなくても支払う意思を示す

弱いシグナル:

  • 「いいですね」(礼儀上の反応)
  • 具体性のない一般的な称賛
  • 「完成したら教えてください」(受け身)
  • 使い方を説明できない

危険信号:

  • 何をするものか理解できていない
  • 「すでに似たものがあります」
  • 「チームが使うかどうかわかりません」
  • 対応できない大きな機能不足

例 2:ソリューションインタビューの結果を分析する

入力:

「働く親 10 人に食事準備アプリのプロトタイプを見せました。以下が概要です。MVP を作るべきでしょうか?」

概要:

  • 10 人中 8 人が内容を理解した
  • 10 人中 6 人が役立つと答えた
  • 10 人中 4 人が試してみると答えた
  • 10 人中 2 人が料金を払うと答えた
  • 主なフィードバック:「見た目はいいですが、実際に使うかどうかはわかりません」

出力:

ソリューションインタビューの分析

スコアカード
指標目標実績状態
ソリューションを理解した>90%80%⚠️
課題を解決すると答えた>70%60%❌
試してみると答えた>60%40%❌
料金を払うと答えた>40%20%❌
診断:検証できていません

すべての指標で基準を下回っています。これは重大な警告サインです。

主な洞察

「見た目はいいですが、実際に使うかどうかはわかりません」というのは、重要なシグナルです。通常、次のいずれかを意味します。

  1. ソリューションが、相手の実際の課題に結びついていると感じられない
  2. そもそも課題がそれほど深刻ではなかった
  3. 口では欲しいと言っても、実際の行動にはつながらない
分析の質問

1. 問題は実際に検証されていましたか?

  • 問題に関するインタビューに戻ります
  • 深刻度は本当に7以上でしたか? それとも、相手が気を遣っていただけですか?
  • 相手は積極的に解決策を探していましたか? それとも、問題があることを認めただけですか?

2. セグメントが合っていない可能性はありますか?

  • お金を払うと言った2人は、どんな人ですか? ほかの人たちと違いはありますか?
  • 「働く親」では広すぎるのかもしれません
  • 「食事サービスにすでにお金を払っている働く親」が必要かもしれません

3. 問題ではなく、解決策が間違っている可能性はありますか?

  • 何が不足していると言っていましたか?
  • 何があれば「迷わず選ぶ」でしょうか?
  • アプリは求めていないのかもしれません。調理済みの食事を届けてほしいのかもしれません
次のステップのおすすめ

オプション1:ギャップを診断する 「役に立つ」と言ったものの、試そうとしなかった6人に戻って尋ねます。

  • 「『役に立つ』と思うことと、実際に使うことの間には、どんなギャップがありますか?」
  • 「実際に試すには、何が必要ですか?」
  • 「ほかに何があればよいですか?」

オプション2:熱心な顧客を見つける お金を払うと言った2人は、アーリーアダプターです。彼らを理解しましょう。

  • 彼らはほかの人たちと何が違いますか?
  • ほかの人たちにはない、どんな問題を抱えていますか?
  • 彼らに特化して作りましょう

オプション3:解決策を方向転換する 問題は検証済みでも、解決策が検証されていない場合:

  • 「時間がなくて健康的な食事ができない」という問題を解決する方法は、ほかにありますか?
  • 食事の計画ではなく、食事の準備なのかもしれません
  • アプリではなく、サービスなのかもしれません
  • 新たな解決策のインタビューで、別の解決策をテストしましょう
まだMVPを作らないでください

使う人が20%しかいないものを作るために、何か月も費やすことになります。まずは解決策との適合度を60%以上に高めましょう。


例3:オズの魔法使い方式による解決策のテスト

入力:

「AIを作る前に、AIが生成したSNS投稿に顧客がお金を払うかどうかをテストしたいです。製品なしで解決策のインタビューを行うには、どうすればよいですか?」

出力:

オズの魔法使い方式による解決策のインタビュー

コンセプト

「オズの魔法使い」方式のテストでは、顧客には自動化されていると思わせたまま、手作業で体験を提供します。これにより、技術を作る前に価値をテストできます。

準備する内容

顧客に見えること:

  • トピックや概要をアップロードする
  • 24時間以内にSNS投稿を受け取る
  • AIが生成したように見える

実際に行うこと:

  • あなた(またはフリーランサー)が手作業で投稿を書く
  • メールまたはシンプルなダッシュボードで納品する
  • 反応と利用状況を記録する
解決策のインタビューの流れ

パート1:問題を確認する 「SNS投稿を書くのに週4時間かかるとおっしゃっていました。今もそうですか?」

パート2:コンセプトを説明する 「SNS投稿を代わりに書いてくれるAIをテストしています。トピックを渡すと、1週間分の投稿を生成します。生成される内容の例をご覧ください……」

[手作業で作成したサンプル出力を見せる]

「最初の印象はいかがですか?」

パート3:テストを提案する 「パイロットを実施しています。今後2週間、私がSNS投稿を作成します。トピックを教えていただければ、24時間以内に投稿をお送りします。

パイロットは無料です。お願いしたいのは、次の3点です。

  1. 実際に投稿を使うこと(使わない場合は、その理由を教えてください)
  2. 良かった点や悪かった点について、フィードバックをいただくこと
  3. 最後に、これにお金を払うかどうかを教えていただくこと

試してみませんか?」

パート4:実際の行動を観察する パイロット中に、次の点を記録します。

  • 実際にトピックを教えてくれるか
  • 実際に投稿を使うか
  • どのようなフィードバックをくれるか
  • どれくらい編集するか

パート5:支払い意思を確認する パイロット終了後: 「この2週間を踏まえて、これにお金を払いますか?」 「迷わず選ぶ価格にするには、いくらにする必要がありますか?」 「何があれば、さらに価値が高まりますか?」

このテストでわかること
わかること確認方法
出力に価値を感じているか投稿を使ったか
品質は十分かどれくらい編集したか
時間の節約になるか時間が節約できたと言っていたか
お金を払うか直接尋ねる+行動を観察する
どの機能が重要かどのようなフィードバックをくれたか
Wizard of Oz の成功基準

次の場合は AI の構築に進みます:

  • 10 人中 7 人以上が、提供した投稿をすべて使用した
  • 編集がほとんど必要なかった(修正率 20% 未満)
  • 定性的なフィードバックが良好だった
  • 5 人以上が、実現可能な価格で支払う意思を示した
  • 重大な品質上の懸念がなかった
効果がある理由
  • コードを書かずに価値を証明できます
  • 予測ではなく、実際の利用データを得られます
  • 「アルゴリズム」(人間によるプロセス)を低コストで改善できます
  • 手動版を使う顧客は、自動版も使います

チェックリストとテンプレート

ソリューションインタビュー準備チェックリスト
## Before the Interview

□ Problem validation confirmed
□ Solution demo/prototype ready
□ Demo script practiced (under 5 min)
□ Questions prepared
□ Note-taking system ready
□ Commitment asks defined

## What to Demo

□ Core value proposition only
□ Not over-polished (avoid distraction)
□ Relatable to their specific problem
□ Interactive if possible

## During the Interview

□ Recap problem first
□ Set expectation for honest feedback
□ Demo in under 5 minutes
□ Watch for immediate reaction
□ Probe on concerns and gaps
□ Test commitment (beta, pay, referral)
□ Get permission to follow up

ソリューションインタビュー記録テンプレート
## Solution Interview #___

**Date:** _______________
**Participant:** _______________
**Problem Recap:** Still experiencing issue? Y/N

### Demo Reaction

**Initial reaction:** (excited/interested/neutral/confused/negative)

**First words after demo:**
"[Verbatim]"

**Questions they asked:**
1.
2.
3.

### Fit Assessment

| Question | Response | Signal Strength |
|----------|----------|-----------------|
| Solves problem? | | Strong/Med/Weak |
| Would use it? | | Strong/Med/Weak |
| Replaces current? | | Strong/Med/Weak |
| Would pay? | | Strong/Med/Weak |

### Gaps & Concerns

**Missing features:**
-

**Concerns:**
-

**Deal-breakers:**
-

### Commitment Outcome

□ Would try beta
□ Would pay (amount: $___)
□ Made referral
□ Gave follow-up permission
□ No commitment

### Key Insight
________________________________

スキルの適用範囲

このスキルが得意なこと
  • 音声制作ワークフローの構成
  • 技術的なガイダンスの提供
  • 品質チェックリストの作成
  • クリエイティブなアプローチの提案
このスキルでできないこと
  • 音響エンジニアリングの専門知識に取って代わること
  • 主観的なクリエイティブ上の判断を下すこと
  • 音声ファイルへの直接アクセスや編集
  • 商業的な成功の保証

参考資料

  • Alvarez, Cindy. 『Lean Customer Development』(2014)- ソリューションインタビューの手法
  • Blank, Steve. 『The Four Steps to the Epiphany』(2005)- 顧客開発
  • Fitzpatrick, Rob. 『The Mom Test』(2013)- 正直なフィードバックを得る方法
  • Constable, Giff. 『Talking to Humans』(2014)- インタビューの手法
  • Torres, Teresa. 『Continuous Discovery Habits』(2021)- 継続的な検証

関連スキル


スキルのメタデータ

  • モード:サイボーグ
name: solution-interview
category: validation
subcategory: customer-research
version: 1.0
author: MKTG Skills
source_expert: Cindy Alvarez
source_work: Lean Customer Development
difficulty: intermediate
estimated_value: $2,000 product validation consulting
tags: [validation, interviews, solutions, prototypes, MVP, startups, YC]
created: 2026-01-25
updated: 2026-01-25

コメント