How to define a good challenge for a Product Build Day

So this is the article people keep asking me for after the step-by-step one: how to actually write the challenge. It is the most important part of the method and the easiest part to get wrong. A vague brief wastes the whole day. A brief that is too tight kills the discovery before the first prompt is typed. The skill is the middle, and the middle can be learned.

One word on words. I say "challenge" for the problem you pick and "brief" for the sentence you write about it, and I will use both below, because on the day they are the same thing: the sentence on the wall.

Charles Kettering, who ran research at General Motors for almost thirty years, said that. On a build day it is the actual deal. You state the problem well the week before. The room solves the other half before five o'clock.

What the brief actually has to do

A lot of people treat the challenge as the opening ceremony. Some words you say before the real work starts. It is the opposite. The brief works three jobs across the day, and when it fails one of them, you find out hours later, when it is expensive.

So the sentence you write the week before is the build instructions, the casting call, and the judging criteria, all at once. That is why it gets its own article.

The shape: user, context, goal

A good brief defines three things and then stops: the user, their context, and their goal. Nothing about the solution. The solution belongs to the teams. That is the point of the day.

Compare two versions.

Take it apart, because every piece is carrying weight.

Just as important is what the sentence leaves out. No screen. No feature. No "AI stylist", no "recommendation engine". Four teams could take this brief and come back with four different products: one rebuilds the home screen around mornings, one builds a remix tool on top of saved looks, one makes the feed calendar-aware, one kills browsing entirely and ships one big button. All four would have served the brief. That spread is what you want.

Context is the part everyone skips

User and goal feel obvious once you see the shape. Context is the piece people leave out, and it carries more than it looks.

The best story I know about this is Clay Christensen's milkshake study. A fast-food chain had flat milkshake sales and had already tried the obvious moves: thicker, sweeter, more flavours. Nothing moved. Christensen's team ignored the product and watched the car park instead, and found that a big share of milkshakes sold in the early morning, to people driving to work alone. The shake had a job: keep a bored commuter company for a forty-minute drive, with the one hand the steering wheel did not need, and hold off hunger until ten. Once you see that job, the answer is obvious and a bit funny: make it thicker so it lasts the whole drive, and move it to the front counter so the commuter is in and out fast. Sales went up. The question was never "how do we make a better milkshake". It was "what is this milkshake hired to do at 7 a.m.".

The "7:45 a.m." in the Zara brief is doing the same work the car park did. Take it out and an evening inspiration app, a browse-for-an-hour experience, becomes a fine answer. Put it back and every browse-heavy idea dies on contact, because nobody browses at 7:45 with a coffee in one hand. Context costs you a few characters and quietly kills a hundred wrong products before anyone builds them.

Where "how might we" comes from, and when it fails

The format is older than design thinking and has better stories. In the early 1970s, Procter and Gamble was losing to Colgate's Irish Spring, a green-striped soap with a fresh promise, and had already tested half a dozen of its own green-striped copies. All of them failed. A young creativity researcher named Min Basadur got called in and changed the question: instead of "how can we make a better green-stripe bar?", he had the team ask "how might we create a more refreshing soap of our own?" Out of that question came Coast, and out of the method came the phrase. It travelled from Basadur through IDEO and Google until it became furniture in every workshop room.

The word doing the work is "might". "Can" demands feasibility before the idea exists. "Might" gives the room permission to suggest things that may not survive, and on a build day you want that permission, because the killing is the user test's job, not the sentence's.

Like all furniture, the phrase gets used without thinking, and it has taken a beating for it. Fast Company once ran a piece calling "how might we" BS, and the fair part of that critique is real: teams treat the three words as a spell. Write "how might we" in front of mush and you get mush with good posture.

So treat the words as optional and the ingredients as mandatory. If "how might we" sounds like consultant theatre to your room, drop it. "Help [user] in [context] reach [goal]" works in any grammar. What you cannot drop is the scope, and scope is the real game. The Stanford d.school and Nielsen Norman Group both call this the Goldilocks problem: "how might we make the app better" sets no direction, and a question that names the feature kills the range.

It is worth noticing what the five-day design sprint does here, because I love the method and it agrees with me on this. Jake Knapp's sprint spends most of its first day narrowing: a long-term goal, the sprint questions, a map, and then one target customer at one target moment. A method with five days to spend gives a whole day to the narrowing. You have fifteen minutes at 9:15. That is why the narrowing happens at your desk the week before, not in the room.

The zoom ladder

Scope is easier to feel than to define, so here is one challenge written at five zoom levels. The example is invented: imagine you run product at an invoicing tool for freelancers.

