Using Jira to consolidate, capture, and contextualize feedback

[Dan Duett]

I'd like to use Jira to improve how my team captures and contextualizes requested features and improvements.

Here's our current approach:

• Direct customer feedback is contained within its own Jira project and issue type.

• Indirect customer feedback and internal ideas are scattered across Desk.com, Gainsight, Jira backlog, Slack, and email. This is insanely ineffective.

Here's what I'd like to see:

• All indirect customer feedback and internal ideas are in Jira.

• Each underlying idea/request has its own Jira issue.

• We track which customers have requested what: if we build a requested feature, we know exactly whom to notify. If we can't associate multiple customers with an underlying issue, we create a special issue type unique to each customer request and associate each customer-specific request with the underlying issue.

Any ideas on better approaches within Jira?

[Henry Thomas]

Hello, Den!

I understand your goals and I like your approach! 

Therefore, I can advise you very useful addon for jira. I'm talking about Customer Case. Have you heard about it? With this addon you can create feedback/support forums based on your JIRA Cloud and then store users' ideas as JIRA tickets. 

You should try it for your purposes. 

Regards,
Henry. 

[Matthew_Horan]

@Dan Duett I'd consider using JIRA Service Desk alongside your JIRA Software projects.

You could create a custom issue type of "Feedback" where clients directly contribute their product feedback via the client facing service desk portal. As long as you include fields that capture the product they're providing feedback for and who the client is you'll be able to slice the info however you'd like. 

Then at some regular interval when you plan future work you can go through the service desk tickets and pick out all the feedback (both direct from "Feedback" issues and indirect from common themes found in support tickets) and create stories in the relevant product boards. Those stories should be linked back to the issues in the support desk so you can alert the appropriate people when things get fixed. 

[Dan Duett]

Thanks, Matthew! Your suggestion for direct feedback is spot-on—we have that and it works well. Service Desk is probably our best long-term play, but implementing that is way outside the scope of my current mandate. We're a high-touch B2B software company: our customer teams get a lot of feedback that needs to make its way to the product team. Product operates out of JIRA so this seems like the best place (at least until we adopt Service Desk).

[Nic Brough -Adaptavist-]

This is probably more of a procedural and training question than a JIRA one.   JIRA can support everything you've defined there off-the-shelf, and easily, so the short answer is "get the users to do it in JIRA instead of <whatever>"

I'd start with a look at why they're using other routes.  Make them read-only with a goal of shutting them down in the long run, so that users have to use JIRA.  Get your teams into the habit of doing nothing unless there's a request or update in JIRA.  Where you can't shut down a route for new stuff to arrive, integrate the data flow into JIRA, so that update in system X is reflected in JIRA (and vice versa)

[Dan Duett]

Thanks, Nic. I recognize that doing this is possible in JIRA; I'm looking for suggestions on workflow and info architecture specific to the platform.

One approach would be to have every underlying product idea as an issue—of specific or varying issue type (story, epic, task; this makes more sense to me). Some requests would already be in the backlog; some would be new. Users would search for an existing product idea in the same way they might search for an existing bug.

I also need to search by customer, seeing all the requests a specific customer has made and ideally noting which are critical, which are trivial, and so on. This would likely require a custom issue type, where each customer request would have a corresponding JIRA issue specific to that customer. These would then be linked to the underlying product idea.

I would've started by outlining this potential solution, but I try to be mindful of the XY problem, so I started with the general goals. The approach I'm proposing also seems very involved; I don't want to over-engineer the process if there's a better way.

Your thoughts?

[sarin7]

Hi @Dan Duett - I would love to know what approach did you finally take to solve this? I am stuck in somewhat similar situation

[Dan Duett]

Though it pains me to say it, we still don't have a unified view of "which customers want what." Organizationally, we've shifted from "put everything in Jira" to "Jira is for engineers." So we've consolidated where feedback/ideas live but there's still no one place. :-/

[Jerry Garcia Stackpoole]

Too bad. @sarin7 Did you find a solution?

We are using intercom, slack and jira and collecting feedback from App Stores too...and would like to have an integrated process for managing it all.

[Patrick Haley]

@Jerry Garcia Stackpoole I'm in the same boat you are... Intercome, Slack, Jira, random emails, and carrier pigeons, etc. Did you ever find a solution to collect and organize feedback from multiple channels?

[Rachel Eaton]

@Patrick Haley We're looking into UserVoice for idea management but are also looking to solve this seemingly unsolved problem.

[Patrick Haley]

@Rachel Eaton I tested a few things and decided to keep this in Jira. I created a JSM project just for collecting feedback on software improvements. We have an approval process to flush out good ideas and decline bad ones. All of these are tracked as change requests and we require users to add a component to organize them. Then we use labels to further subcategorize and ultimately clone issues to a linked Jira Board. We have either integrated or use the JSM project email channel email to feed requests from various sources into the project.