Struggling to figure out how to get more feature requests, evaluate and build them, and let your customers know that they’ve been released?
This is the story of how Christina, a product manager, set up a feature request workflow with a simple button in her product, so she could learn directly from the customers what to build next. That button sent new feature requests to the moon and is responsible for a huge part of the company’s monthly recurring revenue (MRR) growth.
How about if I told you this was also the first time this product manager’s company created this particular process for feature requests? Since then, 54% of everything built from the roadmap was facilitated by that bashful little button.
Christina’s a PM at Usersnap (that’s us). We built a feature request option in our product in order to receive more of them quicker from customers.
By the end of this article, you’ll be able to:
- Setup a feature request workflow for your product
- Take action on the feature requests, and build your roadmap
- See the tangible impact this workflow could have on your company.
Ready to rock?
BTW: if you need a little more context, we’ve got the ultimate guide to customer feedback, on tap just for you 🍻 cheers to that!
- Aligning feature requests with product goals
- How do I set up a workflow for feature requests?
- And how do I take action with my feature requests in mind?
- Overall, how valuable are feature requests to a business?
- What did we learn from our feature request button?
- So, how can I set up my own button for feature requests?
Aligning feature requests with product goals
At Usersnap, we’re all about collecting customer feedback. However, we came to a point in our own evolution where we weren’t quite sure where to turn next. Things were going well, with a great foothold in the quality assurance and software testing niche. However, we also saw the opportunity to go to market for other personas and their needs. We had some hypotheses, a lot of energy and talent across teams, and our fair share of experience in design and product management.
We approached our roadmap and feature building in more or less the following way:
In other words, after failing too slow and sometimes banging our heads on the wall one too many times, we wanted to get back to what we knew how to do best: build a future product roadmap based on validated customer needs. This included getting a deep understanding of our personas, and crafting a long-term product vision that would help our customers get to their desired outcomes. But how do you create a product roadmap that puts customers at the heart of it? Apart from quantitative data collection, Christina started asking them an important question at an equally important touchpoint during their experience: which feature suggestions do you have, and what would they solve for you?
She kicked it into overdrive, off to the races to do product manager work, and make sure we could know which features our customers actually wanted. One by one, through researching and interviewing what felt like hundreds of customers, Christina and the product team realized there were loads of insights from our customers. Besides the research, demos, data analytics, customer interviews, and customer support and service tickets, there was still something crucial missing here: if we want to know what exactly customers need, the best moment to get insights from people is to find out while they’re in their context, looking to accomplish their goals.
And what was the best way to figure that out? A possibility for our customers to send in product requests while they are mid-experience. The most valuable ideas that have shaped our roadmap in the last year have come in one at a time from in-context feedback. It helped us prioritize and build the features that our customers really like to use. That’s why Christina placed a button into the product that opens a feature request widget. Simple as that.
How do I set up a workflow for feature requests?
1. Make it easy for product managers to collect feedback
First and foremost, Christina set up a feedback collector in our product. She made it an option for customers using the product, and asked for people to contact us if they had any specific ideas they’d like to shout out. Above all, the desired outcome was to get feedback from customers who cared enough to find the feature request option, and type one up at that moment in time for a product manager to see. Importantly, Christina configured the request option to be shown to those who logged into the product; essentially, it means we were only hearing from our customers.
At first, it was a digital ghost town, with no feedback to speak of and digest. “Why hadn’t a single customer reached out yet?” Our hero product manager Christina asked herself, scratching her head. Staying patient, the team got a notification: Usersnap’s first feature request via the button.
Pop the champagne bottles? Not quite. The product team had a long way to go. However, it was a win because the team could know with certainty that someone wanted to give suggestions in the first place from that button. Great start.
2. Manage incoming feature requests
After that, it was time to drill down like a great product manager does. Directly in the Usersnap dashboard, Christina could see which company sent the feedback and what people wanted to tell us. People tend to give solutions to their specific need or challenge, when in reality what’s most helpful is getting to the need or the challenge itself (and beyond the solution). Christina could dive into any feature request by communicating directly in the feedback solution, and getting to the core of the need of users.
Also, the product team got colleagues into the customer feedback loop by allowing them to also send in feature requests, tag them, and start both internal and external conversations from the same place. This was awesome to monitor customer needs and create a sense of customer-centric ownership across departments and teams.
Finally, when Christina wanted to sound a loud gong on a particular feature request to the entire team, she could use the Slack integration to push the customer request directly into a channel for all colleagues to see. In summation, the product team could listen to the customer more thoroughly, and gave themselves more qualitative ammo when prioritizing the roadmap.
3. Label and organize requests
In the midst of communicating to customers and colleagues about ideas, Christina started to make a portfolio of feature requests. Day by day, she and her colleagues checked and saw more. The list grew beyond what we all had imagined, and it forced everyone to start categorizing. With labels, all colleagues were able to put each request in an overarching bucket, and categorize within buckets to see the frequency of feature requests. We could get a real overview of what our users wanted.
And how do I take action with my feature requests in mind?
4. Prioritize and build the roadmap
Prioritization is always hard work, and happens in a few ways for the team.
One way is that the team could take requested features to the roadmap discussions and prioritize them directly, when the quantitative data backed up the feedback and told a complete story.
In addition, we could also look at the overall company and product strategy, first from afar. Then, we could dig deeper into the feature requests received to see if their hypotheses about where the company should go were backed up by validated customer needs.
Essentially, requests were broken down into three main categories:
- new functionalities,
- native integrations,
- and product improvements.
Feature Category 1: New functionalities
Every SaaS company wants to know which great, earth-shattering feature they should build next. However, that process would always require customers to actually need and want it. Customers came to Christina with great ideas about how she could innovate our product.
In line with our overall product vision and where we thought our next move could position us in the market, our product managers took these ideas and implemented some of them into our product roadmap as well. For example, some new functionalities included a smiley rater for CSAT, a user interview scheduler, a guest portal and pop-up widgets (with time-based triggers).
Feature Category 2: Native integrations
A native integration, for us, is an out-of-the-box connection between two systems or applications that can make them both better. In our case, we have several native integrations, and also integrations that can be connected via a third-party service such as Zapier. For us, a customer might like native integrations more because they’re easier to set up and there are no additional costs to connect Usersnap via an intermediary service. Customers requested several, and we started narrowing down those which were most relevant to our product strategy. A few of them eventually made it to our roadmap, such as Asana, Azure DevOps, MS Teams, Slack and Trello.
Feature Category 3: Product improvements
How do we know as a business if what we make is quality, if we don’t ask such questions to a customer (or hundreds)? As part of the feature requests we received, improvements to existing functionality came to the surface as well. Throughout the entire product journey, there were already opportunities for us to improve based on customer feedback. Metrics such as customer satisfaction (CSAT) or customer effort scores (CES) augmented our decision-making process, but that’s another story for another time. The feature requests made prioritizing the roadmap easier, as our product managers were able to pinpoint, one-by-one, where our users thought we were falling short of expectations. Some things we eventually improved were our search functionality, our filtering capabilities, and multi-comments for feedback givers.
5. Build the features customers want
After that categorization, Christina knew on a sprint-by-sprint basis what to tackle, her and the team got their hardhats on and started the arduous work of building. Sprints are a 2-week interval for launching new features in our product development process. At each step of the way, Christina could help the design, product, and engineering team on the same page to
- develop prototypes,
- scope out the technical requirements,
- test the upcoming features,
- beta test, and
- fully release them.
6. Communicate the new features to everyone
Once we had a well-tested feature to release to all of our customers, how would they know that they can use it? Anyone from the team could get back to the individual customer or customers who requested it directly in the Usersnap dashboard. Sometimes, it was better to have the product manager who originally received the ticket upon handoff; other times, it was our customer success manager.
Further, we informed our customers at-large via newsletters and in-app messages what we just shipped. The goal here was to close the feedback loop and ensure that our customers knew we’re truly listening to them, and innovating on their behalf.
Overall, how valuable are feature requests to a business?
Since launching our feedback request button some time ago, here are some high-level stats:
- Over 37% of our total paying customer base is using features we built with the help of that feedback button.
- Over 31% of our total MRR growth is attributed to the features we built and promoted, starting with that button.
- The contribution to our company’s bottom line is also over 22% of total MRR growth.
- Over 54% of everything built by Christina and the Usersnap product manager team came from a customer feature request and that feature request button.
Over 42% of all integrations used in the last 30 days are Asana, Azure DevOps, MS Teams, and Trello, double their current usage percentages.
That’s big stuff from a tiny button.
In addition, here is a quick breakdown of the some current feature usage and its share of business MRR contributing to Usersnap:
|Feature Set||Overall Feature Usage||Company MRR Growth|
– Emoji-based rater (smileys)
– Pop-ups (with time-based triggers)
– User interviews scheduler
– Azure DevOps
– MS Teams
We mentioned how we approached building our roadmap in the past.
Now take a look at our breakdown for roadmapping and building features that customers love to use:
What did we learn from our feature request button?
- That quiet little button gave us the opportunity to engage with users beyond their proposed solutions, and get to true customer needs.
- We learned how to set up our own feature request workflow in a way that fostered cross-team collaboration.
- We used the feature request button as a repository of customer-facing information. When a request came originally from a sales demo, our sales team could file it directly in the project; all in one place so that good decisions could be made together.
- We learned that the impact our decisions had on Usersnap were substantial. So much so, that we continue doubling down on feature requests we receive (literally).
So, how can I set up my own button for feature requests?
1. Specify what you want to ask your customers
2. Embed the button or pop-up into your product
3. Too many buttons already? Put ‘em all in one menu
4. Let the customers’ needs come to you.
Also, feel free to give us your feedback below.
Usersnap provides a customer feedback platform that helps software companies (SaaS) to build better, more successful products and services. We do this by collecting actionable user feedback and sharing it with all stakeholders across your company.