I've been in meetings where a developer excitedly walks through a new feature.
"Look at this button - it can do this, this, and this."
And I'm thinking, I can't even see the button.
It's not that the feature isn't impressive. It usually is - it works, it's clever, and it solves something. But over time, I've noticed we don't all start from the same place when we look at it.
Developers often begin with technical questions. What could break? How will this behave in edge cases? What is the safest way to implement it?
That instinct makes sense. They're responsible for the system, and their expertise trains them to spot technical risks first.
Coming from a content background, my first questions are different. Will someone understand this? Will they even notice it? Does this make the experience more complicated?
When I first started in this kind of work, I assumed that if I could not argue in technical terms, my concern was not strong enough, or that I needed to know as much as everyone else before raising it. But I've started to see that noticing clarity gaps or unnecessary complexity is not a weaker instinct. It is a different responsibility.
When different perspectives go unnoticed, something can be technically solid and still miss the mark in practice. Not because anyone did anything wrong, but because not every perspective was surfaced.
Recognizing that has changed how I approach those conversations. Instead of trying to match technical depth, I try to name the risk I'm noticing. If something stands out to me or raises a flag in my head, I say it, even if I can't explain the technical implications yet.
Saying what you notice is often the first step toward making something genuinely useful in practice.