Perfectionism is a red flag

Last post I talked about drilling into unknowns before you build — learning the geology of what you're about to do. Here's the uncomfortable thing that happens when you do that well. You find a lot of problems. And for each one, your brain immediately starts proposing solutions.

If you find yourself convinced there's a perfect one — that's the red flag.
Perfectionism isn't about quality. It's about psychology. It's your brain protecting itself from a hard truth. Every solution is a trade-off. Choosing one means accepting that from some angle, it's not ideal. That's uncomfortable. That's the weight you have to carry as a builder. And perfectionism is just a way to avoid picking it up.

Before our daughter was born, my wife and I read everything — or so we thought. We'd gone deep on sleep, feeding, emotional development. We had the night sleep routine figured out before she even arrived. Then she arrived and we discovered how daily naps reshape your entire day — how every trip, every plan has to bend around them, how much logistics goes into something we hadn't even thought about. We completely missed that side of sleeping. And that's just one example. As she grew, so did we. We started seeing things as they are — options where none of them was perfect, but as parents we had to make quick decisions in the given situation, own the consequences, and do it again and again.

That's exactly what good product decisions feel like.

There's a saying — perfect is the enemy of good. Most people interpret it as a time problem. Finding the perfect solution just takes too long. I don't think it ever was about time. And with AI today, it definitely isn't — you can explore ten alternatives before lunch and build something that looks perfect faster than ever. But that's exactly the trap. If you're using AI to always polish one more thing on your perfect idea, it only pulls you deeper into the rabbit hole and keeps you from seeing reality clearly.

The problem is that perfect solutions don't exist. Building toward one is your brain pretending the trade-offs aren't real. And it's not just trade-offs. It's risks and unknowns too. Every solution has things that could go wrong, things you don't fully understand yet. The perfectionist brain doesn't want to see them — because seeing them means admitting you're about to make an imperfect decision under uncertainty. But that's always the situation. Pretending otherwise doesn't reduce the risk. It just means you stopped looking for it.

See things as they are. Choose the right trade-offs. Accept the risk of being wrong. Own it.

Don't chase perfection. Be the product leader who sees reality clearly — and builds what matters, not what's "perfect".

This is post 4/8 from my talk at Dev/Hack/Day, @BTC Prague 2025.

Before you build, drill (I meant prototype)

Last two posts I talked about understanding what customers need to fire and hire — and how to get the real story out of them. But knowing why to build something is one thing. Figuring out what to build is another quest entirely.

Most teams follow an agile process that's really just waterfall happening faster. PRD → Figma → tickets → code → test. People say we're in a new era with AI now. Honestly? This was already true 10 years ago. I know, because that's why I switched from frontend engineering to product. Writing code wasn't the hard part. Making the right decisions was — and we kept getting that late or wrong.

A side hobby of mine — I followed how highways are built in my country. Before a highway gets built, highway builders do something called geological exploration. They drill holes along the entire route — not to build the road, but to understand what's underneath. If there's a tunnel planned, they'll actually drill a small pilot tunnel first. Not to "build" the tunnel. To learn what the mountain is made of, so they can design the real one to last.

That's what prototyping should be.

Not a rough draft of the product. Not a "quick and dirty" version you'll clean up later. A deliberate investigation into the areas where you have the most unknowns.

Prototyping is learning. Prototyping is de-risking. Prototyping is understanding complexity so you can make decisions about it.

In product work, your "geology" could be anything. Maybe you're an early-stage startup and you don't know if anyone actually wants your idea. Maybe you want to use a library you've never used before. Maybe you have a huge customer base and you're about to introduce a controversial feature with no idea how they'll respond.

Each unknown needs a different kind of drill. But the principle is always the same: go deep where the risk is highest, before you pour concrete.

Yes, AI gives you a faster, more powerful drill. And honestly, it's incredible — working with AI makes me so much better as a PM and it's also way more fun. But a faster drill doesn't mean you don't need to understand the unknowns and the hidden complexity. You do.

Don't jump from idea to building. Drill and learn geology first. I meant prototype.

Thanks to Ryan Singer for inspiration on this one.

This is post 3/8 from my talk at Dev/Hack/Day, @BTC Prague 2025.

During customer interviews, you're a detective, not a podcast host

Last post I talked about what customers have to fire before they can hire your product. But knowing that is only half of it — you still need to get the story out of them.

Most customer interviews sound like a friendly podcast. Open-ended questions. Lots of nodding. "What features would you like to see?" "How would you improve the experience?"

That's collecting opinions. And opinions are noise.

When someone tells you "I think it would be great if your app had X" — that's their imagination talking. It tells you almost nothing about what they'll actually do.

What matters is what already happened.

As kid I watched Detective Columbo. Every episode was this dance between Columbo and the suspect. The suspect would spin this fog of opinions, explanations, alibis. Columbo ignored all of it. He just kept nitpicking the details — what happened, when, in what order — until the real story unraveled on its own.

That's the mindset. Your customers aren't suspects — they're not lying to you on purpose. But they'll give you the same mix of opinions, rationalizations, and wish lists. Your job is to stay focused on what actually happened.

The question you should ask most often is "when" — closely followed by "why."

My favorite opening: "When did you sign up for our product? Why didn't it happen the day before — or the day after?"

My favorite follow-up: "Can you tell me more? What does that mean?"

Those questions force people to stop generating opinions and start remembering what actually happened.

Pay attention to where the energy shifts. When a customer gets frustrated, or suddenly specific — that's the signal you've hit something real. Like the end of a Columbo episode, when all the nitpicked details suddenly click and you see exactly how the crime happened. That's the moment you understand the full switch — from the old solution to yours.

Stop collecting opinions. Start reconstructing timelines and motives.

Thanks to Bob Moesta for the inspiration on this one as well!

This is post 2/8 from my talk at Dev/Hack/Day, @BTC Prague 2025.

What a customer has to fire, so they can hire your solution

Everyone says "start with the problem, not the solution." Honestly? That's not great advice.

People don't think in problems. They think in solutions. When you're hungry, you don't sit there contemplating hunger. You're already imagining a burger or a pizza.

When you're building a product, yes — you need to understand the problem. But that's not enough. You need to know how people are solving it right now. Because that's what they'll compare you to.

If you want people to use your solution, they first have to stop using something else. It could be anything. Sure, sometimes it's your direct competitor. Often it's the spreadsheet they're duct-taping together. The pen and paper they're scribbling on. Sometimes it's just the mental note they've been keeping in their head.

Before someone can hire your product, they have to fire something. And that's hard. They're comfortable with what they have. They know its quirks. They've built habits around it. That's what's working against you.

But they also hate certain things about it — and something about your product caught their attention. That's what's working for you.

If you understand both sides — what's pulling them back and what's pulling them forward — you can figure out how to make the switch easier.

To uncover this, ask your recent customers three simple questions:

🔹 What were you using before us?
🔹 Why did you fire it — and why did our product catch your eye?
🔹 When did it happen? What was the trigger — the last straw?

That third question is the real unlock. It reveals the trigger moment — the thing that turned a vague frustration into action.

Don't start with the problem. Start with the solution that needs to be fired — that's how your product or feature gets hired.

Thanks to Bob Moesta for the inspiration on this one!

This is post 1/8 from my talk at Dev/Hack/Day, @BTC Prague 2025