Openly discuss and decide on features with your users


Openly discuss and decide on features with your users

OpenVoyce is a platform where users can suggest, openly discuss and vote on future features for your company.

Allowing users to vote shows you instantly where you should concentrate your development efforts in the future. Aggregating suggestions in this way allows your team to focus on original suggestions as a collective, not replying to the same one over and over.

Avatar?ixlib=rails 2.1
Hi everyone!

A while ago, Daniel and I wanted to use something like uservoice for our products, but we found it was too expansive for our side projects. So we decided to build our own one.

At which point, we realize we could open it for not that an expansive price, and so we are :)

Right now, we'll try to get a few users to see what are features they would want and try to make the product shift from "our needs" to "something solid for everyone".

At that point, we'll probably adopt a self hosted free / cloud paying model, opensourcing the code, so that people who don't have that much money can host it, and those who are more wealthy can pay to avoid having to manage servers and updates. Which will be the opportunity for other developers to contribute features as well :)
Avatar?ixlib=rails 2.1
@oelmekki I did a bit of research in this space about a year ago as I was contemplating building a product of my own and what I found was that most solutions focus on "ideas" and "feature suggestions". However, my own experience teaches me that what customers think they want, isn't necessarily what they need.

People tend to think in practical solutions, while often reframing the problem yields a much better solution. For example someone might suggest you add "tagging" to OpenVoyce, while what they mean to say is that they don't have a good overview of what's being discussed. Tagging just happens to be the solution that springs to mind for whatever reason, but it's not necessarily the best one.

I'm curious to hear your thoughts on this and if you're doing anything to steer the discussions towards better understanding customers' problems, rather than immediately fixating on solutions and features.
Avatar?ixlib=rails 2.1
@marckohlbrugge Oh yeah, having been a freelancer and then a CTO, I know exactly what you mean :) My most common sentence was : "Ok, I get what you think we should build, now let's try to extract your need from that before going further".

The problem we wanted to solve when we decided we wanted openvoyce was all the duplicates you usually have in a support system. In the previous few years, it became commonplace that support is a prime for startups. Problem is, support teams keep answering the same questions over and over and we think they could use their time better. And you bet it: most requests are feature requests and supposed bugs.

Maybe we should rename "upvote" into "+1", because voting may make people think there's a majority vote going on and the most requested suggestion will automatically be implemented. In the same way, "implemented suggestions" should probably be "previous suggestions", suggestions will probably most of the time not be implemented as is.

That being said, you know people will make feature requests anyway. It's kind of the job of the support to extract a need, and the job of the technical team to present a solution. I'm not sure saying to users "what is your need?" or "try to think of a need instead of suggesting a feature" would be a good thing. What we want is to gather raw material, in the biggest amount possible, with a tool that helps sorting it. De-duplicating feature requests is such a tool : users naturally think feature, they already make an effort to click that link to provide their idea, let make it easy for them to just drop it. Trying to do so, they may realize their question as already been answered, and we have an user generated doc. Or they may see a discussion and enrich it with their own use case. The effort to abstract the need, which requires actual skills, we can do it :)
Avatar?ixlib=rails 2.1
@oelmekki Great answer! I definitely agree you can't expect the user to identify their needs. I guess my question is how OpenVoyce will help the product owners better understand the customer's needs (e.g. how do you go from a feature request to a better understanding of your customer, as solving that problem is where the real value lies IMO).
Avatar?ixlib=rails 2.1
@marckohlbrugge Thanks! :)

Hum, you're right. We didn't implement "needs isolation" features yet, because that's something we're already used to do by ourselves. But that's definitely count in what we need to do to make "something solid for everyone". Thanks for contributing this first step ^^

We already added categories on suggestions, which are only visible for product managers. This helps grouping suggestions and filtering themes, but this is obviously only a first step.

Analytics sounds like an obvious way to go, I would just want to avoid making it too much full featured: big analytics apps are difficult to use because you're easily lost in data. I'm working on a knowledge database on an other sideproject, with a big emphasis on extracting themes and synonyms. This could be a cool feature: isolating themes in opened suggestions and surfacing the most common ones. My bet is that in each feature request, among all the details that describe behaviors, you can extract one or two words that make the need more obvious. I have to test this, actually.

Something I would love too is to make developers participate in discussions. This is a difficult topic, because developers hate those kind of discussions. They just don't speak the same language, and they feel like most discussions are a waste of time because they're not about specific enough problems. That being said, I've seen way too often support promising things they thought would be easy just to discover downstream it will be a hell to do, or on the contrary, trying to temporize reports about something that is casual to fix. Developers certainly are the ones that are the most fit to think about an actual solution. Shadow commenting on support platforms has already been tried, doesn't work (devs will only go there if they are asked for it). Maybe just a weekly or monthly mail summing up the trending categories / themes could help. Support team could also tag a "suggestion of the week" that would appear in it.

Well, you gave us a lot to think about, thanks ;)

Sign in with Twitter to join the discussion