Dropping UserVoice

Several years ago I was introduced to UserVoice, the online forum that enables direct contact with users, allowing you to collect their feedback and build the features they vote for. At the time I had a very poor line of communication with users, so when I joined Redgate and started using UserVoice regularly, I was blown away.

If you haven’t got a clear line of communication with the people who use your product, it is the place to start (go — go now!). But as time went on and several development cycles passed, I started to discover little chinks in its armor.

Here’s a typical example of how we were using UserVoice as a guide to what to develop next:

We’d create a backlog of things we could build and ‘seed’ them as features on UserVoice. We’d then build them in order, based on the number of votes received from users. If we thought a new suggestion posted by a user was valid, we’d add that to the backlog too.

Over time I noticed other product teams doing something similar; taking feature requests from UserVoice and incrementally adding them to their product verbatim. For teams who were using UserVoice as a platform for users to request improvements, tweaks, and fixes to existing functionality, it made sense.

For other teams, including ours, the new feature suggestions occasionally felt at odds with the rest of the product. Sometimes, for example, there were requests that weren’t seeded by us because we’d never be able to implement them without cannibalizing another product.

Fast forward to the beginning of April this year when our team was formed to embark on a challenging project.

When you start a fresh project, it’s easy to make decisions on auto-pilot (tech stack, working practices, support infrastructure, design patterns, etc). As a team, we decided from day one to make bold decisions if we felt the status quo wasn’t right.

One of those decisions was not to set up a UserVoice forum. Here’s why.

1. We can’t afford to overlook motivation. By implementing UserVoice suggestions verbatim, we think it’s easy to avoid having to ask users difficult questions to uncover their true motivation. We want to force ourselves to ask questions and know for sure what our user’s motivations are (and uncover value).
2. We don’t want to create resentment. We don’t want our users to think we’re ignoring them just because we have unimplemented UserVoice feature requests. Worse still, we don’t want potential users to put off using the product because feature ‘x’ isn’t there yet. In the long run, we don’t believe it’s satisfying to implement every single suggestion in order of popularity. We’re developing a new product, not improving/tweaking/fixing a mature product and after three or four development cycles we’d be worried about the direction being set for our product; something we’re responsible for as a team.
3. We want to be Lean. Being lean means we’re able to concentrate on making the product solve our user’s problems in the most efficient way possible. At The Lean Event this year, Josh Seiden described in his keynote, ‘Building a winning UX strategy’, how Lean is a strategy, specifically how it is iterative (i.e. returning to the problem and improving it) and not incremental (i.e. building features based on a UserVoice backlog).
4. We’re best placed to solve the problem. In ‘Intercom — Jobs to be done’, Paul Adams sums it up nicely… “people are experts in their problem, not the solution”. Responses on UserVoice take the form of attributes that all too easily form the description of a feature. We should know the problem — the Job to be done — inside out and apply our knowledge in order to solve it.
5. It’s difficult to trust the data. If 400 people cast a vote for a feature that’s been described by a single person in ambiguous terms, it’s very difficult to trust that data. It takes a lot of research effort to untangle.

With all that said, we realise that by choosing not implementing UserVoice, we could easily miss out on a number of valuable things. Here’s how we’re going to mitigate that:

1. So we don’t overlook customer problems and motivations, we’re going to take every opportunity to understand motivation. To do that, we’re going to use Intercom.io as a team. We’ll use their automated message feature to encourage our users to get in contact with us. I believe Intercom will also work nicely for people less keen to talk on the phone (both on the team and customers) but less likely to encourage anonymity that’s unhelpful.
2. So we know we’re contributing effectively to a product that only becomes more valuable in the future, we’ll publish our roadmap and invite our customer to give their feedback on it — helping us validate our assumptions and hypotheses as they do.
3. So we can demonstrate to our customers that we’re listening, our Lean process should ensure that all of us continue to communicate with them. Talking to customers can be a daunting, anxiety-inducing prospect, but it’s worth it. We’ll learn how to start a conversation like Dave Grohl. Ultimately though, our actions speak louder than words and so our aim is to regularly deliver updates that increase the value of the product for our customers.
4. So we know we’re best placed to solve the problem, we’re going to make use of experts in the area we’re working in. We’ll take their input on everything from technical implementation to testing the validity of our hypotheses.
5. So we have data we trust enough to base a decision on, we’ll implement our own data collection mechanism. When we've tried this in the past, we've seen a 500% increase in the amount of data we can collect by placing a simple and unambiguous ‘yes/no’ survey in the application, at the right time, in the right context (when compared to a general mail out to the customer base about the same feature).

This is new territory for us. We may fail, we may succeed, but one thing I do know is that we’re monitoring our decisions and listening to our users more carefully than we have ever done.

Image credits: stocksnap.io and quiet by Bohdan Burmich