Workshops

Alignment, scope lock, and feedback workshops — modular by sprint.

Workshops

Structured sessions that create alignment, lock scope, and drive decisions. Each sprint uses one or more workshop types depending on where it sits in the project.

Why Workshops Exist

Traditional design processes create feedback loops: designers make assumptions alone, build something, show it to stakeholders, get notes, rebuild. Key decision-makers feel they have to give feedback at the end, which creates friction and poor decisions from late-stage changes.

Workshops eliminate this. With decision-makers and domain experts working on product design together, the correct solution emerges upfront. The structure creates boundaries — not the facilitator.

Workshop Types

Type When Duration Purpose
Align Knowledge Experts and Design Workshop Sprint 1, Day 1 2.5 hours Surface challenges (HMWs), define sprint questions, map user journey
Scope Lock Workshop Mid-sprint 1 hour Demo working code, validate direction, freeze scope
Feedback Workshop Sprint 2+, Day 1 2.5 hours React to working code from previous sprint, set new priorities

Each type is a module — use the one that fits where you are in the project.

Align Knowledge Experts and Design Workshop

The opening workshop for a new project or a first sprint. Based on Day 1 of the Deep Work Sprint — structured exercises that align stakeholders, surface challenges, and involve domain experts in the design process. 2.5 hours.

The end result of this workshop:

  1. How Might We's — challenges reframed as open-ended questions, prioritised by voting
  2. Sprint Questions — testable hypotheses the sprint must answer
  3. User Journey Map — the user flow the sprint will build
  4. Research (optional, if time) — inspiration from existing products solving similar problems

Agenda (2.5 hours)

1. How Might We (45 min)

How Might We statements flip a problem into an open-ended question that invites ideas. Born in 1960s creative-problem-solving (Sidney Parnes), refined at Procter & Gamble by Min Basadur, then spread by IDEO/d.school to boost team imagination.

Example: How might we help first-time parents feel confident and rested in the baby's first 100 days?

How to run it:

  1. Write (30 min) — Ask the Decider to talk about the biggest challenges. While they talk, every participant writes How Might We notes — one idea per sticky note. Guiding questions:
    • "Where is the project right now?"
    • "What can be done with the tech?"
    • "Who is currently using it?"
    • "What is the most important thing to get right?"
    • "What are the most difficult challenges?"
  2. Arrange into Categories (10 min) — Arrange the HMWs into categories. Overlap and group duplicates.
  3. Vote (7 min) — Vote on the most relevant notes. Each participant gets 4 votes. Decider gets 5. Rearrange into a "heat" structure — highest votes at top. Read out the final results.

2. Sprint Questions (30 min)

Sprint questions are testable hypotheses framed as obstacles. They guide every design decision and become the pass/fail criteria for user testing.

How to run it:

  1. Write (5 min) — Everyone comes up with questions independently. Each question starts in the format "Can we..." and relates to the design of the project. Aim to include only questions we have control over. These questions will inform the user testing.
  2. Vote (3 min) — Vote on the most relevant questions — things we can design for. Each participant gets 2 votes. The Decider gets 3 votes.
  3. Select 3 & Combine (10 min) — Select 3 questions (combine if necessary). Rephrase them into "Can we..." questions.
  4. Highlight 1 Focus Question (10 min) — Select the most important question and highlight it. Ask the team: "If it were possible to only work on one question, which would it be?"

Good sprint questions are testable:

  • "Can users perceive meaningful differentiation within the first experience?" (testable — ask them)
  • "Can users trust the output enough to share with a colleague?" (testable — observe behaviour)
  • "Can we find the right ICP?" (not testable in a sprint — this is a business question)

3. User Journey Map (30 min)

Map the user flow the sprint will build. Not a full journey map — a basic user journey condensed into 6 steps.

