テクニカルディスカバリー — 顧客の本当の課題を掘り当てる
初めてのディスカバリーコール
ソウタの手が微かに震えていた。
TechNova のカンファレンスルームで、ノートPCの画面にはGoogle Meetのプレビューが映っている。あと15分で、中規模EC企業「ShopFlow」のVPエンジニアリングとCTOとのディスカバリーコールが始まる。
Arclight AI のFDEチームリーダー、カイがSlackでメッセージを送ってきた。
「準備はどう?」
「正直、緊張してます」ソウタは正直に答えた。「何を聞けばいいかはリストにまとめたんですが、30分で本当の課題を引き出せるか自信がないです」
「リストを見せて」
ソウタが送ったのは、20個以上の質問が並んだスプレッドシートだった。「現在のインフラ構成は?」「月間トランザクション数は?」「使っている言語とフレームワークは?」——すべてが事実確認の質問だった。
カイの返信は短かった。
「ソウタ、これは尋問のリストだ。ディスカバリーじゃない」
WARNING
ディスカバリーの目的は「情報収集」ではない。顧客自身がまだ言語化できていない課題を、一緒に発見することだ。事実質問ばかりでは、顧客は「また技術ベンダーの質問攻め」と感じて心を閉ざす。
「じゃあ、どうすればいいんですか?」
「今から15分でフレームワークを2つ教える。SPINとSandler Pain Funnel。この2つを使えば、30分のコールで顧客の本質的な痛みまで到達できる」
SPIN フレームワーク
カイが画面共有を始めた。
「SPINはNeil Rackhamが35,000件の営業コールを分析して体系化したフレームワークだ。4種類の質問を順番に使うことで、顧客を自然に課題認識へ導く」
S — Situation(状況質問)
「まず現状を理解する質問。ただし、事前にリサーチできることは聞かない。LinkedInやテックブログで分かることを聞くと、相手は『調べてないな』と思う」
カイが具体例を挙げた。
- 「御社のECプラットフォームで、注文処理のパイプラインはどういう流れになっていますか?」
- 「現在のレコメンデーションエンジンは、どのタイミングでユーザーに提案を出していますか?」
INFO
Gong Research によると、トップパフォーマーは Situation 質問を全体の 15% 以下に抑える。ここに時間をかけすぎると、顧客は退屈する。事前リサーチで補完し、確認程度に留めるのがコツだ。
P — Problem(問題質問)
「次に、現状の中にある不満や困難を探る質問だ」
- 「レコメンデーションの精度で、チームが課題に感じていることはありますか?」
- 「注文処理のレイテンシで、ユーザーから苦情が来たことはありますか?」
「ここで重要なのは、相手に問題を『自分で言わせる』ことだ。こちらから『御社のレコメンデーションは精度が低いですよね』と言ってはいけない」
I — Implication(影響質問)
「問題が見えたら、その影響を掘り下げる。これがSPINの核心だ」
- 「レコメンデーションの精度が低いと、コンバージョン率にどのくらい影響していますか?」
- 「そのレイテンシの問題が続くと、ピーク時のカート離脱率はどう変化しますか?」
- 「エンジニアがレコメンデーションの改善に費やしている時間は、他の開発にどう影響していますか?」
「影響質問は、顧客自身に『この問題、放置できないな』と気づかせる効果がある」
N — Need-Payoff(解決価値質問)
「最後に、解決した場合の価値を顧客に語らせる」
- 「もしレコメンデーションの精度が2倍になったら、売上にどういうインパクトがありますか?」
- 「エンジニアがMLモデルの運用から解放されたら、何に時間を使いたいですか?」
「ここがポイントだ。解決策の価値を『あなたが』語るんじゃなく、『顧客が』語るように誘導する。自分で言った言葉は、他人に言われた言葉より100倍刺さる」
ソウタは頷いた。セールスの本で読んだことがある概念だが、技術的な文脈でどう使うかは初めて理解できた気がした。
SPIN を管理するシステム
「コールの後、聞いた内容をどう管理するんですか?」ソウタが聞いた。
「うちでは Discovery Tracking システムを使ってる。SPINの4カテゴリで質問と回答を記録し、後からパターン分析もできるようにしてある」
# db/migrate/20250101000001_create_discovery_sessions.rb
class CreateDiscoverySessions < ActiveRecord::Migration[8.0]
def change
create_table :discovery_sessions do |t|
t.references :account, null: false, foreign_key: true
t.references :fde, null: false, foreign_key: { to_table: :users }
t.string :title, null: false
t.datetime :scheduled_at, null: false
t.integer :duration_minutes, default: 30
t.decimal :talk_ratio_prospect, precision: 5, scale: 2
t.decimal :talk_ratio_fde, precision: 5, scale: 2
t.text :summary
t.string :status, default: "scheduled"
t.timestamps
end
add_index :discovery_sessions, :status
add_index :discovery_sessions, :scheduled_at
end
end
# db/migrate/20250101000002_create_discovery_questions.rb
class CreateDiscoveryQuestions < ActiveRecord::Migration[8.0]
def change
create_table :discovery_questions do |t|
t.references :discovery_session, null: false, foreign_key: true
t.string :spin_type, null: false # situation, problem, implication, need_payoff
t.text :question, null: false
t.text :response
t.text :follow_up_notes
t.integer :order_position
t.boolean :was_asked, default: false
t.timestamps
end
add_index :discovery_questions, :spin_type
end
end
# db/migrate/20250101000003_create_stakeholders.rb
class CreateStakeholders < ActiveRecord::Migration[8.0]
def change
create_table :stakeholders do |t|
t.references :account, null: false, foreign_key: true
t.string :name, null: false
t.string :title
t.string :email
t.string :role_type, null: false # champion, economic_buyer, technical_evaluator, end_user
t.text :priorities
t.text :concerns
t.integer :influence_level, default: 5
t.timestamps
end
add_index :stakeholders, :role_type
end
end# app/models/discovery_session.rb
class DiscoverySession < ApplicationRecord
belongs_to :account
belongs_to :fde, class_name: "User"
has_many :discovery_questions, dependent: :destroy
enum :status, {
scheduled: "scheduled",
in_progress: "in_progress",
completed: "completed",
cancelled: "cancelled"
}
validates :title, presence: true
validates :scheduled_at, presence: true
validates :talk_ratio_prospect,
numericality: { greater_than: 0, less_than_or_equal_to: 100 },
allow_nil: true
scope :upcoming, -> { where(status: :scheduled).where("scheduled_at > ?", Time.current) }
scope :completed_this_month, -> { completed.where(scheduled_at: Time.current.beginning_of_month..) }
def spin_breakdown
discovery_questions.where(was_asked: true).group(:spin_type).count
end
def total_questions_asked
discovery_questions.where(was_asked: true).count
end
def meets_gong_benchmark?
count = total_questions_asked
count >= 11 && count <= 14
end
end
# app/models/discovery_question.rb
class DiscoveryQuestion < ApplicationRecord
belongs_to :discovery_session
enum :spin_type, {
situation: "situation",
problem: "problem",
implication: "implication",
need_payoff: "need_payoff"
}
validates :question, presence: true
validates :spin_type, presence: true
scope :asked, -> { where(was_asked: true) }
scope :with_responses, -> { where.not(response: nil) }
scope :needing_follow_up, -> { where.not(follow_up_notes: nil) }
end
# app/models/stakeholder.rb
class Stakeholder < ApplicationRecord
belongs_to :account
enum :role_type, {
champion: "champion",
economic_buyer: "economic_buyer",
technical_evaluator: "technical_evaluator",
end_user: "end_user"
}
validates :name, presence: true
validates :role_type, presence: true
validates :influence_level, inclusion: { in: 1..10 }
endSandler Pain Funnel
「もう1つ教えるフレームワークがある」カイが続けた。「Sandler Pain Funnel。SPINが質問の『種類』を整理するのに対して、Pain Funnelは質問の『深さ』を制御する」
カイが解説した。
「Pain Funnelは5つのレベルで質問を深掘りしていく」
| レベル | 質問の種類 | 例 |
|---|---|---|
| 1. 広く聞く | オープンな質問 | 「注文処理の仕組みについて教えてください」 |
| 2. 具体化 | 詳細を引き出す | 「具体的にどの部分で遅延が発生しますか?」 |
| 3. 影響の定量化 | 数字で捉える | 「その遅延で月にどのくらいの注文を失っていますか?」 |
| 4. 感情への接続 | 個人的な影響 | 「その状況はチームにどういう影響を与えていますか?」 |
| 5. 解決への決意 | コミットメント | 「この問題を優先的に解決したいとお考えですか?」 |
「SPINとPain Funnelは対立するものじゃない。SPINで質問の種類を選び、Pain Funnelで各質問の深さを調整する。組み合わせて使うのがFDEのスキルだ」
INFO
SPINは「何を聞くか」のフレームワーク。Pain Funnelは「どこまで深く聞くか」のフレームワーク。両者を組み合わせると、表面的な事実確認ではなく、顧客が本当に解決したい課題にたどり着ける。
30分ディスカバリーコールの構造
「30分は短い。だからこそ構造が命だ」カイが時間配分を示した。
| フェーズ | 時間 | 内容 |
|---|---|---|
| 導入 | 2分 | 自己紹介、アジェンダ確認、ゴールの合意 |
| ディスカバリー | 18分 | SPIN + Pain Funnel で技術・ビジネス課題を深掘り |
| ソリューション概要 | 6分 | 聞いた課題に関連する部分だけデモ |
| ネクストステップ | 4分 | 次のアクション、参加者、期限を合意 |
「導入の2分で最も重要なのは『アジェンダの合意』だ。『今日は御社の課題をお聞きして、関連する部分だけ弊社のプラットフォームをお見せできればと思います。最後に次のステップを決めましょう。よろしいですか?』——このYesをもらうことで、相手も対話モードに入る」
「ソリューション概要は6分だけ?」ソウタは驚いた。
「18分聞いた課題のうち、一番痛いポイントに対してだけ見せる。全機能デモは絶対にやるな。フルデモは次回以降でいい。ディスカバリーコールの目的は『次回の約束を取り付けること』だ」
WARNING
よくある失敗: ディスカバリーコールで全機能のデモを始めてしまう。顧客は自分の課題と関係ない機能に興味がない。18分かけて発見した痛みに対して、ピンポイントで「これが解決できます」と見せるのが最も効果的だ。
Gong Research のベンチマーク
「データに基づいた話をしよう」カイがGong Researchの調査結果を引用した。
「Gongは数百万件のセールスコールをAI分析して、勝つコールと負けるコールの違いを定量化している。FDEとしてディスカバリーをやるなら、このベンチマークは常に意識してほしい」
| 指標 | ベンチマーク | 解説 |
|---|---|---|
| トークレシオ | 見込み客 57% / FDE 43% | 顧客に多く話させる |
| 質問数 | 11〜14問 / コール | 多すぎると尋問、少なすぎると浅い |
| フォローアップ質問 | トップは2倍多い | 「それはなぜですか?」が深さを生む |
| コール時間 | 成約コールは25%長い | 短いコールは関係構築が不十分 |
「トークレシオ57:43は覚えておけ。自分が話しすぎていると感じたら、質問で返す。逆に相手が話さなすぎるなら、質問の仕方がまずいかオープンな質問に切り替える」
# app/services/discovery_analyzer.rb
class DiscoveryAnalyzer
BENCHMARKS = {
talk_ratio_prospect: { min: 50.0, max: 65.0, ideal: 57.0 },
question_count: { min: 11, max: 14, ideal: 12 },
follow_up_ratio: { min: 0.3, ideal: 0.5 }
}.freeze
def initialize(session)
@session = session
end
def analyze
{
talk_ratio: analyze_talk_ratio,
question_count: analyze_question_count,
spin_balance: analyze_spin_balance,
follow_up_quality: analyze_follow_up_quality,
overall_score: calculate_overall_score
}
end
private
def analyze_talk_ratio
ratio = @session.talk_ratio_prospect
return { status: :no_data } if ratio.nil?
benchmark = BENCHMARKS[:talk_ratio_prospect]
status = if ratio.between?(benchmark[:min], benchmark[:max])
:on_target
elsif ratio < benchmark[:min]
:fde_talking_too_much
else
:prospect_monologue
end
{ value: ratio, ideal: benchmark[:ideal], status: status }
end
def analyze_question_count
count = @session.total_questions_asked
benchmark = BENCHMARKS[:question_count]
status = if count.between?(benchmark[:min], benchmark[:max])
:on_target
elsif count < benchmark[:min]
:too_few
else
:too_many
end
{ value: count, ideal: benchmark[:ideal], status: status }
end
def analyze_spin_balance
breakdown = @session.spin_breakdown
total = breakdown.values.sum.to_f
return { status: :no_data } if total.zero?
percentages = breakdown.transform_values { |v| (v / total * 100).round(1) }
{
percentages: percentages,
situation_heavy: percentages.fetch("situation", 0) > 30,
implication_light: percentages.fetch("implication", 0) < 15
}
end
def analyze_follow_up_quality
asked = @session.discovery_questions.asked
with_follow_up = asked.needing_follow_up.count
ratio = asked.count.zero? ? 0 : with_follow_up.to_f / asked.count
{
ratio: ratio.round(2),
ideal: BENCHMARKS[:follow_up_ratio][:ideal],
status: ratio >= BENCHMARKS[:follow_up_ratio][:min] ? :good : :needs_improvement
}
end
def calculate_overall_score
scores = []
scores << (analyze_talk_ratio[:status] == :on_target ? 25 : 10)
scores << (analyze_question_count[:status] == :on_target ? 25 : 10)
scores << (analyze_spin_balance[:implication_light] == false ? 25 : 10)
scores << (analyze_follow_up_quality[:status] == :good ? 25 : 10)
scores.sum
end
endテクニカルディスカバリー vs ビジネスディスカバリー
「ソウタ、FDEが他のセールスエンジニアと決定的に違う点がある。それは技術とビジネスの両方を掘れることだ」
カイが2つの軸を整理した。
| 軸 | 質問の例 | 引き出す情報 |
|---|---|---|
| テクニカル | 「現在のアーキテクチャはモノリスですか、マイクロサービスですか?」 | システム構成、データフロー、統合先、スケール要件、レイテンシ制約 |
| テクニカル | 「MLモデルの推論パイプラインはどう構成されていますか?」 | 技術的な制約、ボトルネック、インフラの成熟度 |
| ビジネス | 「レコメンデーション精度の改善が売上にどう影響しますか?」 | 収益インパクト、ビジネスKPI、経営層の優先順位 |
| ビジネス | 「競合のEC企業はパーソナライゼーションでどの程度進んでいますか?」 | 競争圧力、タイムライン、意思決定プロセス |
「セールスはビジネスの話はできるけど、技術の深い話ができない。エンジニアは技術は分かるけど、ビジネスインパクトに結びつけられない。FDEは両方をブリッジする。これが唯一無二の価値だ」
INFO
テクニカルディスカバリーで得たアーキテクチャの制約と、ビジネスディスカバリーで得た収益インパクトを組み合わせることで、「技術的に実現可能で、ビジネス的にROIが高い提案」ができる。これがFDEの本質的な付加価値だ。
マルチステークホルダーアプローチ
「ShopFlowとのコールには、VPエンジニアリングとCTOが出てくるんだったな」カイが確認した。
「はい。2人です」
「Gongのデータだと、成約する案件は買い手側のコンタクト数が平均2倍多い。つまり、1人だけと話している案件は危ない。今回2人出てくるのは良い兆候だ。ただし、ステークホルダーの種類によってディスカバリーのアプローチを変える必要がある」
| ステークホルダー | 聞くべきこと | アプローチ |
|---|---|---|
| チャンピオン | 社内で何が起きているか、政治的な力学 | 味方として信頼関係を築く |
| 経済的意思決定者 | 予算、ROI期待値、承認プロセス | ビジネスインパクトを数字で語る |
| 技術評価者 | 技術的な要件、統合の複雑さ、リスク | 深い技術的な対話でリスペクトを得る |
| エンドユーザー | 日常の痛み、ワークフローの非効率 | 共感を示し、具体的な改善を提案する |
「CTOは経済的意思決定者かつ技術評価者だろう。VPエンジニアリングは技術評価者でありチャンピオン候補かもしれない。それぞれに違う角度で質問を準備しておけ」
ディスカバリーコールの実施
コールの時間が来た。
ソウタは深呼吸をして、Google Meetに接続した。ShopFlowのCTO田村さんと、VPエンジニアリングの佐藤さんが画面に現れた。
「田村さん、佐藤さん、本日はお時間いただきありがとうございます。Arclight AI FDEのソウタです。今日は30分で、御社のレコメンデーション周りの課題をお聞きして、関連しそうな部分だけ弊社のプラットフォームをご紹介できればと思います。最後に次のステップを決めましょう。よろしいでしょうか?」
「よろしくお願いします」と田村CTO。
ソウタはカイに教わった通り、Situation質問を最小限に留めた。ShopFlowの技術ブログを事前に読み込んでいたからだ。
「御社の技術ブログでRailsモノリスからの段階的なサービス分離について拝見しました。レコメンデーション機能は現在どのサービスに含まれていますか?」
佐藤VPが答えた。「まだモノリスの中です。分離したいんですが、優先順位が上がらなくて」
ソウタはProblem質問に移った。
「分離が後回しになっている中で、レコメンデーションの改善や運用で困っていることはありますか?」
田村CTOが身を乗り出した。「正直、かなり困ってます。今のレコメンデーションはルールベースで、パーソナライゼーションがほぼできていない。でもMLを社内で構築するリソースがない」
Pain Funnelの「具体化」レベルだ。ソウタは掘り下げた。
「具体的にはどういうルールで動いていますか?」
「購入カテゴリの上位3つから類似商品を出しているだけです。協調フィルタリングすらできていない」
Implication質問に移る。
「パーソナライゼーションが不十分なことで、ビジネスKPIにどういう影響が出ていますか?」
田村CTOの表情が曇った。「コンバージョン率が業界平均を下回っています。特にリピート購入率が低い。競合のD社がAIレコメンドを入れてから、明らかに差がついた」
Pain Funnelの「感情への接続」を試みる。
「その状況は、チームにとってどういう影響がありますか?」
佐藤VPが答えた。「エンジニアが『自分たちの技術力で解決したい』と言うんですが、MLの専門知識がなくて空回りしている。モチベーションに影響が出始めています」
ソウタはNeed-Payoff質問で締めた。
「もしパーソナライゼーションが高精度で動くようになったら、ビジネスにどういうインパクトがありますか?」
田村CTOが即答した。「コンバージョン率が1%上がるだけで、年間で2億円のインパクトです。それに、エンジニアがMLの運用から解放されれば、コア機能の開発に集中できる」
ソウタは内心でガッツポーズした。顧客自身が、ROIと技術的な解放を自分の言葉で語ってくれた。
ディスカバリーの成果物
コール終了後、ソウタはカイに習った3つの成果物を作成した。
1. ステークホルダーマップ
2. 現行アーキテクチャ
3. Pain-to-Value マトリクス
| 痛み | ビジネスインパクト | 弊社ソリューション |
|---|---|---|
| ルールベースの低精度レコメンド | コンバージョン率が業界平均以下 | AIレコメンデーションAPI |
| ML専門知識の不足 | エンジニアの空回り、モチベーション低下 | マネージドMLパイプライン |
| モノリスからの分離ができていない | レコメンド改善のスピードが遅い | API経由で段階的に統合可能 |
| 競合D社との差 | リピート購入率の低下 | 導入後2週間で精度改善を実証 |
ディスカバリー記録サービス
ソウタは、コールで得た情報をシステムに記録するサービスクラスを実装した。
# app/services/discovery_recorder.rb
class DiscoveryRecorder
def initialize(session)
@session = session
end
def record_question(spin_type:, question:, response: nil, follow_up: nil)
next_position = @session.discovery_questions.maximum(:order_position).to_i + 1
@session.discovery_questions.create!(
spin_type: spin_type,
question: question,
response: response,
follow_up_notes: follow_up,
order_position: next_position,
was_asked: true
)
end
def record_stakeholder(account:, name:, title:, role_type:, priorities: nil, concerns: nil, influence: 5)
Stakeholder.find_or_initialize_by(account: account, name: name).tap do |s|
s.update!(
title: title,
role_type: role_type,
priorities: priorities,
concerns: concerns,
influence_level: influence
)
end
end
def complete_session!(talk_ratio_prospect:, talk_ratio_fde:, summary:)
@session.update!(
status: :completed,
talk_ratio_prospect: talk_ratio_prospect,
talk_ratio_fde: talk_ratio_fde,
summary: summary
)
analysis = DiscoveryAnalyzer.new(@session).analyze
notify_fde_with_feedback(analysis)
analysis
end
private
def notify_fde_with_feedback(analysis)
return unless analysis[:overall_score] < 70
ActionMailer::Base.mail(
to: @session.fde.email,
subject: "Discovery Feedback: #{@session.title}",
body: format_feedback(analysis)
).deliver_later
end
def format_feedback(analysis)
feedback = []
feedback << "トークレシオ: #{analysis[:talk_ratio][:status]}" if analysis[:talk_ratio][:status] != :on_target
feedback << "質問数: #{analysis[:question_count][:status]}" if analysis[:question_count][:status] != :on_target
feedback << "Situation質問が多すぎます" if analysis.dig(:spin_balance, :situation_heavy)
feedback << "Implication質問を増やしましょう" if analysis.dig(:spin_balance, :implication_light)
feedback.join("\n")
end
endAWS QuickSight によるディスカバリー準備
「ソウタ、ディスカバリーコールの前に、顧客のデータを可視化しておくと会話の質が上がる」カイが付け加えた。
「うちではAWS QuickSightを使って、顧客データのダッシュボードを事前に作成している。顧客のパブリックデータやPoCで取得したデータを分析して、仮説を持ってコールに臨むんだ」
「例えば、ShopFlowのケースなら、パブリックに公開されている商品ページをクロールして、レコメンデーションの傾向を分析できる。『御社のレコメンデーション、上位カテゴリの3商品しか出ていないように見えますが、これはルールベースだからですか?』と具体的に聞ける」
# app/services/pre_discovery_data_loader.rb
class PreDiscoveryDataLoader
def initialize(account)
@account = account
@s3_client = Aws::S3::Client.new(region: "ap-northeast-1")
@athena_client = Aws::Athena::Client.new(region: "ap-northeast-1")
end
def prepare_dashboard
upload_public_data_to_s3
run_athena_analysis
end
private
def upload_public_data_to_s3
@s3_client.put_object(
bucket: "arclight-discovery-data",
key: "accounts/#{@account.id}/public_data.json",
body: fetch_public_data.to_json,
content_type: "application/json"
)
end
def run_athena_analysis
query = <<~SQL
SELECT
category,
COUNT(*) as product_count,
AVG(recommendation_overlap_ratio) as avg_overlap
FROM discovery_data
WHERE account_id = '#{@account.id}'
GROUP BY category
ORDER BY product_count DESC
LIMIT 20
SQL
@athena_client.start_query_execution(
query_string: query,
query_execution_context: { database: "discovery_db" },
result_configuration: {
output_location: "s3://arclight-discovery-data/athena-results/"
}
)
end
def fetch_public_data
{ account_id: @account.id, collected_at: Time.current.iso8601, data_points: [] }
end
endINFO
ディスカバリーコールの前に顧客のパブリックデータを分析しておくと、Situation質問を減らせる。「調べてきました」という姿勢は、顧客からの信頼を一気に獲得する。ただし、プライバシーに配慮し、公開情報のみを使用すること。
カイからのフィードバック
コール終了後、カイがフィードバックをくれた。
「よくやった。良かった点は、アジェンダの合意、Situation質問の最小化、田村CTOに自分の言葉でROIを語らせたこと。教科書通りだ」
「改善点は2つ。1つ目、佐藤VPが『エンジニアのモチベーション』に触れたとき、もっと掘り下げるべきだった。『離職のリスクはありますか?』と聞けば、技術課題がビジネスリスクに直結する話を引き出せた」
「2つ目、ネクストステップの詰めが甘い。日程、参加者、準備資料まで具体的に詰めるべきだった」
ソウタはメモを取りながら頷いた。
「でも、最も重要なことは体感できたはずだ」カイが言った。
「何ですか?」
「ディスカバリーは『売る』行為じゃない。『発見する』行為だ。顧客と一緒に問題を発見し、一緒に解決策を探る。相手は『売り込まれた』と感じず、『理解してもらえた』と感じる。これがFDEのディスカバリーが営業と根本的に違うところだ」
ソウタは、コール中の田村CTOの表情を思い出した。「2億円のインパクトです」と語ったとき、彼の目は輝いていた。それは説得された顔ではなく、自分自身の可能性に気づいた顔だった。
ソウタの気づき
その夜、ソウタは自分のノートに書いた。
ディスカバリーの本質は、顧客が自分自身の課題に気づくプロセスを支援することだ。
SPINは質問の種類を選ぶコンパス。Pain Funnelは深さを測る物差し。 30分という制約が、逆に構造化された対話を強制する。
FDEとして最も価値があるのは、技術とビジネスの両方の言語を話せることだ。 CTOに「コンバージョン率」で語り、VPエンジニアリングに「MLパイプラインのアーキテクチャ」で語る。 この切り替えができるのは、コードを書けるエンジニアだからこそだ。
今日学んだこと:
- 聞くことは、話すことより難しい
- 良い質問は、良い回答より価値がある
- 顧客の言葉で語られた課題は、自分の言葉で説明した課題の100倍強い