A build rarely goes wrong because a team chose the wrong framework. More often, it starts with an untested assumption: that everyone agrees on the user, the problem, the priority and what a useful first release looks like. This product discovery workshop guide explains how to create that alignment before engineering begins – while changes are still relatively cheap.
A discovery workshop is not a ceremonial meeting or a slide-deck exercise. It is a structured working session that turns a broad idea into decisions a product team can act on. Done well, it exposes uncertainty early, protects budget from avoidable rework and gives founders a more credible basis for deciding what to build now, later or not at all.
What a product discovery workshop should achieve
The aim is not to design every screen or produce a complete requirements document. It is to reduce the most consequential unknowns before committing to a scope.
By the end of a useful workshop, the team should be able to describe the target user, their problem, the business outcome being pursued and the smallest sensible product response. They should also understand the main risks: technical constraints, dependencies, data requirements, compliance considerations, unclear ownership or assumptions that need research.
That distinction matters. A workshop cannot prove that people will buy a product or use a new feature. It can, however, identify what must be tested before substantial development effort is committed – which is the whole point of running a product discovery process before a single line of code is written.
For a new SaaS product, discovery may focus on whether a proposed workflow genuinely saves users time. For an established business replacing an internal system, the harder question may be how existing processes, permissions and data will migrate. The format is similar, but the evidence required is not.
Who should be in the room
Keep the group small enough to make decisions. A founder or business owner, product lead, relevant operational expert, designer and senior engineer is often enough. If marketing owns acquisition, involve them where positioning, SEO or conversion journeys affect the brief.
Avoid inviting every stakeholder by default. Large groups create a familiar failure mode: people explain their department’s needs, no one has authority to make trade-offs, and the meeting ends with a longer wish list. The people attending should either bring first-hand knowledge, make decisions or will be responsible for delivering the work.
For complex products, run a short set of focused workshops rather than trying to settle everything in one day. A technical discovery session, for example, may need engineers, security or data owners who do not need to attend early conversations about user needs.
Prepare evidence, not just opinions
The workshop will be sharper if preparation happens first. Ask participants to share existing customer research, sales-call themes, analytics, support tickets, competitor observations, process documents and examples of the current journey. These materials do not need to be polished. They simply give the team something more solid than memory to work from.
It is also worth agreeing who can make final calls. Discovery often reveals conflicting objectives: sales wants flexibility, operations wants fewer exceptions, and users want less effort. Without a named decision-maker, these tensions tend to become unresolved requirements for the development team.
A short pre-work questionnaire can surface disagreement early. Ask each attendee what problem they believe matters most, who experiences it, what success looks like and what they think should be excluded from the first release. Comparing answers is often more revealing than the answers themselves.
A practical product discovery workshop agenda
A good agenda moves from context to decisions. Do not begin by asking, “What features do we need?” Features are possible responses, not the problem itself.
Start with the business outcome
Write a plain-English statement of the change the business wants to create. For example: reduce the time a team spends preparing a recurring report, improve the quality of qualified enquiries, or allow customers to complete a process without staff intervention.
Be precise about how progress will be judged. A measure might be completion rate, time saved, fewer manual steps, reduced support demand or a more reliable operational process. The right measure depends on the product. Choosing one does not mean setting a guaranteed result; it means giving the team a direction for decisions.
Define the user and their current journey
Next, map what the user does today. Where does the process begin? What information do they have? Which steps cause delay, confusion or workarounds? What happens when something goes wrong?
This is where vague personas become less useful than a specific context. “Small business owner” is broad. “A finance lead preparing monthly information from three disconnected systems” gives a team something it can design for.
Include non-happy paths. A workflow that works only when every field is complete, every integration responds and every user has the same permissions is not ready for production. Identifying exceptions early helps avoid a polished prototype that cannot support real operations.
Turn assumptions into questions
Most product briefs contain assumptions disguised as facts. “Users want a dashboard”, “an app is required”, “we need real-time updates”, or “this must integrate with every existing system” may all be true. They still need scrutiny.
Record the assumption, why it matters, what evidence exists and how it could be tested. Some questions can be answered through user interviews or analytics. Others need a technical spike: a short, contained investigation into an integration, data quality, performance requirement or platform limitation. If the uncertainty is really about desirability rather than feasibility, it is usually cheaper to validate the idea with real users before committing engineering time to it.
Prioritise assumptions by impact and uncertainty. A minor visual preference can wait. A dependency that determines whether the core workflow is possible cannot.
Shape the smallest useful release
Now discuss scope in terms of user outcomes. What must someone be able to do on day one for the product to be useful? What would make the experience better but is not necessary to prove the core value? What should deliberately wait?
This is not an argument for making everything basic. A first release still needs to be safe, usable and maintainable. Accessibility, appropriate security, sensible error handling, technical SEO for public pages and performance standards should be built in, not treated as optional extras. The trade-off is usually about breadth, not quality – our guide to defining a genuinely useful first release goes into that distinction in more depth.
A useful framing is to separate the work into four areas:
- Core user journeys that deliver the primary outcome.
- Supporting capabilities needed for those journeys to work in practice.
- Risks or dependencies that need validation before a commitment is made.
- Later opportunities that are valuable but not required for the first release.
This prevents a backlog from becoming a flat list where a password reset, a reporting suite and a speculative AI feature appear equally urgent.
Check the technical shape early
Technical discovery is not about choosing technology for its own sake. It is about recognising constraints while the product can still adapt.
A senior engineer should ask questions about user volumes, roles and permissions, data sources, integrations, devices, offline use, reporting needs, content management, hosting and operational ownership. For a public-facing website, they should also consider Core Web Vitals, search visibility and accessibility from the outset. For an application, audit trails, data retention and failure recovery may be more relevant.
The answer may be that a web application is enough and a native mobile app is unnecessary. It may be that an existing system should remain the source of truth rather than being replaced. These are valuable outcomes, even when they narrow the initial idea.
The outputs that make discovery useful
A workshop earns its keep through what happens afterwards. Within a few days, convert the discussion into a concise decision record. It should include the problem statement, target users, agreed success measures, prioritised journeys, first-release boundaries, assumptions to test, key technical decisions and open questions with owners.
Add a user-flow sketch or low-fidelity wireframes where they clarify the journey. Do not mistake visual polish for certainty. A simple flow with clear states and edge cases is often more useful for scoping than a beautiful screen design with no operational detail.
The next step depends on risk. If the core uncertainty is desirability, speak to representative users or test a low-fidelity prototype before writing production code. If it is feasibility, run a technical investigation. If the route is clear, use the output to create a phased scope and delivery plan. It depends on what remains unknown, not on a fixed workshop ritual.
Common mistakes to avoid
The most expensive mistake is treating discovery as permission to avoid decisions. A long list of possibilities is not a strategy. Someone must decide what the first release will not do.
Another is inviting a delivery partner only after the scope has been fixed. That can work for a straightforward build, but complex projects benefit from engineering input before promises are made. An experienced team can identify hidden dependencies, challenge unnecessary complexity and suggest simpler ways to achieve the same outcome. That decision, and how you structure the engagement itself, shapes how much flexibility you have once the build starts.
Finally, do not let the workshop become a one-off document that nobody revisits. Use its decisions during design, planning and delivery. When a new request appears, assess it against the agreed user problem and release boundary rather than adding it because it sounds useful.
A well-run workshop does not remove uncertainty. It makes uncertainty visible, assigns it an owner and stops it being discovered halfway through a build. If you are planning a new website, web application or mobile product, DELLIUX’s engineering team can help you run a focused discovery process with the people who would actually build it. Book a free consultation to talk it through before you commit to a scope.
