I recently read GOV.UK's More than a helpdesk: user support's role in helping GOV.UK Notify send 12 billion messages blog post about how the GOV.UK Notify team use user support as part of how they build products.

It describes a fairly simple approach. Ship an MVP, let real users interact with it, and use support requests as a way of understanding what needs improving. Not idealised user journeys or assumptions from workshops, just people trying to get something done.

That distinction is what made me pause.

Somewhere along the way, many modern product teams have forgotten that the primary purpose of an MVP is learning, not polish.

We tend to treat MVPs as small versions of finished products now. Carefully designed flows, thought-through edge cases, and interfaces that try to prevent confusion before anything has actually been used. It feels responsible, like we're reducing risk, but it also reduces something else: signal.

The more polished something is at the point of release, the harder it becomes to see what you don't yet understand.

What GOV.UK Notify are doing isn't particularly complex, but it is intentional. Support becomes part of the system, not a failure state but a feedback loop. If enough people struggle with something it shows up, if it matters it repeats, and if it doesn't it fades away. It's not especially elegant in a traditional product sense, but it is honest, and honesty is usually what learning depends on.

It reminded me of what Eric Ries describes in The Lean Startup, particularly the idea of the build-measure-learn loop. You can read more about it in the principles here: The Lean Startup. The purpose of an MVP in that framing is to maximise learning, not to ship something reduced or simplified for its own sake. Build, measure, learn. Not build something small that already behaves like the final thing.

There's a related idea in Amazon's working backwards approach, where teams start from the customer experience and work backwards into the product rather than forwards from a solution. It still depends on the same thing: real signals from real behaviour, not imagined usage.

A few years ago, most of the teams I worked in operated more like this out of necessity. Smaller teams, fewer layers, and less distance between the people building software and the people using it. You shipped something and very quickly you knew whether it made sense or not. Sometimes that was uncomfortable, sometimes things broke in ways you didn't expect, but the feedback loop was immediate and there wasn't much room for guessing.

As teams grow, that starts to change. Not because people get worse at their jobs, but because they get better at predicting problems. You start designing against imagined failure cases, smoothing away friction that hasn't been experienced yet, and pre-empting confusion that hasn't shown up in reality. Slowly, MVPs stop being learning tools and become pre-finished products.

None of this is an argument against user research, or design, or trying to build thoughtful experiences. Those things matter. But there is a difference between understanding users and predicting them, and the further away you get from real behaviour, the easier it becomes to confuse the two.

An MVP, at least in the way I still think about it, isn't really a small product. It's a way of asking a question: what is the smallest thing we can build that will tell us whether we're right?

Sometimes that thing is polished. Sometimes it isn't. Sometimes it routes through support, because that's where the signal lives.

The interesting part of product work has never really been building things. It's noticing what happens when real people try to use them.