You booked three hours with the executive sponsor, the operations lead, two power users, and your CTO. Ninety minutes in, the conversation is stuck on a debate about which dashboard should load first, nobody has agreed on what problem you are solving, and the loudest person in the room is winning by volume.
This is the most expensive failure mode in software: building the wrong thing very well. A custom software discovery workshop exists to prevent it, not by producing a perfect spec, but by forcing the decisions that later become change orders, scope fights, and rewrites.
Below is the agenda we use when running these sessions, the facilitation moves that keep them honest, and the output checklist that tells you whether the day was worth the calendar invite.
Key takeaways
- A discovery workshop is a decision-forcing event, not a requirements interview, you leave with agreed problems, constraints, and a prioritized scope boundary.
- Cap attendance at 6-8 people with real authority; separate the business session from the technical deep dive so neither gets crowded out.
- The facilitation script matters more than the agenda: park solutions, ask for evidence, and make tradeoffs explicit rather than averaging everyone's opinion.
- Every session must end with named owners, open questions logged with deadlines, and a one-page output pack, not a 60-page transcript.
- Never let the workshop produce a fixed estimate. It produces enough clarity to scope, and estimates come after the unknowns are priced.
The agenda: a software discovery workshop agenda that actually fits in a day
One day is usually enough for a mid-sized product. Split it into two halves with different audiences, and resist the urge to invite everyone to both.
Morning, business context and problem framing (2.5 hours)
- Framing and ground rules (15 min). State the goal out loud: "By the end of today we will agree on the problem, the constraints, and the scope boundary for the first release." Explicitly say that solutions proposed today are provisional.
- Problem statements, one per stakeholder (30 min). Each person writes their problem on a card in the format: "Today, [role] cannot [outcome] because [obstacle], which costs us [impact]." No software mentioned yet.
- Current-state walkthrough (45 min). Trace the actual workflow end to end, including the spreadsheet hacks and the Slack workarounds. This is where you discover the real system.
- Success criteria and constraints (30 min). What does success look like in measurable terms? What are the non-negotiables, regulatory, contractual, integration, timeline?
- Scope boundary draft (30 min). Build three columns: must-have for launch, next, and explicitly out of scope. The out-of-scope column is the most valuable one you will write all day.
Afternoon, technical and delivery deep dive (2.5 hours)
- Systems and data map (45 min). What systems exist, what data lives where, who owns it, and which integrations are mandatory versus nice-to-have.
- Constraints and risks (30 min). Security, compliance, hosting, existing vendor contracts, internal team capacity.
- User and role inventory (30 min). Who uses this, what permissions differ, and what happens at the edges, the admin, the auditor, the person who leaves the company.
- Unknowns and assumptions log (30 min). Every assumption gets an owner and a date. This log becomes the to-do list that unblocks the estimate.
- Wrap and next steps (15 min). Confirm who reviews the output pack, by when, and what decision the group is being asked to make.
If your stakeholders cannot give you a full day, run the morning session live and send the technical deep dive as a structured questionnaire. What you cannot do is skip the problem framing, that is the part that saves money later.
How to run a discovery workshop for software without it turning into a debate club
Agendas do not fail. Facilitation fails. These are the moves that keep a stakeholder alignment workshop for software projects productive.
Separate problems from solutions, physically
Keep two visible spaces: one for problems and one for parking solutions. When someone says "we should build a mobile app," write it in the parking lot and ask, "what problem would that solve?" Nine times out of ten the problem is clearer and cheaper to solve than the proposed solution.
Ask for evidence, not opinions
"How often does that happen?" and "what happens when it does?" are your two best questions. Opinions are cheap and loud; frequencies and consequences are specific and testable. When two stakeholders disagree, ask them to describe the last time it actually happened.
Make tradeoffs explicit
When the group wants everything in the first release, put the tradeoff on the board: scope, timeline, or team size, pick two to hold fixed. People rarely agree on priorities in the abstract, but they almost always agree once the cost of "everything" is visible.
Assign a decision owner per topic
Consensus is not the goal; accountable decisions are. For each major area, data model, integrations, UX, compliance, name the single person who decides and the people who must be consulted. Ambiguous ownership is what turns a requirements document into a negotiation six weeks into the build.
Timebox ruthlessly and park openly
Use a visible timer and a parking lot that everyone can see. Parking a topic is not dismissal, it is a promise that it will be revisited with the right people in the room. Follow up on parked items in writing within a day, or the trust you built evaporates.
Custom software requirements gathering workshop: what to capture
The output is not a specification. It is the raw material for one. Capture these artifacts during the session, not after it.
- Problem statements in the user's own words, deduplicated and ranked.
- Current-state workflow as a diagram or numbered steps, including the manual workarounds.
- Success metrics the business will actually measure, cycle time, error rate, manual hours, revenue per customer.
- Scope boundary with must-have, next, and explicitly out of scope.
- Systems and data inventory with owners and integration priorities.
- Constraints: regulatory, contractual, technical, and organizational.
- Assumptions and open questions with a named owner and a due date for each.
- Decision log recording what was decided, by whom, and what alternatives were rejected.
Two artifacts deserve special attention. The rejected alternatives list prevents the same debate from resurfacing in month two. The open questions list is what separates a workshop that unblocks a build from one that just produces meeting notes.
The output checklist: did the workshop actually work?
Score the session against these questions before you call it done. If you cannot answer yes to most of them, you have more discovery to do.
- Can you state the core problem in one sentence that every attendee would sign?
- Is there a written scope boundary that names what is out?
- Does every open question have an owner and a deadline?
- Did you identify the systems and data sources the build depends on?
- Is there a named decision-maker for each major area?
- Could an engineer who was not in the room read the output pack and understand what is being built and why?
If the answer to the last question is no, the workshop produced conversation rather than clarity. That is fixable, but only before the build starts.
A note on estimates, and why the workshop should not produce one
Stakeholders often want a number by the end of the day. Resist. A workshop surfaces unknowns; it does not resolve them. The honest sequence is: workshop, then a short investigation phase to price the unknowns, then a scoped estimate with explicit assumptions. Anyone who gives you a confident fixed price on the same day is either guessing or padding, and you will pay for both later.
What the workshop should produce is the shape of the solution and the boundary of the first release, enough for a build team to scope the work seriously and for you to make a real go/no-go decision.
Avaton runs discovery workshops and then builds the software that comes out of them, so if you want a facilitator in the room rather than a vendor pitching features, that is the kind of work we do. You can see how past engagements were structured on our project work, or read more practical guidance on our blog.
Frequently Asked Questions
Who should attend a custom software discovery workshop?
Keep it to six to eight people who can make or influence decisions: the executive sponsor, the operational owner of the process, one or two real end users, and a technical representative. Invite observers only if they genuinely need context, because every extra attendee slows decisions and dilutes candor.
How long should a discovery workshop take?
One focused day works for most mid-sized products, split into a business session and a technical session. Smaller or well-understood projects can fit into a half day. Complex, multi-team or regulated environments often need two sessions spread across a week so people can check facts between them.
What is the difference between discovery and requirements gathering?
Discovery is broader: it establishes the problem, the constraints, the success metrics, and the scope boundary. Requirements gathering then translates that agreed context into specific functional and non-functional requirements. Running requirements gathering without discovery is how teams end up with a precise specification for the wrong product.
Should the workshop produce a fixed price or estimate?
No. A workshop surfaces unknowns and assumptions; it does not resolve them. The reliable sequence is workshop, then a short investigation to price the unknowns, then a scoped estimate with stated assumptions. Fixed numbers produced on the same day are guesses dressed up as commitments.
What is the single most important output of a discovery workshop?
The scope boundary, especially the list of what is explicitly out of scope for the first release. It is the artifact that prevents scope creep, gives the build team a defensible target, and lets stakeholders see exactly what they are trading away.
Cover: Photo by Walls.io on Pexels