Levels 3 and 4 work. Level 3 is the one I would tape to the wall. And the middle is a band, not a point, so do not spend a week polishing the sentence. Get inside the band, then spend the saved time recruiting your five testers.

You can also diagnose your brief live, on the day. The room will tell you which way you missed.

Where good challenges come from

Not from a blank page. The good ones are already lying around your company, usually in three places.

The stuck decision

There are six signals that tell you it is time to run a build day, and the first one is being stuck on the same decision for more than two weeks. That argument is raw material. Take the decision and rewrite it from the user's side. A team that has spent a month arguing whether onboarding needs a demo call is sitting on a brief like: "How might we get an ops manager at a 200-person company from signup to her first live report without talking to a human?" Build against it for a day and the argument meets a user instead of another meeting. The brief deliberately takes the riskiest side of the bet, because that is the side worth testing.

The repeated complaint

Support tickets, lost-deal notes from sales, churn interviews. The same complaint three times in a month is a challenge with evidence attached. This is also why marketing and sales are on my list of who to invite: they hear the customer language you do not. Steal it when you draft. If support keeps hearing "I never know if my invoice got seen", that sentence is half a brief already, and it will test better than anything written in roadmap language.

The untested belief

The idea everyone in the company believes in and nobody has tested, usually the founder's. This one is a fine source and one step from a trap I describe below, so handle it with care: frame the user problem the belief claims to solve, not the belief itself. The belief enters the day as one team's possible answer. It does not get to be the question.

Wherever the challenge comes from, run it through one filter before you commit. You need around five people who roughly match the user in your brief, recruited before the day. Five is enough — the Nielsen Norman Group number on how few users it takes to surface most usability problems holds up here. If your real user is a heart surgeon, you will be testing with the closest proxy you can find, and for your first build day I would simply pick a challenge with reachable users instead. A brief you cannot test turns 15:30 into another exchange of opinions, and the test is what makes the day honest.

And one more filter, on top: pick a question leadership actually wants answered. At 16:50 the most senior person in the room makes a call about your challenge. Hand them a toy question and you get a toy decision.

Six ways a brief goes wrong

I keep a list of the ways briefs fail. All six examples below are invented. The patterns are not.

Write it alone, test it on one person

Now the process, which is short on purpose.

One person owns the challenge. You, maybe with one other person, the week before. Not a group exercise, and definitely not the opening activity of the day itself. This is wartime, not democracy. Open the day with a group debate about the problem and you will still be debating it at lunch.

Owning it alone does not mean writing it from your own head. Steal language first. Fifteen minutes with one salesperson, twenty support tickets skimmed, one churn interview reread. You are hunting for the customer's words, the moment, the verbatim complaint. The drafting is solitary. The ingredients are not.

Then run three checks.

One challenge or four?

My default is one. One brief, four teams, four competing answers to the same question. That gives you the sharpest possible decision at five o'clock, because the judges compare like with like and the sponsor picks a direction, not a vibe.

There are honest exceptions. At Ionian we ran four challenges, because Spyros, the founder, treated the day as experimentation, a scan across product directions rather than one bet. That works, with a cost you should accept knowingly: every extra challenge divides the comparison. Four challenges means four separate one-team answers and a softer decision on each. One challenge means four answers to one question and a hard decision about it. Decide what the company needs from the day, a decision or a map, and set the number of challenges accordingly.

Public days are a different animal. For the Athens community edition we are using a theme, "build something Athens needs", with five lanes: accessibility, climate resilience, bureaucracy, small business, mutual aid. That looseness is on purpose. A public room is full of strangers with no shared product and no CEO waiting at 16:50, so the theme does the aiming, the lanes do the narrowing, and each team tightens its own brief in the first half hour. The big hackathons run the same two-layer shape, a broad theme with focused statements underneath. Inside a company, you already know the product, so skip the theme layer and go straight to the tight brief.

The reveal at 9:15

The brief goes up at 9:15 and the whole slot is about fifteen minutes, questions included, because the clock starts at 9:30. Print it big and tape it where every team can see it from their table. You will point at it all day.

Treat the Q&A as your last diagnostic. Clarifying questions about the user and the goal are healthy, answer them and move. "Build what, exactly?" at this stage means the one-person test got skipped, so tighten on the spot: restate the user, the moment, and the finish line, and start the clock. And if the room keeps relitigating the problem at 11:00, do not negotiate a new brief live. Restate the one on the wall in a single sentence, send them back to build, and write yourself a note for next time.

After that, the brief's work is done and the room takes over. The tools belong to the teams, the reactions belong to the users, and the final call belongs to the sponsor. The sentence on the wall is the one part of the day that is fully, completely yours.