Bug fixes vs product features: what to prioritize

When it comes to determining whether we should devote our resources to addressing existing flaws or blaze ahead with exhilarating new features, it’s not easy to make the right decision.

Undoubtedly, both endeavors hold their own significance.

However, development teams often don’t have enough time to dedicate equal attention to both areas simultaneously.

Therefore, in this article, we’ll answer the timeless question of which aspect should be given priority–fixing bugs or developing new features.

Additionally, we’ll present five important methods that can assist you in this process.

Let’s start!

Bugs vs. product features: key differences

When it comes to bugs and product features, there are a few important differences worth mentioning.

For starters, bugs emerge unintentionally, usually due to coding oversights, logic errors, or unexpected system interactions.

Product features, on the other hand, aren’t only intentional, but a whole army of people, including developers, designers, and project managers, join forces to create and launch them onto the market.

In other words, they are carefully designed, and crafted with the intention of improving the user experience and making sure that the app stands out among its competitors.

The difference between them can also be observed in the impact they leave.

While bugs can have far-reaching consequences such as crashes, data loss, or compromised security, product features usually wield a positive effect as they enhance the usability and efficiency of the app and have the potential to delight users.

However, the line of demarcation between the two isn’t always a clear-cut task.

In software development, there is an oft-repeated joke: “It’s not a bug, it’s a feature.”

This phrase, coined by developers, serves to convince clients and higher-level stakeholders that what may appear as a flaw is, in fact, an intentional design choice.

Playful as it may be, there’s a grain of truth in this joke, as some bugs have indeed been transformed into features.

If you’re curious to explore this concept further, check out the elaborate Reddit thread that reveals bugs-turned-features within the area of video games.

All differences aside, you can view bug fixing and product feature implementation as two sides of the same coin.

Although inherently different, together they contribute to creating an app that captivates users, fosters loyalty, and functions flawlessly.

Bug fixes vs. product features: how to prioritize

On the surface, determining the order in which to fix bugs or implement product features may not seem like something too challenging.

It’s all about identifying the top-priority task and directing all efforts toward its resolution.

But is it really that simple?

After all, who should determine what the priority focus should be? Is it the product managers? Developers? Tech leads?

Since there is no definitive answer to this question, it’s best to turn to existing prioritization frameworks that have already been tried and tested, proving they can facilitate the art of prioritization.

Here are the five most popular frameworks.

Prioritization matrix

When it comes to the battle between bugs and features, the prioritization matrix is one of the most widely recognized and valuable methods for prioritizing tasks.

At its core, it revolves around a simple concept: determining the order in which bugs or features should be addressed based on their relative effort and impact.

In this method, you start by defining the benefits and downsides of individual bugs and features when it comes to the effort it takes to fix or implement them, and their overall impact on the app or user experience.

When it comes to prioritizing features, several pertinent questions arise, such as:

• How many users want the feature?
• How much does it benefit the business?
• How much effort is required to implement it?

Similarly, when prioritizing bugs, it’s essential to address the following questions:

• What is the complexity of fixing each bug?
• How severe are the consequences of the bug?
• How does it affect the users?

By considering these factors, you can assess the urgency and impact of each bug or feature more accurately.

Then you collect the results and place individual bugs and features in four quadrants, as depicted in the image below.

After that, the goal is to first execute tasks in the upper left quadrant, which denotes the tasks that yield substantial results with minimal effort.

Once these tasks are resolved, you can move on to those that demand careful planning and execution, minor tasks can be addressed thereafter, and tasks that can be safely postponed can be placed at the bottom of the priority list.

Of course, in practice, the process isn’t always straightforward because it can be difficult to categorize tasks into quadrants when more complex tasks are involved.

However, the prioritization matrix remains one of the fastest and most effective methods available.

Weighted scoring

Weighted scoring requires a bit more math than the prioritization matrix, but it provides a more structured approach to determining the priority.

The first step in this method is to define the criteria by which you’ll prioritize bugs and features.

These criteria can be the same as the ones we explored in the previous section when discussing the prioritization matrix—severity, user impact, effort, user demand, business impact, and development effort—or you can use your own.

In the next step, you’ll assign weights to each criterion based on its importance.

For example, you might assign a weight of 5 to severity, 3 to user impact, and 2 to effort when prioritizing bug fixes.

Next, you calculate the total score for each bug and product feature by multiplying the score of each bug or feature by its criterion’s weight and summing them up.

Similarly, when prioritizing product features, you might assign, for instance, a weight of 4 to user demand, 5 to business impact, and 3 to the development effort.

In this case, the table for product features might look like the image below.

The general rule is that the higher the total score, the higher the priority for addressing that bug fix or implementing that product feature.

The strength of the weighted scoring method lies in its ability to provide a structured approach to prioritization.

By assigning weights and calculating total scores, you can make decisions based on predefined criteria. This ensures that important factors are considered.

MoSCoW method

Among the other prioritization methods, the MoSCoW method stands out as a strong contender, offering a simplified yet effective approach.

Derived from its acronym, MoSCoW represents Must-have, Should-have, Could-have, and Won’t-have features.

This method categorizes items into four priority levels: highest (M), medium (S), light (C), and future (W), as shown below.

This way, it aids in prioritizing product features, ensuring that you address the most crucial ones first while leaving room to postpone others.

Similarly, it can help you make decisions on which bugs need immediate attention and which can be deferred.

Let’s explore each category to gain a better understanding of this method:

• Must have: This category encompasses critical features that the app needs to have in order to meet user needs, and includes bugs that urgently require resolution to ensure the stability of the app.

• Should have: Features falling into this category add value to the app, while bugs categorized here should be fixed as soon as possible. Although they aren’t as critical as the must-haves, they contribute to the overall stability and user experience of the app.

