These notes assume you’ve read the process documentation. What follows is the harder-to-document stuff: the principles, the traps, and the moves.

The facilitator’s role

Your job is to be a warm, trusted guide with enough authority to keep things moving and enough energy to keep things active. You are not a neutral observer, not a drill sergeant. You are an interested participant who happens to be bringing the team to a happy destination.

A few principles worth internalizing before you walk in the door:

1. The most effective instructions describe the desired behavior as natural and inevitable. “As we listen to these presentations, we’ll inevitably notice things customers struggle with or opportunities worth capturing — these stickies are here to capture those.” The behavior is obvious and expected.
2. Give the reason with the instruction. People follow instructions better when they understand why. “Because we want to be able to cluster these later, we’re going to write one idea per note” is more effective than “write one idea per note.”
3. Use “we” language. “We’re going to write our problems down one per sticky note” is an invitation. “You need to write one idea per sticky” is a command.
4. Model what you want. When you notice a customer problem during Immersion, say so and write it down. Ask clarifying questions, especially when others are not. The facilitator should never appear to be sitting back.
5. Coach the room, not the individual. When someone needs a gentle push, ask whether the instruction would benefit everyone. If it would, speak it into the room rather than at the person.
6. Contribute where you can, but hold your ideas lightly. Never be so invested in your own ideas that you exert undue influence on any phase. Contribute where it helps: generating ideas, noticing problems, reframing benefits, demo prep, pitch prep, note-taking during validation, and synthesis afterward. Don’t take on anything critical during the build phase — you’ll have too much else to do.
7. Let the schedule apply the pressure, not you. Name what needs to happen next and expect the group to participate.
8. Celebrate little successes. The sprint has natural high points — a cluster that everyone recognizes, a concept that makes the room light up, a customer who gets visibly excited. Name these moments. Bring snacks.

Immersion

Steep the group in domain knowledge — product, customers, competition, market — deeply enough that they notice problems and generate benefits from a place of understanding.

Before the first speaker, prime the room. Don’t just introduce the speaker and step back. Set the group’s job first: “We have a handful of people here to tell us about [topic]. They are [who they are] and they’ll cover [areas]. Our job while they’re talking is to notice customer problems we might solve or benefits we might deliver. We’ll write those down as we go — one per sticky — and ask clarifying questions whenever something’s unclear.” This frames Immersion as active work, not a lecture.

Pitfalls to watch for:

• Pre-reads that are too long, too vague, or too internal. Good pre-reads are customer- and competitor-informed, concise, and scannable — research, interviews, data.
• Speakers who arrive with conclusions rather than information. When you notice this happening, reframe it for the room: “This person has been deep in this space and may have opinions — our job is to learn what they know, so we can find our way to a great concept.” You’re not correcting the speaker; you’re setting the group’s posture.
• Participants going heads-down on laptops. Banish laptops for this phase; there’s time in the schedule for people to be in touch with the office. Model active listening yourself: “That sounds like a real problem; I’m writing that down.”
• Too much internal content. The most common Immersion mistake is over-indexing on internal perspective and under-indexing on customer and market realities.

Don’t shortchange Immersion to save time. Under-immersed participants generate fewer and weaker ideas in the phases that follow. Wasted time in Immersion is recoverable; too little Immersion is not.

Participants should arrive at phase 2 with several customer problems already on stickies.

Problems (Phase 2)

Surface the full range of customer problems the group has noticed, cluster them into meaningful themes, and identify which clusters are most worth solving.

Each person reads a sticky and places it on the wall. Drive the clustering actively: name the clusters yourself and check for agreement rather than waiting for the group to self-organize. Invite people to write down additional problems they think of during this process. Imperfect clusters are fine; forward motion matters more than precision. For an energy boost, invite the whole group up to the board to move stickies around as they see fit.

Pitfalls to watch for:

• Solutions disguised as problems. When someone presents one, ask: “What is the problem that idea is meant to address?” Sometimes they need help grounding it in a specific person or situation.
• Clusters that are too large or undifferentiated. Discuss what makes some problems within the cluster different from others, and subdivide.
• Too few ideas. Ask what other ideas are sparked by what we’ve heard so far.

