Why SaaS CEOs Now Have to Innovate Twice

When I rank what actually occupies my thinking:

"How do we continuously grow our business? And that breaks down into a couple of things, particularly as we're a B2B SaaS company."

The first is new business. The second — and in recent years the heavier one — is growing the existing base through net revenue retention and expansion revenue, a topic I've covered in more depth in Expansion Revenue: Key Metrics and Growth Strategies. For a company with significant enterprise customers, NRR often matters more than new logos — and if you want the metrics behind this argument laid out properly, Monetization KPIs Explained: An Executive Guide is the companion piece.

There's a longer list, of course. Staffing, finance, operations. But these two sit at the top, and AI has changed both.

Here's where I think the industry under-describes the problem.

Everyone understands that AI created a product mandate. You need AI capability, partly because it's genuinely useful and partly because buyers now expect it — a shift I've traced in more detail in How AI Is Disrupting Traditional Software Licensing Models. Fine — that's a roadmap conversation.

What gets less attention is that AI simultaneously created a pricing mandate. Buyers trained on AI products increasingly want to pay by consumption rather than by seat or feature tier — a market shift covered well in Why Usage-Based Billing Is Taking Over SaaS. So the business model has to change too.

"I have to innovate as a CEO and now on top of that, I have to innovate in my pricing and packaging as well."

Two mandates. Now count the teams available to deliver them. I've written up the architectural fix to that pricing half in detail — see Software Packaging & Pricing as Configuration, Not Code — because it's the piece of this I get asked about most. What I want to get into here is the leadership problem sitting underneath it: two mandates, one engineering team, and a CEO who has to decide which one waits.

For most companies, both mandates land on the same group of engineers.

"The engineering team is at the center of your business model."

That's the structural problem. If pricing logic is embedded in your product code, then changing how you charge is an engineering project — competing directly with building the AI features that same team is under pressure to ship.

So the CEO gets a genuinely unpleasant choice. Ship the features and postpone the pricing change, or fix pricing and fall behind on product. Neither is acceptable, and doing both usually means doing both badly.

Meanwhile the clock has compressed:

"We've now got months to do a change that took years and years and years."

The move from perpetual licensing to subscription took roughly a decade. The move to usage-based and hybrid models is being asked of us in months, while we're also rebuilding the product.

I should be straightforward about my own position, because it's the reason I have a view on this at all.

We face the identical market pressure. We've launched new products, added AI capability, and had to rethink how we charge for it. The difference is architectural:

"We use our own monetization system on our own products, which means that we've got some middleware in place where we don't need to talk to engineering. The product team can go in and make changes to pricing and packaging. They could do that over a weekend and they can launch it the following week."

That's the whole difference. Not better strategy or smarter people — just a structure where a pricing decision isn't an engineering decision. Our product team changes pricing without opening a ticket, because pricing sits in what we now call the Nalpeiron Growth Platform — specifically the Zenmeter layer — rather than in the codebase itself.

I'm not claiming this is unique to us. I'm claiming that whether pricing is coupled to engineering is now one of the more consequential architectural decisions a software CEO inherits, and most inherited it by accident years ago.

It's worth making that difference concrete, because "a weekend instead of a quarter" can sound like marketing language until you've lived through both.

Before we decoupled pricing from the codebase, a new tier or a metering change followed the same path as any other feature: it went into the backlog, got prioritised against everything else competing for that sprint, and typically took six to ten weeks from "we should do this" to something a customer could actually buy — assuming it didn't get bumped by a release-blocking bug or a bigger commitment already in flight. Multiply that by however many pricing experiments a genuinely usage-based market now demands, and it's obvious why most companies run one pricing change a year instead of four or five.

After, the same change is a configuration exercise. Someone on the product or revenue team defines the new tier, the metering rules, and the entitlement logic directly — the kind of range a platform like this can express is laid out in Pricing Options for Modern SaaS & AI — tests it against a staging account, and ships it, typically in days, sometimes literally over a weekend, exactly as the quote above describes. No pull request, no release train, no engineer pulled off the AI roadmap to review it.

The engineering time recovered isn't only the hours that would have gone into building the pricing change. It's the hours that were never spent context-switching into and out of pricing work in the first place, and the roadmap slots that stayed available for the product mandate instead of being quietly eaten by the pricing one. That's the real prize: not a faster pricing change, but an engineering team that stops being the shared bottleneck for two competing mandates and gets to focus on one.

If pricing and product are still fighting for the same sprint, the conversation with your CTO is worth having explicitly, rather than letting it resolve itself by whichever deadline is loudest that week.

