We ran the whole 3W Loop in one morning with 28 people

Twenty-eight product people. Two and a half hours. One room in Kraków, at WaysConf, starting at 09:40.

The brief I set myself was uncomfortable: by 12:10, every person walks out having run the whole 3W Loop on their own product. Not on a tidy teaching example. On the metric that was actually bothering them when they sat down.

That constraint is the interesting part, so this is a note about the format rather than the content. If you want to run it inside your own team, the structure below is the whole thing.

Be honest about what a workshop can produce

A workshop cannot do discovery for you. There are no real users in the room. There is no live experiment. Whatever happens between 09:40 and 12:10, nobody leaves with evidence.

So the output cannot be an answer. Design the session as though it will be and you get the usual result: a wall of sticky notes, a photo in Slack, and nothing different on Monday.

The output I aim for instead is a scoped, testable bet. One metric. One explanation worth checking. One experiment with a date on it. That is a starting line, not a finish line, and saying so out loud at the start changes how people work for the rest of the morning.

It is the same failure mode as a roadmap that tries to do everything: if everything is a priority, nothing is.

Start on their number, not on my case study

I open with elyps, the French-Belgian neobank I worked with. 80% of users churned during onboarding. Funnel analysis pointed at one step: the pre-KYC screen.

Then I stop, deliberately, before telling anyone what the interviews found.

If you hear my answer first, you borrow it. Every problem in the room quietly becomes a timing problem, because that is the shape of the story you just heard. So exercise 1 runs on their data, not mine.

Exercise 1, 10 minutes. Pick one metric that hurts or puzzles you. Write it in five fields: metric, segment (who exactly), how big, since when, source. Then two minutes each in pairs, talking it through.

The five fields do most of the work. "Retention is bad" survives about ten seconds of that format. "Weekly active rate for self-serve accounts fell from 34% to 21% since the June pricing change, per Mixpanel" is something you can actually investigate.

If you have no analytics yet, you hunt a signal instead: a funnel step people drop from, a retention cliff after a few months, the same support complaint from three separate sources, the objection that keeps losing deals, a feature nobody opens.

Three explanations, including one you don't believe

Exercise 2, 10 minutes. Write three competing explanations for your number, one per sticky. Circle the one you would bet on. Star the one you don't believe.

The star is the part people skip and the part that matters. Naming the explanation you reject forces you to admit the other two are also guesses. Without it, most people write one real hypothesis and two decoys, then "discover" the one they walked in with.

Then one question that would separate them, and it has to start with "tell me about the last time".

This is where the distinction that trips up most teams comes in. Your research question is "why do users abandon the KYC step?" You never say that out loud. It invites theories. The interview question is theirs: "tell me about the last time you tried to open the account. Where were you? What happened?" Past, not future. Specifics, not opinions.

You cannot get real users into a conference room

So for exercise 3 we rehearse instead. Participants describe their segment to an AI interview simulator and run a practice interview against it, digging with "tell me more about that", "why haven't you been able to fix this already?", "what are you already doing about it?"

I am blunt about what this is. A rehearsal, not research. It builds the reflex of asking about the past and catches the habit of pitching mid-interview. It produces zero evidence about your users.

The real interviews happen afterwards, with real people, and you need five to eight with the same persona before a pattern means anything. That part does not compress, which is rather the point of talking to five customers this week rather than scheduling a research phase.

The step nobody budgets time for

The longest exercise of the morning is the one that sounds most abstract, and it gets 15 minutes for a reason.

What you heard in an interview is an insight. The fix you are now imagining rests on assumptions, and those are two different objects. Everyone in a product team can name a fix. Far fewer can name what would have to be true for that fix to work.

Exercise 4. Write three to six "we believe that…" statements behind your fix, spread across desirability, viability and feasibility. Map them on an evidence and importance matrix. Take the one that is important and has no evidence behind it. That is what you test.

For elyps, the bridge looked like this: we believe users will defer the ID check if we offer it, because the blocker was the moment, not the step.

Which is why the fix was not a better document scanner. It was a "Do it later" option and a push notification that evening, when people were at home rather than on the subway. Onboarding churn on that screen went from roughly 80% to 60%, and notification opt-in went up too, because users finally had a concrete reason to allow them. The full elyps case study has the cards.

A date, or it isn't a test

Exercise 5, 15 minutes. The riskiest assumption becomes a test card: we believe that [change] will cause [effect] for [segment], to validate it we will test [what you build and expose], we are successful when [one metric, a number, a threshold], by [date].

Cheapest test that can prove you wrong, always. Demand questions go to a landing page or a fake door. Value questions go to a concierge test, a Wizard of Oz, a single-feature prototype or an A/B. Expensive only when cheap cannot answer.

The "we are successful when" line is the one that does the work, because it is the only line that can produce a no. Write it after the result and you have a demo wearing a test's clothes.

Sometimes you skip the interviews entirely, and that is legitimate when three checks pass: the fix is cheap and reversible, everyone can name the same obvious mechanism, and you would run the test regardless of what interviews said. At UX Pilot we saw free-to-paid conversion of 12.3% among people who used Deep Design versus 1.3% among those who didn't, went straight to an A/B on the default, and won. Three ticks, go and test. Fewer, interview first.

Photograph your canvas before you leave

That is the last instruction of the session, and it is not a joke. The artifact is one A4 sheet carrying a metric, an explanation, an assumption and a test with a date. It is worth more than the slides.

What nobody left with was validated learning. You cannot buy that with a morning, and any workshop that claims otherwise is selling you the feeling of progress rather than progress. What they left with was a decision about what to check first, and a cheap way to check it.

The checking happens at work, on a Tuesday, in between everything else. If nobody runs the test, the morning was theatre. If somebody does, the loop starts turning, and the result becomes the next Where.

Getting a team to write "we are successful when" honestly, on a decision that already has a champion in the room, is most of what we practise in the Product Discovery Workshop. The canvas, the loop graphic and the exercises are free under CC BY-SA 4.0 if you would rather run it yourself.