GTM
POC Is the New Funnel
The funnel did not disappear. Its center of gravity moved from awareness to proof.
Whiteboard · funnel shift
The thesis
For a decade, enterprise GTM was organized around a simple story: fill the top, qualify, demo, negotiate, close.
Marketing owned awareness. SDRs owned meetings. AEs owned the rest. Pipeline was a shape — wide at the top, narrow at the bottom — and success was measured in volume entering the wide end.
That story still appears on board slides. It no longer matches how enterprise buyers buy.
In complex B2B — especially software with security review, integration work, and multi-stakeholder committees — the deal is not won when someone attends a demo.
It is won when the vendor proves value in the buyer's environment: their stack, their data, their workflow, their risk model.
Proof-of-concept and pilot motions are not a late-stage artifact hanging off a linear funnel. They are the funnel.
POC is where qualification, competitive displacement, technical validation, and economic buyer confidence actually happen.
Everything above it is increasingly thin. Everything below it assumes the hard work is already done.
A scene from forecast
A seven-figure cybersecurity opportunity: Stage 3 in Salesforce, executive demo complete, champion still enthusiastic. On paper, the deal was advancing.
In forecast, the VP Sales question was not whether the buyer liked the deck. It was whether agreed pilot criteria existed — and whether security had a credible path on architecture.
Nothing had moved stage in two weeks. Half the buying committee was active in threads the AE was not tracking. Success criteria for the pilot still lived in a Slack channel, not in the CRM.
The deal was not failing on awareness. It was failing on proof operationalization.
Where this does — and does not — apply
This argument is scoped to complex enterprise B2B — not every go-to-market motion.
PLG and self-serve motions convert on product touch, not a sixty-day pilot. High-velocity transactional sales can close on fit and price with minimal evaluation. Repeat buys and expansions on known products often skip a formal POC.
The “POC is the funnel” thesis is strongest when integration risk is real, committees are large, and switching cost makes proof mandatory before commit. That is the center of gravity for most seven-figure software motions — and where GTM systems most often lie about progress.
First principles: why proof wins
This is not a trend about longer sales cycles or pickier procurement.
Four structural forces push the decision surface into evaluation:
Risk transfer. Buyers ask vendors to prove outcomes before signature because switching cost and failure visibility are high.
A deck shifts risk to the buyer. A pilot shifts risk to the vendor — where enterprise procurement wants it.
Buying committee dynamics. Security, IT, operations, and line-of-business each need evidence in their language.
That evidence is generated in threads, tickets, and environments — not in a single champion call.
Integration cost. “Works in our environment” is the bar.
Demos in a sanitized sandbox do not answer whether APIs, identity, data residency, and workflow fit hold under real constraints.
Economic proof. ROI claims in a vendor deck are discounted.
ROI in the buyer's data — even directional — is what unlocks budget and executive sponsorship.
Whiteboard · first principles
When these forces combine, evaluation stops being a stage you “get to” after a good demo. It becomes the work.
Capacity, tooling, and management attention that still optimize top-of-funnel volume are optimizing the wrong bottleneck.
What breaks when you run a POC funnel with TOF tools
Most revenue stacks were built for the old shape. CRM stages assume linear progression.
Marketing automation scores engagement before anyone has seen the product in context.
AI-SDR products celebrate emails sent and meetings booked — useful, but orthogonal to whether a POC slot opens, criteria are defined, or a technical win is achievable.
Whiteboard · pipeline metrics
Three failure modes show up repeatedly.
Lagging pipeline metrics. Leadership forecasts on opportunities created and demos held while deals stall in evaluation threads reps never logged as “stage movement.”
Context fragmentation. The truth of the deal lives across email, Slack, Gong, Jira, and the POC environment.
CRM holds amount and stage. It does not hold whether security answered the architecture question or whether success criteria were agreed.
Execution overload at the proof gate. SEs, AEs, and managers become the integration layer — drafting criteria, chasing technical answers, rebuilding discovery for every pilot.
Throughput caps. Win confidence drops.
Competitors who execute evaluation faster look “stickier” even with a weaker product.
Adding more outbound does not fix a POC bottleneck. It can make it worse.
More opportunities enter evaluation under-resourced. The team learns the wrong lesson — we need more leads — instead of the right one: we need more evaluation throughput with the same headcount.
Proof gates, not stage labels
If POC is the funnel, the unit of pipeline management should be proof gates — discrete outcomes that must clear before the deal earns a forecast category.
This is the net-new operating frame: not another definition of AI-native GTM, but a replacement for stage theater in enterprise evaluation.
Whiteboard · proof gates
Charter. Pilot scoped, owners named, capacity allocated — honest about whether you can run the eval well.
Criteria. Success defined before environment work; no “we’ll know it when we see it.”
Environment. Product and integrations live in the buyer's stack; thread latency on technical and compliance questions is tracked.
Technical win. Criteria met and documented — proof happened, not rep narrative.
Commercial commit. Pricing, executive alignment, and timing — judgment separate from proof.
Slip between gates is a leading indicator. A green CRM stage without gate clearance is lagging.
RevOps and GTM architects who instrument evaluation this way see risk earlier. They stop confusing top-of-funnel motion with down-funnel progress.
What good looks like: the evaluation loop
Winning teams treat evaluation as a system, not a heroics phase.
Execution through proof requires the same loop described in AI-native GTM— applied here at the decision surface, not repeated in full:
Whiteboard · evaluation loop
Awareness across threads, usage, stakeholders, and POC status — one picture of the deal.
Execution on repetitive eval work: criteria, SE prep, technical follow-through — with policy and context.
Human judgment on pricing, executives, competition, and timing — capacity freed from integration labor.
“AI-native” cannot mean AI-SDR alone when proof is the funnel.
A checklist for builders and buyers
When you evaluate GTM systems in a POC-first world, ask:
- Does context persist from first touch through pilot — or reset at every handoff?
- Can the system execute evaluation work — criteria, SE prep, thread follow-through — or only generate top-of-funnel volume?
- Do metrics and forecasting reflect proof gates — or lagging funnel vanity?
- Does the vendor's own motion prove value in your environment — or only in slides?
If most answers are no, you are buying automation — not infrastructure for how enterprise revenue actually converts.
Bruce is built for evaluation throughput on one context graph — including Solution Engineering Copilot for discovery, demo, and POC criteria. Platform overview.
Further reading
What is an AI-native GTM motion? — awareness, automation, and empowerment as the platform frame.
Customer stories — motion, challenge, and proof in operators' words.
Book a conversation to walk through evaluation execution on a live deal context.
Field Notes
Continue
Meeting Booked. Now the Real Work Begins.
Jordan Greene replied on email six. Bruce runs Harbor Goods from Calendar discovery through Sheets close — Google Workspace, not a parallel stack.
What Is an AI-Native GTM Motion?
AI-native GTM is not just automation. It is unified awareness, policy-driven execution, and seller empowerment — awareness + execution + human leverage.
GTM Build vs Buy
Teams building GTM tooling underestimate maintenance — agents, guardrails, eval, observability. Build where product is unique. Adopt where GTM is standardizing.