Last month I shipped an iOS app. I designed it, wrote the code (with the help of Claude), got it through App Store review, and published a blog post about what it taught me about designing a solid onboarding experience. I’m a UX director by title. I did it because I could, and because it solved a problem I have in a novel way that I think will be useful.

Earlier this year I created a feature to help Invoca customers understand the built-in and custom data in their accounts and how it travels within and outside of the platform. I did so because I found that even the most knowledgeable Invocans disagreed about how the customers they support had configured the platform, and as I investigated one such customer I had to do a lot of manual work to trace the flow of data as calls came in and were measured, webhooks fired, writebacks accomplished, signals evaluated. The centerpiece of my pitch, now on the roadmap, was a working prototype using actual customer configuration data that exposed the relationships between the fields and the classifiers, events, and integrations that write, read, and manipulate them. I did it because I could, and because it solved a problem users have in a way that customers find useful and Customer Success Managers desperately want.

This isn’t a flex; if anything, it’s becoming table-stakes for any product manager or designer.

The lines between product management, engineering, and design have been blurring for years. Who owns research? Who owns the customer problem? Who owns accessibility? Who owns measurement? AI design and development tooling has accelerated this trend past the point where anyone can ignore it. A PM who can write a working prototype in an afternoon changes what they need from a designer. An engineer who can generate UI variations in minutes changes what “handoff” means. A designer who can correct an accessibility problem in code and submit a pull request to put that into production has reduced the load on engineering. A designer who can solve a customer problem via a prototype that uses real data has made product management easier and provided more direction to engineering than a sheaf of pictures of interfaces ever could.

If you stay in your lane you are now the bottleneck. This isn’t bad news for designers; it’s exciting to be able to do more, to bring concepts all the way up to the glass.

The best designers I’ve worked with were never purely visual thinkers. Many didn’t have formal design training. They came from mechanical engineering, psychology, industrial design, education – fields that gave them a broader perspective. They were curious about systems, could hold a technical constraint in one hand and a user need in the other, and knew enough to offer possibilities about system behavior, to open engineers’ eyes to alternative solutions. What’s changed is that the tools now let designers satisfy their curiosity more directly. AI-powered prototyping shrinks the distance between an idea and a working thing you can test.

The closer you get to shipping, the better your design gets. You start making decisions with real consequences. You trip over edge cases earlier as you find the limits of the data available to you.

The flip side is that the blur creates a challenge for design leaders. The jobs that matter most — raising the strategic value of design, keeping teams focused on actual customer needs, developing designer capability and integration — are all in flux at once as teams figure out how to work together anew.

Getting your hands dirty with the new tools is critical for design leaders in this moment of upheaval. Design leaders once could champion established processes they learned earlier in their careers; these processes are being thoroughly upset now. You still have to establish standards, reassert the user’s interests, and manage competing priorities, but the way the team will work is not yet established. A director who hasn’t used these tools can’t lead the conversation about them.

A PM with Figma Make might feel they don’t need a designer to make something ready for engineers to chew on. An engineer with Claude Code might prefer to ship and measure in hopes that their idea about the customer problem was sound. A designer with Lovable might race on past the product manager and the engineer to put a prototype in customer hands. Any of these can move fast. Any of them can also skip right past the problem they were trying to solve. The tools accelerate both good judgment and bad — which is exactly why someone needs to stay oriented to what users actually need, and why that someone needs to be in the room, not waiting to be consulted.

Designers can no longer be a translation layer between PM and engineering. A designer’s knowledge of workflows, alternative controls, customer vocabulary, user attention management, and patterns from outside their industry is especially well-suited to offer useful new ideas to their organization. The pressure is on designers to explore and offer concepts that are more fully-realized, more directly testable, and more cognizant of the engineering environment than ever before.

The result is a demand for designers that have more depth in areas adjacent to their traditional role, with more fluency in front-end development, data structures, customer development, metrics. There’s more pressure to have range. A designer with range understands enough about product strategy and code to collaborate without translation – to drive the conversation rather than draft behind it. That’s different from being asked to do everyone’s job.

