Ditch the debate on bug vs enhancement: 4 tips for easier decision-making
If you’re a PM, Designer, or Engineer, you’ve wrestled with the classic debate: “Bug or enhancement?” But the real decision is about prioritizing what truly matters — should we act now, later, or never?
Here are 4 tips that help you balance product quality with growth, so you can stop debating that question, and just focus on delivering kick ass products.
1. Nail the problem definition.
Everyone talks about defining the problem first, but sometimes it’s not really NAILED. It must be clear, narrow, and devoid of possible solutions. If not, you’re set up for failure. When it comes time to decide whether or not an issue need to be corrected, the problem statement is your first line of defense. (Need help with how to make them? Here you go.)
You love your users. You already decided which problem to solve for them. When you spend time on anything else, you fail them.
Even when they are the ones that asked you for it.
Which leads us to how to assess feedback.
2. Assess feedback by experience, not by ticket.
A common mistake I see is to assess one ticket at a time (and worse, have the bug v enhancement debate on each ticket). Waste. Of. Time.
This is where you need to understand a user’s journey. Logging tickets by product area is useful for logging and assigning work, but it’s not useful for prioritization.
Consider how a user moves through your product. It’s unlikely they use one technical area completely without another. Users leverage multiple parts of a system to complete objectives.
Collaborate as a team to decide how to break down the user’s journey into chunks small enough to talk about.
An example might be “finding a product” in an e-commerce site — that might include the homepage, search bar, search results, a cataloging system, ranking system, recommendations, browse structure, and product detail page.
When you assess feedback from customer reported issues, usability test results, KPIs like search abandonment, and internally-reported issues, look at them in terms of the experience of “finding a product” rather than each technical system or each page in the UI.
If the goal is finding the right product and users are not achieving that, then it doesn’t matter if the system is acting exactly as designed, it still needs to change.
When you look at the experience, what’s in the way of achieving the goal for the targeted user? It might be one big thing, or it might be lots of tiny things along the way.
3. Answer “never” to some things.
When you assess the experiences, don’t be afraid to decide that you will never address some of the requests.
Ignore issues that aren’t a part of the defined problem, no matter the cost to fix.
Yep, I said ignore. Do not fix. Think of it as saying “yes” to focused problem solving.
Be honest with yourself (and ultimately with your customers) if you are really going to address the issue, or take the idea into consideration at all. Here are some additional filters to use:
- Don’t improve experiences that are already on the roadmap to die — just close the ticket.
- Don’t improve experiences that are already slated to be re-envisioned — just close the ticket.
- Don’t add features that expand the problem statement to include more types of users — just close the ticket.
Glean any user intent information from customer-reported issues to take into account if you intend to redesign or expand later, but that’s research, not ticket management. Spend no time on them.
4. Plan for change.
Another one that people talk about but fail to follow-through on. The beauty of software is that it’s changeable. And the beauty of prototypes is that they are cheap to change.
Expect to be surprised by something. Put change in your work plan.
Change doesn’t occur at the end of the sprint if/when you have time. You’ll learn something early in experience design, in technical design, in usability testing, in alpha, in beta and beyond. It’s OK!
Iteration is good, but it can also slow you down. The more you plan up front for learnings to impact output, the less change you will see later. Be realistic and cap the change time you put in your plan — force the team to learn up front. But plan for it.
In summary
Debating if something is a bug v enhancement is not worth your time. Nail the problem statement, assess issues holistically by experience, say “never” to issues you should, and plan for change.
Doing these 4 things set you and your team up for knowing exactly what to take action on now, later, or never, so you can focus on the right stuff!
✨Have more tips on how to stop wasting time in that debate? Leave a comment!
