Discovery vs Delivery

Suppose a team spends three months building a feature perfectly.

It is stable.

Fast.

Well designed.

Users barely care.

The team solved the delivery problem.

It did not solve the product problem.

Discovery is the work of reducing uncertainty about what should be built.

Questions include:

• Is this a real problem?
• Who has it?
• How painful is it?
• What solution might work?
• Which assumptions are risky?

Discovery reduces the chance of building the wrong thing.

Delivery is the work of turning the chosen solution into a working product.

Questions include:

• How should it be designed?
• How should it be built?
• What dependencies exist?
• How do we test it?
• How do we release it safely?

Delivery reduces the chance of building the thing badly.

Bad mental model:

Discovery finishes. Then delivery starts.

Real teams often do both at once.

Engineering may discover a constraint during implementation.

A prototype may reveal a new user problem.

New data may change the scope.

Learning continues during delivery.

You want to add automatic meeting summaries.

Discovery reveals users want summaries mainly for decisions and action items.

Delivery reveals speaker identification is unreliable in noisy calls.

That technical reality may change the product:

Ask users to confirm speakers before finalizing the summary.

Discovery and delivery influenced each other.

A PM should know which uncertainty the team is reducing.

Sometimes the next best step is:

talk to users.

Sometimes:

build a prototype.

Sometimes:

ship the smallest safe version.

Sometimes:

investigate a technical constraint.

Discovery reduces the risk of building the wrong thing.

Delivery reduces the risk of building the thing badly.

Strong product teams keep learning during both.