RevOps doesn't create growth. It decides whether you survive it.
I joined Plum, an InsurTech, at around $11M in ARR as its founding head of revenue operations. There was no RevOps function, no annual revenue plan, and no system that could tell you what a customer was worth. There was also a hole in the floor: 8% of new customers churned during onboarding: one in twelve left before they had ever received any value, and the faster the company sold, the more it lost. Over the next fifteen months the company grew to $55M ARR. I did not create that growth; the product and the market did. What I built was the revenue infrastructure that let the company absorb it, starting with the sales-to-onboarding handover, which took onboarding churn from 8% to 2%.
The problem
One in twelve of Plum's new customers left before onboarding finished. Eight percent onboarding churn: customers who had signed, paid, and then left before they'd received anything at all.
A company growing five times over doesn't have a churn problem that stays the same size. It has one that scales with the thing it's proudest of. The faster Plum sold, the more customers it fed into a handover that dropped one in twelve of them; every incremental sales hire made the leak bigger. And there was almost no infrastructure to catch it: no RevOps function, no annual revenue plan, no customer 360. Nobody could tell you what a customer was worth, when they renewed, or whether they were in trouble.
A company about to grow five times had no revenue infrastructure at all. Everything manual at $11M was going to be impossible at $50M.
A leak that scaled with growth. Eight percent of new customers left during onboarding: before a renewal conversation, before a competitor, before any value at all. And the faster the company sold, the more it lost. Growth was, quite literally, making it worse.
A target with no arithmetic. No annual revenue plan: no ICP definition, no segmentation, no territory model, no product-level targets. A number the company wanted to hit, and nothing underneath it.
Nobody knew what a customer was worth. No customer 360, so nobody could say what a customer was worth, when they were due to renew, or whether they were in trouble. Renewals happened when someone remembered.
Built for $11M, about to hit $50M. Quoting ran through insurer portals by hand. There was no compensation plan worth the name. A go-to-market org on its way to 250 people had no system to work inside.
The diagnosis
The company called it churn. It was a handover.
Eight percent of new customers were leaving during onboarding, and the instinct (the universal instinct) was to treat it as a retention problem and send it to customer success. It wasn't a retention problem. It was a wall. Sales closed the deal and threw it over; onboarding picked up whatever landed. The customers who fell in the gap weren't unhappy. They were unattended, and nobody owned the gap because it wasn't on anyone's org chart.
Onboarding churn is a handover problem, not a customer problem
The most common silent leak I've seen in scaling companies, and it's almost never diagnosed correctly, because both teams either side of the wall are performing well against their own metrics. If you're losing people before they get value, don't send it to customer success. Go and look at the wall between the team that sold it and the team that delivers it.
Build for the company you'll be in eighteen months
At $11M the correct-looking decision is to build cheap and light. It's also the expensive one: build for the company you are and you'll rebuild at $25M and again at $40M, each rebuild costing a quarter of momentum you can't afford while growing 5x. The systems that went in were sized for a company several times bigger: the cheapest thing available, paid for early.
At 5x, the constraint moves every quarter
What breaks at $11M isn't what breaks at $30M. Early on it was the handover; later, quoting, then compensation, then the fact that 250 people needed one definition of a qualified opportunity. The job isn't to build a system. It's to see which thing is about to break next, and get there first.
What I built
A revenue plan, where there had been a target
The company's first annual revenue plan: ICP definition, segmentation, territories, product-level targets, and the arithmetic connecting all of them to the number. It delivered 120% of target.
The handover that was leaking customers
The sales-to-onboarding process rebuilt end to end: ownership, triggers, milestones, and accountability across the wall rather than either side of it. Onboarding churn fell from 8% to 2%.
A customer 360, and a renewal motion on top of it
Cohorted retention analysis, so the company could finally see what a customer was worth and when they were at risk. Renewals moved from 'when someone remembered' to a standing motion initiated 25 days before expiry. Annual churn settled under 12%.
A quoting system wired into the insurers
Salesforce CPQ integrated directly with insurer portals, including pricing intelligence that automatically fetches the lowest available quote, replacing a manual, portal-by-portal process that did not scale past the team doing it.
The revenue systems for a 250-person GTM org
A migration to Salesforce across sales, onboarding and customer success; HubSpot reconfigured for channels, attribution and routing; Mixpanel piped into HubSpot for product-qualified-lead signals; Drivetrain for planning; a ~700,000-account B2B insurance database, 80% carrying renewal dates; and the company's first performance-linked incentive plan.
And the function itself
Eight people, recruited and built from zero, supporting a go-to-market organisation of more than 250, plus the executive cadence: forecasting, MBRs, QBRs and board revenue reporting, run on the founder-CEO's behalf.
The outcome
Fifteen months. The company grew from roughly $11M to $55M ARR over that period, driven by product, market and 250 people in go-to-market, not by RevOps. What RevOps built was the infrastructure that let it hold on to the growth.
We were growing fast enough that everything was about to break, and Shashank was the first person who could tell me which thing, and when. He built it all for a company much bigger than the one we were, which is why we never had to stop and rebuild.
What I didn't do, and won't claim
I did not grow this company five times over. The product did, the market did, and 250 people in go-to-market did. Revenue operations does not create growth. What it determines is whether a company that's growing can hold on to what it wins, price it correctly, forecast it honestly, and pay the people who sold it, or whether the whole thing shakes itself apart at exactly the moment it's working. I'm claiming the second job, not the first.
The ~$4M of expansion revenue is not mine. I built the infrastructure that made those new products sellable and measurable. Someone else led the initiative. That distinction matters, and I won't blur it.
And I don't have a forecast-accuracy number for you. We built the forecasting and ran the board cadence on it. I can't tell you what accuracy it landed at, because I don't remember, and I'm not going to estimate a number to fill a gap in a case study.
Why this matters for you
This is your problem if:
You have just raised, and the plan is to triple in eighteen months
New customers are churning during onboarding, and you've been calling it churn
Your sales team hands off to delivery or customer success over a wall, and nobody owns the wall
You're running on the tooling you chose at $5M and you can feel it straining
You have a revenue target and no revenue plan, and you've started to notice the difference
You're deciding whether to hire a RevOps leader now or wait until things settle down
Onboarding churn is a handover problem, not a customer problem
If you're losing people before they ever get value, don't send it to customer success. Go and look at the wall between the team that sold it and the team that delivers it. Nobody owns that gap, because it's not on anyone's org chart, and both teams either side of it are hitting their numbers.
Build for the company you'll be in eighteen months
Building light and cheap at $11M feels like discipline; it's the most expensive option available, because you'll rebuild at $25M and again at $40M, and each rebuild costs a quarter of momentum you won't have to spare.
Don't hire a RevOps leader expecting them to make the number bigger
They won't. What they'll do is make sure that when the number does get bigger (for reasons that have nothing to do with them), the company is still standing underneath it.