The Question Behind All the Other Questions
First I would just like to say that I’ve been writing this essay for about 4 years and still consider it a draft. Before you start reading know that it’s a long read…
Imagine a factory making stuffed toys. It employs 200 people, operates several production lines and supplies retailers across the country. Its management team has spent the past year modernising the operation, introducing automated cutting machines, improving assembly processes and installing systems to monitor production.
The results are impressive. The factory can now produce 30% more toys per hour, manufacturing defects have fallen by half, and the time required to switch between products has been substantially reduced. The operations director has a dashboard showing all of this in considerable detail.
At the next board meeting, the director presents these results with understandable satisfaction. The shareholders listen politely before one of them asks a rather awkward question.
“That’s excellent. What has it done for the business?”
The director explains that production costs are falling and the factory has additional capacity. The shareholders want to know whether revenue has increased, margins have improved or customers are buying more toys. Has the investment generated an acceptable return?
For a private equity investor, the question eventually becomes what those improvements have done to the value of the business. Enterprise Value, or EV, is one way of expressing that value. It reflects what the operating business is worth, rather than simply how much revenue it generates or how efficiently it runs.
Perhaps the factory has increased sales because it can now fulfil orders it previously turned away. Perhaps lower production costs have improved its margins. Alternatively, the additional capacity might be sitting idle because demand has not increased. All three outcomes are consistent with the improvements shown on the operational dashboard, but they have different financial consequences.
The operations director has demonstrated genuine improvements in productivity and quality, while the shareholders want to understand whether those improvements have made the business more valuable. Both are asking reasonable questions, but they measure success differently. The people working inside the factory talk about throughput, cycle times, defect rates and production capacity. The people running the company talk about revenue growth, operating profit, working capital and return on invested capital.
Both groups are describing the same business, but somewhere between the production line and the boardroom, the connection between those two sets of measures has become lost in translation.
Software engineering has much the same problem, and it is one that has increasingly interested me as my career has moved from engineering into business management and investment. Private equity provides a particularly useful perspective because it makes the relationship between operational improvement, financial performance and the value of a business unusually explicit, although other organisations will naturally have different objectives.
A project called Dracula
I recognise some of this in my own experience. Most of the projects I worked on had clear commercial reasons for existing, and many delivered benefits that were understood by the organisations commissioning them. What interests me, looking back, is the way I instinctively describe their success.
If someone asked me about my career in product engineering, I would probably begin by talking about delivering software into production, meeting difficult deadlines and building systems that worked reliably. Those were important achievements, and they remain legitimate measures of success. They were also the aspects of the work for which I was most directly accountable.
An early example comes from my time working with Egg, the pioneering internet bank. We worked on a project called Dracula, a memorable name derived from its focus on account opening. The objective was to improve the process through which customers applied for and opened credit card accounts.
Customers who wanted a credit card had to complete an application, provide information, undergo checks and wait for a decision. Every unnecessary step introduced friction, while every delay created an opportunity for a prospective customer to abandon the process.
Our job was to improve the technology supporting that journey, making applications easier to complete and allowing customers to be approved more quickly. The commercial logic was clear. Reducing friction should help more customers complete their applications, while faster decisions could allow approved customers to begin using their accounts sooner. The financial benefit would depend on the number and quality of additional accounts opened, how customers subsequently used them and the revenue those accounts generated.
I remember the project as a good example of engineering work directed towards a tangible commercial objective. What I cannot now recall is the precise financial return it ultimately generated. That does not mean the return was never measured, or that the project failed to deliver it. It illustrates the difference between the aspects of an initiative that an engineering leader is likely to remember and those that become important when examining the investment from a broader business perspective.
As my career developed, I became more involved in business management, private equity, acquisitions and investment decisions. I became interested not only in whether an initiative delivered what was promised, but also in how its benefits appeared in the company’s financial performance.
Looking back, what interests me is not whether the project had a commercial purpose, because it plainly did, but how differently I now think about the evidence of its success. That change in perspective reflects a broader divide between two disciplines that have spent decades developing increasingly sophisticated, but often quite different, ways of measuring performance.
Two disciplines, two different schools
Software engineering has been trying to understand productivity for almost as long as the discipline has existed. We began by counting lines of code, moved towards measuring functionality and process maturity, then embraced Agile and eventually DevOps, which shifted attention towards the performance of the delivery system as a whole.
Each generation of measures addressed weaknesses in the previous one. Counting code told us little about its usefulness, while counting completed features said relatively little about the efficiency or reliability of the system producing them.
Fifty years of measuring software
| Era | Approach | Key measures | Contribution and limitations |
|---|---|---|---|
| 1960s–1970s | Code productivity | Lines of Code (LOC), KLOC | Quantified code production but revealed little about usefulness, quality or maintainability. |
| 1979 onwards | Functional output | Function Points | Measured delivered functionality rather than code volume, without establishing its commercial value. |
| 1990s | Process maturity | CMM/CMMI, defect density | Improved attention to predictable processes and quality, but did not directly measure business performance. |
| 2000s | Agile and Scrum | Story points, velocity, burndown | Encouraged iterative delivery, feedback and adaptability, although more completed work did not necessarily mean more value. |
| 2010s | Lean and DevOps | Cycle time, lead time, recovery time | Improved delivery flow and operational performance, without directly establishing financial returns. |
| 2014–2018 | DORA | Deployment frequency, change lead time, change failure rate, time to restore service | Established measures of speed and stability and identified associations with organisational performance, but not project-level financial attribution. |
| 2020s | Expanded delivery metrics and AI-assisted development | DORA’s five software delivery metrics, operational reliability and emerging AI productivity measures | Improved visibility into delivery performance and automation, while the financial contribution of individual initiatives remains difficult to establish. |
The dates indicate when approaches emerged or gained prominence. Several overlap and remain in use. DORA’s delivery measures have evolved; operational reliability and AI productivity are related but distinct areas of measurement.
DORA’s 2018 research found an association between software delivery performance and organisational outcomes. Elite software delivery performers were 1.53 times more likely to meet or exceed their organisations’ performance goals, including measures such as profitability and market share. This is evidence of a relationship, although it does not establish the financial contribution of a particular engineering improvement.
Meanwhile, the people running and investing in software businesses were developing their own measures. They wanted to understand recurring revenue, customer acquisition costs, retention, profitability and the durability of future earnings.
Fifteen years of measuring SaaS business value
| Era | Investment focus | Key measures | Contribution and limitations |
|---|---|---|---|
| 2010–2015 | Recurring revenue and scale | ARR, MRR, growth, churn | Emphasised predictable subscription revenue, while the path to sustainable profitability could remain uncertain. |
| 2016–2021 | Growth and market leadership | Net new ARR, LTV:CAC, Rule of 40, revenue multiples | Encouraged attention to growth and customer economics, sometimes alongside substantial capital consumption. |
| 2022–2025 | Capital efficiency and profitability | EBITDA margin, free cash flow, burn multiple, NRR, GRR | Brought greater attention to profitability, retention and cash generation, although business quality remained difficult to separate from market conditions. |
| 2026: emerging priorities | Sustainable earnings and AI resilience | EBITDA, FCF, margins, Rule of 40, retention, AI exposure | Increasing scrutiny of earnings durability, competitive advantages and the implications of AI disruption, with no settled new valuation regime. |
These periods are broad interpretations of changing investor priorities, not distinct or universally accepted phases.
Both disciplines became more sophisticated, although they often approached performance from different directions. Engineering concentrated on the delivery system, while investors refined their understanding of growth, profitability, retention and the durability of future earnings. To understand why this distinction matters for software development, it helps to examine how those financial measures influence the value of a SaaS business.
For a PE-owned software company, Enterprise Value may be estimated by applying a valuation multiple to Annual Recurring Revenue (ARR) or EBITDA. Investors also use multiples of reported or forecast revenue, which should not be confused with ARR. Although the measures may be similar in a predominantly subscription-based business, they are not necessarily identical, and their valuation multiples are not directly interchangeable.
EV = ARR * ARR Multiple
or, for a business valued primarily on earnings:
EV = EBITDA * EBITDA Multiple
The choice depends on the company’s maturity, profitability, growth prospects and the market in which it operates. Investors will often consider several methods and examine the underlying cash flows and risks. A glossary of the financial measures used in this essay appears in the appendix.
An initiative that increases ARR or reduces recurring operating costs may increase the financial measure to which a multiple is applied. Improvements in retention, revenue predictability or earnings durability may also influence the multiple a buyer is prepared to pay. The effects are related, and care is needed not to count the same benefit twice.
Consider a SaaS business generating £20 million in ARR. At a valuation multiple of 3×, its implied EV would be £60 million. If the business increases ARR to £24 million while maintaining that multiple, its EV rises to £72 million. If investors also become willing to value the business at 5× ARR, the implied EV would be £120 million.
| Scenario | ARR | ARR multiple | Implied EV |
|---|---|---|---|
| Starting position | £20m | 3× | £60m |
| ARR growth only | £24m | 3× | £72m |
| Higher multiple only | £20m | 5× | £100m |
| ARR growth and higher multiple | £24m | 5× | £120m |
Valuation multiples cannot simply be engineered upwards by improving a handful of indicators. Buyers also consider market conditions, competitive threats, customer concentration, earnings quality and many other factors. Nevertheless, the example demonstrates why improvements in Gross Revenue Retention (GRR) or Net Revenue Retention (NRR) may have significance beyond the immediate revenue preserved. Strong retention can influence both revenue and investors’ confidence in the durability of future earnings.
In practice, most engineering initiatives will be easier to assess through their contribution to revenue, earnings, cash flow or risk reduction than through changes in the valuation multiple. The multiple reflects a wider assessment of the business and its prospects, making it particularly difficult to attribute changes to individual projects.
For managers participating in a Management Incentive Plan, the distinction can be consequential. Their eventual reward may depend on equity proceeds when the business is sold, after accounting for debt, financing arrangements, investor preferences and the terms of the scheme. EV is therefore not identical to shareholder returns, but understanding what drives it remains important.
An engineering leader might be delighted to report that deployment frequency has doubled and change lead time has fallen by 50%, while the private equity investor sitting opposite is concerned that NRR has fallen from 112% to 103% and EBITDA margin has deteriorated. Both have legitimate concerns, but neither set of measures explains the other.
Perhaps some of this separation is cultural. Many of us who grew up in computer science and software engineering did not spend much time socialising with the MBA crowd. We were more interested in distributed systems, object-oriented design and why the production database had stopped responding. They were studying discounted cash flows and competitive advantage.
We occasionally met in meetings, usually when somebody needed a budget approved.
The boundaries have become considerably less distinct over time. More technologists have become entrepreneurs, founders and business leaders, discovering that understanding customers, markets and financial performance is rather important when you are responsible for paying the salaries.
Eric Ries helped popularise this thinking through The Lean Startup, bringing experimentation, validated learning and commercial outcomes closer to the heart of product development. It also encouraged engineers to consider whether the things they were building were genuinely useful, rather than treating delivery itself as sufficient evidence of success.
We have been talking about business value for years
There is something slightly uncomfortable about suggesting that software engineering needs to pay more attention to business value, because we have spent much of the past twenty years insisting that it already does.
Agile methods encouraged us to prioritise work according to the value it delivered, while product management developed increasingly sophisticated approaches to understanding customer needs. More recently, the distinction between outputs and outcomes has become central to discussions about product development and organisational effectiveness.
Martin Fowler, made much the same distinction in his 2020 essay Outcome Over Output. Martin contrasted the things software teams produce with the changes those things are supposed to bring about. Delivering a feature is an output; increasing sales or reducing customer support calls is an outcome.
Gartner examined a related difficulty in its 2025 case study of Haleon, looking at how developer productivity could be understood and communicated in business value terms. That this remains a subject of contemporary research suggests that recognising the problem and resolving it are rather different achievements.
Consider an engineering team trying to integrate a new customer facing application with a legacy system designed sometime before the invention of colour television. The engineers are dealing with undocumented interfaces, inconsistent data, unreliable test environments and a security architecture that appears to have been assembled through a series of historical accidents.
Their immediate concerns are getting the integration working, making it reliable and ensuring that it does not bring down something important elsewhere in the organisation. The technical problems are difficult and tangible, while the connection between their work and financial performance is more distant. Engineers are not indifferent to that connection, but neither can they resolve it independently of the people responsible for product strategy, customers and commercial performance.
We have created roles intended to bridge some of these boundaries. Product Owners and Product Managers are expected to understand customer needs, prioritise work and maximise value. Yet these roles can also reinforce the separation. Engineering becomes responsible for delivery, product management for deciding what is valuable, and the financial consequences may sit somewhere else again, perhaps with sales, finance or the executive team.
Responsibility for demonstrating value can become distributed so widely that nobody necessarily owns the complete picture.
The missing middle: understanding what customers actually do
There is another discipline whose development over the past fifteen years deserves attention in this discussion: customer and product analytics.
While engineering was improving its ability to measure software delivery, companies were becoming much better at observing what customers actually did with the software they produced.
In the early days of web applications, analytics often meant counting page views, visits and conversions. Tools such as Google Analytics helped organisations understand how people arrived at a website, which pages they visited and where they left. Useful as this was, it offered a relatively limited picture of customer behaviour.
As SaaS businesses matured, a more sophisticated field of product analytics developed. Companies such as Mixpanel, Amplitude and Pendo helped product teams examine how customers used individual features, where they encountered difficulties, which behaviours predicted retention and how adoption differed between customer segments.
The questions became considerably more interesting. Did customers discover the feature we had just released? Did they use it more than once? Did it help them complete a task? Were customers who adopted it more likely to renew their subscriptions? Did it contribute to expansion revenue, or was it simply another feature that appeared briefly in a release announcement before disappearing into the product’s increasingly elaborate menus?
Consider a company that introduces a feature intended to improve customer retention. Engineering can measure how quickly the feature was delivered and how reliably it operates. Product analytics can show whether customers discover it, how frequently they use it and whether its adoption is associated with changes in engagement. Customer success teams may know whether those customers are more satisfied, while finance can examine renewal rates and revenue retention.
Imagine that the company can trace the feature from its original engineering investment through customer adoption and into subsequent renewals. It may still be difficult to prove that the feature caused those customers to stay, but the organisation now has evidence connecting what it built, how customers used it and what happened to the revenue associated with those customers.
That evidence could support an estimate of the financial contribution of the feature. If customers adopting it retain more revenue than comparable customers who do not, the company has a basis for investigating whether the investment is paying off. Controlled experiments, where practical, can strengthen the conclusion by helping to distinguish the effects of the feature from other influences.
Researchers have also begun exploring quantitative models that connect engineering productivity with the outcomes software produces. The 2024 paper Organizational Ohm’s Law in Practice: Measuring Engineering Productivity is an interesting example of this emerging work. Such approaches offer another way to examine the relationship between engineering activity and organisational performance, although establishing the financial contribution of individual investments remains a separate and considerably more difficult challenge.
There are limitations. Product analytics can tell us what customers do, but it cannot always explain why they do it. Heavy use of a feature may indicate that customers value it, or that they are struggling to accomplish something that ought to be simple. A feature associated with higher retention may be genuinely valuable, or it may simply be used more frequently by customers who were already unlikely to leave.
There are also practical difficulties connecting behavioural data with commercial outcomes, particularly in enterprise software where the person using the product may not be the person making the purchasing decision.
Nevertheless, we now have considerably better tools for understanding what happens after software reaches customers. The information is often available, although it may sit in different systems and be interpreted by different teams.
For an engineer accustomed to measuring the journey from code commit to production, the possibility of extending that journey into customer behaviour, retention, recurring revenue and ultimately enterprise value is rather tantalising. It suggests that the gap between engineering metrics and financial results may be more bridgeable than it once appeared.
The chatbot experiment
When organisations began giving employees access to ChatGPT, many quickly discovered that tasks such as drafting reports, summarising meetings and analysing information could be completed more efficiently. The benefits were often obvious to individual employees, but much harder to identify in the company’s financial results.
Saving thirty minutes preparing a presentation does not necessarily reduce the company’s labour costs. The employee is still employed, and the time saved may be spent on more valuable work, absorbed by other tasks or simply disappear into the working day. Without understanding what happens to that released capacity, the financial benefit remains uncertain.
McKinsey’s 2025 global AI survey found that organisations were reporting benefits from AI within individual business functions, including cost reductions and revenue improvements. Yet only 39% of respondents reported any enterprise-level impact on earnings before interest and tax, and most of those reporting an impact attributed less than 5% of earnings to AI. These were self-reported findings, rather than independently verified causal estimates.
The findings do not establish that the remaining investments were worthless. Some benefits may take years to materialise, while others may improve quality, resilience or customer experience without immediately appearing in financial results.
Giving people access to AI was a reasonable way to encourage experimentation and discover useful applications. The difficulty was assuming that thousands of individual efficiency gains would automatically accumulate into better organisational performance, without understanding what people accomplished with the additional capacity.
AI is changing the nature of software engineering
AI-assisted development tools can generate code, produce tests, identify defects, explain unfamiliar systems and automate increasingly substantial parts of the development process. Coding agents are beginning to undertake work that previously required sustained human attention, potentially changing both the cost and speed of software delivery.
Engineering leaders are understandably measuring the effects through familiar indicators, including DORA metrics, deployment frequency and change lead times. Gartner addressed the limitations of this approach in its August 2026 research, Optimize AI Software Engineering Value With Outcome-Driven Metrics, whose public abstract emphasises the importance of evaluating AI engineering investments through outcomes rather than relying exclusively on operational measures.
Gartner examined the financial dimension more explicitly in its April 2026 report, How to Maximize ROI From AI Investments in Software Engineering. Its central observation is that time saved through AI-assisted development does not automatically become financial value. Organisations must consider both the cost of adopting AI and the business outcomes that the additional engineering capacity makes possible.
The more interesting possibility is that AI changes how engineering teams organise themselves and what their members spend their time doing.
Approaches such as Spec-Driven Development are attracting interest because they place greater emphasis on defining the intended behaviour of software before asking AI agents to implement it. Rather than writing every line of code, engineers increasingly work on specifications, constraints, acceptance criteria, architecture and the verification of what agents produce.
Whether these changes produce a lasting reduction in the total cost of software engineering remains uncertain. Faster code generation is only one part of the development lifecycle, and the effort required to validate, secure, integrate and maintain AI-generated software may absorb some of the apparent savings. Even so, the changing distribution of work creates an opportunity to reconsider how engineering teams contribute to business outcomes.
If agents take on more of the mechanical work of implementation, engineers may have additional capacity to think about the problems they are solving. There may be opportunities to bring engineering, product management and customer understanding closer together.
A specification ought to express more than what the software should do. It should reflect an understanding of the problem the software is intended to solve. An engineer working closely with a product manager and a customer analyst may be better placed to challenge whether a proposed feature is necessary, how its success should be measured and what evidence would justify further investment.
This does not mean that engineers should suddenly become financial analysts or that product management will disappear. The disciplines have different skills and responsibilities for good reasons. But AI may create an opportunity to reconsider boundaries that developed partly because software implementation was so labour-intensive.
If AI allows engineering teams to produce software with fewer constraints, organisations will need to become more disciplined about deciding which investments deserve that capacity. In principle, they already have a mechanism for making those decisions: the business case.
The business case nobody revisits
Before a significant project begins, someone estimates its costs, describes the expected benefits and produces a financial justification. The document is reviewed and eventually approved, at which point attention moves towards delivery milestones, expenditure, scope and implementation risks.
Once the project is completed, attention generally shifts towards the next initiative. The financial assumptions that were so important when the investment was approved may receive relatively little attention after the software has been delivered.
A project justified on the basis of increasing customer retention may be declared successful because the software was delivered. A new platform expected to reduce operating costs may be celebrated because it went live on schedule. An AI initiative promising substantial productivity gains may be assessed by counting how many employees have adopted the tools.
These are legitimate measures of implementation, but they do not establish whether the investment delivered the benefits used to justify it.
There are exceptions, particularly where organisations have mature benefits-realisation practices or where financial outcomes are directly observable. But responsibility for measuring benefits can be fragmented. Financial assumptions belong to one team, operational measures to another, and commercial results to a third.
Revisiting business cases can also reveal that the original assumptions were wrong. A project may have been delivered successfully while generating little financial benefit. Another may have exceeded its budget but created substantial unexpected value. Neither outcome fits particularly comfortably into governance processes concerned primarily with whether projects are on time and within budget.
For a PE-owned business, I would strongly advocate that every material investment begins with an explicit thesis about how it might influence Enterprise Value, even when the connection is indirect or uncertain. The thesis should identify the intermediate measures through which the benefit is expected to emerge, together with the assumptions that need to hold. Just as importantly, it should be revisited after implementation, so the organisation can learn whether the anticipated contribution materialised.
This would make the business case a living hypothesis rather than a document that has served its purpose once funding is approved. The organisation could refine its assumptions as evidence emerges, examine whether the expected benefits are materialising and use what it learns to improve subsequent decisions.
The level of analysis should be proportionate to the investment and the uncertainty involved. A major platform modernisation programme might justify detailed financial modelling, while a smaller engineering improvement may need only a simple statement of its expected benefits and how they will be assessed. The important thing is to establish the connection without creating another elaborate process that consumes more effort than the investment itself.
An initiative to improve software delivery speed might have a thesis that shorter lead times will allow commercially valuable features to reach customers earlier, accelerating adoption and bringing forward additional ARR. A programme to reduce production defects might propose that improved reliability will reduce customer support costs, improve customer satisfaction and contribute to stronger GRR. A modernisation programme might reduce infrastructure expenditure, improve EBITDA and lower operational risks that could otherwise affect the valuation multiple.
Some investments are primarily defensive, and their value can be harder to demonstrate. Security, regulatory compliance, disaster recovery and technical debt reduction may deliver little immediately visible improvement in revenue or profitability. Their purpose is often to reduce the likelihood of something going badly wrong, or limit the damage if it does. A company might invest £500,000 in strengthening its security without experiencing a single breach before or after the work. That does not mean the investment created no value. If it has materially reduced the likelihood or potential cost of a serious incident, it may have protected customer relationships, future earnings and ultimately Enterprise Value. The difficulty is establishing how much risk has genuinely been removed, particularly when the outcome we are trying to prevent never occurs.
The chain does not need to reach EV directly. It may pass through several intermediate measures, including customer adoption, support costs, retention, pricing power, operating margins or changes in the probability and financial consequences of material risks. These intermediate measures are often where the most useful evidence can be collected.
This does not mean engineering teams should be held individually accountable for changes in Enterprise Value. Their responsibility is to understand how their work contributes to the wider business objectives, while product, commercial and financial teams share responsibility for establishing whether those benefits are realised. The purpose is to improve investment decisions and organisational learning, rather than replace engineering measures with a financial target that engineers cannot directly control.
Even where the causal relationship is weak, uncertain or difficult to quantify, we should still articulate it. An explicitly uncertain hypothesis can be tested and improved. An unstated assumption cannot.
Over time, revisiting these hypotheses could help an organisation understand which types of engineering investment tend to create financial value, which produce less than expected and which have benefits that were not anticipated. That knowledge would be useful when deciding where to invest next.
The uncomfortable problem of causality
There is a legitimate reason why connecting operational improvements to financial performance is difficult. Businesses are complicated systems, and financial results are influenced by many things happening simultaneously.
Suppose a software company introduces AI-assisted development and subsequently experiences a 10% increase in revenue. It would be tempting to attribute some of that growth to the investment, particularly if software delivery performance had also improved. Yet the company might have increased marketing expenditure, changed its pricing, hired additional salespeople or benefited from improving market conditions. A competitor might have withdrawn from the market, or a major customer could have expanded its contract for reasons entirely unrelated to software delivery.
Even when the connection appears plausible, isolating the contribution of one initiative can be extremely difficult.
Some relationships are relatively direct. If an automated process eliminates a third-party service costing £200,000 annually, and the contract is cancelled without replacement costs, the financial benefit is straightforward to establish.
Others are more complicated. Reducing software defects might lower customer support costs, but the relationship will depend on the types of defects eliminated, how customers experience them and the extent to which support activity actually changes. Further away, we might believe that faster software delivery improves customer satisfaction, which contributes to retention and eventually increases revenue. The relationship is plausible, but several other factors influence the outcome.
Product analytics can strengthen the evidence by showing what customers actually do, while controlled experiments can sometimes help isolate the effects of particular changes. Even so, connecting those changes to company-level financial performance may require assumptions about customer behaviour, pricing, costs and the timing of benefits.
There is another complication when we try to connect these improvements to Enterprise Value. EV is not continuously observable in most private companies. A publicly listed company has a share price that changes throughout the trading day, but a privately owned business does not have an equivalent measure. Its value is usually estimated periodically, or established when somebody invests in or buys the company.
Even when we have a valuation, it can change for reasons that have little to do with the company’s performance. A business might improve customer retention, increase its revenue and become more profitable, only to find that buyers are willing to pay lower valuation multiples because market conditions have changed. Equally, a company’s estimated value might rise simply because investors have become more enthusiastic about its industry.
This means we need to distinguish between making a business more valuable and being able to prove precisely how much its value has increased. If an engineering initiative helps retain customers or reduce operating costs, we can gather evidence of those improvements and estimate their financial contribution. We may not be able to say that a particular project increased EV by exactly £5 million, but we should be able to explain how it contributed to the factors that determine EV, how confident we are in that conclusion and what we have learned for future investments.
None of this means we should abandon the attempt to measure financial contributions. Businesses routinely make investment decisions with incomplete information, whether they are forecasting sales, evaluating acquisitions or estimating the returns from marketing expenditure. What matters is understanding the assumptions behind an estimate, the evidence supporting it and how much confidence we should place in the result.
An imperfect but credible estimate of financial impact may be more useful than a precisely calculated operational metric whose commercial significance remains uncertain.
The danger of becoming more efficient at the wrong thing
AI makes this problem more urgent because it offers the prospect of substantial improvements in the speed and cost of producing software.
For years, the practical constraints of software development forced organisations to make choices. Engineering capacity was expensive and limited. Product managers had to prioritise features, negotiate trade-offs and decide which opportunities justified the available resources.
Those constraints were frustrating, but they also imposed a degree of discipline. As AI reduces the effort required to produce software, the constraint may increasingly move elsewhere. Organisations could find themselves capable of building far more functionality than their customers need, their commercial teams can sell or their operations can support.
Our stuffed-toy factory provides a useful warning. Its automation programme might increase production capacity by 30% and reduce unit costs, but if demand remains unchanged, the result could be growing inventories, additional working capital and eventually discounted stock. The factory would have become substantially more efficient without necessarily becoming a more valuable business.
Software is not identical to manufacturing. Unsold features do not accumulate in warehouses, and the marginal cost of distributing software is often low. But unused functionality still carries costs in maintenance, complexity, security, support and the attention required to manage it.
An organisation that doubles its software output without improving its ability to identify valuable opportunities may simply become more efficient at producing things nobody particularly needs.
This is why better customer analytics, experimentation and new ways of organising engineering teams matter. If the cost of producing software falls dramatically, the ability to identify worthwhile problems and understand whether they have been solved becomes correspondingly more valuable.
What are we actually improving?
For much of my career, making software development faster, more predictable and more reliable seemed an entirely reasonable measure of success. I still believe those improvements are valuable, and the engineering profession has made extraordinary progress in achieving them. But my experience of running and investing in businesses has made me increasingly interested in what happens after those improvements have been made, and how their contribution to financial performance can be understood.
AI may make this question considerably more pressing. For most of the history of software engineering, producing software has been expensive, difficult and time-consuming. Those constraints have shaped the way we organise teams, allocate budgets and decide what to build. If AI continues to reduce the effort involved in implementation, some of those assumptions will need to be reconsidered. Engineering capacity may become less of a constraint, while identifying valuable opportunities, understanding customers and deciding where to invest become more important.
There is an interesting possibility that the next significant improvement in the economics of software engineering will come from getting better at deciding what to build, rather than simply becoming faster at building it. We have spent decades developing increasingly sophisticated measures of engineering productivity, and AI may accelerate that progress considerably. Meanwhile, advances in product analytics have given us a much better understanding of what customers actually do with the software we produce. Bringing those capabilities together could allow organisations to make better investment decisions and learn more quickly from the results.
For PE-owned companies, Enterprise Value provides a useful financial destination for that work. A business that can connect its engineering investments to improvements in customer retention, recurring revenue, operating margins and the durability of future earnings should be better placed to understand which initiatives are contributing to its value. Establishing those connections will rarely be straightforward, and even a carefully constructed EV thesis may remain uncertain long after a project has been delivered. Nevertheless, explicitly examining the relationship is preferable to assuming that improvements in engineering productivity will eventually find their way into the financial results.
Of course, private equity is only one perspective. Other organisations will have different objectives, and even PE investors must consider debt, financing arrangements and the wider determinants of shareholder returns. The broader challenge is to understand how operational improvements contribute to the outcomes an organisation is trying to achieve, rather than relying exclusively on measures of how efficiently work is performed.
What interests me most is that AI may eventually help us with both sides of this problem. We are already using it to produce software more efficiently, but the same technology may also make it practical to analyse the relationships between engineering activity, customer behaviour and financial performance in much greater detail. If that proves possible, we could begin to develop a more reliable understanding of which investments create value, how much they contribute and what we should do differently next time.
That would be a useful development for a profession that has spent so much of its history learning how to build software better.
Appendix: Financial measures used in this essay
| Metric | What it measures | Why investors care |
|---|---|---|
| ARR | Annual Recurring Revenue from subscriptions and recurring contracts. | Indicates the scale and predictability of recurring revenue. |
| ARR multiple | Enterprise Value divided by ARR. | Shows how highly investors value the recurring revenue base. |
| EBITDA | Earnings before interest, tax, depreciation and amortisation. It is not a measure of cash flow. | Indicates operating earnings before certain financing and accounting effects, but does not account for capital expenditure or working-capital requirements. |
| Free Cash Flow (FCF) | Cash generated from operations after capital expenditure, subject to the company’s accounting and reporting conventions. | Shows cash available for reinvestment, debt repayment or distributions. |
| Rule of 40 | Annual revenue growth percentage plus a consistently defined profit-margin percentage. | Evaluates the balance between growth and profitability. |
| Net Revenue Retention (NRR) | The percentage of starting recurring revenue retained from existing customers after churn, contraction and expansion. | Indicates whether existing customer relationships are growing or shrinking in revenue terms. |
| Gross Revenue Retention (GRR) | The percentage of starting recurring revenue retained from existing customers after churn and contraction, excluding expansion revenue. | Reveals underlying revenue losses that upselling might otherwise conceal. |
| LTV:CAC | Customer lifetime value relative to customer acquisition cost. | Tests the economics of acquiring customers. |
| CAC payback | Time required to recover customer acquisition costs from gross profit. | Measures how quickly customer acquisition investment is recovered. |
| Burn multiple | Net cash burn divided by net new ARR. | Measures capital efficiency in cash-consuming growth businesses. |
References
- Forsgren, N., Humble, J. and Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution.
- DORA (2018). Accelerate State of DevOps Report.
- DORA (2024). Accelerate State of DevOps Report.
- Fowler, M. (2020). Outcome Over Output.
- Ries, E. (2011). The Lean Startup. Crown Business.
- McKinsey & Company (2025). The State of AI in 2025: Agents, Innovation, and Transformation.
- Gartner (2025). Case Study: Measure Developer Productivity in Business Value Terms.
- Minning, B. and Hodgkins, A. (2026). Optimize AI Software Engineering Value With Outcome-Driven Metrics. Gartner.
- Albrecht, A. J. (1979). Measuring Application Development Productivity. IBM.
- Kohavi, R., Henne, R. M. and Sommerfield, D. (2007). Practical Guide to Controlled Experiments on the Web.
- Kohavi, R., Tang, D. and Xu, Y. (2020). Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. Cambridge University Press.
- Mixpanel.
- Amplitude.
- Pendo.
- Colman, M., Swan, C. A., Agarwal, N. and Parker, L. (2026). How to Maximize ROI From AI Investments in Software Engineering. Gartner, 22 April 2026.
- Organizational Ohm’s Law in Practice: Measuring Engineering Productivity. (2024). IEEE. Full bibliographic details to be verified.