The designers and design leaders who will matter most in the next few years are the ones who have genuine range and can show that their concepts are actually useful, feasible, and convenient for users, not just assert that through good diagramming. Not decorators, not generalists who do a little of everything. People who know how to use AI tools to close the gap between intent and execution and who understand that the hardest design problem is finding and expressing the direction that is sound, not just generating options or polishing the chosen solution.

That’s still what design is for: knowing whether what you’re building will actually work for the people who have to use it, and having the prototyping capability to prove it before it ships. The tools make that proof faster and more convincing. They don’t make the underlying judgment less necessary.

The first thing you do in Monotasker is tap a checkbox. No tutorial, no tour. And no permissions granted yet. Just the thing you’ll tap every time you use the app.

That first tap fires the iOS Reminders permission dialog. Not a blurb with a “Connect my Reminders” button – the completion checkbox. The same gesture the app is built around.

I built Monotasker to solve a specific problem: I have too many side projects, and it’s easy to get bogged down in the list. Staring at 30 items can be as bad as having no list at all. The app picks one reminder at random and shows it to you, persistently, until you decide you’re done with it or want a new one. That’s it.

The more interesting design decision pays off before you ever load your tasks.

The lobby problem

Most apps treat onboarding as a lobby. You’re outside the real place, getting oriented before you go in. The screens have a different visual style: bigger type, illustrations, a progress indicator, two-phase permission requests. Big obvious buttons, not the controls you’ll actually use. You tap through explanations of features you haven’t used yet. Then you arrive.

The implicit message: “here’s what to expect from the app. Remember all of this. Now let’s see if you paid attention.”

That moment of arrival requires re-learning. You have to reconcile what you were just told with what’s actually in front of you. The controls are smaller. The tone is different. The decisions you make matter now.

Nearly every app has a lobby standing between you and what you came for. Or a tour – a list of things that you’ll forget before you need them.

One interface, not two

The onboarding design I made for Monotasker starts with a single principle: get users into the real interface and have them use it, as fast as pleasantly possible. Every onboarding screen uses the app’s main visual language – the gradient background, the post-it-style task card, the same typography. No separate marketing UI.

The onboarding screen shows a card that explains the concept in one sentence, with one visible control: a completion checkbox in the upper-left corner of the card. Tapping that checkbox fires the system permission dialog.

Why it works: that card and its checkbox are the centerpiece of the app. Not a metaphor for it, not a stand-in. When you grant permission and land on your first real task, the checkbox appears in the same place, doing the same thing. There’s nothing to re-learn. The gesture that gets you using the app is the gesture the app runs on.

The bigger idea

I’ve written before about coordinated experience – the idea that a well-designed system guides users through a task completely, without asking them to do work the system could do for them. Onboarding is the same problem one level up. Most onboarding asks users to remember what the tutorial explained, then go find those things once they arrive.

Putting users inside the interface from the first tap removes that work. The permission dialog isn’t something that happens before the app – it’s something that happens naturally at the right time. The empty state is the real experience, waiting for input.

Resist the impulse to design a special onboarding mode with its own visual language. Use the real thing. Trust the interface to explain itself.

A useful test

If your onboarding screens look noticeably different from your app screens, you’ve probably built a lobby.

The visual break signals a gap between “what we say the app does” and “what the app actually does.” Sometimes that gap is unavoidable – a genuinely complex setup may need explicit guidance. But in most cases it means you don’t trust the interface to stand on its own.

The first screen is already the app. It might as well look like it.

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.

A Concept Sprint is a short, usually week-long, in-person exercise meant to accelerate high-level exploration of a new area of development, a significant problem, or a strategic initiative. A blended team – product, design, architecture, engineering, marketing, and any truly relevant business stakeholders – generates a high-value product concept, validates it with live customers, and produces a pitch covering the problem, benefit, concept, and rough cost and timeframe to deliver a first version. The team works through seven phases led by a facilitator, book-ended by a welcome and a wrap-up. Below are my general instructions and guidelines, arrived at after running several of these at multiple companies.

Phases

a. Welcome

