なぜStartup向けProductをMid-Marketにそのまま持っていけなかったのか
Customer Discoveryで「Founderは顧客として難しい」というフィードバックを受けて対象を変えた結果、Champion、CFO、セキュリティ審査という、まったく別の意思決定の仕組みに出会った話。
この記事が役に立つ意思決定
営業活動やマーケティングを増やす前に、最初に想定したICP（Ideal Customer Profile）を見直すべきか。この記事は、その判断を考えるための材料です。
GRANDRIFTのFounder自身が、Silicon Valleyで自分のProductのCustomer Discoveryを行う中で経験した、ICPの想定が崩れた過程を、意思決定に使える形へ整理しています。
現場で確認したこと
対象はGRANDRIFTのFounder自身のProduct開発です。当初は、Startup FounderとSales・Marketing領域の実務者をICPとして想定し、Customer Discoveryのインタビューを重ねました。
その中で繰り返し受け取ったのは、「Painには共感するが、Startup Founderは買い手として難しい」というフィードバックでした。要求水準は高い一方で、予算が小さく、支払いの優先順位も低い。関心は得られても、購買には進みませんでした。
このフィードバックを受けて対象をMid-Marketへ移すと、今度はまったく別の構造に出会いました。現場のChampion、予算を握るCFO、セキュリティ審査、複数の意思決定者、調達プロセス、既存システムとの接続。Startup向けに設計したProductと売り方は、そのままでは機能しませんでした。
期待していたことと、実際に起きたこと
- Painの強いCustomerであれば、Productを購入する
- Startup Founderは意思決定が速く、良いProductならすぐ導入する
- Startupで機能した売り方は、より大きな企業でも通用する
- Painはあっても、Budgetがなければ購買は起きない
- 意思決定が速いことと、支払う余力があることは別だった
- Mid-Marketでは、UserとBuyerが分かれ、審査・調達・複数承認という別の構造が待っていた
間違っていたAssumption
- Painがあれば購入する、と考えていた
- UserとBuyerを同一視していた
- Customerの属性（Startupか否か）だけでICPを定義していた
- 別のSegmentでも同じGTMが機能すると考えていた
なぜそのAssumptionは失敗につながるのか
Problemの強さだけでCustomerを選ぶと、Budget、Buying Authority、Delivery Cost、導入制約、Retentionが見落とされます。
その結果、興味は持たれても購入されない。あるいは購入されても、導入後の個別対応やChurnによってUnit Economicsが成立しなくなります。
Segmentが変わると、同じProblemでも「誰が判断し、どこから予算が出て、何を審査され、導入後に何が求められるか」がすべて変わります。ICPの定義に購買構造が含まれていないと、この変化を事前に検知できません。
事業に生じる損失
このケースで確認できた損失は、売れないSegmentに費やしたDiscovery・開発・営業の時間です。確認できていない金額を提示する代わりに、同じ状況にある企業が自社のDataで計算できる式を示します。
他の対話との比較
Silicon ValleyのSeed〜Series A周辺のFounderや、Startup / Mid-Market / Enterpriseを経験したRevOps実務家との対話でも、「Segmentが変わると意思決定の構造が変わり、同じ売り方が通用しなくなる」という話は繰り返し聞いています。
ただし、体系的に比較検証できた件数はまだ限られます。ここに書いた内容は、一社の実体験と複数の対話に基づく「次に検証すべき仮説」として扱ってください。普遍的な事実として断定するものではありません。
GRANDRIFTが得たInsight
「困っている人」と「Productの価値が事業として成立するCustomer」は、同じとは限らない。
ICPは、会社規模や業界だけではなく、Pain、Urgency、Budget、Buyer Access、Operational Fit、Retentionの組み合わせで考える必要がある。
次の会議で使える判断基準
新しいSegmentへSales投資を増やす前に、受注・失注・継続・解約したCustomerを比較し、Problemの強さだけでなく、Budget、Buyer Access、導入制約、Retentionまで確認する。
このどれか一つでも未確認のままSalesの量を増やすと、興味は増えても売上は増えない、という状態が起きやすくなります。
このInsightが成立しない条件
この経験はSilicon ValleyのB2B SaaSという文脈で起きたものです。購買の構造は、市場・文化・調達プロセス・規制によって変わります。
例えば、日本のEnterprise商習慣では稟議や商社経由の購買が入り、Buyer Accessの意味が変わります。PLG型のProductや、個人が経費で買える価格帯のProductでは、BudgetとBuyerの制約はここまで支配的ではない可能性があります。自社の文脈に当てはめる際は、この違いを先に確認してください。
もし、同じことが御社でも起きているとしたら。
営業活動を増やしても商談や受注につながらない。受注できても、個別対応が増え、導入後の利用や継続につながらない。そうした状況では、Salesの量ではなく、最初に想定したICPを見直す必要があるかもしれません。
GRANDRIFTでは、受注したCustomerだけでなく、失注、No Decision、早期解約、継続利用しているCustomerを比較します。
それぞれが抱えていたProblemの強さ、Urgency、現在の代替手段、Budget、Buyer、Decision Process、導入後に実現したかったProgressを直接確認し、どのCustomerであればProductの価値が成立するのかを整理します。
そこから、優先すべきICP、対象から外した方がよいCustomer、購入を動かすTrigger、接触すべきBuyer、試すべきMessageを具体化し、次のTarget ListやSales Experimentへ落とし込むところまでご支援できます。
もし御社でもCustomerの選定に同じような難しさがある場合は、現在の受注・失注・継続状況に合わせて、どのような形で検証できそうかご提案します。