Identity Verified Thinker in Technology / Software / Design
Yaacov Apelbaum
Yaacov Apelbaum
is a writer, inventor, and researcher. He holds 8 US technology patents. His professional focus is on software engineering, security, and the human aspects of development.


This Blog has no active categories.
This Blog does not have a Specialty

Just Say No to Features

Apr. 2, 2011 11:20 pm
Categories: Engineering, SDLC

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 MS Office 2010 ribbon is an example of a clever attempt to obfuscate feature gluttony and compensate for poor access to most common features).  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.

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).

Yaacov Apelbaum-Office 2010 ribbon

To hit the market early and within budget, your feature development strategy must focus on creating the bare essential functionality. So in this vein, you should make it prove itself to be a “worthy survivor”. Your features need to be tough, resilient, and lean.  I have come to embrace the U.S Navy SEAL’s “hell week” screening approach before letting any one of them into my development cycle.

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 “it sounds great, but not now honey, I have a splitting headache” or “I’d love to chat 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)…

  1. Hold a management meeting to discuss it (30 min.)
  2. Hold a feasibility meeting with the technical teams (30 min.)
  3. Develop a schedule and if you use SCRUM work the feature into a sprint (30 min.)
  4. Develop screen wireframes (60 min.)
  5. Develop HTML mockups (60 min.)
  6. Develop a POC (120 min)
  7. Allocate resources that are working on other features (30 min.)
  8. Develop an analysis and design document for system, CMS, DB impact, etc. (30 min.)
  9. Create a code branch (30 min.)
  10.   Write unit tests (120 min.)
  11.   Write the code (120 min.)
  12.   Peer review the code (30 min)
  13.   Merge the code back into trunk (30 min.)
  14.   Test, revise, test, revise…(60 min.)
  15.   Modify user documentation (30 min.)
  16.   Update the product guide (30 min.)
  17.   Update the marketing and engineering collateral (60 min.)
  18.   Refactor product cost and check to see if pricing structure is affected (60 min.)
  19.   Deploy to production (30 min.)
  20.   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 should 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 shred them.

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.

There are currently no comments.
Latest Ebooks