The day · Page 37
Assume boldly, test later
Give this to the room
On a normal project, an untested assumption is a risk to manage. Today, it is fuel. Users are coming at 15:30, and the whole architecture of the day rests on that: morning assumptions, afternoon evidence.
When your team stalls on "but what if users do not actually want this?", the answer is short: assume they do, write the assumption down, and build it so we find out today. Not next quarter. Today, from a real person.
Keep your assumptions visible: one sticky note each, stuck next to the screen.
For you only
The sticky notes work twice. They stop the same debate restarting every hour, and they become the pitch. "We assumed she would skip the tutorial, and in the test she did" is the strongest sentence a team can say at 16:00. The judging rubric rewards it directly: user signal is a criterion, and you only get signal on a bet you actually placed.
And bold assumptions beat safe ones. A careful, hedged prototype gets a polite shrug from users and teaches nothing. A bold one gets a reaction either way, and a reaction is the product this day exists to manufacture. A timid build produces neither signal nor inspiration, and the company paid a day for both.
This is where the psychological safety you set at 9:15 earns its keep. Bold assumptions are exactly the interpersonal risk Edmondson's research is about: proposing something that might be wrong, in public, with your name on it. Rooms that have safety place bets. Rooms that do not place hedges.