I thought transparency would help teams learn faster...I was wrong

Dennis Pilarinos

October 14, 2025

One of my favorite product mistakes is rooted in the expression, “there’s no such thing as a dumb question.”

Early on while building Unblocked, we made a key assumption: questions asked by one teammate would likely be valuable to others. If someone was stuck or confused, chances were someone else would be too. So we designed the product to make questions public by default, thinking it would help reduce duplicate interruptions and prevent teams from needing to answer the same question twice.

We believed that visibility would lead to shared learning and fewer disruptions. And in many ways, it did.

But over time, we started receiving support requests from customers asking for a way to make their questions private. When we dug into the reasoning, a clear pattern emerged: many engineers were hesitant to ask questions publicly if they thought the answer might be obvious, already documented somewhere they couldn’t find, or if the question exposed unfamiliarity with parts of the system they hadn’t worked on before.

In short, they didn’t want a searchable record tied to their name that might make them look “dumb”.

We had already built a UI affordance for this feature. We should show users how to turn on “private mode” and they were delighted. (meta lesson: this UI wasn’t discoverable / obvious)

After a few more support requests, and admittedly more time than it should have taken, we revisited our original thesis. In trying to optimize for team learning, we had unintentionally placed a social tax on individuals.

So one day, we changed the default setting. Questions would now be private by default, with a clear and easy option to make them public if desired.

The result was surprising. The number of questions being asked skyrocketed.

We didn’t change anything else. No onboarding tweaks, no pricing changes, no nudges. We just made it safe to ask “dumb” questions.

In hindsight, it makes perfect sense. Engineers, especially those on large or high performing teams, often hesitate to ask questions if they think they should already know the answer.

This is the hidden tax of imposter syndrome.

By giving engineers a space to ask questions without fear of judgment, we unlock a category of knowledge sharing that would otherwise stay hidden. Or stay bottled up until someone burns half a day digging through stale Confluence pages.

This is where real productivity lives. It’s the combination of fast, high quality answers and making it safe to ask in the first place.

The takeaway isn’t just about privacy defaults. It’s a broader reminder that product assumptions shape user behavior.

We built Unblocked to surface institutional knowledge. But we won't do that unless we create an environment where people feel safe admitting they don’t know something.

Kind of like writing a blog post about being wrong about an important product design decision.