How to run it:

  1. Write (10 min) — Everyone writes a basic user journey. One step per post-it. Condense the journey into 6 steps. Start from something like the first contact with the product and end with a successful outcome. If the product exists, write out the existing primary user journey. If it doesn't yet exist, write a basic hypothetical user journey.
  2. Vote (5 min) — Everyone reads through the journeys and votes. Each participant gets 2 votes. You can vote on an individual user journey (row) or an individual user step (column). The Decider gets 3 votes and can vote on one row and two columns or vice versa.
  3. Combine (10 min) — Combine the top-voted journey with additionally voted steps into one user journey.
  4. Highlight Focus Area (5 min) — Move the upvoted HMWs into the relevant areas. Circle the areas with clustered HMWs to see what to focus on. This will help prevent you from overpromising. Stick to the time — it's okay if the map feels incomplete and not perfect.

4. Research (optional, 45 min)

If time allows, run a research exercise to gather inspiration from existing products solving similar problems.

How to run it:

  1. Individual Research (30 min) — Everyone goes out individually to search the web. The goal is to find products or services that faced similar challenges and found elegant solutions. Keep the Sprint Questions and User Journey Map in mind. Take screenshots or copy the things you find interesting. Solutions can be from completely different industries but should have relevant solutions. Include a post-it with your name above the screenshots you share, and post-its explaining where the screenshot is from and why you're including it.
  2. Present & Vote (1-3 min each) — Everyone gets 1-3 minutes to go through their examples and explain why they found them interesting. While participants are presenting, everyone can silently vote on the ideas they like. There is no limit to the amount of dot votes.

Scope Lock Workshop

A 1-hour workshop mid-sprint to demo what's built, validate direction, and lock scope definitively. This is where alignment becomes commitment.

Why This Is Separate from the Alignment Workshop

The Align Knowledge Experts and Design Workshop creates alignment on direction. The Scope Lock Workshop creates scope lock. These are different things.

Trying to force both into a single workshop produces worse outcomes. Separating them gives each step room to work — and prevents building the wrong thing for two more days.

On the first engagement, the alignment workshop didn't achieve full scope lock due to an ICP debate. That was fine — the workshop created alignment on direction (purple path selected, sprint questions locked, visual approach validated). The Scope Lock Workshop then locked scope based on days of building evidence: working code the client could react to.

The cost of one hour mid-sprint is far less than the cost of two days in the wrong direction.

How to Run It

Before the Call:

  1. Prepare a working demo. Show real screens, not slides. The client should be able to interact with the prototype.
  2. Frame the demo around sprint questions. Each screen should map to a sprint question: "This screen tests whether users can perceive differentiation from ChatGPT."
  3. Prepare 3-4 validation questions:
    • Does this visual direction work?
    • Does this screen communicate the core value?
    • What should change before I continue building?
    • What should be cut?

During the Call (1 hour):

  1. Demo what's built (20 min) — Walk through the prototype. Let the client interact. Note their reactions — where they hesitate, what they click first, what surprises them.
  2. Validate direction (20 min) — Ask your validation questions. Listen for concrete feedback: "switch to a trace view" is actionable. "Make it better" is not.
  3. Lock scope (20 min) — Based on the demo and feedback, confirm what the remaining build days will deliver. Write it down. After this point, scope is frozen.

After the Call:

  1. Document the scope lock — Write down exactly what was agreed. Share with the client.
  2. Identify direction changes — If the client requested significant changes (not additions), adjust the build plan.
  3. Cut what won't fit — If scope needs trimming based on feedback, cut now. Thursday noon is the technical freeze.

Scope Freeze Rules

After the Scope Lock Workshop:

  • No new features. Any additions require a change order or a new sprint.
  • Direction changes are fine. "Switch from cards to a list view" is a direction change, not scope expansion.
  • Bugs and polish are expected. Fixing issues in existing screens is part of the remaining build days.
  • The structure says no. If the client asks for more scope, the process creates the boundary. "That's great — let's add it to the next sprint."

Feedback Workshop

A workshop in Sprint 2+ that replaces the Align Knowledge Experts and Design Workshop. Instead of aligning from scratch, the team reacts to working code from the previous sprint.

Working code generates specific, actionable feedback that wireframes can't. Clients reacting to working software make concrete decisions. Clients reacting to sketches make abstract ones.

