Discovery Workshop Guide
A discovery workshop compresses weeks of ambiguity into a few structured sessions that end with a scope, a risk list and a first view of cost. This guide sets out who should attend, what to prepare, how the sessions run, and what you should hold in your hands at the end.
Start your project
What a discovery workshop is for
The workshop exists to answer one question: what should be built first, and why? It is not a sales presentation or a design competition. It replaces assumptions with written decisions, so that an estimate can be given for a defined thing rather than a hope.
When it fits and when it does not
- It fits when a goal is clear but the route to it is not, for example a new product, a replatforming, or an internal tool with many stakeholders.
- It fits when several teams disagree about priorities and need a neutral facilitator.
- It is less useful when a specification already exists and has been tested with users; a short technical review may be enough.
- It is not a substitute for user research where the users are unknown; research may need to come first.
Who should be in the room
Decision-maker
Someone with authority over scope and budget, present for the sessions where priorities are set.
Domain expert
A person who does the work today and knows where the process really breaks.
Technical owner
The lead for existing systems, who can explain integrations, data quality and constraints.
Renvric facilitators
A delivery lead, an architect and, where relevant, a designer who challenge assumptions and record decisions.
Share the outcome you need and Renvric will recommend the smallest useful next step.
What to prepare beforehand
- A one-paragraph statement of the outcome you want and how you will know it has been achieved.
- Access to, or screenshots of, current tools and a list of systems that connect to them.
- Any fixed dates, regulatory requirements or contractual commitments.
- A list of known users and the tasks they perform, even if rough.
- Examples of reports, forms or data exports that the new system must reproduce.
- An honest note of what has been tried before and why it stalled.
A typical agenda
Goals and constraints
Agree success measures, boundaries and what is out of scope.
Journey mapping
Walk through the real process end to end and mark pain points.
Options and risks
Sketch two or three approaches and list what could go wrong with each.
Prioritisation
Sort outcomes into first release, later and not now.
Playback
Review the written decisions together and correct them before anyone leaves.
What you should leave with
A scope outline with a first release defined, a prioritised outcome list, a risk and assumption register, an architecture sketch, a view of delivery sequence, and a cost range with its drivers stated. The documents belong to you and can be used with any supplier.
For example, a membership body might leave with a decision to migrate records first and postpone the mobile client, because the data quality risk dominated everything else.
Related areas to explore: Technical discovery workshops and AI Integration Services.
Common questions
Who is this guide for?
It is for sponsors and product owners considering a first workshop, and for the colleagues who will be asked to attend. It explains what is expected of each role so that the sessions are used for decisions rather than introductions.
What information do we need to provide?
A statement of the desired outcome, a description of current tools and connected systems, fixed dates or regulations, and a list of the people who use or are affected by the process. Rough material is fine; the sessions refine it.
How long does a workshop take?
That depends on the number of stakeholders and the complexity of the systems involved. Many are run as a small number of focused sessions over days or a couple of weeks, with written playback between them. The format is agreed with you beforehand rather than fixed.
Do we own the outputs?
Yes. The aim is that the scope, risk register and architecture sketch are usable with any supplier. A good workshop output lets you compare proposals on equal terms, and should not tie you to the team that facilitated it.
What happens after the workshop?
You review the written outputs, correct anything that is wrong, and decide whether to proceed. If you do, the scope becomes the basis of a proposal with defined deliverables and acceptance criteria. If not, you still hold a clearer picture than you started with.
Keep exploring
Absent decision-makers, vague success measures and attendance by people who do not use the system are the usual causes of a weak result. Another is treating the workshop as a place to produce a final design; the aim is clarity, not polish.