Before the day · Page 26
Six ways a brief goes wrong (2 of 2)
For you only
The everyone user. "How might we help our users collaborate better?" "Users" is not a person. Every team will imagine someone different, and at 15:30 you cannot recruit anyone, because nobody matches "users". Pick the narrowest user who still matters to the business, and accept that choosing a user means not choosing the others. That is aiming. It is supposed to feel like that.
The science-fair brief. "How might we explore what AI could do for our onboarding?" There is no goal, so nothing can fail, and a day where nothing can fail produces demos, applause, and no decision. You wanted a decision day and you wrote yourself an innovation-theatre day. "Explore" is what the six build hours are for. The brief itself commits: one user, one outcome.
The pet feature in disguise. "How might we help users get value from the new dashboard we are shipping in Q3?" The winner was decided before the doors opened, and the room will smell it inside four minutes. The day becomes a ratification ceremony. Aim the brief at the problem the dashboard claims to solve, and let the dashboard compete like everything else. If it is as strong as its sponsor believes, it will survive the day. An idea that cannot survive a day is not worth a quarter.
Diagnose it live. The room will tell you which way you missed:
| What you see on the day | What it means |
|---|---|
| Teams still relitigating the problem at 11:00 | Too loose. Restate the brief in one sentence and send them back to build |
| "Build what, exactly?" during the 9:15 Q&A | Too loose. Tighten the user or the goal |
| No questions at all at 9:15 | Often too tight. There was nothing left to ask |
| Four near-identical builds by 14:00 | Too tight. The solution was hiding in the brief |
| Pitches that cannot be compared | Too loose. No shared user or goal to score against |
| A team done and idle at 12:30 | Too tight. You handed them a ticket |