How a Product Build Day runs, step by step

Building got cheap. Deciding what to build did not.

Your colleagues are already vibe-coding working screens in an afternoon. So is your competition. Yanis, a marketer I know, shipped a real product on Lovable for $38 in three days. He is not a designer and not a developer. Compare that to GrowthMentor, where Foti spent around $50,000 and seven months on the first version back in 2019. Building stopped being the hard part. So the job moved. Someone still has to ask if the thing is worth building, and then get the people who can say yes to actually say it.

That is what a Product Build Day is for. One day. Eight people. One challenge. A working prototype, real user reactions, and a decision made in the room before anyone goes home. One day in, one decision out.

You do not need a specific title to run one. Whether you are a specialist or a manager working on digital products, this is yours to facilitate when the team is stuck and you want to speed things up.

People keep asking me for the shape of the day, so here it is. Five steps: challenge, build, test, pitch, decide. Those five are the whole day. Then one addition most people forget: next steps. That is the part that keeps the day alive in the week after.

Each step below has the same shape, so you can scan it: the goal in one line, what it is, the tips I use on the day, and how to run it when it wobbles.

1. Challenge

This is the most important part of the day, and the easiest to get wrong. A vague brief wastes six hours. A brief that is too tight kills the discovery before it starts. The skill is the middle.

A good brief defines three things and stops there: the user, their context, and their goal. Not the solution. The solution is theirs to find. That is the point of the day.

Compare two versions. "Build something to help users find outfits they love." You have nothing. You do not know who, when, or what good looks like. Now the one I used with Ionian Technologies in Thessaloniki:

I could say that to you, leave you for six hours, and you would know what to do. It tells you who you build for and what good looks like. It does not tell you what to build.

The "how might we" format is worth learning here. The people who study it, the Stanford d.school and Nielsen Norman Group, call the scope problem Goldilocks. Too broad ("how might we make the app better") and you set no direction. Too narrow and you kill the creative range. Keep it to one real user need, and never pack two problems into one question.

Pro tips

• Write the brief in advance, alone or with one other person. Do not open the day with a group debate about the problem. This is wartime, not democracy. One person owns the challenge so the room does not argue for three hours.
• Test it on one person who was not in the planning. If they can picture what to build, it is ready. If they ask "build what, exactly?", tighten it.
• Aim for tight enough to point at, loose enough to discover.

Running it and troubleshooting

This is your 9:15 slot, right after doors open. Keep the brief and the questions short, about fifteen minutes, then form teams and start the clock. If the room keeps relitigating the problem, that is the signal your brief was too loose. Restate it in one sentence and send them to build. If someone wants to run a few bets rather than one idea, you can set more than one challenge. Ionian ran four, because the founder treated the day as experimentation.

2. Build

Six hours, heads down, with tools like Lovable, Bolt, or Replit. You do not teach anyone to code. The tools do that. Your job is the room.

Pair people who do not normally work together. A salesperson next to a designer will argue, and that argument is productive. It is a creative process, so let people pair up in the way that works for them, but push the odd couples together.

Do not polish prompts. Generate a first prompt with Claude or Perplexity, paste it straight into the build tool, and let it run. Do not even read it first. You do not have time. See the result, then fix it. Speed beats craft at this stage.

Expect a team to build something that works but confuses. That is normal. Earlier this year I audited a PM's vibe-coded tool. It worked. The screens were full of colourful buttons, the flow went nowhere, and as a first-time user I was completely lost. Shipping faster does not mean shipping good. Teams often ship confusion. The test catches it. That is what the test is for.

Pro tips

• Roam the room, music on, snacks out. Protect the build time. Everything else gets squeezed before you touch the six hours.
• Do not give a stuck team the answer. Ask them what the user would do next, and point them back at the brief.
• Keep three lines in your pocket: "What does the user see in the first five seconds?", "Show me the click that proves it.", "Talk less, demo more."

Running it and troubleshooting

Build runs 9:30 to 15:30, and it is the heart of the day, so guard it. If a team is stuck staring at a blank screen, it is almost always the prompt, not them. Have them generate a fresh one and paste it in without reading. If two people cannot build side by side at all, that is worth noticing on its own. Sometimes the problem is how they work together, not the tool.

3. Test

Same-day testing is rough, and it still beats another opinion in the room. Be honest about the word. You get reactions, not results. A reaction is a real person opening the thing for the first time and getting lost, or lighting up, or asking "what is this for?" That is signal. It is not a statistic. It is enough to decide and move.

Recruit before the day, not during it. Line up around five people who roughly match your user. Nielsen Norman Group has shown that five users surface about 85% of the usability problems, which is the whole reason this fits in 30 to 60 minutes. If your user is hard to reach, like a heart surgeon, test with the closest proxy you can find. At Ionian, the team walked out onto the streets of Thessaloniki and asked strangers. Brave, and it worked.

How you ask matters. Rob Fitzpatrick's The Mom Test is the rule I lean on: ask about what people actually did, not what they think of your idea. "Tell me about the last time you tried to do this" beats "would you use this?" People are polite, and politeness is noise.

Pro tips

