How to Run a Product Discovery Workshop in Two Days

Before a product gets designed or built, someone has to decide what it actually is. That sounds obvious, but in practice teams often skip it. A founder has a clear picture in their head, the developers have a different one, and the sales lead has a third. Everyone nods in the kickoff meeting. Three months later, the nodding turns out to have meant different things.

A discovery workshop is a short, structured set of sessions meant to prevent this. It doesn't need to be fancy, and you don't need an expensive facilitator. Here's how to run a useful one in about two days, whether you're doing it with an outside team or with your own colleagues.

What a discovery workshop is for

The aim is to leave with shared answers to a few questions:

• Who is this for, and what are they trying to get done?
• What is going wrong for them today?
• What is the smallest first version that would be genuinely useful?
• What are we unsure about, and how will we find out?
• What will it take, roughly, in time and money?

Notice that "what features should it have" isn't on the list. Features come out of the answers. They are not the starting point.

Who should be in the room

Keep it small, five to eight people. You want:

• the person who ultimately decides (founder or business owner)
• someone who talks to customers every day
• someone who runs the current process, if there is one
• a technical person, either in-house or from your development partner
• a designer, if you have one

The customer-facing person is the one most often left out and most often right. They know what people really complain about.

Switch phones to silent. Two days of focus will do more than two weeks of fragmented meetings.

Day one, morning: the problem

Start with the problem, not the idea. Ask each person to write, on their own, a short description of the problem as they see it, then read them out. The differences are the first useful result. You'll usually find that people have been working with slightly different assumptions.

Then map the current process. Draw it on a wall or whiteboard as a line of steps, from the moment a customer or task begins to the moment it's finished. Mark where things slow down, where information is retyped, where someone has to ask someone else, and where mistakes happen. Use sticky notes in a different colour for each of those.

By lunchtime you should have a picture that makes everyone slightly uncomfortable. That's the point.

Day one, afternoon: the people

List the different kinds of user. Be specific. "Customer" is too broad, but "a clinic receptionist who books appointments while answering the phone" is something a designer can use.

For each one, write down:

• what they're trying to achieve
• what they use today
• what frustrates them
• how they'd know the new thing was better

If you have the chance, speak to two or three real users the same week. Even thirty-minute calls will correct a surprising number of guesses. Our guide to validating an idea before development has question ideas.

Day two, morning: the first version

Now, and only now, talk about the solution. Ask everyone to write down on sticky notes the things the product should do. Then put them in order on a simple grid:

• Must have: without it the product doesn't work.
• Should have: valuable, but the first release could survive without it.
• Later: good ideas that can wait for real feedback.

Be firm about "must have". A useful rule is that it should fit on one page. If it spills onto three, the group hasn't yet decided what the product is. Our piece on MVP versus full product can help with this step.

Then sketch the main journey. Paper and pens are fine. Draw the three or four screens a user passes through to complete the key task. Don't polish. A sketch you can throw away is more honest than a design you're attached to.

Day two, afternoon: risks and rough size

List what you don't know. Typical items:

• Will customers really change how they work?
• Can we get data out of the old system?
• Does a third-party service we need actually do what we think?
• Are there legal or compliance questions?

For each risk, decide the cheapest way to learn the answer, and who will do it. Some are answered by a phone call. Some by a small technical test. A few might change the plan.

Finish with a rough size. Not a quote, a range. The developers can say whether the must-have list sounds like weeks or months, and what the biggest cost drivers are. You can then compare that range with your budget and decide whether to adjust the scope, not the other way round.

What you should walk away with

1. A one-page problem statement everyone agrees with.
2. A description of the main users and their goals.
3. A prioritised list of features for the first release.
4. Rough sketches of the key screens.
5. A list of risks, with owners and next steps.
6. A rough range for cost and timeline.

Send it round within a day while the memory is fresh, and ask people to point out anything they disagree with. Disagreement at this stage is cheap.

Common ways workshops go wrong

• The loudest person wins. Have people write before they speak.
• It turns into a design review. Keep screens for the second afternoon at most.
• No decision-maker present. Then the outcome is just a list of opinions.
• No follow-up. If nobody owns the next step, the output lives in a folder and nothing changes.

Doing it with a partner

If you're working with an outside team, a workshop is also a good way to see how they think before committing to a larger project. Pay attention to whether they ask about your customers or jump to technology. Read more about how we approach this on our product discovery page, or get in touch if you'd like us to run one with your team.