Discovery is a short phase before development where the supplier works with you to understand the problem, the users and the existing systems, then turns that into a plan. It is not a sales pitch and it is not a build. Its output is clarity: what to build, in what order, how it will work technically, and what it is likely to take.
What discovery covers
- The problem and the users. Who needs this, what they do today and what success looks like.
- Scope and priorities. What belongs in the first release and what waits.
- Existing systems and data. What the new software must connect to, and what state the data is in.
- Technical approach. Architecture, hosting, security and third-party services.
- Risks. What could delay or derail the project, and how to reduce it.
- Plan and estimate. An order of work and a range based on what was learned.
What you should receive
- A written summary of scope and priorities.
- A technical outline another team could read.
- A list of risks and assumptions.
- A delivery plan with milestones.
- An estimate you can compare with other suppliers.
- In some cases, designs or a clickable prototype.
These belong to you. If a supplier will not hand them over without committing to the build, treat that as a warning.
When it is worth it
Discovery pays off when requirements are unclear or disputed inside the business, when the software has to connect to several existing systems, when you need a business case or budget approval, or when the cost of getting it wrong is high. A small, well-understood change may not need it; a short planning conversation can be enough.
Who should be in the room
- Someone who can make decisions and say no, because scope needs a decision-maker.
- The people who use the current process every day, because they know where it really hurts.
- Whoever looks after the existing systems and data.
- Finance and security or data protection, when the software handles money or personal data.
What to prepare
You do not need a finished brief. A short pack saves days: a plain description of the problem and who it affects, examples of the documents, screens or spreadsheets used today, a list of the systems the software may connect to with access arranged, and any deadlines, budget limits or rules that cannot move.
What the work looks like
It usually combines conversations with users, a review of the existing systems and data, and working sessions to settle scope and priorities. Some discoveries include a clickable prototype, so people can react to something real rather than a document. Many run for a few weeks, but a supplier should give you a defined scope, timeline and price for the discovery itself before you start.
Warning signs
- A fixed price for the whole build after one meeting.
- No questions about your users or data.
- Deliverables that exist only inside the supplier's tools.
- Nobody willing to say what should be left out.
The honest outcome of discovery is sometimes "do not build this yet", or "a simpler option solves it". That result is worth paying for.
The full guide is on the Cognivise blog. To talk about planning a project, see planning and technical advice.
Top comments (0)