Skip to main content
All posts
Process5 min read

What a discovery phase should actually produce

A discovery engagement that ends in a slide deck has failed. Here's what it should leave you with.

Share

Discovery has a reputation problem. Too often it means a few weeks of workshops that produce a polished document and no reduction in uncertainty about cost, scope, or risk.

A discovery phase earns its place only if it makes the decision to proceed — or not proceed — meaningfully better informed.

The deliverables that matter

At the end of discovery, you should hold artifacts you could hand to any competent engineering team:

  • A system architecture, including integration points and data flow
  • A domain model covering the core entities and their relationships
  • A scoped build plan broken into reviewable milestones
  • A costed estimate with the assumptions behind it written down
  • A register of the risks that could move that estimate

Portability is the test

The clearest signal of an honest discovery is that its output is useful even if you hire someone else to build it. If the deliverable only makes sense when the same team continues, it was a sales document.

Discovery should reduce risk for you — not lock in the vendor who ran it.

Have a software idea?
Let’s build it.

Tell us what you’re trying to solve. We’ll help you turn it into a practical, scalable software solution.

hello@trevorix.net