• Could have: This category includes features or bugs that aren’t essential for the app’s functionality. While they are desirable and may enhance the user experience, they fall into the area of nice-to-haves rather than necessities.

• Won’t have: This category comprises features or bugs that currently hold the lowest priority. They won’t be addressed at the moment, but they might be considered in the future.

As a simple and efficient technique, the MoSCoW method can be employed on a day-to-day basis.

It offers a practical framework for making decisions swiftly, especially in situations where quick solutions are required.

Kano model

Among the various frameworks available for prioritizing bugs and features, the Kano model stands out as a popular choice that places customer satisfaction at the forefront.

This versatile method enables you to determine whether bug fixing or product features should take precedence based on their likelihood to delight customers.

For instance, if the application crashes every time it’s launched, it’s obvious that fixing that bug in the code will take priority over all other tasks or features because it’s such a major issue that users may even uninstall the application because of it.

So, the underlying principle of this method is simple: prioritize bugs or features that have the greatest impact on customer satisfaction.

But let’s take a closer look at the Kano model matrix to see exactly how this method works.

As you can see in the image, the main difference between this method and the others on this list is that it uses a need versus satisfaction matrix.

The x-axis represents fulfilled and unfulfilled needs, while the y-axis denotes how users react to the fulfillment of those needs, ranging from satisfaction to dissatisfaction.

Three lines intersect over the x and y-axis, representing three distinct categories of needs and emotional responses.

• Basic needs: These are the requirements that users expect as a minimum, the fundamental needs that every app should have.

• Performance needs: Users distinctly notice the fulfillment or absence of these needs. When present, they contribute to user satisfaction. Conversely, their absence leads to considerable dissatisfaction.

• Attractive needs: These features and bug fixes provide an extra layer of satisfaction to users. While their inclusion isn’t expected, they can pleasantly surprise users and enhance their experience.

You can focus on tackling basic and performance needs first because they can have the most significant impact on user satisfaction.

Then, consider meeting the attractive needs when you want to impress your users.

The Kano model matrix proves invaluable as it offers insights into how different features or bug fixes impact user satisfaction.

Opportunity scoring

Opportunity scoring, also known as opportunity analysis or opportunity gap, is used to prioritize features by measuring the relationship between satisfaction and importance.

The idea is to find key features in the app that hold significance for users, and then evaluate their satisfaction levels with these features.

The goal of all this is to pinpoint the features that users find crucial but that are falling short in terms of satisfaction.

Why prioritize these features, you may ask?

The answer lies in their potential to drive user engagement and retention, and ultimately, attract new users.

In other words, you are basically trying to find out which important features are underperforming or are underdeveloped, and you rely on collecting user feedback to gather this information.

However, this method is not limited to prioritizing product features alone, it also applies to bug fixes.

Richie Harris, a CTO at SingleMind and a proponent of this method, explains it as follows:

Let’s say that as I am developing an application I notice that once clicked, a button doesn’t change color like it’s supposed to. To me, it’s not a big deal. However, if it happens to bother the user immensely, it presents a valuable opportunity – make the easy bug fix and satisfy the user.

The key takeaway is that user satisfaction can be utilized as an important criterion for prioritizing tasks.

By harnessing user feedback and insights, you can uncover important features or bugs that may not be meeting user expectations, opening up a world of opportunities for improvement.

Bug fixes or product features: what to prioritize

One of the eternal debates in software development centers around the question: in the clash between bugs and features, which one should be prioritized?

This conundrum has led to many raised eyebrows and head scratches.

For example, Joel Spolsky, the creator of Trello and co-creator of Stack Overflow, back in the year 2000, composed the Joel Test, where, among other things, discussed whether bugs should be fixed before writing new code.

To prove that bugs should always be prioritized, he shared the story of how Microsoft developers created the first version of Word for Windows.

The problem was that the developers were so tied to the schedule that they wrote bad code and neglected to fix bugs.

This turned out to be a grueling process that left the entire team exhausted.

After this incident, Microsoft adopted the “zero defects methodology,” which boils down to eliminating bugs before writing new code, a stance Joel Spolsky agrees with:

In general, the longer you wait before fixing a bug, the costlier (in time and money) it is to fix.

This viewpoint is countered by Ernest Mueller, another veteran in software development, in his article, Is It a Bug Or A Feature? Who Cares.

He states that the main difference between a bug and a feature is actually the difference between the application you have and the one you want, further emphasizing:

Work items should be prioritized based on their value. There’s bugs that are important to fix first and bugs it’s important to fix never. There’s features it’s important to have soon and features it’s important to have never.

Therefore, prioritization is a balancing act between bug fixes and product features, and which side the scale tips depends on the value it brings to the user.

For example, addressing bugs that hinder core functionality should be given paramount importance because they can negatively impact the user experience.

The same goes for bugs that compromise security, stability or lead to data loss.

Similarly, the stage of app development also proves to be essential.

In the nascent stages, when it’s pivotal to have stable and high-functioning apps, addressing critical bugs should be the primary focus.

As the product evolves, adding new product features can be crucial because otherwise, the application won’t be competitive in the market.

Therefore, it’s not about prioritizing one side over the other in this bug-fix-product-feature correlation, but rather prioritizing the option that provides the best user value when implemented or fixed.

Conclusion

As you can see, by effectively prioritizing tasks, development teams can avoid favoring one option over another.

They have the ability to tackle bug fixing and product feature implementation simultaneously, without sacrificing either aspect.

That is why we have outlined five different methods for prioritization.

These approaches are designed to help you determine which aspect, be it bugs or features, provides the most value to users and should be given priority.

We trust that they have provided you with valuable insights and will assist you in your own prioritization efforts.