Tuesday, March 16, 2010

The Importance of Removing Features

Recently, I had coffee with a product manager of a venture-backed software as a service company. The company’s product has been out on the market for a couple of years, and while they are starting to see their hard work pay off with the beginning seeds of a user community, he still felt like they could be growing faster, and believed that community feedback would be the key.

From a product design perspective, user communities are incredibly valuable sources of product feedback. It's no wonder startup gurus like Sean Ellis and Steve Blank stress the importance of constantly talking with your users to achieve product market fit. But as my product manager coffee-mate started to walk me through his methodology for prioritizing which features he was going to add to the product from a long list of feature requests he was getting from the community, I couldn’t help but ask him “Yes, but how do you prioritize which features you should remove?”

Everyone knows that simplicity is king for product design, but all too often, the focus of product discussions fall in the “What’s next?” camp. i.e., What are the new features? When will they be rolled out? The converse – which features to remove— doesn't have as loud a voice. User feedback almost always skews towards which features to add instead of which to subtract. Consequently, as product development becomes increasingly driven by users, it’s never been easier to forget about the need to remove features.

This can be dangerous. I'm sure everyone's had the experience of looking at a new web app and not knowing where to start. Too many features slows early consumer adoption. That said, the user community actually does provide passive feedback on which features you should consider losing: by not using the features. It's not as in your face as a user begging you on a forum or twitter for a new feature, but it's just as important. That’s why tracking feature engagement is critical and I've always found it to be an important part of the product design workflow for all the great product managers I've met.

My product manager friend didn't have a process for removing features because he was focused on satisfying the user requests. Eight times out of ten, you should focus on building out the featureset. But sometimes, it’s better to ignore what your users say, and focus on what they do.

(Hat tip to SpringPadIt for the inspiration for this post, and blogging about not just which features they added in their new product release, but also which they removed.)

blog comments powered by Disqus