Jira Customer Feedback Process: Our Feature Request Workflow with CRM Context
At Mria Labs, we often say that we build Mria CRM for Jira the same way we expect our customers to build great products: by making decisions based on customer feedback, business context, and transparency.
This week we released Outlook Integration for Mria CRM, and it reminded me how much our own internal workflow has evolved.
Like many product teams, we receive feature requests from multiple channels every day:
- support tickets
- demo calls
- trial feedback
- partner conversations
- Marketplace reviews.
Thus, for us collecting feedback is easy. The real challenge begins when it's time to answer one question: which feature should we build next?
How We Prioritize Our Product Backlog in Jira
Every sprint planning session, our product team reviews the backlog together. We have a bunch of customer feature requests there.
Of course, every customer request matters. But not every request has the same business impact. When evaluating feature requests, we typically consider questions like:
- Is the request coming from an existing customer or a trial user?
- What revenue is associated with this customer or opportunity?
- Is the feature likely to benefit many customers?
- How complex is implementation?
- Does it align with our product strategy?
The interesting part is that most of this information usually doesn't live inside Jira - customer context usually lives inside a CRM. The typical use case is the following: while revenue lives in CRM, feature requests live in Jira and/or Jira service management. That context is usually fragmented.
Using Mria CRM Data in Jira for Product Development
Since we build Mria CRM, we simply use it ourselves not to have this common problem and be able to manage feature delivery in a comfortable and effective way. Every feature request is created as a Jira issue with a special mark in the title.
Whenever a customer requests that feature, we link the corresponding customer account and lead or deal directly to the Jira issue.
In case the feature request is coming from Jira Service management, we link this ticket to the Jira task.
This gives us immediate visibility on:
- which customers requested it,
- whether they're prospects, trial users, or paying customers,
- deal value and sales stage,
- complete customer context,
- and the list of everyone waiting for the feature.
Thus, our Product Manager doesn't have to search across multiple systems before planning a sprint, as the task consists of all the relevant information to prioritize it accordingly without additional interaction between product, sales and support teams. All context stays inside Atlassian tools. The information needed for prioritization is already available where the work happens.
Managing Customer Communication from Jira After Product Releases
The workflow doesn't end after development. For example, when Outlook Integration was released this week, we already had a complete list of customers who had requested it.
Instead of searching through old emails, Slack conversations, spreadsheets, or support tickets, we simply opened the feature request in Jira.
Every interested customer was already linked. Every lead and deal contains info on the related contacts. And it was very easy to send email directly from the deal with our Gmail or Outlook integration:
Our new Outlook Integration together with Gmail integration closes the last gap in this workflow. Once a feature is released, there's no need to switch between Jira, Outlook/Gmail, and your CRM to notify customers.
Since feature requests are already linked to Leads, Contacts, and Deals, product teams can send personalized emails directly from Jira. Every message becomes part of the customer record, ensuring that communication stays centralized, visible to the entire team, and connected to the work that delivered the feature.
Mria CRM helps product teams keep the entire feedback lifecycle inside Jira. From the moment a customer requests a feature to the moment they receive a personalized notification about its release, every step remains connected:
Customer request β Feature prioritization β Product delivery β Personalized customer communication.
Why Product Teams Should Use Their Own Product
People often use the word dogfooding to describe using your own product, though I donβt like it π For us, it means something very important, such as continuously improving our own internal processes while building software for others.
Many of the capabilities in Mria CRM exist because we encountered exactly the same challenge ourselves.
The new Outlook integration for Mria CRM may be the visible release this week, though the workflow behind delivering it is just as important.
I'm curious how other teams in the Atlassian ecosystem manage customer-driven prioritization.
Do you keep customer context inside Jira, or do your product managers still have to jump between Jira, CRM, spreadsheets, and support tools during every sprint planning session?
Was this helpful?
Thanks!
Anna Odrynska
1 comment