The problem with most discovery
Discovery phases often produce one output: a presentation. The presentation gets approved, filed, and forgotten. The team that builds the thing starts from scratch because the discovery artefacts — personas, journey maps, research summaries — are in a format that doesn't translate into engineering decisions.
Discovery that feeds into delivery
The output of discovery should be decisions, not data. Not 'users want a faster checkout' but 'we will reduce checkout to two steps by combining address and payment'. Not 'users are confused by navigation' but 'we will move account settings out of the primary nav into a user dropdown'. Specific, buildable decisions.
How we run it
We run discovery in two tracks simultaneously: technical and user. Technical discovery maps what we're building onto what already exists — APIs, data models, integration points. User discovery maps what users need onto what we're building. Both tracks run for the same two weeks and converge in a single spec document that engineering can start from immediately.
The document that ships
The deliverable isn't a slide deck — it's a living spec in the team's project management tool, broken into buildable units, with acceptance criteria, linked to the research that motivated each decision. The spec evolves as the team builds. By the time the project ships, it's also a record of why the product is the way it is.