A key lesson from my PM days at Google: theoretical problems are everywhere, but user impact is what truly matters.

Here's how we used to cut through the noise with hundreds of bugs being reported each week:

🔥 P0: "Users are actively being affected in important workflows"
- Payment processing failing during checkout or account creation broken
- Search returning no results for common queries
- Core business metrics dropping significantly
- Key workflows failing some of the time

😱 P1: "Users are actively being affected in uncommon or unimportant workflows"
- Minor UI glitches in frequently used features
- Performance degradation in non-critical paths
- Error messages showing in edge cases
- Issues affecting <0.5% of users in major workflows

⚠️ P2: "Bug that might impact users"
- Theoretical user impact (e.g., potential edge case causing an unexpected UI glitch)
- Slowdowns during workflows (e.g., slight lag in settings menu)
- Unreliable behavior in infrequently used features

🤔 P3: "Users could theoretically be affected"
- Performance issues under synthetic load
- Cleanup of unused features
- "What if" scenarios without historical precedent

Real improvements came when we consistently started asking these questions:
- Can you show me a real user experiencing this right now?
- If we don't fix this today, what actually happens?
- Is this affecting our core user journeys or peripheral features?
- Do we have metrics showing user pain, or just engineer intuition?

This framework helped us push back on the common engineering tendency to catastrophize theoretical problems. Yes, that edge case might cause issues someday. Yes, that performance optimization could matter at 100x scale. Yes that refactor could make the product more reliable. But right now, real users are hitting real problems that need our attention.

The most powerful question became: "Show me the affected users."

If you couldn't point to specific users experiencing problems, it probably wasn't a P0 or P1.

This isn't about ignoring technical debt or potential issues. It's about being ruthlessly pragmatic about where we spend our engineering time. Fix what's broken for users today before fixing what might break for users tomorrow.