Jonathan Roberts

28 June 2016

Sometimes, you don’t need UserVoice to give users a voice

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 a team was formed to embark on a challenging project. Our objective? To build an entirely new product to help organizations move and manage data across the Microsoft Data Platform.

The development team, AKA the ‘White Sharks’, implementing Intercom.io as part of building products for the Microsoft Data Platform.

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 the status quo wasn’t right.

One of those decisions was not to set up a UserVoice forum. And 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 (ie, returning to the problem and improving the solution) and not incremental (eg, 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 research and own 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 realize choosing not to implement UserVoice means we could easily miss out on a number of valuable things. Here’s how we’re planning to mitigate the issue:

1. So we don’t overlook user problems and motivations, we’re going to take every opportunity to understand motivation. To do that, we’ve chosen the Intercom customer feedback platform. We’ll use its automated message feature to encourage users to talk to us and discourage anonymity that’s unhelpful. As an aside, we believe Intercom will give those people less keen to talk on the phone (both us and our users) a communication channel they’re comfortable with.
2. So we know we’re contributing effectively to a product that becomes more valuable in the future, we’ll publish our roadmap and invite users to give feedback – helping us test our assumptions and validate our hypotheses as they do.
3. So we can demonstrate to users that we’re listening, our Lean process should ensure we continue to communicate with them. Talking to users can be a daunting, anxiety-inducing prospect, but it’s worth it. 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 users.
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 can have data we trust to help us make decisions, we’ll implement our own data collection mechanism when we need data. When we’ve tried this in the past we’ve seen a 500% increase in the amount of trustworthy 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 user 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.

And what’s the product? Well, I’m pleased to announce Data Platform Studio. We’ve designed Data Platform Studio from the ground up to help organizations move and manage data across the Microsoft Data Platform, from on-premise SQL Server to Microsoft Azure, starting with an Azure SQL Data Warehouse importer.

You can get started now by signing up at dataplatformstudio.com/signup. And remember, we want to hear from you, so feel free to contact the team directly at dps@red-gate.com.

Thomas Hodgson, DPS Team Technical Lead presenting Data Platform Studio as part of the keynote at AzureCraft 2016.