Oct 25, 2009
How to avoid feature creep?
Featuritis (feature creep) is a common plague of all startups and depending on stage, can cripple a startup. In trying to determine the core value to the end user, relying on a combination user feedback, introspection, and internal company feedback can lead to complex and convoluted solutions to simple problems.
In an old article by the NewYorker, “Feature Presentation“, the author cites:
In part, feature creep is the product of the so-called internal-audience problem: the people who design and sell products are not the ones who buy and use them, and what engineers and marketers think is important is not necessarily what’s best for consumers. Being technically savvy themselves, engineers love to enhance the capabilities of a product and give users more control and more options, particularly now that, thanks to digitization, lots of added features don’t mean lots of added production costs. The engineers tend not to notice when more options make a product less usable. And marketing and sales departments see each additional feature as a new selling point, and a new way to lure customers. Often, the result is a product like Microsoft Word 2003, which has thirty-one toolbars and more than fifteen hundred commands.
You might think, then, that companies could avoid feature creep by just paying attention to what customers really want. But that’s where the trouble begins, because although consumers find overloaded gadgets unmanageable, they also find them attractive. It turns out that when we look at a new product in a store we tend to think that the more features there are, the better. It’s only once we get the product home and try to use it that we realize the virtues of simplicity. A recent study by a trio of marketing academics—Debora Viana Thompson, Rebecca W. Hamilton, and Roland T. Rust—found that when consumers were given a choice of three models, of varying complexity, of a digital device, more than sixty per cent chose the one with the most features. Then, when the subjects were given the chance to customize their product, choosing from twenty-five features, they behaved like kids in a candy store. (Twenty features was the average.) But, when they were asked to use the digital device, so-called “feature fatigue” set in. They became frustrated with the plethora of options they had created, and ended up happier with a simpler product.
So how do you solicit meaningful feedback from users and identify what is truly important to them?
A common theme seems to be in the distinction between a need and a want. Though this seems like a simple task to distinguish, as noted above, most users will convey features as a need.
1 A/B paper prototype
Create different wireframes/mockups to test against. For example, if a user says they want feature x, understand if they want feature x over feature y by providing two sets of wireframes.
2 Guide user to explicitly give both positive and negative feedback
People tend to be either overly positive or overly negative. Get their viewpoint by asking questions like, “Name 3 things you like and dislike about this.”, and “Tell me three things you would change and keep about this.”
3 Keep user focused
If you’re testing functionality, avoid graphical or presentation feedback. Avoid pushing peripheral features on the wireframes because those can potentially distract the from focusing on the core you’re attempting to validate.
I also think that if you create pixel perfect mockups for validation, it may be difficult to understand if the user understands/wants/needs the feature or just likes the presentation. Anycase, looking for more concrete methodology to identify pain/need of users in the wireframe phase. Drop me a line if you have any thoughts.
Some other really good tips here: http://sixrevisions.com/project-management/eight-tips-on-how-to-manage-feature-creep/
