Triage Framework for Prioritizing Bugs, Complaints and Incidents as a PM

Walk the interviewer through how you triage the issues that reach your team, such as bugs, customer-reported problems and production incidents: how you decide what gets handled right away, what waits, and what does not get fixed at all. Illustrate your process with an example if you can. ```hint Separate two judgments How badly an issue hurts the users it affects and how urgently the team should act on it are related but different; decide how your process judges each one before combining them. ``` ### Clarifying Questions - Does "issues" mean bugs and production incidents only, or also customer feature requests and support escalations? - Is the product customer-facing, an internal tool, or a service other teams depend on, since that changes whose impact sets the severity? - Does the team already have an on-call engineer and an incident process, or does the PM own the first pass on every incoming issue? ### What a Strong Answer Covers - Intake: how issues from different channels land in one place with enough information to act, and how duplicates are handled - Explicit criteria for severity and reach (customer impact, number of users, data, security or money at risk, availability of a workaround) - How priority translates into action: an owner, a response target, and what happens to low-priority items - Communication with reporters, support and stakeholders, including closing the loop when a fix ships - How recurring issues and incidents feed back into the roadmap and how the triage process itself is measured ### Follow-up Questions - Two high-severity issues arrive at the same time and the team can only staff one. How do you choose? - A senior leader insists their reported bug be fixed now, but your criteria rate it low. What do you do? - How do you keep the backlog of low-priority issues from growing forever?