“We never actually kill any features.”
“What about when you rewrite an existing system into a new tech stack?”
“We just port over all the old features.”
When you tell a stakeholder what you’re going to build, odds are they’ll get excited. When you tell them that you’re going to shut down a feature, they often get scared. “What if a customer is using that?” Fair question, particularly if you have 5 customers. But if you have hundreds, thousands or perhaps millions of users the question becomes a bit more complicated.
There are lots of reasons to sunset a feature (aka “to kill” it). Some of them will be objective, some subjective and some personal (“We always hated that feature!”). However, to ensure we’re always making the best decision about whether to maintain an existing feature or move it to the bin we can rely on objectives and key results (Is there anything they can’t do?).
We build infinite systems
When I started my career software came in a box. It was finite. We had to literally print millions of copies of the software. This meant that, at some point, the software “ended.” Today software is continuous. It’s infinite. This is both a blessing and a curse. It provides us the opportunity to improve the software as often as we like. It also means we can work on a feature or an entire system indefinitely (another word for indefinitely is forever). With boxed software there was a clear definition of done or, at the very least, a hard deadline. With continuous software a feature is never done. We continue to work on it, improve it, and support it as long as it’s delivering value to the end user. How do we know it’s delivering value?
Behavior change tells us if we’re delivering value
We determine the value of a feature by measuring how user behavior changes once the feature is live. If a feature changes customer behavior for the better, consistently then it’s delivering value. The tweaks and updates we make should continue to improve those behavior metrics. Coincidentally those behavior changes are called outcomes (as in, outcomes over output) or more recently key results (as in Objectives and Key Results).
At some point, if we’re measuring key results consistently we may notice that behavior change has stagnated or perhaps dropped off or even stopped completely. If we couple this discovery with a little qualitative research to understand why we’re experiencing the dropoff we may draw the conclusion that this functionality no longer delivers value. It’s at this point that we’ve collected enough evidence to suggest the decommissioning of this feature. This decision is objective. It is cost efficient and it’s the right thing to do.
Infinite features, finite teams
Continuous software not only offers infinite opportunities to improve our products it also offers the ability to build, deploy and maintain infinite features. Sadly we don’t have infinite people to do this work. By using objectives and key results we can ensure that the work we’re doing – be it new feature development or maintenance of existing features – is always focused on making our customers more successful. At some point some features will no longer deliver that customer success. It’s at this time that we can make the evidence-based decision to kill these features.