Design Sprint Day 1: Map the Problem and Pick a Target

Run design sprint day 1: set the long-term goal and sprint questions, map the problem, collect How Might We notes from experts and pick one target.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

Design sprint day 1 is where the team decides what the rest of the week is about. By the end of Monday the team has agreed where the project is heading, what could make it fail, how customers move through the problem, and which single moment in that journey the sprint will attack. Everything that follows (the sketches, the prototype and Friday's test) is built on those four outputs, so a vague Monday produces a vague Friday. The background on why the sprint starts this way is on the Google Design Sprint method page.

The current checklist from Jake Knapp and John Zeratsky packs Monday into a fixed sequence: introductions, a long-term goal, a list of risks, a map, expert interviews with How Might We notes, a vote, and a target picked by the Decider (Design Sprint guide). GV summarises the day the same way: start at the end with a long-term goal, map the challenge, ask the experts, and pick "an ambitious but manageable piece of the problem that you can solve in one week" (GV).

Google's Design Sprint Kit calls this stage the Understand phase and describes its job as creating "a shared knowledge base across all participants" (Design Sprint Kit: Understand). The kit uses prepared Lightning Talks from business, user, competitor and technology angles. Knapp and Zeratsky use live expert interviews instead. Both routes aim at the same result: nobody sketches on Tuesday with a private picture of the problem.

The skill matters most to the Facilitator, who runs the day, and the Decider, who makes the final call on the target. It is also useful to anyone preparing a sprint brief, because a draft goal and draft sprint questions written before Monday speed up the morning. The main failure it guards against is scope. A target that covers the whole journey cannot be prototyped in one day or tested in five interviews, and the team only discovers that on Thursday.

How It Works

Monday runs in two halves. The morning belongs to the sprint team alone and produces three artifacts on the whiteboard: the long-term goal, the sprint questions and the map. The afternoon brings in experts, whose answers refine those artifacts and generate How Might We notes, and it ends with a vote and a decision.

The long-term goal is an optimistic statement of where the team wants to be in six months, a year or longer. The checklist then asks the team to "get pessimistic" and ask how the project could fail, turning each fear into a question the week could answer (Design Sprint guide). AJ&Smart's four-day variant frames the same step as a two-year goal and a set of "Can we...?" statements (AJ&Smart). Whichever phrasing you use, these questions later become the rows of Friday's scorecard.

The map is deliberately rough. Customers and other key players go on the left, the completed goal on the right, and a flowchart of five to fifteen steps connects them. Its purpose is to give the group a shared picture it can point at, so it should show how customers interact with the product and nothing more.

Expert interviews fill the gaps. The checklist suggests fifteen to thirty minutes per expert, covering the vision, customer research, how things work and previous efforts, with the interviewer acting like a reporter. Google's kit recommends that prepared talks be kept concise, citing 10-15 minutes, and notes that speakers can join remotely (Design Sprint Kit: Lightning Talks). While experts talk, everyone else writes How Might We notes: one problem per sticky note, reframed as an opportunity and starting with "HMW."

The last hour converges. The team sticks the notes on a wall, groups similar ones and labels themes, stopping after about ten minutes. Each person gets two votes and may vote for their own note or the same note twice. Winning notes move onto the map, where they tend to cluster around the risky moments. The Decider then circles one target customer and one target moment. The team can weigh in, but the Decider makes the call.

Step-by-Step Guide

Step 1: Set the long-term goal

Open by asking why the team is doing this project and where it wants to be in six months, a year or five years. Write one sentence on the whiteboard and push the group toward an optimistic but concrete statement. If the Decider disagrees with the wording, resolve it now, because every later choice is checked against this sentence. Phrase it as an outcome for customers or the business; feature lists belong later in the week. A draft prepared before the sprint helps, but let the room rewrite it.

Step 2: Turn risks into sprint questions

Ask the group how the project could fail, and write each fear as a question that could be answered this week, such as "Will customers trust a new brand with this?" Aim for a short list of questions the prototype and five interviews could plausibly test. Mark the ones that feel most dangerous, because they should shape the target later in the day. Leave questions that only data or engineering can answer on a separate list so they do not crowd out the testable ones.

Step 3: Draw the problem map

List the customers and key players down the left side and draw the completed goal on the right. Connect them with a simple flowchart of five to fifteen steps showing how customers encounter and use the product or service (Design Sprint guide). Use words and arrows; screen designs come later in the week. If the map grows branches for every edge case, trim it back to the main path. It exists so the team can point at the same place when it argues.

Step 4: Interview the experts and write How Might We notes

Bring in the people who know the customers, the business, the technology and past attempts, one at a time. Ask open questions, update the goal, questions and map as you learn, and keep each interview inside the fifteen to thirty minutes the checklist suggests. Everyone else writes How Might We notes silently, one per sticky note, starting with "HMW." Encourage specific notes such as "HMW show the price before sign-up?" over broad ones such as "HMW improve onboarding?"

Step 5: Organize and vote on the notes

Stick every note on a wall in any order, move similar notes together and label the themes as they emerge. Stop after about ten minutes; a perfect grouping is not the goal. Give each person two votes, allowing votes on their own notes or two votes on one note. Move the winning notes onto the map next to the step they address. The places where votes pile up are candidates for the target.

Step 6: Pick the target

Ask the Decider to circle the most important customer and one target moment on the map (GV). Let the team comment first, then let the Decider decide without a further vote. Check the choice against the sprint questions: the target should put the riskiest questions in play. Also check that the moment can be shown in a prototype built in one day. If it cannot, narrow it to the step where the risk is highest.

Step 7: Record the day's outputs

Photograph or export the goal, the questions, the map with its votes and the circled target before anyone leaves. Write the target as one sentence naming the customer and the moment, and share it with the team that evening. Note any open questions the experts raised that the sprint will not answer, with an owner for each. Tuesday's Lightning Demos and sketches start from this record.

Best Practices

• Draft the goal and sprint questions before Monday. A written draft shortens the morning, though the room should still rewrite it, as the Design Sprint guide expects the team to work these out together.
• Book experts ahead of time and in short slots. Busy people agree more readily to a fixed interview than to a day in the room, and the checklist plans for two to three hours of expert time in total.
• Capture as you go. The Facilitator should write the essence of each answer on the whiteboard during the interview, since the checklist's "always be capturing" advice keeps knowledge from staying in one person's notes.
• Prefer specific How Might We notes. A note tied to one step of the map is easier to vote on and easier to sketch against on Tuesday.
• Ask obvious questions. The Facilitator can pretend to be naive and ask "why?" to surface assumptions that insiders no longer notice.
• Keep the map ugly and small. A map that takes a long time to draw is usually trying to show every path, which makes the target harder to pick.

Common Mistakes

• Choosing a target that covers the whole journey: A target such as "the onboarding experience" cannot be prototyped in a day or tested in five interviews. Circle one moment for one customer, where the biggest risk sits.
• Letting the group vote on the target: A vote spreads the choice across people who do not own the outcome. The team informs the choice, and the Decider makes it.
• Writing sprint questions nobody can test: Questions about scalability or cost need different methods. Keep them on a separate list and focus the sprint on questions a prototype can answer.
• Treating expert interviews as presentations: A prepared slide deck crowds out the questions the team actually has. Ask about the vision, customer research, how things work and previous efforts, and keep the expert talking in answers.
• Skipping the long-term goal because it feels obvious: Teams often discover on Monday morning that they hold different goals. Writing the sentence down is how that disagreement surfaces early.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Google Design Sprint

Related Skills

• Planning a Design Sprint Agenda and Schedule
• Design Sprint Facilitator: How to Facilitate a Sprint
• Design Sprint Exercises: Sketching and Voting
• Sprint User Testing: Running Design Sprint Day 5

Sources

• Jake Knapp and John Zeratsky: Design Sprint guide
• GV: The Design Sprint
• Google Design Sprint Kit: Understand phase
• Google Design Sprint Kit: Lightning Talks
• AJ&Smart: What is a Design Sprint

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.