What Product Teams Get Wrong About Discovery
Discovery is not a phase. It's not a set of methods. It's a disposition - a commitment to staying in contact with reality.
Samuel (center) leading a Slalom Build discovery team.
The word discovery has become overloaded in product circles. It now refers to so many different things: user research, market analysis, opportunity identification, problem framing, prototyping, that it’s in danger of losing meaning entirely.
What I’ve seen in practice is that most teams treat discovery as a phase: something you do before development, a box to check before you’re allowed to start building. You run some user interviews, maybe a survey, you make a journey map, you present findings to stakeholders. Then you’re done with discovery and you start building.
This is exactly wrong, and it leads to the most common and most painful failure mode I know in product development: building things that don’t work, not because the engineering failed, but because the underlying assumptions were wrong.
The problem is that discovery as a phase treats uncertainty as something you can exhaust. Do enough research and you’ll know what to build. But uncertainty isn’t exhaustible, it’s structural. The world is complicated, users are complicated, and your understanding of both is always partial and always potentially wrong.
What good discovery teams do, the ones that consistently build things that actually work, isn’t do more discovery. It’s maintain a continuous state of epistemic humility. They keep asking: what are we assuming? How would we know if we were wrong? What would change our mind?
This isn’t a phase. It’s a disposition. And it doesn’t end when development starts.