On scoring: the dimensions are common (does it affect many customers, come up often, matter to the prospects we want?) and painful (expensive, maddening, intractable). These are estimates, not data. If everything clusters high or low on one axis, move the origin; differentiation is almost always there if you look for it. Think of this as a practice run for benefit scoring, which matters more.

Carry the problem clusters forward into phase 3.

Benefits (Phase 3)

Ultimately the product will solve one or more problems by delivering a benefit. In this phase we are choosing the benefit to pursue.

Ask the group: “How would a customer know that the problems in each of these themes had been solved?” That question puts people in the right frame. Add a reminder that a benefit is a result not expressed in terms of the solution. Have people write down benefits, one per sticky, including any they noticed during Immersion.

Pitfalls to watch for:

• Benefits expressed as product features. Push toward customer outcomes: what does the customer feel, accomplish, or avoid? “Faster reporting” is a feature. “Always knowing what’s working before the budget meeting” is a benefit.
• Safe choices. Score on value to the customer and relevance to the business — how credible would we be delivering this, and is it strategically aligned? A benefit customers would love but that we’re poorly positioned to deliver is less attractive than one where we have genuine standing. If there’s a known constraint (e.g., a mandate to use a specific technology), score against that too.
• Picking the comfortable cluster. Name it, ask what a customer would say if told the problem was solved, and remind the group that we’ll learn more by getting out of our comfort zone.

Problems and benefits are not one-to-one. A single problem may spawn many benefits; a single benefit may cover multiple problems. The latter is often especially attractive strategically — worth saying out loud when the group is close to a decision.

Carry the selected problem/benefit set forward as the brief for concept generation. Write it where everyone can see it.

Concept Generation (Phase 4)

Each participant independently sketches one or more specific concepts, the group shares and discusses, and everyone converges on a single concept to build.

Specificity is the whole game. The most common failures are concepts that are too abstract, expressed as slogans rather than situations, or drawn as a single screen rather than a sequence of events. A good concept sketch shows real people in real situations doing real things. Remind participants: think in storyboards, not snapshots or headlines.

For the stuck: ask who is the protagonist and what they are doing, what they do next, or what started the sequence of events. Any of these can unlock someone who has frozen.

For the quick: ask them to sketch another way of delivering the same benefit, ask when the payoff occurs, or ask which steps could be reduced or designed away.

On participant dynamics:

• Engineers are the most likely to critique ideas at the wrong moment. Invoke the ground rules if needed — the gallery walk is for questions, not evaluation.
• Senior leaders and architects are the most likely to resist sketching. Normalize “making marks on paper” for the whole team. It doesn’t have to be pretty.
• Some people will zoom out and try to synthesize everything into something lofty or abstract. Redirect them toward specifics: the scene, the people, the sequence.

After the gallery walk, encourage the group to mix the best parts of the various ideas to arrive at a single powerful concept. Most groups negotiate easily and are excited about each other’s ideas. When they converge, summarize what they seem to have done. Get explicit agreement and write the selected concept on the whiteboard where it will stay visible for the rest of the sprint. If timing allows, land concept selection right before a break, and bring snacks or serve lunch. This is a genuine milestone.

If the group starts re-litigating the problem/benefit choice after concept selection, shut it down. Remind them the choice was deliberate and that re-thinking it now costs build time. If needed, ask product to restate why the chosen problem and benefit were compelling. Persistent argument gets all three in escalating order.

Concept selection is where the sprint pivots from divergence to convergence.

Building (Phase 5)

Produce a demo that expresses the problem, the benefit, and the concept — real enough for a customer to react to honestly.

The enemy of the build phase is the person who wants to plan it. Building needs to be active and free-form. Negotiating scope and content during the build is fine; stopping to schedule it is not. Identify the planner early and redirect them to making. Everyone should be busy and collaborating.

