Discovery is a track, not a phase

Discovery as a phase means somebody researches for six weeks, produces a conclusion, hands it over, and the team builds it.

The problem isn't the research. It's the handover.

By the time delivery starts, discovery is over. And everything learned during the build has nowhere to go, which matters more than it sounds, because building something is the most rigorous way there is to discover what you didn't understand about it.

No track is still running to absorb any of it.

So it goes into the backlog as a "phase two" nobody ever prioritises.

And the thing ships as specified.

Two tracks, always running

The alternative is dual track.

At any moment one track delivers what was validated, and another validates what comes next. Continuously, side by side, with the same people moving between them.

Concretely, in a given fortnight.

The team ships the thing decided last month. In parallel, the trio plus one or two engineers talk to customers, build prototypes, and kill bad ideas about the thing coming after.

The distinguishing property, and the reason this isn't just phases overlapping.

What's learned in delivery feeds discovery immediately. What's learned in discovery redirects delivery next. Neither waits for a boundary.

It also means discovery is never a project with a start date.

Which matters, because a discovery project has to produce a conclusion to justify itself, and that's exactly the pressure that turns research into theatre.

What it costs

The usual objection is engineering capacity, so let's price it honestly.

Roughly ten to fifteen percent of a team's engineering time, ongoing.

One or two engineers, a day or two a week, on the next thing rather than the current one. Joining customer conversations. Building throwaway prototypes. Spiking a technical unknown.

Sounds like a real cost. It is.

Now price the alternative. The industry number for features that don't get used or don't move the metric sits around half, and my own experience isn't better than that.

Move the hit rate from fifty percent to sixty-five and discovery has paid for itself several times over, because the wasted half isn't only the build cost. It's the build cost plus the permanent run, support and removal costs described in the saying-no lesson.

That's the argument when somebody proposes cutting discovery to go faster.

Cutting it doesn't produce more output. It produces more output of unknown value, and unknown-value output is the expensive kind.

Engineering's seat

The specific thing I'd protect: engineering is in discovery as an input, not as a gate at the end.

The gate version: a solution gets designed, validated with users, then handed to engineering for a feasibility review.

At that point feasibility can only be a veto or a rubber stamp. And everyone has an incentive for the rubber stamp, because a lot of work has already gone in.

The input version: an engineer is in the room while options are still open.

What they contribute isn't "can we build it." That's nearly always yes. It's the cost gradient. This approach is a week. That one is a quarter. And this third one you haven't considered gets you eighty percent of the value using something you already have.

That third sentence is the one that makes discovery pay, and it can only be said by someone who knows the system, early enough to matter.

One engineer is enough.

It doesn't have to be the same one, and rotating is better for spreading context. As long as it isn't so rotated that nobody accumulates any.

When discovery has quietly stopped

It decays without announcement, and these are the signs.

The discovery output is always yes.

Nothing killed in six months means you aren't validating. You're building a case for decisions already made.

Research happens after the roadmap is set.

The order tells you what the research is for.

Nobody in engineering can tell you why the current thing is being built, beyond who asked for it.

The prototypes are getting more polished.

Discovery prototypes should be embarrassing and disposable. Once they start looking like production work, discovery has merged into delivery and all you've added is a design phase.

And the most reliable one. No engineer has spoken to a customer in the last month.

Five-second check, and it correlates with everything else on this list.

Making it real without a research department

Small companies hear "continuous discovery" and imagine a research function they can't afford.

The lightweight version is genuinely lightweight.

Three customer conversations a week. Held by the trio, every week, forever.

Not a research programme. Fifteen to thirty minutes each, about what they're doing rather than about what they want.

That single habit does more than any formal process, and it's the one thing I'd protect if everything else got cut.

One prototype for anything expensive or contested. Built in a day or two. Thrown away.

And a written record of what was learned and what got killed. Short.

The killed list is the one that proves the track is real.

The thing to watch for in yourself

Discovery is uncomfortable for engineering leaders.

It produces evidence that the plan is wrong. Usually after you've defended the plan in front of other people.

The organisation takes its cue from how you handle that.

Treat a finding that kills committed work as valuable news and discovery keeps working. Treat it as an inconvenience and everyone keeps doing discovery, which keeps finding that the plan was right.