The Welcome is a short orientation for participants before Immersion begins. The facilitator covers three things:

• Purpose: Why we’re here, what a Concept Sprint is, and what we’re hoping to walk away with at the end of the week.
• Ground rules: The behavioral norms that will govern the week, especially the generation and categorization phases. (See Ground rules below.)
• Assumptions and known constraints: Anything the group is taking as given before we start — for example, a strategic directive to explore a particular technology, a market segment we are or aren’t targeting, or a business constraint that will shape what’s in scope.

The Welcome should be brief. Participants are eager to get into the material, and the most important orientation happens through doing, not explaining. Get through it crisply and move into Immersion.

1. Immersion

Supplies: sticky notes and fine-point markers, presentation materials, guest speakers, computers and a good internet connection

In Immersion the team learns all they can about current product capabilities, customers, competitive and alternative technologies, the difficulties customers face, and the opportunities those difficulties present. The goal is to steep ourselves in information that might be relevant to customer behavior or the aims of the sprint.

Give participants things to review prior to the first session. They can read these materials on the plane on the way to the session or the night before in their hotel room. Bring in experts from the business to present findings; if we’re running a sprint, we’ve likely already been studying the space and have people worth hearing from.

Participants should ask clarifying questions and be watchful for:

• customer needs or problems that we might consider satisfying, or
• customer benefits we might consider delivering.

Remind participants to capture problems and benefits on individual sticky notes as they go.

Scheduling this phase is critical. Speakers must be tightly scheduled, arrive on time, and deliver informationally-dense presentations. This phase opens the sprint; wasted time here delays everything that follows.

2. Problem review and categorization

Supplies: sticky notes and fine-point markers, whiteboard and markers

Each participant presents the problems they captured during Immersion. As problems are presented, others may find that they think of new ones; these should be offered to the group and added to the pool.

With all problems surfaced, the group works together to cluster them into themes. Each cluster needs a name for future reference.

The group then evaluates each cluster on two dimensions:

1. How common this problem is among the people we want to sell to (Does it affect many customers? Does it come up often for the affected customers? Is it felt strongly by a set of prospects we are interested in?)
2. How painful it is (expensive, maddening, intractable – is it something customers badly want solved?). These are the group’s best estimates, not data points; the goal is to make a collective judgment rather than wait for certainty that doesn’t exist yet.

Often the group will converge naturally on the most promising clusters. When they don’t, a dot-voting exercise can surface what the group is collectively thinking and narrow the scope of debate.

3. Benefit generation and categorization

Supplies: sticky notes and fine-point markers, whiteboard and markers

As with problems, participants have been watching for potential customer benefits during Immersion and have captured them on sticky notes. Before presenting those, however, the group pauses to consider the problem clusters from Phase 2: for each cluster, participants ask themselves what benefits a customer would receive if that problem were solved, and make note of any new benefits.

Each participant presents their sticky notes to the group. Others may build on presented benefits, offering new ones in the moment. The group then clusters the benefits into themes. Each cluster needs a name for future reference.

Each cluster is evaluated on two or three dimensions:

1. How valuable would this benefit be to customers
2. How relevant is it to the business – how credible would we be as the company delivering it, how strategically-aligned is it, etc. A high-value benefit that we’re poorly positioned to offer is a less attractive target than one where we have genuine standing or takes us in a direction we want to go.
3. If the sprint is operating under a known constraint (for example, an assumption that the concept will use a particular technology), clusters may also be scored on how well they fit that constraint.

Problems and benefits are evaluated separately because the relationship between them is not one-to-one — a single problem may spawn many benefits, and a single benefit may cover multiple problems. The latter is often especially attractive strategically, suggesting a concept with broad impact.

Use dot voting to help the team converge if needed.

4. Concept generation and selection

Supplies: fine-point markers, letter paper, whiteboard and markers, computers and a good internet connection

Before concept generation begins, the group selects a problem/benefit pair to work against — typically comprising top-scoring candidates from phases 2 and 3. This target helps the group generate specific ideas that might reinforce each other, and maintains focus during the build phase. That said, a concept that also addresses additional problems or delivers additional benefits is not penalized for it; ambition is welcome as long as the concept is buildable and coherent.

