Product Build Day // Podcast

"It really felt like you were going through a survey and reading real comments." Someone said that at Product Build Day Stockholm, after their team tested a prototype with synthetic users. More than 100 people ran synthetic tests in my rooms this year.

So can you trust synthetic users? There are two questions hiding in that one: can people use it, and do people want it? Synthetic users answer the first one at light speed, and that makes your time with real people worth more. Only real people can answer the second.

What you'll hear:

• The two camps: "fake research" against "the obvious next step"

• Why 100% task success is a usability result and not a market signal
• What synthetic users are best at for now, and what they can't do
• Will synthetic users replace testing with real people?
• When a mature product needs something else, and why someone has to read the findings with judgment

Try this week: test a website you often struggle with using synthetic users. Before you look at the results, write down where you expect them to get stuck.

I'm Marcin Klimaszewski and I run ⁠Product Build Day⁠. Send me your question on ⁠LinkedIn⁠, and it might become an episode.

Sources:

• User Interviews: State of User Research 2025 (10 September 2025)
• uhura: AI personas and synthetic users: fast research or risky illusion? (10 September 2025)
• Nielsen Norman Group: Synthetic users: if, when, and how to use AI-generated "research" (21 June 2024)
• MeasuringU: A review of experiments with synthetic users (14 April 2026)
• Sauer, Braun, Kostic and Krauß: Humans vs. AI: who's the better usability evaluator? (HCI International 2026)
• Product Build Day September tour: Amsterdam, Copenhagen, Stockholm and Berlin

"Who produces better ideas: individuals or teams?" Stanford's d.school asks that in its online library of design questions.

The usual answer at work is to start together, all in one room. But in a study from Wharton and INSEAD, groups that spent the first ten minutes alone came up with about three times as many ideas in the same half hour, and their best ideas were better.

This episode is about why starting alone makes the whole team better, and how to run the part where the team decides together.

What you'll hear:

• The 1957 claim behind brainstorming, and the study where starting together lost
• Product Build Day Athens: two real challenges, everyone building alone first, then deciding as a team
• What teams in Copenhagen, Stockholm and Berlin named as the hardest part, and why the time limit helps
• Four good moves when a team sits down with everyone's ideas
• Why the test comes first, and why "assumption" scares so many managers
• Where this breaks: people, and weak facilitation

Try this week: pair up with a colleague, build against the same challenge separately, compare what you found, what you built and what you assumed, then build one thing together.

Next episode: Can you trust synthetic users?

I'm Marcin Klimaszewski and I run ⁠Product Build Day⁠. Send me your question on ⁠LinkedIn⁠, and it might become an episode.

Sources:

• Stanford d.school library: Who produces better ideas: individuals or teams? (with Robert Sutton)
• Stanford d.school, Jeremy Utley: To brainstorm better, alternate solo and team work (2 September 2021)
• Korde and Paulus: Alternating individual and group idea generation (Journal of Experimental Social Psychology, 2017)
• Girotra, Terwiesch and Ulrich: Idea generation and the quality of the best idea (Management Science, 2010)
• Knowledge at Wharton: How group dynamics may be killing innovation (12 May 2010)
• Diehl and Stroebe: Productivity loss in brainstorming groups (1987), quoting Alex Osborn's 1957 claim
• Jake Knapp, John Zeratsky and Braden Kowitz: Sprint (2016)
• Product Build Day Athens, July 2026
• Product Build Day September tour: Copenhagen, Stockholm and Berlin

"Did you really throw everything away, or only the code?" Someone asked that on a French forum, under a post from a developer who vibe coded an app for a month, about 20,000 lines of code, and then threw it all away.

AI-built prototypes look finished, so the usual move is to call them version one and keep going. But in Veracode's 2026 report, AI-generated code had an average security pass rate of 56%. This episode is about what a prototype is actually for: learning what's worth building, before a development team builds it for real.

What you'll hear:

• Why the handoff in product discovery is knowledge of what to build
• Build before you build: vibe code to prove it's worth building, then let a development team build the real thing
• The four-line contract to put at the top of every prototype
• When a prototype can do a real job, and when it can't

Try this week: before your next build, write the four-line contract: the test, the one path, what it must never hold, and the signal that ends it.

Next episode: Four people alone had twice the ideas of four together.

I'm Marcin Klimaszewski and I run Product Build Day. Send me your question on LinkedIn, and it might become an episode.

