The Only SaaS Metric That Survives When the Market Tightens
There is a moment in the lifecycle of any subscription software company when the metrics dashboard begins to look like a symptom rather than a tool. Daily active users, feature open rates, session time, module adoption, quarterly NPS. Everything is measured. Everything is presented in green. And yet, contracts are not being renewed.
That disconnect between activity and value is not new, but neither is it being corrected at the speed that market pressure demands. At a time when enterprise buyers are applying real scrutiny to every line of the technology budget, the question that many software vendors avoid asking themselves honestly is whether their customers are actually making money thanks to their platform, or whether they are simply using a tool that no one has had the time to cancel.
David Pickard, global director of Phonexa, recently published in Forbes Technology Council a thesis that summarises that disconnect with a self-evaluation question: if you were your own customer, would you use your software? The provocation is effective because the diagnosis that supports it is precise. The SaaS sector has built a culture of activity metrics that works well for internal roadmaps and investor presentations, but that has an increasingly weak correlation with the customer's actual economic experience.
When the Success Metric Is Internal
The problem is not measurement itself. It is what is chosen to measure and why.
Vanity metrics — daily actives, login volume, number of features adopted — have a legitimate function in the early stages of a product: they indicate whether the software is being used, whether onboarding is working, whether there is sufficient engagement to justify a round of feedback. The mistake occurs when those metrics migrate to the centre of the executive dashboard without having made the transition toward metrics of economic outcome.
A customer can generate a high usage pattern while simultaneously generating less money than before implementing the platform. The software consumes configuration time, requires integrations that their team does not master, and produces reports that nobody knows how to interpret correctly. The retention rate appears healthy for months because cancellation processes are slow and organisational inertia is powerful. But the contract is not renewed, and when one has to explain why, the answer is not to be found in the internal metrics dashboard.
This has a less obvious consequence: product teams begin to optimise for what is being measured. If the success indicator is feature adoption, features are added. If it is session time, flows are designed that retain the user inside the platform even when it is unnecessary. If it is NPS, perception is managed at the moment of the survey. Optimising toward activity metrics produces more complex products and customers with lower real returns. Not out of bad intention, but because the architecture of incentives points in a different direction from what the customer actually needs.
Pickard's argument about what he calls "vanity development" — building features that are not driven by customer needs, but by market trends, competitive pressure, or internal technological affinity — describes exactly that mechanism. The result is a platform that accumulates layers of complexity without any of them demonstrably moving the customer's revenue, efficiency, or cost reduction.
The Incentive Structure That Nobody Audits
Behind the proliferation of vanity metrics there is no naivety. There is an incentive structure that produces them systematically and that operates on at least three simultaneous levels.
The first is the funding cycle. Capital rounds at early and middle stages of a SaaS company have historically been tied to user growth metrics, monthly recurring revenue growth rates, and market expansion projections. Those metrics are capturable through activity data. The customer's economic return, by contrast, is slower to measure, requires access to data the customer does not always share, and does not appear cleanly in a Series B pitch deck. The consequence is predictable: teams optimise for the indicators that move the price of the next round, not necessarily for those that reflect delivered value.
The second level is the structure of Customer Success teams. For years, this function was designed as technical-relational support: solving implementation problems, responding to tickets, managing onboarding. In that model, the team's performance indicator was customer satisfaction and retention rate, not customer revenue expansion. That creates a team well positioned to detect friction but without the tools or mandate to quantify the financial impact of the platform on the customer's business.
The third level — and the most resistant to change — is the distance between the product team and the customer who operates day-to-day. Roadmap decisions are fed by user interviews, in-product behavioural analysis, and competitive benchmarking. They are rarely fed by the customer's financial statements, their operational efficiency metrics, or an honest evaluation of whether the platform reduced their cost per transaction or increased their conversion rate. That distance produces features that solve perceived problems but not economic ones.
Pickard points to what he describes as "vanillifying" requirements as a solution to this: when a customer requests a specific feature, the product team must generalise that request so that it scales across other segments and is sufficiently flexible for future use cases. The principle is correct, but there is a prerequisite that the argument does not directly resolve: in order to know whether a generalised feature creates value, it is necessary to have an operational definition of what value means for the customer. Without that definition, generalisation can produce complexity in the same way that copying competitors does.
The Customer's Return as a Financial Indicator of the Vendor's Health
There is a structural reason why the customer's return ends up being the best leading indicator of the financial health of the SaaS vendor, and it is worth making it explicit.
Subscription business models depend on two variables: the retention of existing revenue and expansion within the current customer base. Net Revenue Retention (NRR), one of the most closely watched indicators in the industry, measures precisely that: whether revenue from active customers grows, holds steady, or contracts after accounting for cancellations, downgrades, and expansions. An NRR above 100% indicates that the existing customer base is expanding its usage, which is typically the most efficient growth indicator because it avoids the acquisition cost of new customers.
That number cannot be sustained without demonstrable economic return for the customer. A customer who is not generating incremental revenue, saving costs, or gaining operational efficiency through the platform has no economic reason to expand their contract. They may renew out of inertia for one or two cycles, but the logic of expansion — which is what causes NRR to exceed the 100% threshold — requires that the customer has connected the software with a positive business outcome.
The causal chain is therefore precise: customer return → contract retention → spending expansion → healthy NRR → vendor valuation. Measuring only the intermediate links in that chain — retention and expansion — without auditing the initial link produces an illusion of solidity that the market corrects in the next renewal cycle.
Pickard points in the same direction when he notes that in usage-based revenue models, the growth of the customer's spending on the platform should be a symptom of that customer generating more revenue through the system. If the customer doubles their spending on the platform, their profit should grow by a larger multiple. If that does not happen, the model is not delivering value: it is capturing a growing portion of revenue that is not itself growing.
The managed services that the article mentions function as an accelerator of that cycle when they are well designed: they reduce the time between implementation and demonstrable return, which in turn accelerates the customer's decision to expand usage. The risk — which the article does not address explicitly but which is real — is that managed services become a patch for platforms that are not sufficiently intuitive or that require too much intervention to produce results. In that case, the services layer indefinitely subsidises a complexity that the product should have eliminated.
What Precedes the Visible Number
The argument for centring everything on customer return is correct in its diagnosis, but its implementation faces a prerequisite that few SaaS companies have resolved: how to measure that return in a systematic and non-anecdotal way.
Customer success stories exist in every software company. They are the fuel of sales presentations and testimonials pages. The problem is that a success story narrated after the fact has commercial value but little operational utility. It does not say what produced the return, under what conditions it could be replicated, or what variables made it possible in that customer and not in others with similar profiles.
Building a customer return measurement methodology that is comparable across segments, that updates in real time, and that feeds product and Customer Success decisions requires access to data that the customer often does not share by default. It requires that the platform be instrumented to capture not only behaviour within the system, but its downstream effects on the customer's business indicators. And it requires that the product and Customer Success teams speak the same economic language as the executive buyers who evaluate the renewal.
The friction that nobody is accounting for in the debate about vanity metrics is precisely this: the problem is not that SaaS companies do not want to measure customer return. It is that the data infrastructure, the information exchange agreements with customers, and the analytical capacity to convert that data into roadmap signals are not built out in the majority of mid-sized vendors. Changing the executive dashboard is simple. Changing the information architecture that feeds that dashboard is the work that takes years.
That does not invalidate Pickard's thesis. It reinforces it. But it places the real problem where it belongs: not in the choice of what to measure, but in the capacity to measure what matters in a systematic way. The SaaS companies that manage to build that capacity first — including the agreements with customers that enable visibility into their results — will hold an advantage that cannot be replicated simply by renaming an indicator on the quarterly report.
The metrics dashboard does not change if the platform is not generating demonstrable return. But the architecture that produces that dashboard — and the teams capable of interpreting it honestly — is the investment that separates the vendors who survive budget renegotiations from those who do not make it to the next renewal cycle.
