Most workshops are theater. Design yours to end in a test

A workshop cannot do discovery for you. I say that out loud in the first five minutes of every workshop I run.

There are no real users in the room. There is no live experiment. Whatever happens in the next two or three hours, nobody walks out with evidence.

That sounds like a strange way to open a workshop. It is the most useful thing I say all morning, because it changes what everyone in the room is trying to produce.

Most workshops end where the work should start

You have probably been to the version I mean. A good facilitator, a wall of sticky notes, a lot of energy, a photo in the team channel. Then Monday arrives, everyone goes back to their backlog, and nothing changes.

The problem is not the facilitation. It is the promise. If a workshop is designed as though it will produce an answer, it ends with a list of ideas that feels like an answer. A list is not a decision, and an idea nobody tests is just an opinion with a sticky note on it.

So I design backwards from a smaller, more honest output: one metric, one explanation worth checking, and one test someone will actually run. That is a starting line, not a finish line.

The work starts a week before the room

For the WaysConf masterclass, I asked participants one week before the workshop to prepare one product metric that hurts or puzzles them. Something from their own product they actually wanted to work out.

One metric. That's all.

This one request does more than any exercise I run on the day. People arrive with a real problem in their head instead of a vague hope of "learning about discovery". They have already looked at their own data, at least briefly, and they have already chosen. When the first exercise starts, nobody spends fifteen minutes deciding what to work on.

It also makes the workshop theirs. A case study is something you watch. Your own number is something you care about.

Don't tell them your answer first

This is why I tell the elyps story step by step during the workshop, and ask participants to do each exercise in between, rather than presenting the case and then handing out the canvas.

Here is what happens if you tell the whole story first. You hear that the fix was about timing, and suddenly every problem in the room is a timing problem. People borrow the shape of the answer they just heard, because it is the freshest pattern in their head.

So we find your Where and your Why before I tell you mine. You look at your own metric, write your own competing explanations, and decide which one you would bet on. Then you hear what happened at elyps, and it becomes a comparison instead of a template.

It is a small sequencing choice. It is also the difference between a room full of people thinking and a room full of people agreeing with the speaker. If you want the full exercise-by-exercise format, I wrote it up in we ran the whole 3W Loop in one morning with 28 people.

The test happens the next day, at work

The last instruction of the morning is always the same: photograph your canvas before you leave, or take it with you to work.

Because the test does not happen in the room. It happens the next day, at work, in between everything else. In a meeting someone has to book, on a landing page someone has to build, with five customers someone has to call.

If nobody runs it, the morning was theater.

That is why the most important line on the canvas is the one that says what success looks like and by when. A test with a threshold and a date has a chance of surviving contact with Tuesday. A test without one doesn't, and if you only write the threshold after the result, a test you cannot fail is a demo.

How to tell if your workshops work

Here is a question worth asking about the last workshop your team ran, whoever facilitated it. What did it actually change?

Not what did people enjoy, or what did the feedback form say. What decision got made, what test got run, what did the team stop doing? If the honest answer is "we had a good discussion", the workshop was an event, not a step in discovery.

Three questions I would use to check, two weeks after any workshop.

Did a test start? Not get planned. Start. Two weeks is generous: a test that hasn't started by then is competing with everything else on the backlog, and losing.

Did anyone talk to a customer? Workshops generate explanations. Only customers can tell you which explanation is true. That is the habit behind talking to five customers this week.

Did a decision change? Something on the roadmap moved, got cut, or got a different success metric. If nothing moved, the workshop confirmed what everyone already believed.

A good workshop is a short, intense way to get a team to the start of discovery with a sharper question than they walked in with. That is valuable. It is just not the same as doing the discovery.

Designing sessions that end in a test someone runs on Tuesday, rather than a wall of sticky notes, is the whole idea behind the Product Discovery Workshop.