Product Discovery

The work of deciding what is worth building before building it, run as a track parallel to delivery rather than a phase before it. Discovery tackles the question "should we build this, and will it work?" through fast, cheap experiments; delivery answers "can we build it well?" The two run continuously and feed each other.

Why it Matters

Most features fail not because they were built badly but because they should not have been built at all. Separating discovery from delivery puts the riskiest question first and answers it with prototypes and evidence, not with months of engineering. When code is cheap to produce, the scarce and decisive work shifts to discovery: deciding what to build and establishing that it solves a real problem.

Signals

• A backlog of features handed down to be built, with no evidence they will work.
• "Validation" that happens only after launch, when it is expensive to be wrong.
• Discovery treated as a one-time upfront phase rather than an ongoing track.

Benefits

Fewer expensive mistakes, faster learning about what customers actually need, and engineering effort spent on ideas that have already survived cheap tests.

Risks

Discovery theater that produces artifacts without real evidence; endless discovery that never commits to building; treating discovery and delivery as sequential rather than parallel.

Tensions

Discovery takes time that pressures to ship resist, yet skipping it trades a little speed now for a large risk of building the wrong thing.

Examples

Testing a feature's value with a prototype before committing engineers to it; running discovery for the next bet while the current one is being delivered.