The $80 Million Bet That the GTM Stack Is Broken — and One Founder's Framework for Rebuilding It
Most enterprise software categories get disrupted the same way: a startup finds a narrow wedge, nails one workflow better than the incumbent, and slowly expands outward. It's the playbook that built HubSpot, Salesloft, and a dozen others.
David is deliberately not running that playbook.
In a recent episode of BUILDERS, David Zhu, the Co-Founder and CEO of Reevo laid out a thesis that starts from a different premise: the problem with the modern GTM stack isn't any individual tool — it's the stack itself. Solving it requires something most founders strategically avoid: committing to breadth before proving depth.
Reevo raised $80 million, incubated with Vinod Khosla at Khosla Ventures, and launched with a founding team of 14 to go after the full revenue operating system — marketing, sales, success, and support — from day one. That's not a land-and-expand motion. It's a structural argument.
The number that became the product brief
Before Reevo, David spent two years running go-to-market at a previous company. As a technologist dropped into a GTM role, he experienced firsthand what the data eventually confirmed.
"Sellers are only spending 30% of the time selling and 70% of the time not selling," he said, "wrangling tools and stuff. It's like, that kind of sucks, right?"
That ratio became the entire product brief. Not a feature request list. A single number that makes the case for a unified platform more forcefully than any market map could.
The GTM stack hadn't failed sellers through bad intentions. It failed them through accumulation. Every point solution that solved one problem added integration overhead, API fidelity loss, and another workflow that required a human to bridge the gap between systems. The Frankenstack wasn't designed — it evolved. And what it evolved into costs revenue teams more than it saves them.
Map the system before you touch the wedge
Most founders pick a product wedge by finding the loudest customer pain. Reevo did something structurally different before writing a line of code.
They mapped every GTM persona — SDRs, AEs, RevOps, marketers, CS — as nodes, with jobs-to-be-done as the edges connecting them. Prospecting, customer engagement, forecasting, reporting — each one an edge between nodes. Then they looked at the full MECE graph and asked: where can you reroute edges between nodes to make the entire system more efficient?
Pain points and leverage points are not the same thing. A seller who hates manual data entry has a pain point. A system where closing a deal triggers zero automated downstream actions across marketing, CS, and finance has a leverage point. One produces a feature. The other produces a platform architecture.
The framework David applies before any product decision is what he calls "learn, love, advise." Learn the space deeply. Love — meaning genuinely respect the rationale for why the status quo exists, not just what's broken about it — before attempting to disrupt it. Only then apply first-principles thinking to decompose what got us here and inform what comes next. Skipping the "love" step is how founders build against a straw man version of the problem.
Why Reevo is saying no to enterprise — for now
With $80 million and a 14-person founding team, Reevo could credibly pursue enterprise accounts. They're choosing not to — and the reasoning is worth understanding precisely.
David's formula: trust equals consistency over time, and you cannot compress time. Enterprise deals require a track record. A company that is a year and eight months old cannot manufacture one. So instead of burning runway on deals that need years of proof to close, Reevo targets breakout-stage companies — growing with them so that by the time they scale, they've scaled on Reevo.
His CTO Clement built a three-verb ICP framework to operationalize this: discover, build, sell. For the core target segment, the team maniacally discovers use cases, builds toward them, and sells when the product is ready. For segments below that bracket, they opportunistically sell and fast-follow with PLG. For segments above — enterprise — they opportunistically learn use cases but explicitly refuse to distort the product roadmap to build for them. Every person on the team has a shared language for saying no that doesn't require a founder decision every time.
The discipline this creates is harder than it sounds. When a large company comes with budget and urgency, the reflex is to take the meeting seriously. David's counterpoint: selling to an entrenched CRO at a 400-person company means selling to someone who has spent years seeing the GTM stack one way. They'll bend the product to match their mental model rather than adopt a new one. For a company trying to establish a new way of working, that customer isn't a win — they're a roadmap tax.
Why a compound thesis requires compound proof
There's a pattern David flagged in companies that claim to be building all-in-one platforms: their actions don't match the intent. They announce a broad vision, quietly start with a single point solution, and hope to expand later. The gap eventually becomes visible — to customers, to the team, and to the market.
Reevo's answer was to make team composition itself a proof point from day one. "We came out the gates with a founding team of 14," David said, "which is very different, it's built different. Most companies don't do that." The reason: "it's such a breadth of surface area." You cannot credibly claim to be building across the full GTM stack if your founding team is sized for a point solution.
The logic extends to how Reevo manages culture at scale. "The first 10, 15 employees is basically the DNA of the company," David said. Scale too fast without protecting that DNA and mutations compound. His operating rule when something feels wrong: "When there's doubt, there's no doubt."
The infrastructure question every AI GTM vendor is avoiding
As AI tools proliferate across the revenue stack, Reevo's CTO introduced a concept that cuts through the hallucination debate with more precision: verifiability.
The question isn't whether your AI is accurate. It's what level of accuracy a specific job-to-be-done actually requires — and whether your underlying infrastructure can reliably meet that threshold. A QBR forecast a CRO presents to a board has near-zero tolerance for error. High-volume outbound sequencing has more. These are not the same build problem, and treating them as one is how you ship AI that gets pilots but never earns trust.
The infrastructure investment Reevo is making — across the data lake, graph layer, vector store, evals, and inference — exists entirely in service of being able to meet different verifiability thresholds per function. This is why David dismisses the agentic wrapper approach directly: tools that consume data streams from existing sources, process them, and feed outputs to frontier models lose fidelity at every integration handoff. "It'll get you enterprise pilots," he said. It won't get you a system revenue teams stake their board presentations on.
The bet Reevo is making is a long one. But as David put it — borrowing a principle from DoorDash — "dream big, bets are small." The dream is the unified revenue platform. The bets — which personas, which workflows, which segments, in what sequence — are where the discipline lives.