Check in at least three times: halfway through, when someone goes quiet or seems stuck, and about an hour before the first customer arrives. Each check-in is a chance to adjust scope: can we shrink this, cut that, or just talk about it rather than build it? Is our demo going to show what we need to show? Is someone blocked?

The most common build failure is a demo too long to fit a 30-minute customer session, where the demo is only one part. Remind the team of this constraint at check-ins as needed. A timed run-through in the final hour makes the case.

Keep the session structure firmly in mind: problem expression/validation, benefit expression, concept demo, follow-up questions. All four must be ready before the first customer arrives.

The build phase ends when the demo is strong enough to show or we run out of time — not when it’s perfect.

Customer Validation (Phase 6a)

Learn whether the problem resonates, the benefit excites, and the concept delivers, from real customers, honestly.

Arrive at the first session with a tight plan. Know what you need to show and what you need to learn. Assign roles before the first session: one person drives, one runs the demo, one takes notes; others observe and contribute questions.

Excitement leaks. The team will be proud of what they built, and that energy can surface as leading questions or overselling. Brief the team before the first session: our job is to learn, not to persuade.

Customers downplay their objections. When you sense a real concern being softened, draw it out: “Tell me more about that.” “It sounds like you’re not sure about X; is that right?” “What would you need to feel confident about deploying this?” Adapt to the flavor of the hesitation.

Between sessions, when there’s a gap of 20 minutes or more, use it. What are we learning? Is there anything to adjust in the framing or the demo? The demo can be refined between sessions if feedback warrants it, especially after recurring feedback.

When a session is deflating, remind the team that a skeptical customer is valid data and a bad session or two doesn’t invalidate the concept. After a difficult session, ask: what specifically did this customer object to, and what does that tell us about the concept, the framing, or the customer fit?

Sync with the implementation planning team whenever there’s a long gap and at the end of the day. Often the people in 6b finish first and can rejoin the validation team. Before pitch prep begins, make sure both teams have presented their findings to each other.

Implementation Planning (Phase 6b)

Arrive at a credible, honest answer to “could we do this, and roughly how,” enough for leadership to weigh, not enough to be mistaken for a commitment.

T-shirt sizes and a whiteboard fish chart are the right output. The most common failure in 6b is producing something too detailed that starts to look like a plan.

Pitfalls to watch for:

• Over-cutting. In the drive toward a lean MVP, teams sometimes scope down until the concept no longer delivers meaningful value. The test: would a customer be pleased by it? If not, you’ve cut too far.
• Not deferring enough. A good MVP delivers the core benefit clearly; everything else is a future iteration.
• Despairing of risks rather than naming them. When the team sees a hard problem or unknown, the instinct can be to treat it as a blocker. The job in 6b is to name risks, not solve them, so leadership knows what needs to be sorted and the team knows where to focus first.
• Forgetting existing capabilities. Ask explicitly: what do we already have that we can use or adapt? Existing platform capabilities, APIs, and infrastructure can dramatically accelerate delivery and change what belongs in the MVP.

This process predates AI-assisted coding. What once required a large team or long runway may no longer. Factor that in! It may shift scope, surface new constraints in place of old ones, or make a dependency diagram a better deliverable than a rough schedule.

Pitch Preparation (Phase 7)

A short, honest, compelling story, 30 minutes including the demo, that gives leadership enough to make an informed decision about next steps.

Before the team presents, set the stage for the executive audience: acknowledge the intensity and creativity of the week, and let them know the team is excited to share what they found. This primes the audience to receive the work generously and frames the pitch as the beginning of a conversation, not a verdict.

The pitch tells a simple story: we understood the assignment, learned the domain, chose a problem and benefit worth pursuing, built a cool thing, and showed it to real customers. Keep the deck minimal and let the demo and customer reactions do the heavy lifting. Over-producing at the expense of practicing the story is the most common mistake. Raw material from the week is more compelling and authentic than anything flashy.

Be honest about what you’ve learned and what you don’t know. Executives are better served by a clear-eyed account than a sales job. If customers were skeptical, say so and say what it tells you. If the implementation estimate has significant unknowns, name them.