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.