Why most digital products fail before design starts

The undefined-problem trap

Most digital products fail before design starts. Not because the interface was ugly or the code was slow, but because the problem was never clearly defined. The team knew roughly who the product was for and roughly what it should do — and "roughly" is where budgets go to die.

A product built on an undefined problem can still look finished. It has features, screens and a launch date. What it doesn't have is a reason for users to change their behaviour, which is the only thing a new product actually asks of people.

The symptoms are familiar

You can usually diagnose an undefined problem without reading a single line of strategy. The roadmap churns: features get added, reprioritised and removed without anyone being able to say what the change is for. Feature debates run on opinion, because there's no agreed definition of success to settle them. And design feedback collapses into taste — "make it pop" — because nobody can say what the design is supposed to achieve.

What definition actually looks like

Defining a product isn't a vision statement. It's three concrete artefacts: a proposition (who this is for, and what they get that they can't get elsewhere), a journey (the path from first contact to habitual use, with the friction mapped), and an MVP scope (the smallest version that tests the proposition against real behaviour).

Each one forces a decision the team has been avoiding. That's the point. A discovery workshop is cheaper than a quarter of misdirected engineering.

A five-question self-test

Ask your team: Who is the first user, specifically? What do they do today instead of using your product? What single behaviour must change for the product to work? How will you know within a month whether it's working? What did you decide not to build, and why?

If two people on the same team give different answers, the problem isn't defined yet — and design is not the next step.