The Product Spec Is a Liability

A well-written spec is satisfying in a way that almost nothing else in product work is. It's organized. It's complete. It has sections. Everyone in the meeting nods.

Then you start building, and you realize the spec described a product nobody needs, or one that's technically impossible, or — most commonly — one that made sense on paper but falls apart the moment a real user touches it.

The false confidence problem

Specs are written before you know anything. You write them to organize your thinking, to get alignment, to communicate intent. These are all fine reasons. The problem is when the spec starts to feel like evidence that you've validated the idea.

You haven't. You've just written down your assumptions clearly.

Every decision in a spec is a guess. Some guesses are well-informed. Most are not. The only way to find out which is which is to build something and put it in front of people.

What happens when the spec becomes the goal

Teams that treat the spec as the deliverable optimize for completing the spec. They build what was written, not what users need. When reality diverges — and it always does — they either ignore the signal or they go back and update the spec, which delays everything and resolves nothing.

The spec becomes a paper trail rather than a tool. You end up with a product that faithfully implements a document nobody believes in anymore.

What to do instead

Don't throw out planning. Throw out the illusion that a plan is a substitute for learning.

Write down what you're trying to accomplish and why. Keep it short — a page is usually too long. Then build the smallest thing that could tell you whether your core assumption is right. A prototype. A single screen. A fake flow.

The feedback you get from something real is worth more than any amount of spec refinement.

Specs as anchors, not blueprints

The best teams we've worked with treat specs as working documents — anchors for shared understanding, not instructions for implementation. They change constantly. They get shorter as the team learns more. Sometimes they get abandoned entirely when the evidence points somewhere else.

That's not failure. That's the process working.