• Watch where they hesitate, where they tap something expecting it to do a thing it does not, and whether they can say what the product is for after the first screen.
• Do not chase the praise. The thing that failed teaches you more than the thing they said they liked.
• Aim for two or three real findings per team.

Running it and troubleshooting

This is a fast round, 15:30 to 16:00, sometimes up to an hour if you have it. If you genuinely cannot test on the day, run the day anyway for alignment and test in the days after. A Product Build Day with no test is still worth it, because the room aligned and built together and you led it. But test if you possibly can. At Ionian, one user spent ten minutes and never found an outfit, another tapped an outfit expecting details that were not there, and a third could not say what the app was for. Heavy findings. Learned in a day instead of a quarter.

4. Pitch

Every team pitches. No exceptions. Ten minutes each. Five minutes to show and explain, five minutes of questions from the judges. Pitch in the open, in front of everyone, not in a side room, so people hear how each other think.

This part matters more than people expect. Most of us who work on digital products are not good at selling our own work, whatever our title. This is a safe place to get better at it, in front of a friendly room.

Keep the pitch to four things: who you built for and the challenge, what you built, what the user test showed (one thing that worked, one that did not), and what you would do next. Show the product, do not describe it. Keep the live demo to about two minutes and aim it at the problem you solve, not the feature list.

Pro tips

• Rehearse the demo once before the room sees it, so a glitch does not eat your five minutes.
• Do not read slides. Two minutes of working product beats ten minutes of explanation.
• Jenny Lindbad, the Pitch Coach, posts short, usable advice on this. Worth a follow before you run your first one.

Running it and troubleshooting

Pitches run 16:00 to 16:40 for four teams, ten minutes each. Keep them on the clock or the decision hour slips. If a live demo breaks, have the team talk through the one click that proves the idea rather than restarting the whole thing. Aim for one clear story per team: the user, the problem, the click that proves it.

5. Decide

Judge on signal, not polish. The rubric scores three things, each one to five. Did it serve the brief, building for the user and goal we set? What did real users actually do with it? Is it worth building? Highest total wins. If two are close, the room talks it out and the judges own the call.

The bigger hackathons score the same way. Keep it to three or four criteria, make each one a question a judge can answer, and score the stage the team is at, not the spit and polish. A rough demo that taught you something real beats a clean one that did not. Score the learning, not the looks.

Here is the move that separates a fun day from a day that changes the company. Invite the most senior person you can, the CEO, CPO, or head of product, for the last hour only. One hour is an easy yes, even from someone hard to reach. A whole day is not. They watch the pitches, they see what real users did, and they make the call in the room. Go, iterate, or no-go. No follow-up alignment meeting. No deck sent around for three weeks. The people who needed to say yes were there, and they said it.

Pro tips

• Get a verbal yes and a thumbs up in the room, not "let's sync next week".
• Do not let the winner be the demo that looked most finished. Score the signal.
• This is your moment as much as theirs. You run the room, not the deck. Leadership sees you leading, not presenting.

Running it and troubleshooting

Judges deliberate 16:40 to 16:50, and the winner and the decision land by 17:00. The path is simple: pitches done, judges score on the rubric, the senior sponsor picks a direction, then go, iterate, or no-go. If leadership cannot join even for the last hour, record the pitches and the rubric scores and get the call within 24 hours, while the signal is fresh.

The addition everyone forgets: next steps

The five steps above are the whole day. This one is the addition, and it is the one that decides whether any of it mattered. Five teams pitch, a winner gets picked, everyone feels good, and then nothing happens on Monday. The day works. The week after is where it dies, if you let it.

So plan the next steps before anyone leaves, and protect them in the days after. Three moves keep the day alive.

Write the decision down on one page before they walk out: what we are taking forward, what we are dropping, who owns the next step, and by when. Send it within 24 hours, while the room still remembers. That page is what stops the energy dying.

Give the winning team a real next step, not a trophy and silence. Even a small one. The point of the day was to ship, so ship something on Monday.

Tell the story inside the company. Write up what happened and what you learned, and put your name on the room you ran. This is how you get invited to run the next one, and how leadership starts seeing you as the person who ships.

Pro tips

• Name an owner and a date for every "go". A decision with no owner is not a decision.
• Keep the decision doc to one page, not a report. If it takes more than ten minutes to write, it is too long.
• Do not end on applause and a group photo with no page signed.

Running it and troubleshooting

If the day produced more than one "go", do not start all of them at once. Pick the one with the clearest user signal and ship that on Monday. If leadership went quiet after the room, send the one-pager anyway with a date next to each decision and ask them to reply yes or no. Aim for a working thing in front of real users on Monday, and a company that knows you made it happen.

That is the whole flow. Challenge, build, test, pitch, decide, and then the next steps that keep it alive. Do not skip that last part. A clean day with no follow-through is just a nice memory by Friday. The decision and the Monday ship are what turn it into something the company actually did.

The five-day design sprint is a method I respect and still love. It also takes four to five days, and that is a lot to ask a team to commit to. This is one day, and it ends in a decision.

If building is no longer the hard part, deciding what to build is the job. This is how I do it.

This week, write down one challenge your company could build against, in the user-context-goal shape above, and pitch it to your manager. That is the whole first step.