Why so many digital projects fail before a single line of code is written

Every year, billions are spent building digital products that, frankly, should not have been built. Not because they are made badly: very often the code is clean, the infrastructure solid, the interface presentable. The problem sits further upstream. The product solves the wrong problem. Or solves the right problem in the wrong way. Or solves the right problem for the wrong people.

It is a kind of failure that is hard to talk about, because it leaves no visible wreckage. There is no crash, no security breach, no front-page article. There is just a product that exists, gets launched, and then doesn't do what it was supposed to do: users don't adopt it, the metrics don't move, the expected revenue never arrives.

And when you go looking for the cause, you almost always find it in the same place: in the weeks before the first line of code.

There is a stubborn belief in the corporate world: that the expensive part of a digital project is development. It is an understandable belief — developers are visible, hours are billable, quotes speak the language of code. It is also a belief that systematically leads people to underestimate the most important phase of all: the one in which you decide what to build.

The most-cited data point on this, and still the most accurate, comes from a classic study by Barry Boehm in the early 1980s: the cost of fixing a mistake grows by an order of magnitude every time you move one phase forward. A mistake caught during requirements costs 1. The same mistake caught in design costs 5. In development, 10. In QA, 20. By the time it reaches production, it can cost up to 100 times as much.

The exact numbers vary by context — on small, well-managed projects the curve is much flatter — but the principle is intact and more relevant today than ever: the later you discover that you got it wrong, the more expensive the fix. And the most expensive fixes of all are not about individual features: they are about having built the entire product around a flawed assumption.

That is why the strategic question is not "how much will it cost to develop?", but "how much will it cost us to discover, too late, that we developed the wrong thing?". It is a less comfortable question, because it doesn't fit on a quote, but it is the one that really determines the ROI of a digital project.

The typical starting point in a corporate digital project is a requirements document. A list of features, often a long one, written by whoever commissioned the project — sometimes with help from consultants, sometimes not — and handed over to the development team as the spec to build. It is a practice so widespread that it looks self-evident, and it is one of the leading causes of failure in digital projects.

The problem isn't that the document is poorly written. The problem is that, in the vast majority of cases, the document contains the list of solutions the stakeholder has already imagined, not the list of problems the product is supposed to solve. It looks like a small logical jump, but it is a costly one: whoever writes the requirements has, alone, already done the job of product design. Without data, without users, and often without specific experience.

The Standish Group's CHAOS Report, which has been studying software project outcomes for nearly three decades, has consistently named two of the top three causes of failure as lack of real user involvement and poor quality of requirements. In the most recent edition, based on roughly 50,000 projects, only 31% are considered fully successful.

The consequence is predictable: the development team gets detailed specs to build something that doesn't solve a verified problem. They build it well. They ship it on time. And then nobody uses it. The project shows up as "successfully completed" on the internal report, while the product, in production, fails to move any of the metrics it was funded to move.

Discovery is the phase in which a team tries to answer three questions before touching the code: who has this problem, how often do they have it, and what are they doing today to solve it? It is the work that separates a hypothesis from an informed decision. And yet, in many projects, it gets skipped or reduced to a formality.

The reasons are almost always political, rarely technical. Discovery is invisible from the outside: it produces no screens, no code, no artefact that looks like progress. It produces decisions — the hardest kind of output to defend in a status meeting, because you can't take a screenshot of it. And yet it is the moment in which it is decided whether the project, in the end, will be worth anything.

Skipping discovery is a choice you always pay for, sooner or later. You pay for it in three ways: wasted build time (months of development on features that will need to be rewritten or scrapped), missed opportunities (the real problem, the one users actually had, stayed unsolved), and internal credibility (next time someone proposes a digital project, somebody will remember the last one).

There is one number, often quoted by Marty Cagan in his work on digital product, that is worth internalising: on average, more than half of the ideas a team tries to develop don't work. Not because the team is incompetent, but because most hypotheses — even plausible ones, even ones written by experienced people — don't survive contact with the reality of users. A serious discovery process doesn't eliminate that fact: it catches it early, when it still costs little.