Each participant then independently sketches one or more specific concepts: each a product idea or approach that delivers the chosen benefit to a specific customer facing the chosen problem. These sketches should express the experience of specific people operating the product concept. This is not the time to be abstract.

Sketches need not be polished – the goal is to make the idea tangible enough to share and discuss. Some participants may be reluctant to draw, so we typically encourage them to “make marks on paper” to express their ideas. The facilitator should time-box this work to keep energy high and prevent over-refinement.

When everyone has sketched, the group conducts a gallery walk: each author narrates their own concepts while the group listens and asks questions. The group and facilitator should both push toward specificity — the group by asking clarifying questions, the facilitator by reminding participants that specific ideas are more valuable to the group than impressive-sounding ones, and that abstract things are hard to build and evaluate.

A second sketching pass is sometimes useful, for example if concepts weren’t specific enough, or the group wants to remix what they’ve seen.

Blending or combining elements from multiple sketches is encouraged, but the group must land on a single coherent concept before moving to the build phase. Use dot voting to help the team converge if needed.

5. Building and customer validation prep

Supplies: computers and a good internet connection

With a concept selected, the entire group turns to building a demo. It’s up to the group to decide what to build (working software), what to fake (HTML, Figma, or slides), and what to leave as presentation materials. Any combination of these is valid, so long as the group arrives at Customer Validation with:

• An expression of the problem
• An expression of the benefit we hope to deliver
• A demo of the concept that is intended to deliver that benefit

As with concept sketches, we must resist the temptation to be abstract. A demo that shows a specific person doing a specific thing in a specific situation is far more evocative and easier for a customer to respond to than one that gestures vaguely at possibilities. The facilitator and the group should push each other toward specificity throughout the build.

Once the demo is in good enough shape, the group starts validation prep. This means aligning on the key questions the team hopes to answer during customer sessions and preparing a loose interview guide to keep conversations productive. Roles for the sessions should be assigned: who presents the context, who runs the demo, who asks questions, who takes notes. (Building can continue until the arrival of the first customer.)

Building and validation prep together constitute the longest sustained work period of the sprint. The facilitator’s job during this phase is to protect the time, keep the group focused on what is essential rather than merely nice to have, and ensure the group arrives at customer validation with something they feel confident showing.

6a. Customer validation

Supplies: customers, computers and a good internet connection

Customer validation sessions are run by a small subset of the group — typically a presenter, someone operating the demo, and a note-taker. The rest of the sprint participants are welcome to observe quietly; engineers and architects will often use this time to decamp and begin implementation planning in parallel (see 6b Implementation Planning).

Each session follows a loose sequence: the presenter establishes context by describing the problem, then asks the customer whether they recognize that problem in their own business. This is not a rhetorical question — the answer is genuinely informative, and customers who don’t recognize the problem are telling us something important. The presenter then describes the benefit the concept is intended to deliver, and the team runs the demo.

Customers should be told at the outset that the team values their honest reaction and that it is out of respect for their thinking that they were invited. This gives them permission to be candid.

The team is trying to understand:

• Is the selected problem relevant to this customer (and customers like them)?
• Is the selected benefit likely to be of high value to this customer (and customers like them)?
• Does the demo show the benefit being delivered?
• Does the customer see the demo as meeting a significant need in a way that is worth paying for?
• Is the demo exciting to the customer? Can they see themselves adopting the proposed capability?
• What misgivings, concerns, or feedback does the customer have?

This feedback can be used to refine the demo between sessions, and it will be used in pitch preparation later.

It is an acceptable outcome that some customers may not find the demo exciting, may not find the benefit appealing, may not find the concept meets a strong need. This is informative; this is why we do the validation.

Scheduling this phase is critical; see Notes about scheduling below.

6b. Implementation planning

Supplies: whiteboard and markers, computers and a good internet connection, and a location out of earshot of the validation team so as not to disturb the customers

While the validation team is with customers, engineers and architects – and any others not needed in the room – turn their attention to what it would take to ship an MVP. This work runs in parallel with Customer validation.

