Someone has an idea. It sounds reasonable. It lands in a backlog. Designers start sketching, developers start estimating, marketing starts planning the launch. A few months later the feature ships, everyone is tired, and users… barely touch it.

It’s not that the team can’t design or code. It’s that everyone quietly answered different questions in their head: What problem are we solving? For whom? What does success look like?

A product discovery workshop is a deliberate pause at the beginning of a project to answer those questions together, before you spend serious time and money.

It isn’t a fancy ceremony. It’s a focused working session where the people who want the product and the people who build the product sit in the same (real or virtual) room and create shared clarity.

What is a Product Discovery Workshop?

In simple terms, a product discovery workshop is a short, intense design thinking workshop at the start of a project.

Design thinking workshops are a bit like stepping out of the driver’s seat and looking at the road from above. Instead of flooring the accelerator and hoping you’re on the right highway, you climb up to a balcony, look at the map, and ask: where are we actually trying to go, who’s in the car with us, and what’s the best route from here?

You borrow a designer’s mindset for a while: stay curious, zoom in on real people, sketch possibilities, and test assumptions before you pour concrete.

In that spirit, a product discovery workshop brings together a small, cross-functional group – usually product, design, engineering, and someone close to customers – and gives them space to work through a few basic things:

• What problem are we trying to solve?
• Who are we solving it for?
• What do we already know about them?
• What constraints do we have in terms of time, tech, budget, or regulation?
• What’s the first version of the solution that’s realistic and worth building?

You don’t need a huge group; five to eight people who care is usually enough. You don’t need an offsite; a room, a board, and a few hours of undistracted attention can go a long way.

You also don’t walk out with a 40-page specification. You leave with a shared understanding, a handful of artefacts that capture that understanding, and a clear idea of what happens next.

Why does it matter?

The first reason is waste. A lot of effort in software goes into things that never really get used. That usually doesn’t happen because teams are lazy. It happens because ideas go straight from someone’s head into a backlog and then into design and development without being properly challenged.

Discovery is where you challenge them.

You take the shiny request and ask: is this a real problem for our users, or just something we assume they want? Is it the most important thing we could be working on right now? How will we know if it worked?

When you have that conversation with people from different parts of the business in the same room, you quickly discover which ideas are actually strong and which ones fall apart under a little pressure. A lot of “must-haves” quietly become “nice-to-haves”.

The second reason is rework. Changing your mind on a whiteboard is cheap. Changing your mind after two sprints, integration work, and a round of testing is not. A discovery workshop won’t remove all uncertainty, but it pulls a lot of it earlier. You spot contradictions, hidden assumptions, technical blind spots and gaps in user understanding while things are still flexible.

The third reason is focus. Inside any organisation, different teams naturally optimise for different things. Sales thinks in terms of deals. Support thinks in terms of tickets. Marketing thinks in terms of visibility. Engineering thinks in terms of reliability and complexity. All of those are valid. But if nobody ever sits down and says “for this next phase, this is the main problem we’re trying to solve”, the product ends up trying to do everything at once and doing none of it particularly well.

A discovery workshop doesn’t magically resolve every conflict, but it gives you a structured moment to agree on a direction. For the next release, what matters most? Which trade-offs are we consciously making? What are we okay leaving for later?

What actually happens in the room?

Although every facilitator has their own way of running things, most workshops follow a similar arc.

You start with the problem. A simple exercise is to ask everyone to write, individually, a sentence that begins with “We are building / changing this product so that…” and finish it in their own words. No discussion at first, just honest answers.

When you read those sentences out, you often realise people have been working from very different mental pictures. One person describes a revenue goal, another describes a usability issue, another talks about internal efficiency. Putting this in the open is useful, not embarrassing. You then work together to turn those different perspectives into one or two clear problem statements everyone can stand behind. Those statements become your anchor for the rest of the day.

From there, you move towards the user’s reality. Rather than talking about features in abstract, you sketch a simple journey. How does someone discover you? How do they start using the product? What are they trying to get done? Where do they get stuck, confused, or frustrated? You add whatever evidence you already have: support tickets, analytics, comments from sales calls, previous research.

The aim here is not a perfect persona deck. It’s a shared mental picture of who you’re helping and what a “good outcome” looks like for them.

Only when the problem and the user feel clear do you open up the solution space. This is usually the more energetic part of the day: people sketch ideas, suggest flows, reference other products they like, and build on each other’s thoughts. The only real rules are that ideas stay linked to the problem you agreed on, and that everyone gets space to contribute, not just the loudest voice in the room.

After a while, you shift from generating options to making choices. This is where constraints come back in. You look at ideas through a practical lens: which of these have a realistic chance of improving the problem we defined? How hard would they be to implement? What depends on what? Given our team and timelines, what can we honestly attempt first?

Some groups like to plot ideas on an impact-versus-effort grid; others just talk them through. The format matters less than the fact that trade-offs are visible and explicit rather than hidden.

Finally, you turn all of this into a concrete first step. That might be a thin slice of a feature, a small set of flows to prototype, a list of assumptions to test with users, or a minimum version of the product you want to build first. You decide who is responsible for what after the workshop and what you will look at to decide whether you are on the right track.

You don’t leave with certainty. You leave with a shared starting point.

Do you really need a workshop for everything?

No.

You don’t need a formal discovery workshop to change a label, add a small filter, or tweak a report. For very small, low-risk changes, a couple of user calls and a quick internal discussion are usually enough.

Where a discovery workshop pays off is when there is real uncertainty and real risk: a new product or major feature, a new market or user segment, work that touches several teams, or an initiative where getting it wrong would be expensive or painful to unwind later.

If you ask three people “what are we trying to achieve here?” and they give you three different answers, that’s a strong signal you should slow down and create some clarity before you race ahead.

Wrapping up

A product discovery workshop is not a magic trick. It won’t guarantee that every bet you make is perfect. What it does do is move the hard thinking earlier, to a point in the project where changing course is still relatively cheap.

At heart, it’s a day of structured conversation that helps you agree on the problem, understand the person on the other side of the screen, and choose a small, clear first step to take together.

In a world where it’s easier than ever to ship new features, the real advantage isn’t speed for its own sake. It’s knowing which things are worth building at all. Discovery is where that advantage starts.