Discovery workshops have a bad reputation, mostly earned. Too often they're agency-led performance art that produces a Miro board nobody refers to again. Done well, they're the highest-leverage week of the entire project. They replace months of back-and-forth scoping with a written, signed-off scope by Friday afternoon.
Here's the format I've seen actually work, after running and observing dozens for Australian businesses.
What a real discovery workshop produces
By end of day five (or whenever the workshop ends), you should have:
- A written scope document, two to four pages, agreed by both sides.
- A flat list of features, each with a one-line description, ordered by priority.
- A data model, even just on a whiteboard, that names the core entities.
- An identified critical path, the smallest set of features that proves the product works.
- A fixed price (or phased fixed prices) and a timeline with milestones.
- An exclusion list, what's not being built.
If you finish the workshop and don't have all six, the workshop didn't work. Don't sign the contract yet.
Who's in the room
Everyone the project depends on, nobody else.
- The founder or product owner. The person who'll be making decisions during the build.
- One internal subject-matter expert. Someone who actually does the work the software is automating. Not their manager.
- The senior developer. The person who'll be writing or leading the code.
- The designer. If design is in scope.
Avoid: stakeholder committees, observers from other departments, anyone whose role is "providing input." They slow everything down.
The two-day format that works
Day one: understand the work
- Morning: the SME demonstrates the current process end-to-end. The developer asks questions. The founder takes notes on what's painful, what's manual, what users complain about.
- Lunch: developer reviews notes alone. Drafts a working data model.
- Afternoon: all hands review the data model. Argue. Refine. Identify the entities, the relationships, the rules.
Day two: design the solution
- Morning: map the user flows on a whiteboard. Five to seven core flows, no more. For each: who triggers it, what data it needs, what data it produces.
- Lunch: developer + designer go away with the flow map. Sketch screens.
- Afternoon: review sketches with the founder. Cut anything that doesn't earn its place. Lock the v1 scope.
If you have five days, not two
Days three to five are about turning the day-two output into something signable:
- Day three: Figma prototype of the core flows. Click-through, not pixel-perfect.
- Day four: founder tests the prototype with two or three real users. Notes fed back into scope.
- Day five: developer writes the scope document and the fixed price. Founder reads it. Both sides sign.
The point of a discovery workshop isn't to be thorough. It's to make decisions quickly, in a room, that would otherwise take three months of email threads.
What to ban
- Tech stack debates. Not your call as the founder. Not the workshop's job. Defer to the developer.
- "What if we also built…" tangents. Capture them on a parking lot list. Don't expand scope.
- Slide decks longer than five slides. Discovery is conversation, not presentation.
- Stakeholder reviews mid-workshop. Decisions need to be made in the room. If five other people need to approve every choice, you're not running a workshop, you're running a focus group.
Anti-patterns I see
- The whiteboard wall. Forty post-its on a wall, photographed, never referenced again. The output is the document, not the wall.
- The endless "what about edge cases." Edge cases are version two. Lock the happy path first.
- The wireframe rabbit hole. Scope first, screens second. Senior developers often skip wireframes entirely.
- The "we need more time." Two-day workshops produce decisions. Five-day workshops also produce decisions. Six-month workshops produce nothing.
What it costs
A discovery workshop with a senior Australian developer or small studio runs $1,500–$5,000 for a two-day version, $5,000–$10,000 for a five-day version. It's the highest-leverage spend in the entire project. Yes, you pay for it. No, that's not a red flag, it's a sign the developer takes scoping seriously.
You should be very wary of any developer who quotes a large project without offering some form of paid discovery. The padding in the quote is the cost of skipped discovery.
The bottom line
Discovery workshops work when they produce decisions. Two days, the right four people in the room, a written scope by the end. Skip the theatre.
If you want three Australian developers who run discovery the way it should be run, FindDevs gets you those quotes. Free, three real prices, in 24 hours.