The history of industry is littered with failed projects. Projects where a team was asked to build a product based on a specification, a budget and a timeline. And failed. According to the research I’ve conducted, 60-80 percent of all IT projects are considered failures in some sense, either because they failed completely or failed to deliver all the value expected at the start.
The idea of kicking off a project with a finishing date a year or more in the future and trusting the team to deliver it is, in many ways, akin to pointing your car toward a point on the horizon, closing your eyes and hitting the accelerator, hoping to reach that point. Everyone understands that this is a stupid idea when it comes to cars, but when it comes to software-intensive systems projects, I still see the attitude present in many companies.
Of course, with the adoption of Agile, there are sprints and cycles, at least at the team level. However, the value delivery to the customer is still often predominantly transactional. While many companies seek to deliver some post-deployment value, the scope of that value and the monetization are often a fraction of what’s delivered initially.
A second major problem we’ve been working on for close to a decade now is that many companies don’t have a clear, quantitative definition of what it is that constitutes customer value. There’s a lot of storytelling. Sales has its anecdotes from customer meetings. Product management tells a different story to each of its stakeholders. Different departments responsible for aspects of the system tell stories about why their focus area is so incredibly important.
What’s missing are quantification and prioritization. Quantification in that virtually every company I work with treats customer value in qualitative terms, rather than quantitative ones. Prioritization in that when asked which aspect or focus area takes priority over another, the typical answer is that both are important to the customer and hence to the product development initiative.
Many companies don’t seem to know the difference between important and differentiating. For example, cars have brakes and brakes are important to avoid dangerous traffic situations that may harm or kill people. But car brakes aren’t differentiating in that you would select a certain car over another type because of its brakes (unless you like car racing). Instead, you focus on aspects that make one car stand out from others and that are important to you, as a customer.
Important functionality needs to be quality assured and, where necessary, certified, but it doesn’t necessarily require major R&D investment. Differentiating functionality may not be critical from a safety or security perspective, but it drives buying behavior and as the primary job of a company is to create and keep a customer, being the preferred supplier is a critical aspect for any company. Hence, investment should primarily go toward differentiating functionality and only to the minimum extent possible to commodity functionality, no matter how important it is.
My main point here is the transition toward continuous value delivery to customers. Rather than delivering after a long and unpredictable project, hoping that the hit-or-miss effort results in a resounding success, the aim should be to develop as little as possible before the first delivery and find ways to maximize the ability to add value afterward.
To move from transactional to continuous value delivery, three main factors need to be in place: a clear, quantitative definition of what constitutes value, mechanisms to continuously deliver functionality that increases the value of the system to the customer and a monetization mechanism where improved value to customers either directly or indirectly leads to additional revenue. In practice, this means that companies need to fundamentally rethink how they structure product development, delivery and even their business models.
First, a clear and quantitative definition of value is non-negotiable. This doesn’t mean that every aspect of customer value can be reduced to a single metric, but it does mean that for every significant investment decision, there should be an explicit hypothesis about how that investment increases customer value and how that increase can be measured. Is the value reduced time, reduced cost, increased revenue, reduced risk, improved user experience or something else? And by how much? Without this, prioritization becomes political rather than rational, and learning becomes impossible.
Second, companies need mechanisms for continuous delivery of value. This goes far beyond adopting CI/CD pipelines or releasing software updates more frequently. It requires an architecture that supports incremental improvements, the ability to activate new functionality remotely and organizational processes that allow teams to work on small, high-impact changes rather than large, bundled releases. In software-intensive systems, this increasingly means leveraging data and AI to continuously improve the system based on real usage, rather than relying solely on upfront requirements and assumptions.
Third, and often the most uncomfortable, is monetization. Many companies are quite good at delivering incremental value but remarkably poor at capturing a fair share of that value. If additional value delivered after deployment doesn’t translate into additional revenue – directly through subscriptions, upgrades or usage-based pricing, or indirectly through higher retention, reduced churn or increased share of wallet – then the organization will inevitably drift back to a transactional mindset. Continuous value delivery without continuous value capture isn’t a sustainable strategy.
Putting these three factors together leads to a very different way of thinking about products. The initial delivery becomes a starting point rather than an end point. The goal is no longer to “finish the project,” but to establish a value-generating system that can evolve over time. This also fundamentally reduces risk: instead of betting everything on a large, upfront commitment, companies place many smaller bets, learn from real customer behavior and continuously reallocate resources to where they create the most value.
The transition isn’t easy. It challenges deeply ingrained habits around budgeting, governance and performance measurement. It requires leaders to give up the illusion of long-term predictability in exchange for short-term learning and adaptability. But given the persistent failure rates of traditional projects and the increasing pace of change in markets and technology, the alternative – continuing to point the car at the horizon, close our eyes and hope for the best – seems far less attractive.
The transition toward continuous value delivery isn’t a process change or a tooling exercise. It’s a shift in mindset: from delivering scope to delivering value, from one-off transactions to long-term relationships and from certainty in plans to confidence in the ability to learn and adapt. To end with Heralclitus, “No man ever steps in the same river twice, for it’s not the same river and he’s not the same man.”
Want to read more like this? Sign up for my newsletter at jan@janbosch.com or follow me on janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch) or X (@JanBosch).
