I’ve spent the last few months building. Tools, prototypes, experiments. The dopamine hit of shipping something is real - there’s nothing quite like pushing code and seeing it work.

But I’ve started to notice a pattern. I build, I ship, I share… and then I wait for validation. Not feedback. Validation.

There’s a difference.

The Comfortable Question

When you share something you’ve built, there’s a version of the question that feels safe:

“What do you think?”

It sounds open. It sounds like you want feedback. But if you’re honest with yourself, you’re really hoping they’ll say it’s great. You’re bracing for criticism while secretly wanting applause.

I’ve asked that question a lot. And I’ve noticed how good I am at steering conversations toward the parts that work, explaining away the rough edges, pre-emptively defending decisions before anyone’s even challenged them.

That’s not discovery. That’s performance.

The Uncomfortable Question

The question that actually matters is much harder to ask:

“Would you use this? Why or why not?”

Or even harder:

“What problem are you actually trying to solve - and does this help?”

These questions are uncomfortable because they invite a “no”. They create space for someone to tell you that the thing you’ve poured hours into doesn’t solve a real problem. That’s vulnerable. That stings.

But it’s the only way to learn whether you’re building something that matters.

Why This Is Hard for Builders

If you’re someone who builds things, you probably got here because you’re good at solving problems. You see something broken, you fix it. You imagine something useful, you make it.

The identity is wrapped up in the making.

So when someone suggests that the thing you made might not be needed, it doesn’t just feel like feedback on the product. It feels like feedback on you. On your judgement. On your ability to see what matters.

That’s why we avoid the honest question. It’s not that we don’t want to improve - it’s that we don’t want to discover we were wrong from the start.

The Shift I’m Trying to Make

I’m trying to move from “build and hope” to “discover and build”. It sounds obvious when you write it down, but the practice is harder than the principle.

It means:

• Sharing rougher work, earlier, before I’m attached to it
• Asking questions that invite “no” as a valid answer
• Sitting with the discomfort when someone doesn’t get it
• Distinguishing between “this needs polish” and “this doesn’t solve a real problem”

It also means accepting that some things I’ve built might not have an audience. Not because they’re bad, but because I built what I found interesting rather than what someone else actually needs.

The Irony

The irony is that I’ve built coaching tools. Tools designed to help people reflect honestly, identify blind spots, and improve through genuine feedback rather than flattery.

And yet I’ve been dodging that same process myself.

It’s easier to build a tool that coaches others than to sit with the question: does anyone need this tool?

What I’m Doing About It

I don’t have a neat answer here. I’m still figuring this out.

But I’m starting to:

• Share work with people who I know will be honest, not just supportive
• Ask specific questions that can’t be answered with vague encouragement
• Notice when I’m defending rather than listening
• Treat “I wouldn’t use this” as data, not rejection

The goal isn’t to stop building. The goal is to build things that matter to someone other than me.

And that requires asking questions I’d rather avoid.

---

This is part of an ongoing series about building in public - including the uncomfortable parts that don’t make it into the “shipped it!” posts.