The central questions are:

• What is in the MVP, and what do we deliberately leave for later?
• What is the right sequence? What do we need to build first to unlock everything else?
• What does the technical approach look like at a high level — what are the key architectural decisions or investments?
• Roughly how much effort does this represent?
• What risks and unknowns will need to be sorted before or during implementation?

This is not a sprint plan or a commitment. It is a first-order answer to “could we do this, and roughly how” — the kind of grounded estimate that gives leadership something real to weigh when they see the pitch. T-shirt sizes and a sequence/schedule sketch on a whiteboard are fine. The goal is to arrive at pitch preparation with enough implementation shape that the concept doesn’t feel like a dream, and enough honesty about risks and unknowns that it doesn’t feel like a fantasy.

Note: this process was designed before AI-assisted coding dramatically changed what a small team can build in a short time. The implementation planning conversation should take that into account; what once required a large team or a long runway may no longer, though new constraints may emerge in their place.

7. Pitch preparation

Supplies: computers and a good internet connection

With customer validation complete and implementation planning in hand, the full group reconvenes to prepare a pitch for an internal executive audience. The pitch is short, 15 to 30 minutes including the demo, and tells a condensed story of the sprint.

That story has a natural arc: we understood the assignment, immersed ourselves in the domain, identified a problem worth solving and a benefit worth delivering, built something, and showed it to real customers. The pitch should follow that arc. A good structure is:

• The problem we chose, and why we found it compelling (common, painful, strategic)
• The benefit we chose, and why we believe we’re well positioned to deliver it
• The concept, demonstrated live
• What we heard from customers: what excited them, what gave them pause, what they said they’d pay for
• What it would take to get started: rough sequencing, effort, key risks and unknowns

The pitch should be honest about what was validated and what remains uncertain. Executives are better served by a clear-eyed account of what the sprint found than by a sales job. If customers were enthusiastic, say so and say why. If some were skeptical, say that too, and say what it tells us. The goal is not to get a decision in the room but to give leadership enough to make an informed one.

The sprint team should resist the urge to over-produce the pitch deck. The demo and the customer reactions are the most compelling material; the slides exist to set them up.

z. Wrap-up

Regardless of how the validation went, the team has accomplished a remarkable amount in a short time and should be thanked genuinely for their effort and creativity.

The Wrap-up is also the moment to align on next steps: who will be in the pitch, when it will happen, and who owns any loose ends. These don’t need to be resolved in the room, but they should be named and assigned before people scatter.

A retrospective can happen another time if needed. The goal here is to close the week with gratitude and a sense of accomplishment, not to extend it.

Notes about scheduling

A concept sprint is logistically demanding and the schedule is unforgiving. Two external dependencies anchor the entire week: immersion speakers and customer validation sessions. Both must be locked in well before the sprint begins, because everything else is scheduled around them.

Customer validation is the primary constraint. Once customers are scheduled, the rest of the sprint works backward from those sessions — each phase must be complete before the next can begin, so slippage anywhere cascades into build time. Aim for five to ten customers in closely-arranged half-hour slots, expect attrition, and overbook. Assign one person to own customer scheduling weeks in advance; they will likely still be wrangling participants up until demo time.

The build phase is the long pole. Protect it aggressively. This was especially true before AI-assisted coding changed what a small team could accomplish quickly; even so, building something specific and demo-worthy takes real time. Phases 2 and 3 can move at whatever speed the group needs, but the facilitator should be watching the clock.

Immersion opens the sprint. Speakers must be tightly scheduled, arrive on time, and deliver informationally-dense presentations. Wasted time in Immersion is wasted time everywhere downstream, but don’t shortchange it; insufficiently-immersed participants generate fewer, less-powerful ideas.

Participants need time each day to stay connected to the rest of the organization. Build predictable breaks into the daily schedule for people to check messages and handle urgent matters; it protects their focus the rest of the day.

Ground rules

These rules apply throughout the sprint, but especially during the generation and categorization phases. They are loosely based on IDEO’s brainstorming ground rules.

