The Question on Every Board's Mind
In strategy workshops, the same question keeps surfacing in different forms: "Why does it take us six months to turn an idea into working software, while others do it in two weeks?" The wording varies, but the core is always the same: the time between "we should do X" and "X is running in production."
That span has become a metric in its own right. It isn't Time-to-Market, it isn't Time-to-Decision, it isn't Cycle Time. It's Time-to-Software: the span in which a company turns a business requirement into productively usable software. And it's becoming the central competitive metric of the coming decade.
Why the Old Metrics Don't Cut It
Time-to-Market was a good metric in a world where products were built once and then sold. Bringing a car to market, launching an insurance product, certifying a machine – these were one-off efforts with clear start and end.
That world is shrinking. In more and more industries, the product itself is no longer a finished thing but a bundle of hardware, service, and software that keeps evolving. A modern car gets more software updates than a smartphone did ten years ago. An insurance product is defined through an app whose features expand weekly. A factory machine gets new AI-powered diagnostic features every month.
In this world, "Time-to-Market" measures something that happens once. "Time-to-Software" measures continuously how quickly a company can respond to demands – from the market, from regulation, from its own strategy.
What Time-to-Software Actually Means
Time-to-Software is cleanest measured as the span between two clearly defined points: the moment a business requirement is formulated ("we need a workflow that does X") and the moment that exact workflow is available to users.
That sounds simple but is a sharp measure. It includes what many companies would rather ignore: time spent in backlogs, in architecture meetings, in approval processes, waiting for vendor releases, moving through test stages, and finally rolling out in a maintenance window.
A concrete example: An insurer wants to introduce new evaluation logic for a niche product. The concept is clarified within two weeks. By the time the logic actually arrives in the system and applications are being scored against it, another eight months have passed. The Time-to-Software is eight months – not eight months of development time, but eight months of total cycle. The actual code was written in three weeks.
That difference – between actual build time and total cycle – is the lever.
What Time-to-Software Leaders Do Differently
Companies that compress this KPI from months to weeks do three things differently:
They have a platform you can build on. No isolated tools, no ten different databases, no spaghetti integrations. Instead, a consolidated platform with standardised interfaces, auth, reporting, and deployment. A new requirement lands on this platform and doesn't need to bring its own infrastructure.
They have small, autonomous teams. A team that owns a requirement end to end – concept, build, operations – is orders of magnitude faster than three sequential teams juggling handoffs with tickets and specs. Handoffs are the single biggest Time-to-Software killer in practically every organisation.
They have approval processes that match the speed. Approvals that used to flow through committees meeting once a quarter are turned around in days at fast companies – with clearly defined authority, clear escalation paths, and willingness to accept small risks rather than pre-vetting every detail.
None of these three points is primarily about technology. The platform is learnable, autonomous teams are an organisational model, lean approvals are a culture question. That makes Time-to-Software simultaneously harder to improve and more strategically valuable: a competitor can buy the same cloud platform, but not the same organisational and decision culture.
Why This KPI Matters Now
Three shifts make Time-to-Software the central metric:
Build time itself is dropping dramatically. With AI-assisted development, the actual coding now takes a fraction of what it did three years ago. That removes build time as the determining factor – the wait times around it become the real bottleneck, and therefore the real lever.
Competitors move faster. In every industry there are individual players who've more than halved their Time-to-Software over the past three years. They set the new speed norm. Anyone sticking with old cycle times falls behind – not because their own output gets worse, but because the market adapts to fast competitors.
Regulatory and technological changes come more often. EU AI Act, NIS2, CRA, new authentication standards, new foundation models – the frequency of external requirements has gone up. Anyone needing six months per adjustment never gets out of reaction mode.
Where Companies Should Start
The typical bottlenecks are distributed similarly in practically every company:
Backlogs and prioritisation. Requirements often sit for weeks or months before even being assigned to a team. That logjam comes from central steering and unclear prioritisation rules. Decentralised budgets and clear owners cut this phase drastically.
Architecture reviews and security approvals. Every new workflow runs through the same committees, often with the same long wait times. Standardised architecture paths and pre-vetted components – "guard rails" instead of "gatekeepers" – make most of these reviews unnecessary.
Deployments and test stages. In many companies, weeks pass between "code is done" and "code is running for users". CI/CD pipelines, automated tests, and feature flags reduce that to hours. The technology has been ready for years – it's just rarely applied consistently.
Vendor dependencies. When every adjustment requires an external vendor to process a change request, Time-to-Software is capped by the vendor. This is where "Build the Buy" architectures pay off – with the last mile in-house.
At nh labs, we routinely look at exactly these four bottlenecks in advisory engagements. In most cases, 70 to 80 percent of Time-to-Software sits in wait time, not work time. That's the bad news. The good news: wait times can usually be massively reduced with modest effort – if there's willingness to change old decision paths.
How the KPI Anchors in Reporting
Time-to-Software becomes measurable as soon as a company defines the points at which a requirement "starts" and "completes". That's the only hard question – everything after is bookkeeping.
Once it's measured, pressure to improve it follows. Companies working with this KPI typically report it in two flavours: as median across all requirements (showing the normal case) and as 90th percentile (showing the outliers, which strategically often hurt more than the average).
These two numbers, per quarter, with clear ownership and visible trajectory, change behaviour. Suddenly architecture meetings don't only discuss elegance, they discuss which architecture lowers Time-to-Software. Suddenly standard paths emerge because they're faster. Suddenly approval committees get restructured because they become visible bottlenecks.
Bottom Line
Time-to-Market was the right KPI for a world of discrete product launches. It doesn't become wrong, but it isn't enough. In a world where software is created and demanded continuously, Time-to-Software decides a company's strategic agility. Anyone who makes this metric measurable in the next twelve months has a clear lever to surface bottlenecks and remove them deliberately. Anyone ignoring it will spend the next decade in reaction mode – while the faster competitor builds a few weeks of lead, quarter after quarter.