I want you to become a relentless, cold-blooded killing machine.
A feature killing machine, that is. Last week, I blogged a few ideas about how to make enterprise software suck less. I suggested that focusing on end-users vs. buyers, changing the selling model, and killing features results in better software. By better, I mean easier to use, more intuitive, and therefore more able to make people productive in their work. Steve Boese nailed it today in his Simpler Answers post:
How about by taking a longer and harder look at more simple technology solutions? What? Simpler solutions? Ones that don’t necessarily have the ability to check ‘Yes’ on that 89 page performance management capability RFP you just issued? … Solutions that take a ‘less is more’, or perhaps more accurately a ‘only the features that are truly needed are included’ approach to development and deployment?
That post kicked off a lot of discussion, both in the comments and in places like Hacker News. The “kill features, often” idea got the most push back. It seems to have hit an emotional chord, with the enterprise folks saying “but, you just don’t understand!” and the other folks saying “yes, please, we’d like some of that.” Let’s take a closer look to see how we can kill features gracefully and still keep customers and users happy.
Enterprise or Business Software?
One of the first “kill features” objections is about language. Here’s a typical response:
“Rypple, Xactly, Zendesk, Atlassian, Box.net, Zuora, Xobni” is not enterprise software. It’s consumer software for the enterprise. There is a difference. It’s business software. — @codemonkeyism
The very definition of enterprise software means large, complex and with many, many features. To pull features out and make it less complex would therefore render it less enterprise-ey, and more business/consumer-ey. Fair enough, as far as circular arguments go. But, if usable, simple and elegant are not part of what it means to be enterprise software, then I say: Hell yes! Stop building (and asking for) enterprise software!
“Kill features?! But, you can’t do that!”
Nobody said killing features is easy. In fact, it’s really, really hard. Creating anything awesome is hard. So, here’s how to make it less hard:
Step 1: Who you are building for?
Do you want to build an impossible app that does everything that every possible customer in the entire world would want? Or do you want to solve a very real set of focused problems for an identified set of users and customers?
The more that you know about your most important customers, the easier it is to kill features. If you don’t know who pays your bills, you’re shooting fish in the dark. If you know a feature doesn’t appeal to your core customers, killing it is as easy as shooting fish in a barrel (and yes, it’s as easy as it sounds).
We made a choice early that our core user is a manager and his or her team, not the HR buyer. We understand and respect HR people and their role in the adoption of Rypple, but, we also know that they’re not our most important customer. This was a fundamental decision and has helped us many times in deciding both what to build and what to take out of our service. Who is your most important customer?
Step 2: Build a culture of killer learners
It’s crucial that you make killing features a cultural “win” for your product and development teams. People don’t like when their sleepless nights of coding and designing gets consigned to the dust-bin of software history. Developers take great pride in building and shipping a great product, so killing can be interpreted negatively if you are not careful.
Take the time to get your team to understand the motivations and reasons for code killing. With enough patience and openness you can get your team to celebrate the power of the delete button. In fact, done well, killing can be very motivational. Good developers hate building things that nobody wants or appreciates, which maps perfectly to understanding what’s most valuable to your users. That works out well because killing features is, at its core, about understanding users. The more your developers learn about your core users, the more trigger happy they’ll become. We’ve gotten to the point where people nominate features for the “kill list” and take delight when their choices get selected.
Step 3: Use data & context
You need to be data-driven or you’re killing features on a whim. The most killer data: which features get used most often by your core customers. Granted this is much easier to track when you offer SaaS software, but anyone can do it if you build a metric-driven development approach into your company.
With quantitative data in hand (e.g.: which features are used by less than 10% of users? Less than 1%?), you can then talk to users and gather qualitative data about the few cases where outlier features are actually important. You can discover if these are core users and the why and how of use. Armed with the right information you can make choices about killing with confidence.
Data can also help to communicate the thinking behind changes. There is no doubt that some users will be upset when you take their pet feature away, but explaining that it was a pet feature can help mitigate their concerns. Some of you may have followed the recent release of Digg v.4, which includes tons of great new features. Some long time users were upset that the Upcoming Stories section (a view into which stories were trending toward the homepage) didn’t make the cut. Kevin Rose, Founder of Digg, was able to appease them by sharing a killer data stat: “Out of 200+ Million pageviews in July, only 0.4% was from upcoming (yes, that’s less than 1/2 of a percent).”
Step 4: Tell them honestly
The biggest concern with killing features is how to break the news to customers. No doubt, in those cases where a customer was promised the feature as part of a deal closing package there is gonna be a lotta ‘splaining to do when it gets whacked and goes off to the big feature list in the sky.
The short answer to this problem is: tell your customers what you killed and why. Don’t be shy. Be honest and upfront. Tell them that the thing they loved is not being used by the vast majority of users. If possible, share the data. Be transparent about your decision making. They might not agree but hopefully they can at least they can understand.
This isn’t an easy process but we believe it’s an absolutely necessary one. It’s orders of magnitude harder if you have not changed your selling process to explain your product philosophy up front, when the differentiated value of your core features is not clear, and when the features you kill were “must have” in an RFP-bake off. Like we said, it’s a bunch of things that have to change!
We’re going to keep talking about this but we want to hear from you. What features have you killed? What would you love to kill? Let us know in the comments below.
Barrel photo by Graham Dean. Garbage can trophy photo a horrible mashup of our own invention. I Love Lucy cover photo of the sixth season DVD collection.