• Defer judgment. During generation, there are no bad ideas. Evaluation comes in the categorization and evaluation phases, not during generation.
• One idea per sticky note/page. This makes clustering and voting possible, and prevents one note from doing too much work.
• Quantity over quality in generation. A large, diverse pool of raw material is more valuable than a small, polished one.
• Build on the ideas of others. When someone presents an idea, your first question should be whether it sparks something new for you, not whether you agree with it.
• Be specific. Vague ideas are hard to cluster, hard to evaluate, and hard to build. Describe who benefits and how.
• Votes are signals, not mandates. Dot voting surfaces collective thinking and narrows debate; the facilitator may weigh it against strategic context.
• Trust the facilitator to keep time. Discussions will feel unfinished. That’s normal. The schedule is unforgiving and the facilitator’s job is to protect it.

The case for human interfaces becoming obsolete is getting more sophisticated. It used to be “AI will do everything” – easy to dismiss. Now it sounds like Matt Webb’s recent piece on headless architecture: services need to expose their capabilities as CLI tools and APIs for AI agents, making the visual front-end “sacrificial” – encountered once or twice to get the vibe, then handed off to an agent who never needs to see it. That’s a more interesting argument.

I think that’s only partially right. Headless software is on the way. Agents are genuinely better than GUIs for a lot of repetitive tasks. And Jeff Gothelf put it well recently; the cost of building has dropped to near zero.

But several other costs didn’t change, or didn’t change much:

• The cost to support user trust didn’t fall.
• The cost of knowing whether the system delivered what it promised didn’t get lower.
• The cost of responding to a mistake an agent made on your behalf didn’t go away.

When an AI agent does something unexpected – and it will, just as a person does – the user needs to inspect the system’s state, understand what happened, decide whether it’s right, and tweak it if it’s not. That’s not a chat conversation; “explain what you did” gets you a plausible summary, not an audit trail. You need an interface that exposes the objects the agent operated on, their current state, and the relationships between them – something a human can look at, poke around in, and believe.

The “just talk to your AI” folks paper over this by assuming users know exactly what they want, can specify it precisely, will recognize an incorrect result when they see one, and will know how to ask for a correction. Every one of those is an interface design problem waiting to happen. Real users often need to be led to value: shown what’s possible, guided toward good configurations, helped to see that the system actually did the right thing.

A company serving a market and actually learning about their customers and prospects has accumulated expertise about that domain that no individual customer has, and a well-designed product expresses that expertise in its ability to lead a customer to right action. A personal AI that generates a piece of bespoke software on demand doesn’t benefit from that knowledge.

There’s an engineering-minded version of this worth acknowledging. APIs are a bit brittle compared to what an agent can do with a well-designed MCP; the agent can reason about tools, compose them, and adapt to partial failures. That flexibility is valuable. But MCP tools still have schemas and the underlying objects still need to be coherently designed. A poorly conceived MCP tool or underlying model is just as brittle, or worse if the agent confidently does the wrong thing instead of throwing a clean error. The technical design work doesn’t disappear: it moves upstream to the object model, the capability definitions, the semantic coherence of what you’re exposing. That’s more foundational design work, not less.

None of this is an argument for forcing users through rigid prescribed workflows. The right response to the agentic era isn’t to wall off capabilities or ignore the headless trend. It’s to design both surfaces from the same foundation: the human-facing layer for initial trust, inspection, and correction; and the agent-compatible capabilities underneath. Same objects, same data model, two interaction methods. The front-end and the agent tools should be driving the same underlying model. This is, incidentally, what API-first development has been asking us to do for years.

Interfaces are becoming harder to design well, not less necessary. The object model has to be right for both interaction types. The visible informational layer has to foster trust. The inspection and correction paths have to exist. Since users will operate the human interfaces less often, they need to rely less on training and recall, and rely more on recognition. And someone still has to understand the users well enough to know what value looks like and design toward it.

The cost of knowing what to build didn’t get smaller. Neither did the cost of helping people trust and use what you built. That’s the product management and design work. AI didn’t wave it away. It just made it more important to get right.