Why the Spec Is Not the Product

There's a ritual in software projects that feels responsible, thorough, and professional. It goes like this: before any code is written, you document everything. Every screen. Every user flow. Every edge case. You produce a specification document — sometimes 20 pages, sometimes 80 — and everyone signs off on it.

Then the build begins. And somewhere around week six, you realise the spec was wrong.

Not because anyone was careless. Because the spec was written before anyone had used the product.

The Illusion of Certainty

A specification document creates the feeling of certainty. You can point to it. You can share it. You can say "this is what we're building" and have something tangible to show for the planning phase.

The problem is that certainty about a software product — what it should do, how users will interact with it, what actually matters — can only come from using the product. Not from imagining it.

This isn't a failure of imagination. It's a structural problem. The information you need to make good product decisions doesn't exist until real users touch real software. No amount of workshops, wireframes, or stakeholder interviews can fully substitute for that.

What Happens in Practice

Here's a pattern I've seen more than once.

A business commissions a software project. They spend two months in discovery — workshops, user research, a detailed spec. The spec is thorough. Everyone is confident.

The build takes six months. At the end, the software does exactly what the spec said. It also turns out that several of the spec's core assumptions were wrong. Users navigate the product differently than expected. A feature that seemed essential is barely used. A workflow that wasn't in the spec turns out to be the one everyone needs.

The business now has two options: ship what was built and live with the gaps, or spend more money fixing them. Either way, the spec didn't protect them. It just delayed the moment of truth.

The Cost Is Not Just Money

The financial cost of over-speccing is real — discovery phases at agencies can run to tens of thousands of pounds before a line of code is written. But the less obvious cost is time.

Every week spent producing documentation is a week you're not learning from real users. In a market that moves quickly, that delay has consequences. Competitors ship. Customer needs evolve. The window for a particular product idea can close while you're still in the planning phase.

There's also a psychological cost. After months of planning, teams become attached to the spec. Changing it feels like failure, even when the change is clearly the right call. The sunk cost of the planning phase makes it harder to adapt.

What Works Better

The alternative isn't to build without thinking. It's to build in a way that generates real information as quickly as possible.

That means starting with the smallest version of the product that can be put in front of real users. Not a prototype. Not a mockup. Working software that does one thing well.

From there, you learn. You watch how people use it. You find out which assumptions were right and which weren't. You make decisions based on evidence rather than prediction.

This approach requires a different kind of discipline. Instead of specifying everything upfront, you have to be ruthless about scope — constantly asking what's the minimum we need to build to learn what we need to know.

It also requires a development partner who can work this way. Not every agency or developer is set up for it. The traditional model — fixed spec, fixed price, fixed timeline — is incompatible with genuine iteration.

The Role of Planning

None of this means planning is useless. It means planning should be proportionate to what you actually know.

Before building, it's worth being clear on: the core problem you're solving, the primary user and their most important workflow, the one metric that would tell you the product is working, and the constraints — budget, timeline, technical.

That's a conversation, not a document. It takes a few hours, not a few months. And it leaves room for the product to evolve as you learn — which it always will.

A Different Way to Think About It

The spec is a hypothesis. The product is the experiment.

The faster you can run the experiment, the faster you find out which parts of the hypothesis were right. The longer you spend refining the hypothesis before testing it, the more expensive it becomes to discover you were wrong.

This is why the most successful software projects I've been involved with have all shared one characteristic: they got something real in front of real users as quickly as possible, and they were willing to change based on what they found.

If you're planning a software project and you're being asked to spend months on a spec before anything is built, it's worth asking: what would we learn from building a small version of this first?

The answer is almost always: more than the spec will tell us.

If you want to talk through how this approach might apply to your project, get in touch. I'm happy to have that conversation before you've committed to anything.