When it comes to prioritizing bug fixes vs. new features for your next application update, Product Managers are faced with incredibly difficult choices. Asking them to choose between a vital new feature or repairing an app-crashing bug is like asking them to pick a favorite child (impossible!).
Thankfully, seasoned PMs and product teams relieve themselves from the truly challenging decisions by using one – or more – of the common product prioritization methods below.
Focus on what’s best for the whole project
From a high-level perspective, the process of prioritization in product development is deceivingly simple – find what’s most important and focus on it.
But how do you determine what’s most important? Does the Product Owner/Manager decide?
Do all product team members have a voice in the decision-making process? Does the team assess and then accommodate for customer satisfaction of potential features or bug fixes?
In reality, prioritizing features vs bug fixes has as much to do with your sales cycle and market position as anything else. If your team is building a new product and you haven’t secured stable (paying) customers, you should be working on creating a set of features to drive product adoption and attract new customers.
Once you’ve created a feature set driven by sales input, fixing bugs becomes paramount – you cannot go-to-market with an application that has any characteristics that might prevent a successful product adoption.
The exception, not the rule
Keep in mind that though we push for and are focused (primarily) on securing a stable customer base – it doesn’t mean we don’t fix bugs as they arise.
For example, let’s say you’ve added a new page to a website, you notice a text typo or other small inconsistency. There is no point in waiting to fix the issue. The feature is the new page – including the text on that page.
If the bug is preventing the feature from being called “complete”, it needs to be tended to. Even common sense says fix it now – it’ll only take a few minutes.
On the other hand, if within the software development process you’ve implemented a contact form feature and its core purpose is to allow users to input data and that data to be accurately received – as long as that core criterion is met, the feature is complete. Even if the form produces information in a questionable (wonky) format, that bug can be filed and reviewed at a later date.
Popular prioritization methods
To tame the constant battle – bug fixes vs. new product features – seasoned Product Managers implement a prioritization framework (or several) to simplify the prioritization process.
- Prioritization matrix: A product prioritization matrix is a simple way of mapping out benefit vs effort for both bugs and features.
To prioritize features, product management considers; which of these features will make the biggest improvement? Which will matter most to the customer? What is the effort level? The key is to organize feature tasks by priority and potential improvement. You want to tackle tasks in the low effort high impact quadrant (low hanging fruit) first.
Bug prioritization works in the same way. Development considers; is this a trivial or severe bug? What is the effort level required to resolve the bug? The goal is to capitalize on the low hanging fruit. Any bug that can be resolved quickly but will make a customer happy is worth tackling right away.
In its simplest form; a prioritization matrix looks like this.
- Weighted scoring: Weighted scoring is a complimentary prioritization framework leveraged by project management teams often used to determine feature/bug priority on a scale from 1 to 5 – lowest, low, medium, high, highest – on your product roadmap.
Weighted scoring models are useful for product teams looking for objective prioritization techniques that factor in multiple layers of data.
The purpose of the weighted scoring method is to extract an objective, measurable market benefit for each contending item on the list. Teams then utilize those attributes to assess which elements in the plan will be given priority.
I use this particular method with client projects and find it to be extremely successful. When a new feature is introduced my team can simply assess and determine the weighted value of the feature – highest to lowest priority – and tackle features (or bugs) in that order. I’ve found that this method allows us to include any features that the Product Owner suggests (regardless of priority) and only tackle them when we have the bandwidth available to do so.
One of the highlights of a weighted scoring model is the visual representation available for use with stakeholders. Providing visual aids when making tough decisions can make it much easier to keep the entire team on the same page – and moving in the same direction. - MoSCoW method: A simplified prioritization matrix, the MoSCoW method helps to determine things your product Must have, Should have, Could have, or Won’t ever have.
Developed by Dai Clegg in 1994, the method was created specifically to be used within the Agile project delivery framework Dynamic Systems Development Method (DSDM).
Within the MoSCoW method, if an item is determined to be an:
M:The product must have this attribute or feature, it is non-negotiable as the system cannot be used without this feature.
S: If possible, the product should have this feature. It has high business value, but (if necessary) the product could function without it.
C: The product could have this feature, but it is less critical. Oftentimes a “C” label simply indicates a nice-to-have feature.
W: These features represent the least business value – and will not be included now, but in the future.
Though the Product Owner is the team leader – he makes the final decisions for the whole team – prioritization should always be an entire team effort. When labeling features, the team should work together to discuss the viability of each feature – all team members should be given an opportunity to explain why (or why not) any given feature should be considered M, S, C, or W.
Leveraging the MoSCoW method helps the team build a shared understanding of what is most important to the customer in terms of business value.
If you’re fascinated with the MoSCoW method, you just might be interested in The ToToTo Method – Today, Tomorrow, Tonight – inspired by the MoSCoW method. - Kano model: The Kano model is an approach to feature prioritization that places the highest emphasis on customer satisfaction. Product teams can weigh a high-satisfaction feature against its costs to implement, to determine whether or not adding it to the roadmap is a well-grounded, strategic decision.
Japanese professor Nariaki Kano developed the Kano model in 1984 as a solution to enhance customer satisfaction and manage customer needs within the product development process.
The Kano model is used for inspecting customer needs and defining new product requirements. Customer needs are not created equally, different needs have different priorities and/or meanings attached to them – it is the Product Manager’s job to decipher these needs and pursue them in a way that ensures product adoption in the long run.
Take a look at the Kano model below: the x-axis defines met and unmet needs giving insight into how those needs were fulfilled, from – very poorly (or not at all) to done very well. The y-axis highlights the customer’s response to the need resolved – were they disgusted (i.e. a basic need wasn’t met) or delighted (need was met at above expectations)?
The Kano Model identifies 3 types of needs:
Basic needs – these needs are required for any product, users take them for granted but would be dissatisfied if these needs went unfulfilled.
Performance needs – these needs are noticeable to users, they generate satisfaction when fulfilled (and dissatisfaction when unfulfilled). The more you can integrate these types of needs into the product, the better. Choosing the right amount of performance needs is integral to ensuring an attractive, competitive product.
Attractive needs (delighters) – these needs are meant to delightfully surprise users. They are not expected but when well-executed users are intrigued, satisfied, and more likely to repeat the experience with your product/service (or tout your product to friends).
Using the Kano Model within UX Design? Check out this 45 minute video explanation from prominent UXer Jared Spool – his Twitter account is pretty fun too – follow him @jmspool. - Opportunity scoring (opportunity analysis, gap analysis)
Opportunity scoring is used to discover which product features have the highest importance but hold the least satisfaction among users. This model differs from the previous models as its primary goal is to reveal features with the highest opportunity to increase customer engagement, satisfaction, and retention – and also attract new users.
Opportunity scoring helps teams determine where their product is underperforming. What features are underdeveloped? What features are disappointing users?
Conducting an opportunity analysis begins by inviting customers to rate the importance and their satisfaction with each product feature. A feature that returns a high importance score but low satisfaction score presents the perfect opportunity to create a valuable improvement to your product.
Because I am interested in reducing risk (whenever possible), conducting an opportunity analysis gives me the confidence required to invest time and resources in developing a new product feature (or fixing a bug).
Performing a gap analysis uniquely reveals opportunities for bug fixes as well. For example, 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.
For a 3 minute explanation of Opportunity Scoring, check out this quick video from ProductPlan:
The Kano Model identifies 3 types of needs:
Using the Kano Model within UX Design? Check out this The biggest (avoidable) mistake
Over budget, behind schedule projects typically have one big thing in common – the team failed to plan ahead. Smart teams know that building a balance of feature development and bug fixing into the software development life cycle is vital.
This isn’t as easy as it sounds. Building features is fun. Features make people happy. New features show improvement. Features are what sell.
However, if you don’t stop and pay down technical debt that incurs over time by introducing features, it will build up until it’s a lot harder to solve.
Fixing bugs should be like cleaning your kitchen. You don’t wait until every surface is filthy before you clean it – you clean it every time you use it.
While shortcuts and assumptions help developers iterate quickly, they also cause software to accrue technical debt. Left unaddressed, this debt bogs down systems, crashes software, and causes multi-month delays in product releases.
Falon Fatemi, Technical Debt: The Silent Company Killer
No one is as smart as all of us
Remember, the best prioritization happens when it’s not driven by one person, one idea, or one perspective on the product. No one is as smart as all of us.
A Product Manager/Product Owner should get input from every department; QA (Quality Assurance), sales, engineering, etc. A great PM doesn’t just follow their gut. They conduct user research and leverage the tools available to make the most informed decisions possible for the success of the product.
—
Keep reading:
Six Product Management Thought Leaders Worth Following
Best Practices For Product Research
18 Powerful Competitor Research Tools to Crush Your Competition
See how Singlemind uses technology to solve business problems – learn about our full set of services.
Singlemind is an awarded software design and development agency in Portland, OR. We serve enterprises, innovative startups, and non-profit organizations around the globe. Our diverse, agile team has more than 15 years of success in designing and developing digital products (mobile apps, websites, web apps, etc). Our goal is to help businesses thrive in today’s ever-evolving, omnichannel world of technology.