We Need a Culture of Feature Killing

The buzzword (or letters, as it were) of the past year or two in the startup world has been “MVP"…minimum viable product. You should shove out the smallest version of your product just to get something out there and get real humans using the thing.

In general, I agree with that. The sooner (and faster) you can get something out there, the better. But what typically gets ignored with "shipping it fast” is “killing it fast.”

The focus is still very much on features and just piling them on. Get something out there with a basic feature set, then use customer feedback to add more features. The emphasis is on “expanding” the product, and less on “refining.” That needs to change. We need a culture not of shipping it fast, but of killing it fast.

So. Much. Clutter. #

Over the past couple of years, my wife and I have been on a bit of a mission to de-clutter our lives. We’ve cut our wardrobes down significantly, had multiple yard sales, and have donated more stuff to the local thrift store than I can even remember.

In doing that, we’ve simplified our lives and made them much more manageable. When we want to find something, we generally know where it is. When we want to wear something, we don’t spend a ton of time staring at the closet trying to make a decision. Everything is where it should be and it doesn’t drive us crazy trying to figure out where things are.

In case you didn’t notice, there are many correlations with well made software.

When you pile on features and expand what you offer, you complicate things. You add visual complexity that makes your users think. You add overhead for maintenance down the road. You add support weight to your customer service process. Everything has a cost. Everything. Doesn’t matter if it’s some tiny icon hidden in the corner. It cost something to include and maintain that.

It’s your job (and everyone working on whatever you’re building) to keep things as “cheap” as possible while maximizing value.

How do you know when to bring down the hammer? #

For me, knowing when to ax something is simple. I generally play in the world of building products at their earliest stages (both on a personal and consulting level), and in those cases, the metric is always this:

If it doesn’t have a noticeable affect on revenue, it gets killed.

The only kind of business I care about is a sustainable one. And the only way to sustain a business is with revenue. So, no positive affect on revenue? It gets the boot. Simple as that.

Kill it quickly #

How do you know when it’s time to kill it? As soon as it’s obvious it’s not adding value. I’ve killed massive features that took 6 months to develop in as few as 3 weeks after launch.

By having good analytics on how users are interacting with your product, and also being self-aware and honest with yourself…you can pretty easily know when something isn’t working like it should.

Feature Audit #

Slow down on pumping out every feature your users request. Regularly audit what is and isn’t being used and what is or isn’t affecting your bottom line. If it’s not helping your business grow, it’s likely hurting it. A feature that’s hurting your business is a cancer…and you need kill it. Quickly.


Now read this

The Art of Juggling: 4 Methods for Managing All Those Projects

Back in high school I went on a mission trip to Brazil. Everyone in my youth group had volunteered to do various things on the trip with the kids we’d be working with (soccer, crafts, music, etc). What did I sign up to do? I signed up to... Continue →