Kill your own feature

The number everyone quotes here is that 45% of features are never used. It comes from a talk, and the sample was four internally developed applications at four companies. Asked to defend the CHAOS reports it sits in, Standish’s own chairman replied that “All data and information in the Chaos reports and all Standish reports should be considered Standish opinion and the reader bears all risk in the use of this opinion.”

So do not use it. There is a better study and it says something more useful.

You cannot tell which of your features are already dead

Juergens and colleagues instrumented a real production system and watched it for five months. Of 53 profiled features, “only 38 were used during the five months of study. The remaining 15 features (28%) were not used at all.”

That is not the interesting part. Before the study, three engineers who had worked on the system wrote down how often they expected each feature to be used. Eleven of those fifteen dead features surprised at least one of them. Actual usage deviated from the product manager’s expectation for 43% of the features.

Read that as a statement about you rather than about them. These were people who knew the system, making a written prediction, and they could not identify what was already dead inside their own product.

And nothing removes it on its own. A separate study of method-level usage found “25% of all method genealogies were never used during the complete period”, sitting in the codebase, being maintained, compiled, and read by everybody who came after.

Why it has to be procedural

An earlier move in this book covered why: being the person who chose something makes bad news about it into a reason to invest further, not less. Staw measured that in 1976 and the effect is strongest exactly where you are standing, on a decision you made that then went badly.

So try harder to be objective is not a plan. The chapter that opened this part gave you the mechanism, which is the threshold you wrote down before you had any feelings about the outcome. This chapter is the second half of that bet: the part where you actually pay it.

The move

When the number you named in advance comes in under the line, remove the feature, and write the removal down as a plan with a date and a named owner rather than an intention.

What a good removal looks like

Twitter’s announcement when they removed Fleets is the model, and it is short: “We built Fleets as a lower-pressure, ephemeral way for people to share their fleeting thoughts. We hoped Fleets would help more people feel comfortable joining the conversation on Twitter. But, in the time since we introduced” them, that did not happen.

What it says is the intent, the hypothesis, and that the hypothesis failed. No blame, no justification, no promise of a spiritual successor.

Google run this as a standing programme rather than an event, and their own count in one post is “70 features or services closed since our spring cleaning began in 2011.” Seventy. Removal is a process they have staffed, not a thing that happens when somebody feels brave.

AN INTENTION                    A REMOVAL PLAN

 "we should probably             feature:  bulk edit
  deprecate bulk edit"           measured: 3.1% of active accounts
                                            at 60 days
 said in three consecutive       threshold: 5%, set 3 March
 planning meetings
                                 affected: 31 accounts, 4 of them
 never scheduled                            on paid plans. list attached
 never owned
 still shipping                  in-app notice: 14 Apr
                                 read-only:      12 May
                                 removed:        9 Jun
                                 owner:          me

                                 what we learned: people wanted to
                                 fix one wrong row, not forty

The affected list is the part that makes this real. Every feature has somebody using it, and naming them turns nobody uses this into thirty-one accounts use this, four of them pay us, and here is what we are offering them instead. That is a conversation you can have. The vague version is not.

What it costs

Somebody is always using it, and if you have paying customers among them the removal has a commercial cost that is not yours to decide alone. Bring the list, not the conclusion.

Removal is real engineering work, competing with new work, and it is the easiest thing in the world to defer indefinitely. This is why it needs a date and an owner in the same way a feature does.

And I want to be honest about the outline’s framing. The part nobody does is my assertion. I looked for a measurement of how often teams actually remove features and could not find one. What is measured is that teams cannot tell which of their features are already dead, which is a different and more interesting claim.

Try this week

List your team’s features and, before looking at any data, write down next to each one how often you expect it to be used. Ten minutes, from memory, in writing.

Then get the actual numbers.

The value is entirely in the gap between the two columns, and in the study above that gap was 43% of features. Whatever is at the bottom of your list, and lower than you guessed, is your candidate.

Then write the removal plan rather than the intention. A date, an owner, the affected accounts, and one sentence about what you learned. That last sentence is what turns a deletion into the end of an experiment, which is what it always was.