What is a Product Build Day?

It is rapid product discovery for a world where building got cheap. Not a five-day workshop. Not a quarter of research. One day that ends in a working thing and a decision a real user helped you make.

I am Marcin Klimaszewski. I made Product Build Day because building got cheap fast, and the people who understand users got pushed to the edge of the room.

The short version

• It is a one-day hackathon for non-coding product people: PMs, product owners, designers, product ops, marketers.
• Up to eight people, four teams of two. Small enough to run alone.
• The team builds with AI tools, tests with real users, and pitches the same day.
• A senior decision-maker joins for the last hour and makes the call in the room.
• The whole method is free.

If you have ever run a workshop, you can run this.

Why now

For most of software history, building was the expensive part. You needed engineers, months, and a budget before anyone could see a working screen. That is over.

Two real numbers make the point. Foti Panagiotakopoulos built the first version of GrowthMentor in 2019 for roughly a brand new BMW sedan equivalent (~50k USD) and seven months. Last year, Yannis Karagiannidis, a marketer who is not a designer and not a developer, built a working product on Lovable for $38 in three days. Different products, of course. But the shape of the change is hard to miss. The MVP got about 99% cheaper and faster.

You can call this an AI bubble. I think it is one. But remember the dot-com bubble in the early 2000s. Plenty of companies went under, and we still have the internet. Vibe coding tools are going to stay with us in one form or another, so it is worth catching the wave rather than arguing with it.

Here is what the change actually did.

When building was expensive, it was the bottleneck. Now it is cheap, the bottleneck moved. Spyros Tsoukalas, the founder of Ionian Technologies, said one thing that stayed with me: building got so easy that the hard part is now promoting and selling the product. Product-market fit is the bottleneck. The decision about what is worth building is the bottleneck. The user test is the bottleneck. None of those is the build.

What this does to product and UX people

Many PMs already vibe-code solutions on their own, without UX, marketing, or dev input. If they are not, they will be next week. There is real FOMO out there, with new AI tools showing up every hour, and a lot of people are shipping straight to development without users or UX anywhere near the room.

Nielsen Norman Group ran a survey asking UX people about our biggest struggle. It was not design skills. It was impact and influence. That was true before AI, and AI sharpened it. UX gets called a bottleneck now too.

So here is the honest situation. Shipping faster does not mean shipping good. Teams often ship confusion.

That sentence is the whole opening for product and UX people. The build is no longer your value. The question is. Is this worth building? Who is the user? What does good look like? Those are the questions we have always owned, and now everyone can build, so the questions matter more, not less. A Product Build Day is how you put those questions back in the centre of the room, and put yourself there with them.

The paradigm shift: build before you decide

The old map of product work is align first, then build. Weeks of discovery, research, workshops, and alignment, and only then does anyone build something real. That made sense when building was expensive. You did not want to waste engineering on the wrong idea, so you spent a long time deciding before you committed.

Flip the cost of building and the logic flips with it. When a working prototype costs $38 and an afternoon, building is no longer the thing you protect. It becomes the cheapest way to think. So you build first, in order to decide. You put a real, clickable thing in front of a real user on day one, and their reaction settles the argument that a workshop would have run for three weeks.

This is the shift Product Build Day is built on:

• From talking about the idea to building the idea, on the same day.
• From one prototype made by one designer to four working prototypes made by the whole room.
• From findings reported next week to a decision made in the room.
• From alignment as a separate phase to alignment that happens while people build side by side.

Product Build Day vs the design sprint

I love design sprints. I am not in opposition to them. The design sprint was announced with the book in 2016 and the method goes back to around 2010, and it gave a whole industry a shared way to work. It is a serious method and I respect it.

It also takes four to five days, and it is hard to get a full team and their leadership to commit to a week. Shorter two-day variants exist, with a day of building and testing on top, and that is still a real ask. The bigger thing is what changed underneath both methods: when the design sprint was designed, building a realistic prototype was slow and specialised. Now it is fast and open to anyone. A one-day format can do what used to need a week, because the build is no longer the expensive step.

Here is the honest comparison.

