Saying No to Features Part II: Ripping Things Out

July 29, 2013 Graham Siener

The subject of today’s post is inspired by moving (which I’m doing tomorrow). I’ve talked in the past about the theme of not putting features into your product unless they are absolutely critical. An extension of that is to observe your product in the wild and evaluate where you went wrong. Perhaps the commenting functionality you added no longer makes sense since you pivoted to a “single player mode” experience. Or maybe your platform is now self-serve, which means the whole publishing workflow you created is never used.

No plan survives contact with the enemy, so you shouldn’t feel bad about features that didn’t find a place with your users. Instead, you should ruthlessly rip these features out to save yourself the agony, maintenance and UX limitations you’re imposing on team and your product.

What are the possible outcomes? You remove a feature that users secretly love (despite your metrics saying otherwise) and they cry bloody murder. Great — now you have a vocal and engaged group of users that you can interview and gather a better understanding of how they’re using your product. Maybe they applaud your courage and thank you for removing that stupid feature that no one liked and frankly made you look a little silly. Or (most likely) they say nothing, which is tacit approval.

I encourage everyone to turn off one feature this week and see what happens.

About the Author


Introducing (for all your example-app needs)
Introducing (for all your example-app needs)

Hamazon, your Fine Purveyors of Pork Products since 2010, is the default example I use so as to have a con...

3 Quotes Explain It All: Why IBM Is Betting On Cloud Foundry
3 Quotes Explain It All: Why IBM Is Betting On Cloud Foundry

After reviewing a broad array of press and Twitter coverage the past several days, there were three great p...

SpringOne 2021

Register Now