Most product instincts sound good in theory. Real users are where those instincts get tested.
Working in support changed how I think about building software. A bug report is rarely just a bug report. It is often a story about a broken expectation, a missing edge case, or a decision that made sense in isolation but not in real use.
That changes the way you prioritize. You stop asking only whether something is technically correct and start asking whether it is dependable under pressure.
The most useful thing support taught me is that pain is specific. People do not say, “this workflow lacks coherence.” They say, “I was about to launch and this broke.” That level of specificity makes product tradeoffs much clearer.
It also makes you less attached to elegant assumptions. A tidy system diagram can survive a planning meeting and still collapse in a real environment with plugins, custom data, hosting quirks, and human urgency layered on top.
The best product work I know starts there: close to the friction, close to the context, and close to what people were actually trying to get done.