All insights Product R&D

Three Questions Before You Commission a Build

Almost every project that gets proposed is a good idea. That’s exactly why “is this a good idea?” is the wrong test.

Most build decisions get evaluated on the merits of the idea. This is a mistake, and it’s a hard one to see, because the merits are usually real. The proposal is coherent. The problem it addresses exists. Someone smart has thought about it. The idea passes.

Then it ships, and nothing changes.

The questions worth asking aren’t about whether the idea is sound. They’re about whether the organization can absorb it. I ask three before anything gets commissioned. None of them are clever. All of them are routinely skipped.

What business objective does this move, and how would we know?

Not “what does it do.” What changes, measurably, in the business — and what number would we look at afterward to find out.

The bad answer is confident and unfalsifiable: it will improve the experience, it will make us more efficient, it will position us for what’s coming. The other bad answer is that we’ll define the metrics once it’s live. Metrics defined after launch are chosen to be met.

If nobody can name the number before the work starts, the project has no way to fail, which means it also has no way to succeed. It will simply exist.

Show me eighteen months, not version one.

Anything can be made to demo well. The question is what the second and third releases look like, and whether they make sense given what the first one costs.

Most things that die don’t die at launch. They die about seven months in, when it becomes clear there was never a plan past the thing that got approved — no owner budgeted for the next phase, no roadmap anyone believed. A build with no second act is a demo with a longer timeline.

Does this accelerate what we’re already doing, or stop business as usual?

Both are legitimate. Confusing them is not.

If it accelerates, it has to fit the way work is already done, and the bar is whether people will use it without being made to. If it stops business as usual, the technology is the small part — the hard part is the process being replaced and the people who own that process.

Projects fail here more than anywhere else. Something that requires a real change in how the organization works gets scoped, funded, and staffed as though it were a convenience. Then it lands, and the old way is still there, because nobody was ever asked to give it up.

“Ask them before the work starts. Afterward they’re just an explanation.”