How do you decide on what bug or feature to prioritize in your next product cycle? This is a big question that teams stumble over.
A lot of thought goes into deciding what features to prioritize. These decisions are influenced by customer feedback, market research, or innovating technology.
But the real struggle is how to prioritize your list.
As a support employee when product limitations start driving customers crazy, you will drop those problems on product developers.
But this poses a huge problem for developers especially if product feedback keeps getting dropped on them while they’re in the middle of a cycle. This was happening to us at Kayako.
The pain of not prioritizing features
In the past when Kayako’s support department worked with the product team, we’d get developers to work on a bug. But without a process it was difficult to roll out updates.
When a new request came from product feedback we’d drop the feature request on developers. They’d start working on it, then we’d drop another request on them. If a more pressing feature came along, they’d have to drop their current projects again only to start afresh on the latest pressing features.
There was no prioritization when working on product development.
This prompted us to decide on cycles or time slots. We gave one month to complete bug fixing where no one would drop extra workload on the developers. And this what we learned:
- There should always be standard prioritization metrics for everyone in the company to stick to.
- If you are low on resources, plan. Divide the team and or their time, between fixing bugs and feature roll outs.
- When logging bugs and features, ensure you probe enough to determine if there is any other way to achieve this in the meantime. This enables you to ship something important first.
Using this method, the last minute hassle of prioritizing features or fixes can be avoided. But it requires all internal stakeholders to be on the same page. The real challenge is getting to that agreement.
What should drive feature prioritization?
The most important question every business has to answer before making the decision is the impact on monthly recurring revenue (MRR).
What is the ROI on the effort they are putting in for something where they could have invested somewhere else? That’s the principle of great product management.
In any business involved in bug fixing or feature rollouts, there are three general stakeholders – developers, support team (could be a Customer Success Manager, Account Manager, or Customer Advocate etc) and the customer.
The chain looks something like this:
Customer complains to the support team who pass it onto the developers.
However, customer complaints are not always equal and need to be funneled in a systematic way to determine their value.
The support team should have a clear picture of how issues are going to be taken up. They act as an intermediary liaising with both parties – the customer and the developers.
They need to make a list of the impact that each customer request has on the workflow. If you give each request a number on a scale of 1-10, this will help you answer and frame your case to vouch for your customer’s request. This will also help you combat any cognitive bias when prioritizing bugs.
Here are the kind of metrics you can look to use. Go through this feature prioritization matrix and assign a number to the feature or bug you’re investigating:
- Paying customer? (No=1, Yes =2)
- Impact to customer (1= low, 2= significant no impact to their customers, 3= impacts them and their customers)
- Number of customers affected (1= low, 2= several, 3= most)
- Priority = [impact*number of paying customers*paying customer]
We also add on our own internal rating which we call, support priority (1 – 10). This isn’t added into the equation, but as we use our own tool to support our customers, we’re essentially asking if we agree with their feedback—is this an issue for our support team as well? The higher the number, the more we agree.
Using this criteria helps you filter out feature requests. And then you can move onto identifying the bigger impact to help with feature prioritization:
- Why should we be prioritizing a bug?
- Is it a paid customer or a trial customer?
- How much MRR is at stake?
Should intuition power product feature decisions?
There’s one question that is difficult to answer: How do you argue for a feature or fix that is tricky to map back to MRR, even if your intuition is telling you it will be valuable for customers?
This is an extreme example which only happens in exceptional cases. But it’s one worth noting how to handle.
- If you can help the customer find a workaround using a third party software like Zapier, then prioritize doing that.
- If there’s no workaround, make a business case for the fix.
As the support agent you can easily dip into your metrics to check on the customer churn. You are the one in touch with the customer and who sees the tone changing over three weeks of waiting for the bug fix or feature request. You understand that the customer is losing productivity and workflow because of this bug. At this point MRR goes out of the window.
This is the time to use your veto power as a support agent. But remember your responsibilities in using your power in the right situation.
Sometimes there can be a workaround for the bug reported by someone who has higher MRR and there might be none for the one with comparatively lower MRR. But at this point leading simply based on MRR can be misleading. This is especially so if you are in SaaS business where customers have easy option to switch.
Other factors to influence product development:
Bugs vs Features:
You need to start by separating a bug from a feature. Ask yourself:
- “Do I want the existing features/product to be stable before we roll out the new one?”
- “Will the effort I am putting into a new feature reduce the pain points raised by the existing bugs?”
And don’t forget that rolling out new features (generally) adds to the backlog of bugs that need to be fixed.
Resources:
If you have to juggle between the same resources ensure you understand their working patterns. Or even better, decide on dedicating specific times, say one week to bug fixes and the next on feature roll outs.
This will help you keep balance.
However, if a request for a bigger MRR comes in and has to be forced on people, this may not work well.
Market:
They say nothing is unique, it’s all about who delivers it first. I am not saying you have to compete in every area but you have to be careful about delivering quickly for your customers.
MRR:
No doubt is always going to be the biggest driving factor, and yet I am wary of making this the only factor. It can definitely be taken in combination with the other factors we shared above.
3 things not to influence prioritizing bugs or features
Gut feeling alone
I admit Kayako has been a victim of this which is why we came up with the prioritization matrix. This ensures no one can jump in and say a particular issue needs to be prioritized.
It came directly from a senior manager
Understandably this can’t be avoided in every situation and there might be companies out there which don’t allow such a culture to sideline their requests….but try avoiding it as much as possible. The metric we talked about can help you make them understand where it falls and where to prioritize.
Because Sales and Support is requesting it
Usually requests that come from sales and support are based on a couple of interactions with customers.
There is no way requests should be prioritized based on a limited number of customer interactions.
What you can do is make support/sales log such feature requests in a Google form or a specially created document and once you see enough requests coming in, prioritize them in cycles.
What feature will you prioritize?
Next time, think twice about how and why you prioritize a feature. You should have a system in place to help you make product decisions. As we learned at Kayako, without a system you work within a scattered team jumping from one thing to the next and never really getting the important things done.
And keep in mind, it should neither be based entirely on MRR nor on other factors alone. It has to be a combination of both.
Create your own feature prioritization matrix to help you make decisions, and be willing to make exceptions where needed. Treat these decisions like any other decision in life. Sometimes you are willing to make an exception for all the good reasons because your gut tells you so.