The Spec Graveyard

Somewhere in your shared drive there is a document nobody opens. It has a version number in double digits, a table of contents four levels deep, and a sign-off page with three signatures on it. It cost a quarter of someone's salary to produce. When the project finally shipped, the team built from memory and hallway conversations, not from the document. The spec sat there the whole time, authoritative and ignored. That's the spec graveyard, and most growing companies have one.

The instinct behind it is reasonable. You're about to spend real money building software, you can't write the code yourself, and you want to know what you're getting before you commit. So you ask for everything to be written down first. Every screen, every rule, every edge case, agreed and signed. It feels like control. It feels like the responsible thing a founder does with other people's money and their own runway.

The problem isn't that the spec is too detailed. The problem is timing. A big upfront specification asks you to make your most consequential decisions at the moment you know the least. You haven't shipped anything, no customer has touched it, and your understanding of the problem is at its thinnest. You commit it all to paper anyway, because the document demands answers in boxes that can't be left blank. Then reality arrives.

The document is obsolete before it ships

Markets move. A competitor launches the feature you scoped for Q3. A regulation changes. Your best customer asks for something nobody anticipated, and it turns out to matter more than half of what's in chapters four through nine. The world keeps editing itself while your specification stays frozen at the date it was signed. By the time the build catches up to page 600, the early pages describe a company that no longer exists.

This is the quiet violence of the big spec: it converts learning into rework. Every genuine thing you discover while building, the discoveries that should be your most valuable asset, now contradicts a document somebody approved. So a discovery doesn't feel like progress. It feels like a problem. It triggers a change request, a re-estimate, an awkward conversation about scope. The spec turns the act of getting smarter into a cost centre. A process that should reward learning starts punishing it.

A specification frozen at the start of a project is a bet that you understood the problem perfectly before you'd seen it work. You didn't. Nobody does.

And the rework isn't free. Across 1,471 IT projects, the average cost overrun ran to 27%, but the average hides the real danger: one in six projects blew through budget by 200% and ran roughly 70% over schedule (Flyvbjerg & Budzier, HBR 2011). Those aren't projects that were managed carelessly. They were projects that committed hard and early to a plan, then discovered the plan was wrong somewhere around the point of no return. The fat tail is where the spec graveyard buries you. Not the average miss. The catastrophe nobody could course-correct out of, because the whole apparatus was built to resist change.

Nobody reads it anyway

Here is the part that should bother you most. Even when the spec is good, the people building from it largely don't use it. A developer facing an ambiguous screen will ask the person next to them before she scrolls to section 7.3. Engineers build from the conversation in the room and the ticket in front of them. The document is a reference of last resort, consulted mostly to settle arguments about what was agreed, which means it functions less as a blueprint and more as a contract you reach for when something has already gone wrong.

You can see the same waste from the customer's side. Pendo studied how people actually use the software they pay for and found that 80% of features are rarely or never used, while around 12% drive most of the usage (Pendo 2019 Feature Adoption Report). Read that against a thousand-page spec and the maths is grim. You paid to specify everything. You paid to build most of it. And most of what you built, nobody touches. The spec's great promise was completeness. Completeness turns out to be the expensive way to deliver a pile of features your customers will never open.

None of this means planning is the enemy. You should think hard about what you're building and why. The failure isn't thought. It's the format: a single monolithic document, decided once, defended forever, that mistakes the volume of detail for the reduction of risk. The risk it was meant to kill, the risk of building the wrong thing, is exactly the risk it makes worse, because it locks the wrong thing in before you could possibly know it was wrong.

Smaller is the whole game

So if the monolith is the problem, what's the fix? The data points in one direction, and it's not subtle. The Standish Group's CHAOS research, looking across thousands of projects, found that small projects succeed 61% of the time. Grand projects, the big-bang efforts the thousand-page spec is built to govern, succeed just 6% of the time (Standish CHAOS 2015).

Sit with that gap. It isn't 61 versus 50. It's 61 versus six. The single strongest predictor of whether a software project lands isn't the talent on it, the methodology, or the budget. It's size. The smaller you cut the work, the more often it actually ships.

(Standish CHAOS 2015. "Challenged" means delivered late, over budget, or short of scope.)

That table is the argument of this entire part of the book, in two rows. The thousand-page spec is a machine for producing the bottom row. It takes work that could have been cut into small, shippable pieces and welds it into one grand project that the numbers say has a 6% chance of going well and a 43% chance of outright failure. You don't fix that by writing a better spec. You fix it by refusing to build a grand project at all.

The alternative isn't planning less. It's planning in a different shape. Instead of one document that decides everything before anything ships, you break the work into small units you can scope, build, and verify one at a time. Each piece is small enough to succeed at the 61% end of the table. Each one ships, gets used, and teaches you something real before you commit to the next. Learning stops being rework. It becomes the input to what you do next.

That unit has a name, and the whole operating system is built around it.

Next: the task. What a unit of work looks like when it's small enough to actually finish.