Start with the constraint, not the wish list. Ask directly: if we had to ship a new consumption tier next month, what would it displace? A good CTO can answer that in a sentence — a named feature, a named release, a named customer commitment. If the answer is vague, that's a sign pricing work has been absorbing engineering time invisibly, in small increments, for a long time.

Then separate the two mandates on the roadmap rather than blending them. Product and AI features go through the normal prioritisation process, weighed against customer demand and competitive pressure. Pricing and packaging changes get evaluated on a different axis entirely — commercial urgency — because a missed pricing window costs revenue every month it stays missed, in a way a slightly-later feature usually doesn't.

The honest version of this conversation usually ends one of two ways. Either the company commits real, ongoing engineering capacity to pricing as a permanent line item — a legitimate answer, if it's under-resourced today — or it moves pricing off engineering's plate entirely, onto a layer the product or revenue team can operate without a ticket. I know which one I'd choose, but the point isn't to arrive at my answer. It's to make the trade-off visible enough that it becomes a decision, not a default.

The other half of growth gets misdiagnosed just as often — we've gone deep on the metrics themselves in SaaS Usage Analysis: Net Revenue Retention, so here I want to focus on the diagnosis rather than the formula.

NRR is usually treated as a relationship problem — hire good CSMs, run good reviews, build rapport. Relationships matter. But CS teams can't act on what they can't see.

"How does that CS team know what to do? How do they know when to grow an account? How do they know how to retain an account, prevent churn? That's all about data."

The specific questions a CS rep needs answered are concrete. Is this customer actually using the product? Are individual users engaging more or less over time? Have they activated the features that create the value they bought? Are they approaching a seat limit — which is an expansion signal? Are they not using something, which might mean a different product fits better?

Without that, teams default to the calendar: a quarterly review, a generic email, and a renewal conversation that starts too late.

"They're not waiting for the QBR and hoping for the best. They're not sending generic emails."

Every account you save is worth roughly what a new one is worth, and costs far less to keep. That makes visibility a growth investment, not a support cost — which is precisely the gap a product like Zengain exists to close, surfacing exactly those account- and user-level signals so CS teams stop guessing.

Since AI created this squeeze, it's fair to ask where it relieves it.

Our position is deliberate: use AI to remove work people dislike and shouldn't be doing, not to replace the people.

"We use AI not to replace the sales team, but to get rid of some of the busy work the sales team don't like doing."

Research, data gathering, scheduling, analysis — that work is real, necessary, and a poor use of a skilled rep's day. Automate it and you get focused humans with better information, which is what actually grows accounts. I made this argument at greater length in The AI Sales Automation Paradox: automation should compress the gap between a rep and the answer, not compress the rep out of the loop.

I'd apply the same test to the product mandate. AI that removes drudgery gives you capacity. AI adopted because it's expected gives you a feature and a maintenance burden. Only one of those helps with the squeeze.

Three things.

Find out whether pricing is coupled to engineering. Ask what it would take to launch a consumption tier next month. If the answer involves a release cycle, that's the constraint on your commercial strategy — and it will bind harder every quarter.

Treat NRR as instrumentation before headcount. More CSMs working blind won't outperform fewer with good signals. Ask what your CS team can actually see at account and user level.

Be honest about engineering capacity. Two mandates, one team, no prioritisation is a plan to underdeliver on both. Either add capacity, or remove one mandate from engineering's plate — and pricing is the one that can be removed.

Boards are generally good at evaluating a resourcing decision and bad at evaluating a technology preference, so frame it as the former.

Don't bring the board a request to fix your pricing architecture. Bring them the trade-off: engineering capacity is fixed in the near term, two initiatives are competing for it, and the company is currently defaulting to whichever one shouts loudest that quarter rather than choosing deliberately. That's a resourcing risk, and boards exist partly to catch resourcing risk before it compounds.

Quantify what the status quo is costing, even roughly. How many pricing changes has the company actually shipped in the last 12 months, versus how many the market arguably demanded? How much engineering time went to pricing work that could have gone to the AI roadmap instead — and what's the revenue cost of the AI features that slipped as a result? Boards respond to that kind of comparison far more readily than to an abstract argument about technical debt.

Then present the choice, not just the problem: fund additional engineering capacity to serve both mandates properly, or remove one mandate from engineering's plate by moving pricing onto a platform the commercial team can operate directly. Either is a legitimate board-level decision. What isn't legitimate — and what most boards will back you on once they see it clearly — is continuing to let the two mandates fight it out informally, sprint by sprint, with no one actually deciding.

The job changed. It's no longer enough to build a good product and sell it well; you now have to keep changing how you charge for it, at a pace the industry has never sustained before.

Companies that treat pricing as configuration will run experiments while their competitors file tickets. Over ten months, that gap compounds into market share.

The CEO's job is to notice which of those two companies they're running — while there's still time to change the answer.