10-Jul-26
A few years ago I watched a team spend two weeks writing a requirements document. It went through three rounds of review. Stakeholders signed off. Engineers built it. And the first time anyone saw the thing running, it was obviously wrong. Not wrong in the details. Wrong in the premise.
Nobody had lied and nobody had been careless. The document was accurate. It just described something none of us could actually picture until it existed.
That was the last time I let a written spec be the source of truth on my teams.
What changed
Building a rough working version of something used to be expensive, which is why we invented documents as a cheaper proxy. That math has flipped. A competent engineer with modern tooling can now put a clickable, half-real version of a feature in front of a stakeholder in a day or two. When the cost of showing drops below the cost of describing, describing stops making sense.
So we stopped. Requirements now live in the prototype. Stakeholder sessions run against something on a screen that responds when you click it. The conversation shifts from “does this document capture what I meant” to “no, not like that, like this,” which is a far more useful sentence to hear early.
The prototype is not a mockup and it is not a throwaway. It is the artifact everyone argues about, and it usually becomes the first version of the real thing.
The part people resist
This breaks a role that many organizations depend on: the person in the middle who translates business intent into engineering instructions and back again.
When the prototype is the spec, that translation layer has much less to do. Engineers talk to the people who need the thing. They ask why. They hear the business constraint directly instead of receiving it filtered through a ticket. Some engineers hate this and will tell you it is not their job. Others discover they are good at it and never go back.
I have found this to be the sharpest signal I have about who to build a team around. Not raw technical ability, which is easy to assess and widely available, but whether someone reaches for context or waits to be handed it. The people who ask what the business is trying to do are the ones you want owning outcomes. The people who want a fully specified task are telling you something honest about the level they want to operate at.
Where it does not apply
I would not run a compliance or payments flow this way. Anything with legal exposure needs a written decision trail, and “we prototyped it and it felt right” is not a defense. Regulatory work still gets documents, and it should.
Everything else gets built.
If you try one thing
Take your next feature and skip the requirements doc entirely. Give an engineer two days and direct access to whoever asked for it. Have them show something rough on day three.
You will learn more about the feature in that meeting than in a month of review cycles. You will also learn a lot about the engineer.