Gathering a list of features to implement in your software is pretty easy. Sources of inspiration usually come from all different directions. Users will request features, your team will suggest features, your competition will taunt you with their features and then, of course, there’s always what necessity dictates.
The problem is once you’ve amassed this collective list of wishes, hopes and desires, you realize that your limited resources (time, money, manpower) force you to have to prioritize them. You can only do so much right now, implement certain things eventually and pretty much make everything else wait. If you’re not careful about managing your expectations and your users’ expectations, it can end up feeling like a game of constant disappointment because the things you want to do will always be larger than what you’ve already done.
Since prioritization is really about ranking items, democratizing the process through voting is one way to go about it. In fact, community link ranking sites like Reddit.com end up having the features basically voted on and delivered to them by fiat via the very service they created. Feature requests from the community often rise up on the homepage at Reddit demanding the founders to do something about it. And often, if not every time, the founders have responded accordingly. I imagine there’s a mixed sense of excitement and annoyance that comes from developing by public decree, but it ends up being an amazing experience for the users. Nothing seems to deepen a relationship more than seeing that there’s an actual relationship between what you ask for and what gets done.
In fact, if you want to outsource prioritization to your users in a similar fashion, you can even use a service like UserVoice to make your community part of the feature request discussion. Once submitted, ideas can be voted up or down (just like Digg or Reddit) and the status of the feature requests can even be updated by you, which creates a nice feedback loop of what’s being done.
Now, there’s definitely some drawbacks to having the development schedule of your product come solely from the masses. One of the biggest is that your users, for the most part, ask for Frankenstein. If the road to hell is paved with good intentions, then the road to feature bloat is probably paved by agile developers always listening to their users. Henry Ford probably has the best quote on the topic:
“If I had asked my customers what they wanted, they would have said a faster horse.”
In fact, Jakob Nielsen even argues that listening to your users actually breaks the First Rule of Usability:
To discover which designs work best, watch users as they attempt to perform tasks with the user interface. This method is so simple that many people overlook it, assuming that there must be something more to usability testing…ultimately, the way to get user data boils down to the basic rules of usability:
- Watch what people actually do.
- Do not believe what people say they do.
- Definitely don’t believe what people predict they may do in the future.
For additional perspective, Jeff Atwood over at Coding Horror wrote an excellent essay titled Don’t Ask — Observe, which highlights why especially in web applications, we should have no excuses about getting down to the bottom of our users’ behavior.
Why ask users if they’d like recommendations in their shopping carts when you can simply deploy the feature to half your users, then observe what happens? Web sites are particularly amenable to this kind of observational testing, because it’s easy to collect the user action data on the server as a series of HTTP requests.
For those of you thinking that data driven development requires a complex system of monitoring and analytics, you’ll be surprised to know that you can even do it with something as simple as a 404 error. Tech-savvy members of the web community know that a 404 error is likely the fault of the web developer. However, Stephen Kaufer of TripAdvisor.com wagers that when your Mom surfs the internet and encounters one, she just assumes (without assigning blame) that ‘something went wrong’, presses the back button, and chooses another link. And so before deciding to spend engineering resources to develop costly features on TripAdvisor, he would often determine whether something would have a strong uptake by creating a fake button or interface element of the feature on the site and have it lead to a 404 page he monitored. He’d then publish the link on a subset of his web servers for a statistically relevant period of time and count the number of click-troughs. If the count for the link is high, he’ll task his developers with the creation of the actual feature. If not, he’ll direct his staff to create something else. It was simple, saved him lots of money and only cost him some slightly confused users.
That being said, showing 404 errors on purpose isn’t for everyone. If you don’t have the stomach to treat your users as unwitting participants in a web development experiment then the 404 Test might not be for you. Thanks to the folks at Clearleft you can take a more intimate approach to user observation by taking it to the streets with a laptop and Silverback, their application for implementing guerrilla usability testing. After recording a session with a user, you can playback a screecast of what they were doing along with video of the user in action while they use your web site or software. It’s a brilliantly elegant piece of software that gets the job done without breaking the bank.
Additional Reading
Everyone needs a hug… Even Henry Ford.
Nice post, Tim.
Excellent article.
User feedback like the kind your get from UserVoice should not be treated as canon is valuable data and can be invaluable in helping you steer the ship. I’d even like to point out that Jeff Atwood uses UserVoice on StackOverflow.com. :P
We also sell UserVoice on the secondary benefits you get from simply listening to your customers. It helps build the customer champions, by making them feel invested in the product, that help companies get over the hump with word of mouth referrals. It also helps my blood pressure to know that user’s ideas are being capture somewhere for later usage rather than just falling out of my inbox.
Thanks for the tip on SilveBack I’ll have to check it out.
I loved the part with the 404 page being used to measure user interest in a particular feature, before it’s developed.
Young open source projects are being shaped functionality wise by their users. And, for free projects, linking feature requests with donations, in the form of sponsorships for the development of a certain feature, can boost the community involvement and financial support.
But democratizing the feature selection process through voting is not a silver bullet. Winston Churchill said “The best argument against democracy is a five-minute conversation with the average voter”
“If I had asked my customers what they wanted, they would have said a faster horse.”
Yes. Of course they’d say that. And then , as a designer, you’d ask them why they wanted a faster horse, and you’d disscet speed as being a requirement. You’d ask if there are other concerns they have, and if they told you they wanted a more comfortable journey, or if they didn’t like animals you’d factor all these requirements in. At the end you’d have a precise set of requirements from which you begin to build a solution.
Customers always talk in the lower levels (“I want a flash home page with movies and sound effects”), and we have to ask why (“Oh, well I guess I want it to look high tech and futuristic”) In my experience customers know what their overall goal is, but they have 2 big problems. 1. They have trouble explaining what they really want 2. They tend to think at a low level rather
Great post guys, love this blog!
Des
Excellent article. Thanks a lot.
@Tim
Nice article. I just found your blog, but you can bet that I will be spending some quality time here.
It’s so common to hear “Just listen to your users/customers/prospects and they will tell you what they want.” If it were that easy, Product Management would be largely unnecessary, but it’s not (easy or unnecessary). As Des said, the feedback has to be distilled. Users will gladly tell you what the solution is, but it’s more useful to find out what the problem is so that you can identify the best way to solve it. Otherwise, you end up going down the path of being a software project rather than a software product.
Ivan Chalif http://theproductologist.com
Voting doesn’t optimize the value delivered to the customer, nor the customer’s training/learning load.