When a digital product fails, the inquest usually looks at the build: the missed deadlines, the technical debt, the features that shipped late. But in most failures the outcome was already settled before a developer was hired. The build simply revealed a decision that had quietly been made months earlier, by nobody in particular.
Five early failures account for most of the damage.
1. The problem was never validated
Most products begin with a solution: an app someone can picture, a platform someone sketched. The problem it solves is asserted rather than tested. The test is not whether people say the idea is good. People are generous in conversation and ruthless with their time and money. The test is whether specific, reachable people currently pay a real cost, in money, hours or frustration, for the absence of a solution, and whether that cost is large enough to change their behaviour.
A fortnight of honest problem validation is the cheapest insurance in product work. It is skipped precisely because it might succeed, and kill the idea while the idea is still exciting.
2. The proposition was never sharpened
Ask a struggling product's team who it is for, and the answer is usually "well, there are a few audiences." Ask what it does for them, and the answer is a feature list. A proposition is neither. It is a single sentence: for this person, in this situation, this product does this thing better than their current alternative. Every word of that sentence is a decision. Products that cannot complete the sentence do not have a marketing problem. They have a definition problem, and the build inherits it.
3. Requirements lived in someone's head
Between "we know what we want" and a specification a delivery team can build from, there is a document that most projects never write. Its absence is invisible at the start, when everyone agrees in principle, and expensive at the end, when everyone discovers they agreed on different things.
Good requirements are not a bureaucratic artefact. They are decisions made in cheap ink instead of expensive code: what is in the first release and what is not, what happens in the edge cases, what quality is required where, what the product refuses to do. A rough rule holds across projects of every size: an ambiguity that costs an hour to resolve in a requirements document costs a week to resolve in development and a quarter to resolve after launch.
4. The MVP was a smaller version of everything
The most common corruption of the minimum viable product is the "minimum" that includes a third of every feature rather than all of one. It demonstrates effort and proves nothing, because no user can complete a real task with it. A true first release is an argument with the market: we believe this specific value, delivered properly, will change this specific behaviour. It should be complete enough to test that argument and nothing more. Deciding which argument to make is strategy work, and it cannot be delegated to a backlog.
5. Nobody was empowered to say stop
Product decisions concentrate optimism. The founder wants it to work, the team is paid to build it, the agency is paid to agree. What is often missing is anyone whose role is to ask the unwelcome questions: has the assumption behind this milestone been tested? Is the evidence still pointing where the plan says? Would we start this project today, knowing what we now know?
Teams that build this role in, through an independent adviser, a board with licence to be critical or simply a founder with unusual discipline, kill weak directions early and cheaply. Teams that do not, kill them late, in production, in public.
What the disciplined path looks like
None of this argues for slowness. The disciplined path is usually faster end to end, because it front-loads the thinking that undisciplined projects do during development, at development prices. Validate the problem with real people. Write the proposition in one sentence and defend every word. Document the requirements before committing the budget. Ship one complete argument, not fractions of ten. And give someone standing to say stop.
Development is where products become real. Whether they deserve to is decided earlier, and it is the cheapest decision you will ever make about them.