Understanding the UX callout

Yesterday I scrolled past a post where a product person had spotted a small UX issue in some app's flow and took to LinkedIn to lament that people just aren't thinking about these things. Doesn't take much effort to fix, he said.

I’m not calling that out, because who cares, really. He has a right to post it, it's harmless, you scroll by. But it made me think about how that dynamic plays out internally, when someone finds a thing, decides it's their thing, and suddenly it has a kind of importance it maybe didn't earn yet.

There's a difference between noticing something and understanding where it actually sits; between a pet problem and a priority. That gap is a big part of the work we do in product management.

If you work in tech, or anywhere, you know what corporate realities actually look like. Annual planning that locks in high-level OKRs months before you know what's going to blow up. Quarterly roadmaps that get reshuffled the moment something urgent catches fire. Sprints that were supposed to include that small fix but then didn't, and then didn't again, and then it's Q4. Every team, at every company, has a list of known issues that is longer than their capacity to address them.

The assumption baked into the callout post is that visible equals unnoticed, or worse, uncared-about. As if the gap between "this exists" and "this got fixed" is explained by inattention. But discovery is the easiest part. Users find things. Colleagues find things. You find things on a random Tuesday. The hard part is everything that happens after you add it to the backlog—the triage, the solution, the negotiation between what's technically scoped and what's strategically urgent, the moment you have to tell someone that yes, we know, and no, it's not next.

And then there's this piece that I find genuinely curious: the implied logic that I found this, therefore it is the most important thing. Which, maybe! You don't really know. You spotted something real and it bothered you, and that's useful data. But a product team's priority stack isn't waiting to be reorganized around any one person's observation, even a smart one. We can't all pivot because another product person spotted a thing on their way through a flow.

There's a meaningful difference between noticing something and understanding where it sits in the larger picture. Between making something your pet problem and thinking strategically about what actually needs to happen for a product and a business to move forward.

The actual job is aligning those things, which means some issues wait. Some issues are known and loved and perpetually deprioritized because three other things matter more right now. That's resource allocation under real conditions, not neglect or apathy. Software is imperfect. Product teams are small. The list is always longer than the bandwidth. Anyone who's been inside it for a while knows this, and mostly makes peace with it.