How to run the build hours of a Product Build Day

You run the room. The tools do the typing, the teams do the thinking, and you do everything that keeps eight people pointed at one brief. This article is what that looks like in practice: what the teams should actually be making, why the first prompt should go in unread, how to coach without touching anyone's keyboard, and what to say to a team staring at a blank screen at 11:40.

I wrote earlier about how to define the challenge. This is what happens to that sentence for the next six hours.

The first version, not the final one

Get one expectation straight before the clock starts, for the room and for yourself: today the teams build the first working version of a product, not the finished one. Call it a prototype, an early cut, the thinnest slice that works. Its job is to put something in front of a real user at 15:30 that they can click and react to, and for that it does not need accounts, payments, settings, or clean code. It needs one believable path through the idea.

Jake Knapp's Sprint book set the old expectation for what one day of building buys. In 2016, building was expensive, so his prototype day was openly about illusion: stitch together screens that look real from the front, like an Old West movie set, and test on that. Daniel Burka, who worked on sprints at Google Ventures, gave the quality target a name I still use: Goldilocks quality. Polished enough that a user believes it, rough enough that you finish today.

Vibe coding changed what the same day buys. Your teams are not stitching a facade. They are building a working early version of the product, live and clickable from the first prompt, something a 2016 sprint team would not have believed. The Goldilocks rule still holds, it just moved from realness to scope: build the slice of the product that proves the idea, and nothing more.

And expect every team to build something that works but confuses. That is normal. Shipping faster does not mean shipping good, and the user test this afternoon exists precisely to catch it. Just because it works does not mean it is useful.

The tools are secondary

The teams build with vibe coding tools: Lovable, Bolt.new, Replit, or whatever shipped last month and does the same trick. You describe what you want in plain English and a working, clickable product comes back. That trick is the fact the whole method stands on. A product manager who has never written code builds something interactive before lunch.

And still, the tools are secondary. I mean that completely. People ask me which one is best, and my honest answer is that the question is worth about thirty seconds. Pick one default for the day, let anyone who already knows a different one use that, and move on. The differences between them matter to reviewers on YouTube. They will not change what your room learns by 15:30.

What the tool has to do for the day is a short list: a working result from a first prompt, runs in the browser, and gives you a link you can put in front of a stranger in the afternoon. Every tool I named does all three.

Paste the ugly prompt

Now the advice that surprises every room, and the most important section in this article. Do not polish your first prompt. Generate it with another AI tool — Claude, ChatGPT, or Perplexity — paste it into the build tool, and run it. Do not even read it first.

I know how that sounds. Everyone in the room was raised on garbage in, garbage out, and here I am telling them to paste in something unread. So let me defend it properly, because this is the method, and it works for three reasons.

I do this live on stage. At UX CE 2026 in Berlin I generated a first prompt, pasted it into Lovable without reading it, and let the audience watch what came back while I kept talking. The point was never the tool. The point was the order of operations: build first, judge after.

Two AIs are better than one

The build tool is not the only AI in the room. The fastest teams run two screens side by side: a thinking tool and a building tool. ChatGPT, Claude, or Perplexity on the left; Lovable, Bolt.new, or Replit on the right.

The thinking tool covers everything around the build. Quick research on the user's world. Ten ideas in thirty seconds when the team is dry. Real copy for the screens, because real words test better than lorem ipsum. And prompt composing, for the moment a team knows what they want but cannot say it in tool language.

One warning from experience: research on a build day is measured in minutes, not hours. Fifteen minutes of Perplexity is plenty. If a team is still researching at 11:00, that is not diligence, that is hiding from the build, and the kind move is to name it and walk them to the next section.

Assume boldly, test later

On a normal project, an untested assumption is a risk to manage. On a build day, it is fuel. Users are coming at 15:30, and the whole architecture of the day rests on that: morning assumptions, afternoon evidence.

So when a 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, at 15:30, from a real person.

Have teams keep their assumptions visible, one sticky note each, stuck next to the screen. Partly because it stops the same debate restarting every hour, and partly because those notes 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.

There is real research behind why some rooms get bold and others do not. Google spent two years studying its own teams, the study is called Project Aristotle, and the single strongest factor in team effectiveness was psychological safety — Amy Edmondson's term for a room where people can take risks without fear of looking stupid. On a build day you set that in one sentence at 9:30 and then prove it by how you greet the first weird idea. The sentence I use is some version of: nothing is wrong yet. It cannot be. There are no users in the room until 15:30.

The three hats

The build hours have their own working mindsets. I tell builders there are three hats on the table, and a good team passes them around all day.

The scientist turns arguments into testable bets. The gambler keeps the build interesting enough to produce a real reaction. The magpie steals shamelessly, from the tool's accidents, from competitor apps, from a glance at the next table's screen.

Notice the hat that is not on the table: the engineer. Nobody is responsible for code quality today, because the code is disposable and the learning is not. A pair where one person is wearing the scientist hat while the other wears the gambler hat is not a problem. That is the friction working as designed, and it is why I pair people who do not normally work together.

What you actually do for six hours

Back to the fear from the top of this article. Here is the facilitator's job during the build, and it is a loop, not a mystery.

Ask about worries because most concerns at a build day are permission questions in disguise. Ask what the user does next because it is the question that refocuses without instructing. When a team is stuck, do not give them the answer, even when you can see it. Ask what the user would do next, point them back at the brief on the wall, and walk away. The prototype has to stay theirs, because at 16:00 they are the ones pitching it.

Same rule for prompting. Mentoring the vibe coding is your job, and the way to do it is out loud, next to them, never through their keyboard.

Six hours of facilitation fits in those three sentences plus snacks.

Fun is a working part

The day should be fun, and I do not mean that as decoration. Fun is what makes boldness cheap. Nobody builds a weird, wonderful prototype in a room that feels like an exam, and the gambler hat only goes on in a room where laughing is allowed. The atmosphere to aim for is closer to a game jam than a steering committee.

Cheap moves that work: silly team names announced at 9:30, music the room argues about, a two-minute walkabout after lunch where everyone peeks at the other tables' screens. The peeking is not just fun, it is the magpie hat doing its job across teams.

There is also a longer game here. The build day is an advertisement for building. If the day felt like play, a PM opens Lovable again on a random Tuesday two weeks later, because now she knows she can. If it felt like an exam, the tools get filed under "training I attended". The fun is how the method outlives the day.

When it wobbles

Six things go wrong on most build days. Here is the diagnostic I keep in my back pocket.

The part that is yours

Six hours is enough to build four working early versions of a product, which means four placed bets. By 15:30 you will have them on four screens, a wall of written-down assumptions, and a room that is louder than it was at 9:00. None of it will have depended on which tool won the thirty-second debate, or on whether anyone's prompts were elegant. It will have depended on the brief, the bets, and a room where bold felt safe. The teams build the prototypes. You build the room.

This week, try the core move yourself so you can teach it with a straight face: ask Claude or ChatGPT for a first prompt based on one sentence about your user, paste it into Lovable, Bolt.new, or Replit without reading it, and give it twenty minutes. The feeling when that first screen comes back is the feeling your room will have at 9:40, and it is the reason this whole format works.