When Building for Yourself Becomes a Product Blind Spot

The Tool That Works Perfectly — For Someone

A post caught my eye this week: "I spent 4 years building a UI design tool with only the features I use." It was framed as a quiet flex. Focus. Restraint. Conviction. And to be honest, part of me admired it.

I’ve been in enough roadmap meetings where the hardest thing isn’t deciding what to build — it’s deciding what to leave out. There’s something refreshing about a product shaped by deep, lived familiarity. Someone who knows the problem well enough to say, this is enough.

But the longer I sat with it, the more a tension surfaced. Not disagreement — discomfort. Because I’ve also sat across from users struggling with products that were internally coherent and externally confusing. Tools that were beautifully intentional, but only if you thought the way the builder did.

That tension shows up all over the conversations I’ve been seeing lately. We’re fixing interfaces. We’re tightening flows. We’re celebrating clarity. And still — quietly, consistently — we’re missing people.

This isn’t a call to abandon conviction. It’s a reflection on where conviction turns into a blind spot.

The Comfort of Familiar Problems

When you build something you use every day, you gain an incredible advantage: high-fidelity feedback loops. You don’t need to schedule a session to notice friction. You feel it immediately. You iterate with care because the cost of a bad decision is personal.

That’s real. And it’s valuable.

But there’s a hidden tradeoff that doesn’t get discussed enough: familiarity collapses variability.

When you are the user:

Edge cases stop feeling like edges
Workarounds feel reasonable
Missing affordances fade into muscle memory

I once worked with a founder who could complete their core workflow in under 30 seconds. New users averaged closer to five minutes — and needed a walkthrough to get there. The product wasn’t broken. It was overfit.

A product can be internally elegant and externally brittle at the same time.

This is where a lot of teams unintentionally stall. The product keeps improving — but only along dimensions that matter to the people closest to it.

There’s a data point from Nielsen Norman Group that’s stuck with me for years: testing with just 5 users can uncover around 85% of usability issues. Teams hear that and think, Great — we don’t need much research.

What often gets missed is the follow-up: those users need to represent different mental models, not just different roles or companies.

Usability issues are easy to find. Misalignment is harder — and more expensive.

When Usability Isn’t the Same as Understanding

Another thread gaining traction this week revisited a familiar critique: we still conflate usability testing with user understanding.

If someone can complete a task, we mark it as success. If they don’t make errors, we ship with confidence. But I’ve watched too many users succeed despite the product, not because of it.

One research session stays with me. A participant completed every task we gave them. Clean metrics. No blockers. But at the end, they asked a simple question:

“Is this really what you expect people to do every day?”

They weren’t confused. They were unconvinced.

That’s the gap many teams are falling into right now. We’re validating interaction, not intent.

Here’s how I’ve learned to spot the difference:

Usability testing answers: Can someone use this?
User understanding asks: Does this fit how they think the work should happen?

Those are fundamentally different questions.

According to a 2023 Productboard report, teams that regularly incorporate continuous discovery practices are 2x more likely to report strong product-market fit. Not because they test more screens — but because they stay close to evolving context.

The risk of building primarily from personal intuition is that it narrows that context over time.

Customization, Control, and the Illusion of Choice

A related conversation has been unfolding around modular customization in B2B SaaS. On the surface, it’s about flexibility. Underneath, it’s about something more human: control.

When products don’t quite fit, we add options. Toggles. Settings. Configurations. We let users bend the system instead of asking whether the system understands them.

I’ve seen this play out repeatedly:

A product is designed around a clear internal logic
Users adapt — awkwardly, but successfully
Requests for customization increase
The product becomes modular instead of coherent

Customization can be a powerful sales enabler. But it can also be a signal that the core mental model is doing too much work.

One mid-market SaaS company I advised had over 120 configurable fields in their main workflow. Sales loved it. Implementation teams survived it. End users tolerated it.

When we stepped back and ran contextual interviews, a pattern emerged: most customers were recreating the same three variants — all approximations of workflows the product never explicitly supported.

The fix wasn’t more customization. It was acknowledging that the original design reflected how the team thought the work should happen, not how it actually did.

Flexibility without understanding is just responsibility shifted onto the user.

The Quiet Role We Keep Underestimating

Several of this week’s pieces touched on roles that sit between teams and users — product specialists, researchers, hybrid PMs. These roles are often framed as translators. I think that undersells them.

Their real value isn’t translation. It’s tension maintenance.

They hold space between:

What the system optimizes for
What people are actually trying to accomplish

When teams build primarily from their own usage, that tension disappears. Decisions get faster. Alignment gets easier. And blind spots get deeper.

I’ve watched teams lose this without noticing. Research becomes validation. Feedback gets summarized instead of debated. Roadmaps feel calm — right before churn spikes.

There’s a sobering stat from Pendo: 80% of product features are rarely or never used. That’s not a failure of execution. It’s a failure of judgment — of mistaking internal logic for external value.

What I’ve Learned to Do Differently

After years of watching this pattern repeat, I’ve changed how I approach conviction-driven products — especially those built by deeply experienced teams.

A few practices that have helped:

Separate fluency from fit: Just because something feels obvious to you doesn’t mean it’s natural to others.
Listen for resignation, not confusion: Users often adapt quietly before they complain.
Test mental models explicitly: Ask users to explain the system back to you — not just complete tasks.
Resist premature pride: A focused product isn’t the same as a complete one.

None of this requires abandoning taste or vision. It requires expanding the circle of people whose experience you treat as authoritative.

The Work That Still Matters

I don’t think building for yourself is wrong. I think it’s incomplete.

Some of the best products in the world started as tools someone needed badly. But they lasted because their creators eventually made room for unfamiliar struggles — and let those struggles change the product.

The conversations I’m seeing right now tell me we’re at another inflection point. Building is faster. Tools are sharper. Conviction is celebrated.

Which makes judgment — real, human judgment — the scarce skill again.

Not the kind that shows up in feature lists or clean interfaces. The kind that notices when something works, but still doesn’t belong.

That’s the work I hope we keep choosing. Even when it complicates the story. Even when it challenges the product we’re proud of.

Because the people on the other side of the screen aren’t trying to admire our tools.

They’re just trying to get their work done.

And they deserve products that were built with them — not just for someone like us.