The loudest voice loses

The most expensive code I have ever seen was not buggy. It worked perfectly. Nobody used it.

Every engineering leader knows this shape of waste, and has seen the studies on how much shipped software goes unused. That is not a coding problem. Every one of those features passed review, passed tests, shipped clean. The waste happened months earlier, in a meeting, when someone decided it should exist.

Deciding what to build is the hardest question in the software development lifecycle, and we answer it with the least rigor. We spec carefully, we test carefully, we deploy carefully. But the decision that everything downstream depends on usually goes to the loudest voice in the room: the senior title, the most recent customer call, the pet feature someone has been carrying for a year. Volume wins, and then a team spends a quarter building the winner.

I got tired of watching that happen. So we made deciding-what-to-build a governed workflow, the same way we govern writing code.

Discovery as a workflow, not a meeting

Inside the ClickChain AI constitution there is a product discovery workflow, and it treats "should we build this" as a claim that has to survive evidence, not a preference that has to survive a meeting.

It runs in six stages:

• Propose. The opportunity is written down with an evidence bar it must meet, not a slide.
• Research. Personas, journeys, and what users actually said, logged.
• Assess. The codebase as it really is, not as the diagram remembers it.
• Validate. Assumptions ranked by risk and testability, with kill criteria committed in advance.
• Measure. How we will know it worked, defined before anyone builds.
• Plan. A roadmap where every line traces back to something upstream.

Two things make this different from a template. First, every stage ends at a gate where a jury of adversarial AI reviewers deliberates: a critic, a product thinker, a market skeptic, a sage. They return specific, cited conditions, and "blocked" means blocked. Second, everything is auditable. Every stage transition is logged with hashes and verdicts. When someone asks "why are we building this," the answer is a record, not a recollection.

The jury has blocked me. On our own product roadmap, the first pass came back blocked with two critical findings. The plan I was proud of had an activation metric that could not actually be measured and an installer that could corrupt a user's setup and poison the very experiment we were running. I did not lose an argument to a colleague. I lost it to evidence, and the roadmap that survived is better than the one I wrote.

What it looks like when it works

Three moments from real projects, no names.

A modernization of a decades-old financial system, fixed price, still in flight. Discovery did not just start the project, it keeps re-scoping it. When the evidence said the original sequencing was wrong, a discovery run re-planned the how while the contract's what stayed fixed, and the change sits in the roadmap's changelog with its reasoning attached.

When the client's own tester found a real discrepancy, that finding became a governed study, then a fix, then permanent tests. And the client does not get documents to wade through. On this engagement they get a short list of decisions with a worked example for each, and sign-off on those decisions takes a sitting, not a review cycle.

A sales-intelligence product built with a partner. Version two replaced a mature, already-validated interface with something new and thinner, and my partner felt the loss immediately. In most companies that becomes the fight: his conviction against the team's momentum, and whoever argues better wins. We ran a discovery instead. It grounded what actually existed in the code, found that nothing had been deleted, only routed out, and the jury returned a conditioned verdict: revive the proven surface, make the new engine power it, resequence the slices. Nobody won the argument. There was no argument. There was a finding.

And our own product, where discovery cut features I liked. A persona marketplace we had already built parts of: not on the critical path, dropped, with the honest note that the underlying need was never re-validated. A whole in-app workspace: deferred, with the reasoning recorded so we do not re-litigate it every quarter. The riskiest assumption got a numeric kill line committed before any user saw the product, so warm feedback from friendly early users cannot quietly flatter us into believing it worked.

Why clients say yes

Here is the part that surprised me. I expected governed discovery to be a quality story. It turned out to be a sales story.

When you walk a client through a discovery output, you are not pitching. You are showing them their own decision, already de-risked: the assumptions named, the riskiest ones tested first, the kill criteria that protect them if the bet is wrong, the roadmap where every line has a receipt. The conversation stops being "trust us" and becomes "here is exactly what you would be paying for, and here is how you will know if it is working."

At that point the decision gets simple, because saying no means walking away from work that has already been made falsifiable, priced, and sequenced. The pattern I keep seeing in those conversations is the same: walking away starts to feel like leaving money on the table.

The quiet ending of the loudest voice

None of this makes the humans less important. It makes them more important, at the right altitude. My team and I still make the calls: what matters, what is worth betting on, when to pivot. But we make them against evidence a governed process produced, and we make them on the record.

The loudest voice in the room did not lose to a louder one. It lost to a workflow that asks, politely and every single time: what is the evidence, and what would prove you wrong?

That question, asked before a line of code is written, is worth more than everything we used to build instead of asking it.