← All chapters

Before the day · Page 27

Where good challenges come from

For you only

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

The stuck decision. The first signal in Chapter 6 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 the invite list: 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 the pet-feature trap, 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.

Then run two filters. Can you get the users? You need around five people who roughly match the user in your brief, recruited before the day. If your real user is a heart surgeon, you will be testing with a proxy, and for your first build day I would simply pick a challenge with reachable users instead. And second: 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.

Sources: "How to define a good challenge", productbuildday.com/resources, 2026.