Approach in Handling Production Bugs Post-Launch
What steps would you take to handle customer feedback about bugs in features?
That’s a fundamental question that sits at the core of a Product Manager’s responsibility. Handling bug feedback effectively isn’t just a technical or QA process; it’s a critical customer trust, product quality, and communication process.
My approach is to apply a structured framework that ensures we are responsive, systematic, and strategic. I’ll call it the “Acknowledge, Validate, Prioritise, Resolve, Communicate, and Learn” framework.
Here’s how I would break down the steps:
1. Acknowledge & Triage (Immediate Action)
The moment feedback arrives—whether from a support ticket, a user forum, or a ‘Report a Bug’ button—the clock starts.
Immediate Acknowledgement (External): The first priority is empathy and responsiveness. The customer who reported it needs to feel heard. I’d ensure our support team (or an automated system) immediately responds: “Thank you for reporting this. We’ve received your feedback and are investigating. We’ll follow up with an update shortly.”
Log the Issue (Internal): I (or the designated team) would immediately create a ticket in our tracking system (like Jira). This ticket must capture:
Reporter: Who reported it (User ID, company, etc.)?
Source: Where did it come from (Support, Sales, internal)?
Description: What is the actual vs. expected behavior?
Repro Steps: Can we reproduce it? (This is critical).
Environment: What browser, OS, app version, and device are they using?
Initial Triage: I would make an immediate “gut check” assessment of severity (the impact of the bug). Is this a “stop everything” P0 issue (e.g., site down, data loss, payment failure) or a P4 (e.g., a typo)? If it’s a P0, I’m escalating it to the engineering lead immediately and initiating our incident response protocol.
2. Validate & Categorize (Structure)
Not all bug reports are created equal. The next step is to add structure.
Reproduce the Bug: I, or a QA engineer, must validate the report by trying to reproduce it. If we can’t, we go back to the customer for more information.
Categorize the Issue: Once reproduced, I classify it. Is it...
A true bug? (Functionality is broken).
An enhancement request? (The user thinks it’s a bug, but it’s actually a request for a new feature. This is a common and valuable source of ideas).
A user error/documentation gap? (The feature is working as designed, but the UI is confusing or our help docs are unclear).
Assign Severity & Context: Assuming it’s a true bug, I’d formally assign:
Severity (Impact):
P0 (Critical): Blocks core functionality for all/many users (e.g., login, checkout). No workaround.
P1 (High): Blocks a key flow for a segment of users. No workaround.
P2 (Medium): A feature is impaired, but a workaround exists.
P3 (Low): Minor UI glitch, typo, or inconvenience.
Context (Breadth): How many users are affected? Is it one customer, 10% of users, or our single biggest enterprise account? This context is vital for prioritization.
3. Prioritise
This is where the hardest trade-offs happen. A bug doesn’t get fixed just because it’s a bug. It gets fixed based on its priority relative to all other work.
Priority vs. Severity: Severity is the impact of the bug. Priority is the order in which we’ll fix it. Priority = Severity + Context + Business Value. A P3 typo on the homepage might get a higher priority than a P2 bug in an admin-only feature that 3 people use, simply because it impacts brand perception.
The “Bug vs. Feature” Trade-off:
P0/P1s: These almost always break the current sprint. They are “all hands on deck” or “fix next” items. They preempt new feature work.
P2s/P3s: These go into the main backlog.
My Prioritisation Process: I’d bring the validated P2/P3 bugs to our regular backlog grooming and sprint planning meetings, just like a user story. I’d weigh them against new features and tech debt using a simple matrix:
Customer Impact: (Severity + % of users affected)
Business Impact: (Does it affect conversion? Churn risk? Brand?)
Engineering Effort: (Is this a 2-hour fix or a 2-week refactor?)
A high-impact, low-effort bug is a quick win and goes to the top. A low-impact, high-effort bug goes to the bottom of the backlog.
I also advocate for dedicating a fixed capacity (e.g., 15-20%) of each sprint to “quality,” which includes bugs and tech debt. This prevents the “bug backlog” from exploding while we’re focused on new features.
4. Execute & Resolve (Workflow)
Once prioritised, the bug enters the standard development workflow.