One of the most deeply rooted distortions in digital projects is feature-framing. The opening conversation, in many companies, sounds like this: "we want a website with a product configurator, a user dashboard, a blog, an integrated booking system and a chatbot". These are plausible asks. They sound concrete. And yet, taken as such, they are already a symptom of the problem.

A feature is a solution. And every solution presupposes an underlying problem that someone, somewhere, has already diagnosed. When a feature lands at the top of the brief without the problem that justifies it, one of three things is happening: the problem exists but hasn't been made explicit (so you won't be able to verify whether the feature actually solves it); the problem has been taken for granted (so it hasn't been tested); or the problem isn't there at all, and the feature has been requested out of competitor mimicry or internal pressure from some department.

Problem-framing, by contrast, starts from a different question: "what is the specific thing users today can't do, or do badly, and that is preventing us from selling/retaining/lowering support cost?". The answer to that question is almost never a feature. It is a behaviour, a path, a friction point. Only after you have understood that can you decide — with more than one hypothesis on the table — which design solution best addresses it.

The risk profile of these two approaches is wildly different. Building a feature presupposes that the solution has already been found. Building around a problem leaves open the possibility that the real solution is simpler, smaller, or completely different from what was first imagined. And, in retrospect, almost always it is.

The single tool that does the most to reduce the risk of a digital project isn't a new methodology, a framework, or a tech stack. It is the prototype. Not as a polished mockup, but as an interactive simulation good enough to let a real person try the experience before any code exists.

The prototype does one specific job: it turns opinions into data. Inside a company, in front of a screen, six people with different roles can spend hours debating "how the onboarding flow should work". Everyone has legitimate opinions, everyone has arguments. That conversation never reaches a robust decision, because there is no external arbiter. Putting the prototype in front of five real users and watching them use it for fifteen minutes ends the conversation, definitively.

Nielsen's data point is one of the most cited and least applied numbers in the field. Five sessions are enough to catch the vast majority of usability problems in an interface. Five sessions cost, in time and money, a small fraction of one development sprint. And yet a great many projects ship to production without the product ever having been put in front of a user who didn't work for the company that commissioned it.

There is one more thing the prototype does, less talked about but equally important: it aligns internal stakeholders. When a decision is made by watching, together, a user get stuck on a particular step, it stops being a matter of taste and becomes a matter of evidence. The conversation changes register. Meetings get shorter. "I think" gives way to "we saw that".

The digital projects that work share one trait you notice immediately: design and product work begins before development, not in parallel with it or after it. It isn't a matter of internal hierarchy, it is a matter of decision sequence. Design choices are product choices. Product choices are business choices. Making them well means making them in the right order.

Concretely, this looks like a handful of recognisable habits. The starting point is user problems, not features: the project's opening document describes what isn't working today, before describing what gets built. Interviews happen before kickoff: even five or six conversations with target users tend to shift the project's priorities radically from how they had been imagined in the first brief.

Prototyping precedes estimation: the development estimate lands on a tested flow, not on a brief. This drastically reduces in-flight surprises and the "clarification" tickets that pile up in the early sprints. Design gets an explicit iteration budget: it is not treated as a coat of paint to apply at the end, but as the phase in which wrong hypotheses get discarded while it still costs little to discard them.

The companies that work this way don't seem any slower: they often look slower at the very start of a project, because the first pixel arrives a few weeks later. But then they don't redo the product six months after launch. They don't kill it after a year. They don't redesign it from scratch because "it didn't work the way we expected". The time they appear to lose at the start is exactly the time everyone else loses afterwards.

Every failed digital project is, deep down, the same project: someone decided too early what to build. They decided without data, without users, without alternatives on the table. They wrote it into a requirements document and handed it to the people who had to build it. And by the time the product reached production, it turned out that the decision made at month zero — the most important decision of all — had also been the one made with the least information.

This isn't a developer problem, a methodology problem, a stack problem, or a budget problem. It is a problem of decision sequence. Discovery before requirements. Problems before features. Prototypes before development. Users before stakeholders.

Reversing that sequence isn't a way to go faster. It is a way to keep paying the bill later, and at a much higher rate, every single time. And by then the bill is rarely paid in money: it is paid in products that exist but serve no one.