Ready to build your own Founder-Led Growth engine? Book a Strategy Call
Frontlines.io | Where B2B Founders Talk GTM.
Strategic Communications Advisory For Visionary Founders
Before writing a line of code, Reevo mapped every GTM persona — SDRs, AEs, RevOps, marketers, CS — as nodes, with their jobs-to-be-done (prospecting, customer engagement, forecasting, reporting) as edges between them. The goal: look at the complete MECE graph and identify where rerouting edges between nodes makes the whole system more efficient. This is a categorically different exercise than surveying customers for pain points — it forces you to see the system, not just the symptoms, and reveals which tools are genuinely load-bearing versus which are sacred cows you can kill.
Reevo's CTO Clement built a segmentation framework that maps three verbs — discover, build, sell — onto each market segment. For the core ICP bracket, the team discovers use cases maniacally, builds toward them, and sells when the product is ready. For segments below that bracket, they opportunistically sell and fast-follow with a PLG motion. For segments above, they opportunistically discover use cases but refuse to distort the product roadmap. Most founders conflate these modes — selling up-market while pretending to build for mid-market, or building for enterprise while claiming SMB focus. Separating the verbs by segment gives the whole company a shared language for saying no without losing sight of where the market is going.
Reevo's framework is explicit: trust equals consistency over time, and you cannot compress time. Rather than burning runway on enterprise deals that require years of track record to close, Reevo went after what the host called "the next rocket ship companies" — growing with them so that by the time they scale, they've scaled on Reevo. The insight isn't just about ICP selection; it's about recognizing that your go-to-market motion has to match what trust actually requires at each market tier.
Most companies say they're building an all-in-one platform while starting with a single point solution and hoping to expand later. Reevo's view: if there's a gap between what you say you're building and how you're actually investing, the market will eventually expose it. Reevo launched with a founding team of 14 — unusual by any standard — because the breadth of surface area they're building requires it. The team you build in the first 10 to 15 employees is the DNA of the company. You're not just hiring for today's problem; you're establishing the mutation rate.
Reevo's CTO coined the concept of "verifiability" as the design constraint governing every AI deployment across the GTM stack. The framing reframes the hallucination debate into something actionable: instead of asking whether your AI is accurate, ask what level of accuracy a given job-to-be-done actually requires — and build to that threshold. A QBR forecast a CRO presents to a board has near-zero tolerance for error. A high-volume outbound sequence has more. These are not the same build problem and shouldn't be treated as one. Reevo's investment in data infrastructure — data lake, graph, vector store, evals, inference — is all in service of being able to meet these thresholds per function rather than shipping a general-purpose AI layer and hoping it's good enough.
When asked if Reevo is saying no to customers, David's answer was direct: proactive disqualification is an active practice, not a fallback. Specifically, Reevo avoids selling to entrenched CROs at large companies — because those buyers have spent years seeing CRM in a particular way and will try to bend the product to match their mental model rather than adopting a new one. For a company trying to establish a new way of working, selling to buyers who can't unlearn the old one is a roadmap distraction disguised as revenue.
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.
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.
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.
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.
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.”
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.