Both put a decider in the room. Both use a real user to settle the call rather than the loudest opinion. The design sprint contracts a long discovery into a focused week. A Product Build Day contracts it further into a day, because vibe coding lets the whole room build instead of watching one person prototype.

One more thing they share. This is wartime, not peacetime. A normal week is democracy, lots of opinions, slow consensus. A build day is closer to a benevolent dictatorship for one day: one person owns the challenge, sets it, and the users settle the rest. That is a feature, not a flaw. It is why the day ends in a decision instead of a follow-up meeting.

How a Product Build Day runs

The shape of the day, in six steps. Five everyone sees, and one most people forget.

Challenge → Build → Test → Pitch → Decide

The day, hour by hour

Protect the build time. It is the heart of the day. Everything else gets squeezed before you touch the six hours. If one day feels too tight for proper testing, split it: build on day one, test most of day two, then judge and decide. Two days, same shape.

Who is in the room

Keep it small. Eight people, four teams of two. Big enough for real difference, small enough to facilitate alone.

The rule for the room: invite the people who decide what gets built, and the people who quietly shape those decisions. Get them building next to each other for one day.

When to run one

You do not need all of these. One is enough.

How the winner gets picked

Judge on signal, not polish. Three questions, each scored one to five.

Highest total wins. Score the learning, not the looks. A rough demo that taught you something real beats a polished one that did not. Then the senior person makes the call in the room: go, iterate, or no-go. Write it on one page before anyone leaves, with an owner and a date, and send it within 24 hours.

Rapid prototyping, rapid user testing, and the parts people get wrong

A Product Build Day lives or dies on two things that sound easy and are not: rapid prototyping and rapid user testing.

Rapid prototyping with AI. The tools do the coding, so nobody in the room needs to write code. The trick is to stop treating the prompt like a craft. Generate a first prompt with Claude or Perplexity, paste it straight into a vibe-coding tool, and let it run without even reading it first. See the result, then fix it. Speed beats craft at this stage. Pair people who do not normally work together, because the friction between a salesperson and a designer is productive.

Rapid user testing. Be honest about the word. On the day 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, not a statistic, and it is enough to decide. Nielsen Norman Group has shown that about five users surface roughly 85% of usability problems, which is exactly why a 30 to 60 minute round is worth running. Recruit those five before the day, not during it. Ask the way Rob Fitzpatrick teaches in The Mom Test: ask what people actually did, not what they think of your idea. "Tell me about the last time you tried this" beats "would you use this?" People are polite, and politeness is noise.

At Ionian Technologies in Thessaloniki, the team walked onto the street and tested with strangers. In one day they learned that 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. The prototype looked finished. The test is what told them the truth.

The manifesto

Product Build Day stands on six lines. They are the mindset, not slogans.

What you walk out with

The outcomes line up with what a good design sprint delivers, in a fraction of the time.

For the business

• Up to four tested prototypes in a single day.
• Real user reactions, same day, not a research readout three weeks later.
• A decision made on user signal, with leadership committed in the room.

For the team

• Alignment that happened while people built together, not in a separate phase.
• Cross-role understanding, because sales, marketing, and product built side by side.
• A clear read on what leadership actually wants.

For you, the facilitator

• You run the room, not the deck. Leadership sees you leading, not presenting.
• You become the person who ships, with a tested thing that came out of your method.
• You earn a seat closer to the decision next time.

Who it is for, and who it is not

It is for a product or UX person inside a company who wants to lead something real. You have run a workshop before. You are not a developer. You have heard of Lovable or Bolt but have not shipped with one yet. A founder who wants to validate fast fits too.

It is not for anyone trying to run a 200-person public hackathon. That is a different thing, with a stage, sponsors, and big budget. A Product Build Day is a small room making one decision. The big players are already moving this way, by the way. Lovable has advertised for an Enterprise Hackathon Producer, and Replit ran a multi-day hackathon where a company shipped a real build. The market is walking toward the method. This is the small-room version any product team can run on a Monday.

Frequently asked questions

Run one

If building is no longer the hard part, then deciding what to build is the job. A Product Build Day is how you make that decision in a day, with a working thing and a real user, instead of another month of opinions.

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