How to Run It

Same 2.5-hour structure as the alignment workshop, but adapted:

  1. Demo of working code (45 min) — Walk through what was built. Let the team interact. This replaces the user journey mapping.
  2. Supervote (30 min) — Each person votes on what to focus on next. Red dots for priority, blue dots for "needs improvement."
  3. Sprint questions review (30 min) — Are the sprint questions still right? Adjust based on what was learned.
  4. Scope lock for new sprint (45 min) — Lock the next sprint's scope based on the voting and discussion.

Supervote for Prioritisation

When there's a "what do we focus on" question, the Supervote resolves it in under 15 minutes:

  1. Straw Poll (7 min) — Everyone places 1 supervote simultaneously
  2. Present (3 min each) — Explain your choice to the Decider
  3. Decider Votes (3 min) — 2 supervotes, decision is final

Quick, efficient, no endless debate.

What Workshops Can and Cannot Validate

Can validate: Interface approach, flow logic, visual direction, feature priority, user journey assumptions.

Cannot validate: ICP, pricing, market size, business model. User testing can give signal on some of these, but the workshop validates interface, not market.

Locked Decisions

Decision Why
2.5-hour workshop based on Deep Work Sprint Day 1 Structured exercises (HMWs, Sprint Questions, User Journey Map) create alignment. Sketching exercises removed — working code replaces paper sketches.
HMW with categorisation and voting Surfaces challenges as open-ended questions. Top-voted HMWs guide sprint focus and map onto the user journey.
Supervote for feature prioritisation Quick, efficient, Decider has final say. Standard for any "what do we focus on" question.
Scope frozen after Scope Lock Workshop Protects both parties from surprise expansion. Process says no, not you.
Separate direction (Align Knowledge Experts and Design Workshop) from scope lock (Scope Lock Workshop) The alignment workshop creates direction through HMWs, Sprint Questions, and User Journey Map. Scope Lock Workshop freezes scope after the team has seen working code. Forcing both into one produces worse outcomes.
Demo on working code, not slides Clients reacting to working software make concrete decisions.

Research Tech Example

Align Knowledge Experts and Design Workshop (5 January 2026):

  • HMW brainstorming surfaced a 50/50 split between marketing/positioning (7 votes) and product/UX concerns (13 votes)
  • Two user journeys received equal votes — resolved by overlaying HMWs and sprint questions on each path
  • Purple path (app onboarding) selected as sprint focus based on alignment with product/UX HMW clusters
  • Three sprint questions locked: differentiation from ChatGPT/Gemini, trust to take action, navigate information hierarchy
  • ICP debate emerged but was redirected — the team explicitly warned their existing research was outdated

Scope Lock Workshop (7 January 2026):

  • Demo of Processing View and Report Overview — team validated the approach
  • Sprint questions confirmed as correct focus
  • No ICP debate re-emergence (acknowledged and parked in the alignment workshop)
  • Three major direction changes — all concrete, actionable, only possible because the client was reacting to working code:
    1. Processing screen: "Too complex — switch to Laminar-style trace view."
    2. Report screen: "Users don't read reports because they're too long. Executive summary IS the first screen, not a collapsible component."
    3. Onboarding: "Should come AFTER Value Preview — show value first."
  • Scope stayed locked — no new features added, but existing features rebuilt in better directions.

Feedback Workshop (12 January 2026):

  • Feedback session on working code (Sprint 1 deliverables: 8 screens)
  • Supervote with red dots (priority) and blue dots (needs improvement)
  • Workflow + Chat identified as core flow for Sprint 2
  • Team circled Steps 4-5 together with "Chat" — the Supervote resolved focus in under 15 minutes

Key observation: The alignment workshop didn't fully lock scope — and that's fine. It creates alignment on direction through HMWs, Sprint Questions, and User Journey Map. The Scope Lock Workshop creates scope lock. The Feedback Workshop on working code was far more productive than the initial alignment session — decisions were concrete because the team was reacting to real interfaces.

Previous: Project Setup | Next: Build & Prototype