Sources:

• ⁠LinuxFr: J'ai vibe-codé une appli pendant un mois, puis j'ai tout jeté (11 September 2026)⁠
• ⁠SweClockers forum thread (29 July 2026)⁠
• ⁠Veracode: GenAI Code Security Report (30 July 2025)⁠
• ⁠Veracode: 2026 GenAI Code Security Report (28 July 2026)⁠
• ⁠WIRED: Thousands of vibe-coded apps expose corporate and personal data on the open web (7 May 2026)⁠
• ⁠Security Boulevard: the RedAccess scan of about 380,000 apps (7 May 2026)⁠
• ⁠Product Build Day Warsaw, July 2026

Your boss is probably vibe coding more than you are. In a French survey of 1,031 people in product teams, 29% of CPOs said they use a vibe coding tool, against 12% of product owners.

So yes, learn it. The tools take one afternoon. The skill that takes practice is writing the challenge: one or two sentences that tell your team exactly what to vibe code, so you can test four assumptions in one day.

What you'll hear:

• Why your boss is probably ahead of you on vibe coding

• How to write a challenge you can vibe code against, with the real one from Product Build Day // Stockholm
• Why one challenge gave us four different apps, and when to write four challenges instead
• A case study
• When same-day testing doesn't work, and why a challenge is only the start

Try this week: write four challenges for your next idea, one or two sentences each, and vibe code against one of them.

Sources:

• Reddit, r/ProductManagement: How important is vibe-coding for PMs apart from core PM work? (7 July 2026)
• Le Ticket: L'IA dans les équipes produit, quel est le vrai état du marché ? (7 September 2025)
• Product Build Day Warsaw, July 2026
• Product Build Day Athens, July 2026
• Product Build Day September tour, including Stockholm
• Ionian Technologies: four ideas, one day, one decision

Next episode: A prototype is an instrument with an end date.

I'm Marcin Klimaszewski and I run Product Build Day. Send me your question on LinkedIn, and it might become an episode.

A startup founder told me they can vibe code faster than their dev team, and they still don't know what to ship. I hear the same question at every conference and in almost every conversation with product managers.

When anyone can build a working first version in about five minutes, "it works" stops telling you which idea is worth building. This episode is about finding the one belief your idea can't survive without, and testing it fast, before it costs you money and time.

What you'll hear:

• What makes you different when everyone in the room can build
• The test that kills it, with a real brief from Product Build Day // Copenhagen
• Build before you build: synthetic users for usability, The Mom Test interviews, then a fake door
• How many clicks a fake door needs, and why you write your kill line before you look
• When "just build it and see" is the right call

Try this week: circle the belief that would kill your idea, and write a kill line before you test it.

Next episode: should product managers learn to vibe code?

I'm Marcin Klimaszewski and I run ⁠Product Build Day⁠. Send me your question on ⁠LinkedIn⁠, and it might become an episode.

Sources:

• ⁠⁠Product Focus, 2026 Survey of the Product Management Profession⁠⁠
• ⁠⁠Eurostat, Labour cost levels by economic activity, 2025⁠⁠
• ⁠⁠Die Produktwerker, episode 340, 24 August 2026⁠⁠
• ⁠⁠Rob Fitzpatrick, The Mom Test⁠⁠
• ⁠⁠Kromatic, The Real Startup Book: Fake Door Smoke Test⁠⁠
• ⁠⁠Product Build Day Warsaw, July 2026⁠⁠
• ⁠⁠Product Build Day September tour, including Copenhagen⁠

Building got cheap. Deciding got hard.

This year, over 120 people joined Product Build Day in six European cities to build an idea with AI and test it within one day. A working first version took minutes. The hard part came after: does anyone want this, and how do you find out before you spend a month on it?

I'm Marcin Klimaszewski. I run Product Build Day, and in this podcast I answer one question product people keep asking, in about ten minutes, every weekday.

In every episode:

• The question, as it was asked
• The usual answer, and why it makes sense
• A moment from one of our build days where that answer broke
• One thing to try that week

Every number comes with a source in the show notes. Topics: product discovery, testing ideas before you build them, vibe coding and prototyping with AI, and getting to a clear decision.

Start with episode 1: You built it. Now try to kill it.

If there's a question you keep asking yourself, send it to me on LinkedIn. It might become an episode.