Run a product discovery workshop by gathering the right people, defining the problem and goals, mapping users and their journeys, generating and prioritising ideas, sketching key flows, listing assumptions to test and agreeing a lean first scope with clear next steps. The outcome is a shared, written plan and a testable prototype brief, not a finished product.
- Discovery reduces the risk of building the wrong thing.
- Invite decision-makers, users' voices and a technical lead into the same room.
- Focus on problems, users and assumptions before features.
- End with a prioritised first scope, risks to test and named owners.
What is a product discovery workshop and why run one?
A discovery workshop is a focused session, or a short series of sessions, where stakeholders align on what problem the product solves, for whom, and what the smallest valuable version looks like. It brings business, design and technology views together before significant money is spent on development.
Without discovery, teams often start with a feature list that reflects opinions rather than evidence. They build for months and then learn that users wanted something different. A workshop surfaces disagreements and unknowns early, when changing direction costs a conversation rather than a rewrite.
Who should attend and what should you prepare?
Invite a decision-maker who can approve scope, a product owner, someone who talks to customers regularly, a technical lead and, ideally, a designer. Keep the group small enough to work, usually five to eight people, and appoint a neutral facilitator who keeps time and draws out quieter voices.
Beforehand, gather what you already know: customer feedback, support tickets, sales calls, existing processes, competitor products and constraints such as budget, timeline and regulations. Share a short agenda so people arrive thinking about the problem, not defending a solution.
- A decision-maker who can commit to scope.
- A product owner or business lead.
- Someone close to real customers or users.
- A technical lead to judge feasibility.
- A facilitator, ideally a designer or consultant.
How do you structure the day?
Begin with goals and success measures: what must change for the business or the user if this product works? Then define the problem statement and the target users. Create simple personas or user types grounded in real conversations, and map their journey from need to outcome, marking pain points.
Move to ideas only after the problem is shared. Use short, timed exercises for brainstorming, then group and vote. Resist the urge to discuss technology too early. A well-run agenda alternates divergent thinking, where options are widened, with convergent decisions, where they are narrowed.
How do you prioritise what to build first?
List candidate features and rank them by user value, business value and effort. A simple grid of impact against effort helps, as does asking which feature, if removed, would make the product pointless. That answer defines the core of your first version.
Separate must-haves from later ideas, and write down what you are deliberately not building yet. This protects the team from scope creep and gives stakeholders a clear picture of version one. Keep the first release small enough to learn from quickly.
- Core user problem solved end to end.
- Minimum features needed for that journey.
- Features deliberately postponed.
- Dependencies on integrations, data or approvals.
What happens with risks and assumptions?
Every idea rests on assumptions: users will pay, they will switch from spreadsheets, an integration will be possible, a regulation allows it. List them and mark which are most uncertain and most dangerous if wrong. These become your validation plan.
Choose cheap ways to test: customer interviews, clickable prototypes, a landing page, a manual service behind the scenes. The aim is learning before large spending. Assign each test an owner and a date.
What should you have at the end?
Leave with a short written summary: problem, users, goals, prioritised scope, key flows sketched, top risks, next steps and owners. Share it within a day while memory is fresh, and ask participants to correct anything misrepresented.
The most valuable output is shared understanding. If a prototype or design sprint follows, the workshop notes become its brief. Treat the document as living and revisit it when you learn something new.
Step by step
- Prepare inputs. Collect customer feedback, constraints, competitor examples and any existing data.
- Align on goals and problem. Agree the success measures and write a one-sentence problem statement.
- Map users and journeys. Describe who the users are and chart their journey with pain points.
- Generate and rank ideas. Brainstorm in timed rounds, then rank by value and effort.
- Define version one. Choose the smallest valuable scope and list what waits for later.
- Plan validation. Record assumptions, tests, owners and dates, and circulate the summary.
Frequently asked questions
How long should a discovery workshop last?
One focused day suits a simple product, while complex ones may need two or three sessions spread over a week or two.
Do we need a prototype afterwards?
Usually yes. A clickable prototype lets real users react before development, which is cheaper than changing finished code.
Can this be done online?
Yes, with a shared digital whiteboard, short sessions and a firm facilitator. Keep cameras and discussion active to maintain engagement.
What if stakeholders disagree?
That is the point of the workshop. Use evidence and user insight to resolve differences, and let the decision-maker settle what remains.
Need help with this? Ask us a question about it — we reply within one working day.
