Run one, then tell me

Thank you for reading this far, and for trusting the method enough to try it.

This is version 2 of the playbook. It exists because people ran version 1 and told me what broke, what worked, and what was missing. The pitching chapter, the troubleshooting tables, the handout cards: all of it started as a message from someone who ran a room. So this book improves the same way the prototypes in it do: contact with real users. You are the user.

Run one. Then message me on LinkedIn and tell me how it went: what your room built, what the users did, what the sponsor decided, what wobbled. I read everything, I collect the stories, and I share them onward with credit to you. Some of them end up in the next version of this book.

A week ago we ran a company-wide hackathon. Three or four of us designers built side by side, pushing commits, and we had a working demo by the end of the day. It is possible.

A designer in the audience, UX Camp Europe 2026, Berlin

I made Product Build Day because building got cheap fast, and the people who understand users got pushed to the edge of the room. A PM can vibe-code a working screen in an afternoon now. That does not make it useful. Someone still has to ask if it is worth building.

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

This week, write one challenge for your own product in the user, context, goal shape. Aim for 31 words. Read it to one colleague, and if they start describing what they would build, you have your first build day.

You ran it, you get the credit.

AUTHOR Marcin Klimaszewski Founder & Facilitator · Product Build Day productbuildday.com