The SaaS discovery workshop: who attends, what is decided, what you keep

Most SaaS projects that run over budget do not fail in the code. They fail in the weeks before it, when a scope nobody tested gets turned into a plan and the plan into a contract. A discovery workshop is the short, structured phase that tests that scope before money goes into building it.

The format varies, but a good one is recognisable. The right people are in the room, the agenda moves from problem to solution to plan, decisions are written down as they are made, and everyone leaves with documents they can act on. This post walks through each of those parts.

What a discovery workshop is for

A discovery workshop turns an idea, or a rough brief, into something a team can estimate and build. It does that by answering a small set of questions together:

• Who is the product for, and what job does it do for them?
• What must the first release include, and what can wait?
• How will it work: the main flows, the data, the integrations, the constraints?
• What will it take to build, and what could go wrong?

For a SaaS product there are extra questions from the start: how customers sign up and pay, whether one account holds many users with different roles, what each customer's data must be kept apart from, and what compliance the target market expects. These shape the architecture, so they belong in discovery, not in the second month of the build.

Who should be in the room

A workshop is only as good as the decisions the people in it can make. On the client side that usually means:

• The decision maker. A founder, product owner or sponsor who can say yes or no to scope on the day. Without one, every decision becomes a follow-up email.
• Someone who knows the users. A person from sales, support or operations who talks to customers, or a founder who has done the early interviews.
• Domain experts for any area with rules of its own: finance, logistics, clinical workflows.
• Your technical lead, if you have one, especially where existing systems must be integrated.

On the delivery side, a small team is enough: a product person or business analyst to run the sessions, a senior engineer or architect to judge feasibility and effort, and a designer to sketch flows as they are discussed. A room of ten people from the vendor is a sign of a sales event, not a workshop.

A typical agenda

The exact shape depends on the product, but most workshops move through the same stages, usually as half-day sessions with work in between.

1. Goals and context. Why the product exists, what success looks like in a year, the constraints (budget range, deadline, regulation) and what is already decided.
2. Users and problems. The main user types, their jobs and their current workarounds. If there are gaps, this is when user interviews get scheduled.
3. Journeys and features. The key journeys drawn end to end, from sign-up to the moment the user gets value, with features listed against each step.
4. Prioritisation. Features ranked for the first release, the next one and later. This is the hardest session and the most important.
5. Architecture and integrations. The system at a high level: main components, data model outline, third-party services, tenancy and security needs, hosting.
6. Risks and assumptions. Everything the plan depends on but nobody has proven, with a way to test each one.
7. Plan and estimate. Phases, team shape and a range of effort for the first release.

Between sessions, the delivery team writes up what was agreed and brings back sketches, questions and draft estimates. The write-up is where vague agreement turns into something concrete enough to disagree with, which is the point.

What gets decided

A workshop should leave fewer open questions than it started with. By the end, these should be settled or explicitly parked with an owner and a date:

• The first release's scope, with a line drawn and the items below it named.
• The primary user and the primary journey the first release serves.
• The pricing model at a level that affects the build (per seat, per usage, free tier or not), since billing touches accounts, limits and data.
• The tenancy model, the roles and permissions, and any data residency or compliance needs.
• The main technical choices: platform, key services, what is bought and what is built.
• What would make the team stop or change direction.

What you should leave with

Decisions spoken in a room are forgotten within a week. The workshop's value lives in what is written down. Expect at least:

• A product brief: the problem, the users, the goals and the measures of success, in a few pages.
• A prioritised scope: features for the first release with enough detail to estimate, and the deferred list.
• User journeys or a clickable prototype of the core flow, tested with a few real users where possible.
• An architecture outline: components, data model sketch, integrations, tenancy and security approach, and the reasons behind the main choices.
• A risk register with each risk's owner and the test that would retire it.
• A delivery plan and estimate: phases, team composition and an effort range with its assumptions stated.

All of it should belong to you, in formats any competent team could pick up.

Useful workshop or theatre

Some workshops are mainly a sales step dressed as a process. Signs of theatre:

• Lots of sticky notes and energy, but nothing ruled out. Every idea survives into the scope.
• No engineer in the sessions, so feasibility and effort are guessed afterwards.
• The estimate arrives as a single number with no assumptions attached.
• The prototype is polished but was never shown to a user.
• The outputs only make sense if the same vendor builds the product.

Signs of a useful one:

• Someone argues with the idea, respectfully and with reasons.
• Features get cut, and the cuts are written down with why.
• Open questions are listed with owners, not hidden.
• The architecture notes explain trade-offs, not only choices.
• You could hand the documents to another team and they could start.

Where to start

Before booking a workshop, write one page: the problem, the users, what you believe must be in the first release, the constraints you already know and the questions that worry you most. Share it with whoever will run the sessions, and ask them to tell you what they would cut. Their answer tells you a lot about the workshop you are going to get.

Our own discovery phase follows this outline: a short, focused stretch before the build that tests demand, fixes the scope and names the risks while they are still cheap to deal with.