You Can't Spec Your Way to a Working MVP

The most useful document on one of our recent builds wasn't the roadmap. It was a list a user typed up after an afternoon of poking at the actual software: a handful of items, half of them with screenshots, a couple of them things nobody on either side had thought to raise during planning. In one release stretch, nine changes shipped to production across two waves in a single week, almost all of them pulled straight from that list. None of them were in the original spec. Every one of them made the product better.

That is the pattern I want more founders to sit with before they spend a dollar building anything. A spec is a pile of guesses that feels like a pile of decisions. It reads as finished. It has sections and bullet points and a satisfying sense of completeness. And almost none of it survives contact with a real person using the real thing.

A spec can't fail. That's the problem.

When you write a specification, you are describing software that does not exist yet, based on how you imagine people will use it. That is not a criticism. It is the nature of the document. But a spec quietly can't do the one thing that matters: it can't be wrong in a way you will notice. Every screen works perfectly in a Google Doc. Every workflow flows. The edge cases you did not think of never show up, because the only way they show up is when real data and a real human hit them at the same time.

So the spec sits there looking complete, and it feels like progress, and it feels safe. Founders love it for exactly that reason. It is cheap to change, you stay in control, and nobody can tell you it does not work because there is nothing to test. That comfort is the trap. You can spend a month making a spec more detailed and end that month knowing exactly as much about whether your product works as you did on day one, which is nothing.

What a real user finds in an afternoon

Put the same idea in front of one real user for one afternoon and you get a different category of information entirely. Not opinions. Facts about your product.

You find the field everyone gets stuck on. You find the "obvious" feature that turns out to be nobody's actual workflow. You find the assumption buried three layers down that only breaks when someone imports their own messy data instead of the clean example you built with. You learn that the thing you agonized over for a week does not matter, and the thing you added in an hour is the thing they open every day.

None of that lives in the spec. It can't, because it only exists once the software is real enough to be wrong. The user who sent over that list of fixes was not handing us a wish list. They were running the experiment the spec could only pretend to run.

Build the smallest thing that can be tested

This changes what you should actually pay for. The instinct is to fund the plan: the detailed requirements, the complete feature set, the version that anticipates every case. The better move is to fund the shortest path to a real user touching real software, and then hold back real budget and real calendar time for the loop that follows.

That is the whole reason we push so hard on scope. It is not about doing less for its own sake. One workflow that genuinely works can be in front of a user next month. Forty features that half-work can't be tested at all, because when everything is a little broken, no single piece of feedback means anything. A small, real, working thing is a machine for producing truth. A big, half-built thing is just a longer spec with a login screen.

So the sequence that actually works is simple to say and hard to accept. Pick the one workflow that has to be right. Build it for real, with real data, all the way through. Get it in front of someone who will use it for the actual job, not a staged demo. Then treat what they tell you as the real backlog, because it is. Their notes outrank your roadmap every time, for one reason: their notes are the only part of this process that has met reality.

The spec is a hypothesis, not a plan

There is still a place for writing things down. You need a shared picture of what you are building and why, and you need enough of a plan to start. But hold it loosely. The spec is your best guess about what will work. It is a hypothesis. The build is how you make that hypothesis testable, and the first real user is the experiment that tells you which parts of the guess were right.

The founders who ship good products are not the ones with the best specs. They are the ones who reach that experiment fastest and then actually listen to it. They treat the plan as the start of the conversation instead of the end of it, and they budget for being wrong about a few things, because they will be. Being wrong early and cheaply is the entire point.

If you are sitting on a document you keep refining, waiting until it feels complete enough to build from safely, that waiting is the signal. It will never feel complete, because completeness is not a property a spec can have. The only thing that can tell you whether your idea works is the smallest real version of it, in one real person's hands, producing the kind of feedback no document ever will. Build that first. Then go listen.