Should You Track Feature Requests in Jira (or Any Other Issue Tracker)?
“Jira is where feature requests go to die.”
I’ve heard this, or variations of this, literally dozens of times when talking to Product and Customer Success teams. (I’ve even said it myself… woops 😬.)
That doesn’t mean you shouldn’t use Jira—or another Dev tool—to track customer feedback and feature requests. You can create a feature request tracking system that works using Jira. There are even some good reasons why it might be the tool of choice.
But it’s worth considering the limitations of Jira so that you can understand where your system is most likely to break down.
In this article, we cover the pros and cons of using a Dev tool like Jira to track feature requests. We’ll cover:
Why use JIRA to track feature requests?
Jira isn’t a feature request tracking tool… so why would you use it as one? There are a few reasons.
You want to keep requests in the same tool that your development team uses to build the features. Your Dev team is going to use Jira (or another dev tool) to organize the process of building features. So it might make sense to keep requests there too. There’s a kind of logistic ease in using the same tool for both planning and building processes.
One tool is simpler than two. Adding tools to your stack adds some complexity. Using your dev tool for feature requests means that you don’t have to find or learn a new one. It means minimal changes to process and your product management and development teams already have access. It also could be a bit cheaper to minimize tools.
What you need in a feature request and bug tracking system
Whatever tool you use, you want to make sure your feature request tracking system is able to do the following:
Collect product feedback from all their channels with little to no pain
Categorize and organize feedback to understand what customers are asking for
Prioritize and sort by basics like number of feedback customer attributes
Close the loop with customers
Let’s see how a tracking system using Jira fares against this list. We’ll compare and contrast with Savio to provide some sense of where Jira works best and where it falls a bit flat.
1. Collect product feedback from all channels
Collecting feedback in Jira is a manual process. Someone—perhaps a product manager or someone on the Customer Success team—would copy product ideas from your support tool, CRM, email, or wherever it comes in. They would then find the relevant issue in Jira and paste the feedback into it.
First, you have to manually copy the feedback.
It’s a lengthy process. They have to:
Copy the feedback
Open or switch to JIRA
Login, if necessary
Use search to find the issue (this is painful in our experience)
Add a comment with the feedback and other information
Go back to the support tool
Copy the URL of the support ticket
Go back to JIRA
Save in JIRA
Then, you have to paste the feedback and add any other relevant information manually.
The person would have to ensure that they recorded the customer’s contact information and email address. They could also include the link back to the support tool, if necessary. To upgrade and automate the process slightly, you could use Zapier… but even still, the process would be clunky.
Collecting feedback in Savio is much easier. Savio has a bunch of integrations so you can simply forward emails to Savio, tag feedback in your support tool, or quickly capture feedback using the Chrome Extension. These automate the process, reduce task switching, and ensure you capture all the important information you need.
2. Categorize and organize to understand what customers are asking for
In Jira, your feature request would be “issues” kept in a feature request project. When your team is adding customer feedback to Jira, they would have to find the appropriate issue and add the feedback as a comment. Keeping them in a separate project helps ensure your backlog isn’t swamped and they’re accessible.
This process relies on your team member knowing which feature request the feedback is relevant to. When this kind of categorization is left to Sales, customer support, or customer success, there could be mistakes. (That’s not a dig at Sales or CS—it’s just not their job to know the product and list of existing feature requests as well as, for example, the product team).
The other thing is that the feedback is added as just a text string. That makes it hard to roll-up requests together or to group by customer.
In Savio, CS, Sales, and other customer-facing teams usually send feedback to an inbox, leaving the categorization to someone who knows the feature request list well. This helps ensure that feedback is categorized properly and reduces duplicate requests. Categorization is still manual in Savio, but it’s designed to be quick and accurate.
Also, feedback isn’t a text string—it’s an object with attributes. You know who gave what feedback, the company they belong to, their MRR, plan, and more. That means you can easily sort and filter customer feature requests based on attributes that are important to you.
3. Prioritize and sort requests to know what to build next
In Jira, prioritization is hard because you can’t see important metrics of a feature request, like how many people have requested it. To find that out, you would need a manual process: you would have to go into each feature request and count the number of pieces of feedback that are in it.
It’s also very difficult to prioritize by metrics that are important but more advanced. For example, you might want to prioritize the feature requests that have the greatest cumulative MRR. To do that in Jira, you would have to look at each FR, make a list of each company that requested it, and then switch tools to manually find the MRR of each of those companies. And then you’d have to add that all up.
In Savio, it’s much easier to prioritize based on attributes that matter to you. You can easily see the feedback count right beside a feature request, so you know exactly how many customers have requested each feature. You can also quickly see the MRR tied to each feature.
Besides those basics, you can quickly filter feature requests to find the feedback that might matter most to you: feedback given in the last month, feedback from people on active trials, feedback from customers on the enterprise plan, and more. Slicing and dicing your feedback based on attributes makes it much easier to figure out what to put on your product roadmap to reduce churn, expand revenue, or whatever your biggest priority is.
4. Track the status of feature requests
Jira is great for coordinating your Devs’ work. It allows you to easily move feature requests to the proper Jira project and the Dev workflow. Anyone with access to Jira would be able to see the status of that feature request and follow it through the dev process.
The one hiccup here is that your customer-facing teams may not be able to see the status of a feature if they don’t have a Jira login. So you might still need manual communication to keep other teams up-to-date on statuses (or, you could provide a Jira login for your non-product and non-dev stakeholders).
Savio can connect to Jira, too. Savio has a Jira integration that’s simple to set up. It lets you create Jira issues and connect them with feature requests in Savio. When your Devs update an issue in Jira, the status updates automatically in Savio. That means you can easily create feature requests as issues into your Devs workflow, and then all stakeholders can keep up to date of the status of that feature right from Savio. The result is less manual communication between your Devs and your customer-facing teams.
5. Close the loop with customers
Closing the loop happens when you tell the customers that you build a feature they asked for. It’s a very simple and very powerful way to develop loyalty with your customers.
In Jira, it’s not easy to close the loop automatically. You would have to go through the feedback in the feature request issue, copy and paste email addresses, and then follow up individually. You could easily BCC everyone in an impersonal message. Or, you could take some more time to manually set up a spreadsheet to do a mail merge to personalize the message… but that would take some elbow grease.
(Also, note that with Jira, you are relying on your team to note email addresses and contact information. It’s possible that not everyone would be as careful about that as you’d like.)
In Savio, it’s easy to close the loop. Just choose who to close the loop with and then send. Personalization is built right in, so your customers feel like you’re talking directly to them. The most time-consuming part of the process is drafting the email (but we’ve included a template for you to make that go faster).
Note: Savio helps B2B SaaS Customer Success, Product, and Sales teams organize and prioritize product feedback and feature requests. Learn more about Savio here.
Summary: The pros and cons of Jira for tracking feature requests
So should you use Jira to track your feature requests? It depends.
The pros are that:
It’s logistically simple. You add requests to the same tool your Devs will use later to build them.
You simplify your software stack. You only need to learn one tool and use one log-in. And you save some money by forgoing an extra tool.
The cons are that:
Collecting feedback is manual. Your customer-facing teams need to leave their tool to add feedback. There is a chance they’ll forget important details or contact information.
It’s not designed for easy categorization. Customer-facing teams would have to find the right FR to add feedback to, and this could introduce errors.
Prioritizing is painful. You can’t see the number of requests, and you’d have to do a lot of manual work to prioritize based on total MRR, plan, customer segment, etc.
It requires more communication. It’s not easy for anyone who doesn’t use Jira to see the status of feature requests. This method requires more communication.
Closing the loop isn’t built-in. You either have to send messages manually or build a mail merge spreadsheet.
Considering all that, Jira would be fine for tracking feature requests when companies are small or when they don’t receive many feature requests. If you’re not receiving a lot of feedback, the cons of using Jira—all the manual processes—may not be too much of a burden.
But as soon as you have a healthy flow of feedback and feature requests, the manual processes required to make Jira work would likely become so onerous that it would be worth switching to a feature request tracking tool like Savio.
How to best use Jira to track feature requests
If you’re going to use Jira software, try to create your process to make up for the drawbacks. Here’s what that could look like:
Create processes to collect feedback from all your sources. Create a project in Jira just for feature requests. Remind your customer-facing teams to include all relevant information like email addresses and links to support conversations.
Categorize feedback well. Ensure your customer-facing teams add feedback directly to the appropriate issue. Provide them with training to make sure they categorize feedback into the right feature requests to minimize errors or duplicates.
Prioritize feature requests thoughtfully. You can’t easily see feedback counts in Jira, so make sure you’re taking the time to create a spreadsheet (or other solution) so you can prioritize the feature requests that your customers actually want.
Help stakeholders follow feature request statuses. Ensure your Devs communicate with other teams to know the status of requests, especially when a feature is shipped.
Close the loop. Make sure someone is responsible for closing the loop with customers, and that they’re taking the time to personalize close-the-loop emails if possible.
Whatever you do, track your feature requests
If you want to build software that your customers want, you need to keep track of the features they’re asking for.
Jira could support that system, but it’s not ideal. No offense to Atlassian, it’s just not built for tracking feature requests, so it doesn’t have the right functionality. There are some important drawbacks to using it in that way.
But, you still might want to use it because it’s convenient and your team already knows how to use it. Maybe you’re still small or maybe you’re using it as a stopgap measure while you develop a better system.
It’s better than nothing! And probably even better than using a spreadsheet or Trello.
But if you’re looking for a fool-proof system that works even with lots of feedback, Jira’s probably not your best bet. Our golden rule is to keep Jira focused squarely on the actual software development process:
“Only put things in the issue tracker that the dev team will actually work on.”
For feature requests and bug reports, we would keep them in a separate feedback tool like Savio. That way, you can collect, organize, prioritize, and close the loop on feature requests in a way that’s easy and that allows you to make the best product decisions. And you get additional functionality—like voting boards for feature upvotes, feedback forms, and more.
Want to give Savio a go? Get started with a free trial.
Kareem is a co-founder at Savio. He's been prioritizing customer feedback professionally since 2001. He likes tea and tea snacks, and dislikes refraining from eating lots of tea snacks.
Prioritize high-value Feature Requests
Centralize customer feedback from HubSpot, Intercom, and Slack.
Prioritize high-value features sorted by churned revenue or MRR.
Close the loop for Sales and CS by automating status updates from JIRA.