When you’re building an app to scratch an itch, it’s easy to design and launch new features and tools that you need. But once you starting gaining customers, they’re going to have their own set of needs that hopefully your app can fulfill. Most will be along the lines of the same itch that you’re scratching but sometimes they’re unique.
Enter the feature request.
I’ve talked about how to handle those emails to a customer here. This time, let’s talk about what to do with them.
Keep a list of the most common ones someplace your team can see it. For us at 37signals, we pick three of the most common requests / pain points from our customers and put them in a project. We include links to cases from customers, examples of what they’re saying, and even screenshots. Anything to give the rest of the team a clear picture.
From there, we do a quick demo of each of those at the company meetup. Everyone is in the same room so it’s a prime opportunity to talk about how to fix them.
We also include info on those top three in our weekly heartbeats to the rest of the team. That way, it stays on everyone’s radar the entire time.
You’ve got to keep them in sight.
That’s the biggest thing. You can use boards, lists, or even a dancing cat that announces the top ones. You’ve just got to keep them in sight for the rest of the team to see.
What ways do you make sure the top customer feature requests stay in sight?
Would love to hear more thoughts on this topic – we keep a Trello Board for feature requests and try to track how often things come up that way, as well as a feature Request forum for end-users to see and vote up topics. Neither has been a killer solution though. All too often discussions turn into “What have you been hearing most often lately?”
How many active requests are you tracking with the Trello board? I’d imagine with lots it could get unwieldy.
We’ve been using a feature request forum to track “Active Requests” – users post their ideas there and then others vote them up. Higher voted items float to the top so they’re more visible to both us and other users. When the feature request email comes in I’ll re-direct them to the forum or an existing topic if it exists.
That works great until you realize that the highly voted items are seen the most, and so get the most votes, and no one wants to read through hundreds of feature requests to find other things they like, so I know there are things in there that people want but aren’t highly rated.
The trello board… unwieldy sounds about right.
I like the idea of the re-direct there. That at least gives them a chance to do something actionable like add their vote or share a comment about that feature request. And I could definitely see the higher voted items getting more action just because they’re at the top. I saw that happen with a help site’s “Top 20 Questions”. They were the top 20 because people clicked on them all the time from the top 20 page. It was just a loop that kept them there.
Maybe you could try tagging the actual support cases you get with some specific feature request labels? That’d give you a chance to see how many users were actually writing in about it. Clicking on a vote for some vague feature is easy. But an email usually means they’ve at least thought it through and can actually give you some ideas on how to implement it. Using the tags would help let the rest of your team know which ones you’ve been hearing about most often.
Yea for sure – Tagging could help. One concern is boiling the information people bring down to a number “15 people want this feature!” instead of the conversation a forum post generates. I’m not sure how good our reporting tools are, but I imagine being able to just bring up a list of emails on a particular tag at least gives real voices to the devs.
I’ll give it a go, thanks!
Jim – not sure if you’re using our product, UserVoice, but we’ve seen much of the same thing. I don’t want to pitch here, but we’re working on a “hot or not” style widget that tells you what people really want (vs what they see the most, or think is kind of nifty). We’re hoping it solves that challenge. Info here: http://www.uservoice.com/touchpoint-toolkit
I definitely agree with the danger of just looking at a number. We try to bring numbers to our feedback meetings but also user stories and pain points. It’s absolutely important to know that 25 people want this feature AND they’re all really upset that it doesn’t exist already and might cancel their subscription. We pretty much shut down any feature request that doesn’t come with stories.
This also helps us weed out what the problem is we’re trying to solve. I like to say that there aren’t bad ideas, just bad solutions to real problems. Customers have a problem and suggest a solution…digging in for stories allows you to surface what their actual, original pain point is.
We actually do use Trello for feature requests. It’s sort of a UserVoice/Trello/UserVoice sandwich. Many ideas come from our UserVoice forums and we often get our stories and numbers from there. We then bring them to the team and discuss them. If we decide they’re important to act on, they go into a relatively small queue in Trello where we mercilessly prioritize. Then once we are ready to act on them we often go back to UserVoice to communicate with these customers, get info from them, have them beta test, etc.
Hope that insight helps a bit…