Why churn is a product problem before it's a support problem
Most SaaS teams treat churn as a lagging indicator to report on rather than a signal to act on. By the time a customer cancels, the decision was usually made weeks earlier, often within the first fortnight of onboarding when they failed to reach the point where the product proved its value. The cancellation is the paperwork; the real event happened much earlier and left no ticket, no complaint, and no trace in your support queue.
At Wocal, our churn didn't come from venues that hated the product. It came from venues that never got fully set up — staff weren't trained, the menu wasn't fully loaded, and by week three it was easier to go back to the old system than fix the gaps. The fix wasn't a feature. It was a mandatory setup checklist and a human check-in before day ten, which cut early churn by more than any feature we shipped that year.
This is the pattern I look for first with any SaaS client: pull your churned accounts from the last two quarters and map what they did in their first fourteen days versus what your retained accounts did. The gap is usually obvious once you look, and it's almost never a missing feature.
Pricing tiers built on cost, not value
Most SaaS pricing pages are built the way the product was built — bottom-up, feature by feature, with tiers that reflect internal engineering milestones rather than anything a customer actually cares about. 'Starter, Pro, Enterprise' tells the customer nothing about which one they need, so they either under-buy and churn when they hit a wall, or over-buy and churn when the CFO notices the invoice.
The fix is to price against a value metric the customer already tracks — venues served, seats used, transactions processed, whatever correlates with the value they're getting, not with what was cheapest to gate. When we restructured Wocal's pricing around venue count and transaction volume rather than a flat feature-tier model, expansion revenue started happening on its own: growing venues moved up tiers naturally instead of needing a renegotiation.
The hard part is never the new pricing model. It's migrating existing customers onto it without a mass cancellation. That takes a grandfathering plan, a clear story about what's changing and why, and enough runway between announcement and enforcement that nobody feels ambushed. Get this sequencing wrong and you'll generate more churn than the old broken pricing ever did.
Expansion revenue is a product feature, not a sales tactic
Net revenue retention above 110% almost always has a product mechanism behind it, not just a good sales team. Usage limits that create a natural upgrade moment. An add-on module surfaced exactly when a customer's workflow needs it. Seats that expand as teams grow. These moments need to be designed into the product, because sales teams can only push expansion on the accounts they happen to be watching, and most accounts aren't being watched closely enough.
The multi-tenant question sits underneath all of this. If your architecture treats every customer identically, you can't offer the tiered permissions, custom roles or usage-based limits that expansion revenue depends on. This is usually the real reason a SaaS company plateaus at a certain size — not a sales problem, but an architecture decision made when there were 20 customers that nobody revisited at 300.
Enterprise readiness deserves the same honesty. SSO, audit logs, granular permissions and data residency all cost real engineering time, and building all of them speculatively is how roadmaps die. The right approach is to build the one or two that are actually blocking deals you can name, and to say no, clearly, to everything else until there's a signed contract waiting on it.
What I actually do differently from a generalist
- —I read your churn and NRR numbers before the first call and come with a hypothesis, not a discovery workshop.
- —I price the redesign work against a value metric customers already understand, never against feature count.
- —I've personally made the call on which enterprise features to build first with real revenue on the line, not in a workshop.
- —I treat multi-tenant architecture as a product decision with commercial consequences, not purely an engineering one.
- —I've lived through migrating an existing customer base onto new pricing without losing the base — it's a specific, learnable skill, not a leap of faith.