Specification accuracy is not problem accuracy (2/6)

This newsletter is a six-part sequence built on one anchor: AI is compressing the prototyping cycle — but faster technical iteration without parallel commercial assumption-testing doesn't reduce risk, it accelerates the gap. Perspective 2 takes that gap from one specific angle: specification accuracy is not problem accuracy. Each edition puts one assumption under the knife. None of them end with a fix. The terrain is the point — you locate yourself in it.

The Assumption

If the prototype matches what the customer specified, the customer's problem is addressed. Sign-off on the spec is treated as evidence that the underlying pain has been solved, rather than as evidence that a request was accurately transcribed.

The Reality Check

The prototype matched the specification line for line. The champion signed off. Six months after launch, the plant floor was still running the spreadsheet it was built to replace.

The Forensic Analysis

Five links typically sit between the pain and the artifact meant to solve it:

1) the user experiencing it,

2) the internal champion who translates it into a request,

3) the founder who interprets that request,

4) the AI system that turns the interpretation into a formal specification, and

5) the prototype built to match that specification.

Each link loses fidelity on its own terms — the champion compresses nuance into something politically sellable internally; the founder fills the gaps with what's technically buildable; the AI-assisted spec formalizes whatever ambiguity survived into confident, well-structured requirements. AI doesn't shorten this chain. It makes the last link faster and more convincing — a spec that reads as precise and complete regardless of how much of the original pain it actually carries. The system optimizes for producing a spec that looks right, not one that is right. And the champion who wrote the request usually has the strongest incentive to call that spec the finish line: it closes their ticket, protects their credibility, and moves the risk downstream to whoever has to make the tool work in production.

The opener of this series referenced GE Predix, GE's industrial IoT platform, built to make GE — in Jeff Immelt's stated ambition — a top-ten software company. The technical build was not where this one broke: by 2014, GE was reporting over a billion dollars in Predix-linked revenue and real engineering wins, including fleet analytics that flagged jet-engine maintenance needs before failure and pipeline risk-assessment tools built exactly to specification. The commercial outcome ran a different course. GE Digital's investment losses were later estimated at close to $4 billion (Westerman, Bonnet & McAfee, Leading Digital, Harvard Business Review Press, 2018), and the documented pattern isn't a technical one — GE built to what customers and internal champions specified, and those specifications outran what plant-level operators could use or were willing to change their workflow around. The prototype matched the spec. The spec had already lost the plant floor.

Open Questions

Incentive

• Who benefits when a signed specification, rather than a working outcome, is treated as proof the problem is solved?
• If the person who wrote the request and the person who has to live with the tool are different people, whose definition of "done" is the spec actually protecting?

Comparative

• Why does an identically spec-perfect build succeed with one team and fail with another?
• What would change if adoption, not sign-off, were the tracked milestone?

Destruction Desk
We perform autopsies on innovation’s failed assumptions.

This newsletter was edited by Manfred Lueth.

You received this email because you signed up for this newsletter from DestructionDesk.com.
To stop receiving this newsletter, unsubscribe or manage your email preferences