Just Say No to Features

Yaacov Apelbaum-Just Say No

A quick feature inventory of most “mature” commercial software products like Microsoft Word, Lotus Notes, etc. reveals that more than half of their features are either never accessed or are outright useless (the historical evolution of the Microsoft Word tool ribbon is an example of feature bloat). If you are developing software in a startup, useless features will be the death of you and your product. The secret to developing the right set of features is learning how to say no to the rest.

Yaacov Apelbaum - Word 1.0 ribbon

Yaacov Apelbaum - Word 6.0 ribbon

Yaacov Apelbaum- Word 2003 ribbon

Yaacov Apelbaum - Word 2003 ribbon

Yaacov Apelbaum - Word 2013 ribbon
Figure 1. Bloat progression in Microsoft Word from version 1.0 to 2013

Whenever you say “yes” to a new feature, you agree to adopt a baby. And with the baby come such responsibilities as changing it’s diaper, waking up at 3 AM to feed it, and paying for its education (e.g. architecting, developing, integrating, and testing).

To hit the market early and within budget, your feature development strategy must focus on creating the bare essential functionality. So in this vein, stay away from developing a Swiss arm knife with dozens of capabilities solutions.  You should make each feature prove itself to be a “worthy survivor”. Your features need to be tough, lean, and mean. Embrace the SEAL’s “hell week” screening approach before letting any one of them into your development cycle.

Yaacov Apelbaum - Swiss Army Knife Bloat

Whenever product, sales, marketing, or even the CEO requests a feature–it should instinctively meet a resounding no. If you don’t feel comfortable saying no, try a variation along the lines of “not now honey, I have a splitting headache” or “I’d love to chat about this feature, but I’ve got to run into a day long meeting right now”. If you are cornered and can’t escape, listen and take some notes, but stop there. There is no need to be heroic or do anything just yet.

If a request for a particular feature keeps surfacing over and over again from different sources, that’s when you know it’s time to take a closer look at it. Only at this point should you start considering it seriously.

What do you say to the product team that complains vocally that you won’t adopt the top one hundred features on their wish list? Remind them that developing even the most basic feature is prohibitively expensive. Alternatively, you can use the following list of tasks to illustrate the amount of work needed to insert a simple image on a MVC CMS driven web page:

To develop this feature, you need to (times are in minutes)…

  • Hold a management meeting to discuss it (30 min.)
  • Hold a feasibility meeting with the technical teams (30 min.)
  • Develop a schedule and if you use SCRUM work the feature into a sprint (30 min.)
  • Develop screen wireframes (60 min.)
  • Develop HTML mockups (60 min.)
  • Develop a POC (120 min)
  • Allocate resources that are working on other features (30 min.)
  • Develop an analysis and design document for system impact, (30 min.)
  • Create a code branch (30 min.)
  • Write unit tests (120 min.)
  • Write the code (120 min.)
  • Peer review the code (30 min)
  • Merge the code back into trunk (30 min.)
  • Test, revise, test, revise…(60 min.)
  • Modify user documentation (30 min.)
  • Update the product guide (30 min.)
  • Update the marketing and engineering collateral (60 min.)
  • Refactor product cost and check to see if pricing structure is affected (60 min.)
  • Deploy to production (30 min.)
  • Cross you fingers and hope that everything worked out as planed
  • Total development cost = two days of work

As you can see from these steps, even the most basic feature request can cost two days of planning, design, development, testing, and documentation effort. On average, feature tend to be 5 to 10 times more complex.

Sometime User Feature Request Can be Evil 
What about using your customers as the main driver for feature development? Well, this strategy has several small flaws as well. Your customers want everything under the sun, yesterday, and for free. You shouldn’t fault users for making feature requests. I encourage our customers to speak up and I diligently collect their input. In the end, most of our functionality comes from user requests.  But as I have indicated, even for user feature requests, my first response is to always say no. So what do I do with all these new customer feature requests? I read them, try to forget them and finally, for safe measure, I putn them in a backlog file.

It sounds terrible, I know, but don’t worry, if the feature request is important enough, it will keep on coming back and you won’t have any difficulty remembering it then. These persistent features will be the ones essential to your products that you will need to prioritize and implement.

It may not be apparent, but most software feature surveys revolve around questions like “What features are missing in our product?” or “What what would be the one feature you couldn’t live without?” or “What would make this product a killer app?”. Rather than continue to ask for more in this way, the questions that you should be asking are “If you could remove one feature, what would it be?” or “How would you simplify the product?”. Sometimes the best thing you can do for you product is to develop less.

Now go ahead and practice your newly acquired skill of just saying no.

© Copyright 2011 Yaacov Apelbaum All Rights Reserved.

One thought on “Just Say No to Features

Leave a Reply

Your email address will not be published. Required fields are marked *