When we talk to teams about Progressive Delivery they are often most interested in learning how they can move faster without introducing technological jerk for their users. They want to innovate, but realize they also want to build the right thing for the right people at the right time. 

We love this. 

However it’s also worth mentioning there is an upside down world to product delivery. Though it does not have to be scary and evil like in Stranger Things, sometimes it can be. This upside down is seen and entered when we make the decision to remove a feature or product. In software delivery terms, we refer to this as sunsetting. In the book we use the following description:

The reference paints a beautiful picture where we gradually remove features and products like a beautiful sunset providing a user with a delightful experience as the feature slowly sinks below the horizon. 

In an ideal world, the user is afforded the time and guidance to adopt the new workflow, migrate their data, and say goodbye with a sense of closure and completeness. They are then ready to embrace the new features, workflows, button colors (design) with all the excitement of a toddler discovering a glockenspiel. Because, as builders, we have hopefully built the new features to offer greater value, reduce toil, and increase joy for the completion of their task.

The road to innovation is paved with good intentions; and often the substrate underneath is the user experience that has been ripped away from the white knuckled clutch of a group that will recall the day the feature disappeared with greater scorn and longing than Author Dent when the Vogons destroyed Earth.  In some cases this can cause such strong emotions people will build entire websites dedicated to the devastation.

“Valid” Reasons to Sunset Software

The decision to sunset software is likely to be a point of contention, but here are some popular rationalizations:

• No one uses the feature: This is possibly the best rationalization that I have ever had for eliminating a feature/product. Of course the caveat is that ‘no one’ has to be validated to mean literally users = 0
• Cost to serve (CTS): The cost to provide the feature is too great. This could be as extreme as the cost to provide the feature is greater than the amount that users are willing to pay, but more likely means the business is not meeting the target for margin on the feature and is seen as a drag on the business.
• Code is harmful or broken, and too costly to fix: This often occurs when external dependencies change. Examples of this are a deprecated API, SDK, or protocol (TLS, I’m looking at you).  
• Newer features or workflows: This is unfortunately the most common rationalization and often presents the greatest challenge for positive user experience. The goal is usually to provide more efficient methods to reach the same outcome. However, without proper preparation and planning for the transition, users often feel the ‘new’ experience is not an improvement.

Regardless of the reason you may have for sunsetting the feature or product, there are ways to reduce the impact and harm to your users. 

Staging the Sunset: A Communication and Observability Framework

It is important to acknowledge that for some people in some cases regardless of your best intentions, sunsets will be difficult. People can become dependent on a feature or workflow and as builders we may not always have a full understanding of how users have creatively adopted our software. But we can use tools to observe and measure usage and even infer the user experience. 

Observability tools (Honeycomb.io, Datadog, Dynatrace, etc.) can provide valuable insight about the frequency of use of a particular workflow or portion of code. Even providing insight into the latency a user experienced or the percentage of users that start a workflow and never finish it. Instrumenting features to gain this type of insight into user behavior allows for more informed decisions around which parts of your product or service are most heavily utilized.  These are likely the parts of your code you should be most cautious about changing or features you should do the most planning for when updating or removing.   

Once the decision has been made to remove a feature or End Of Life (EOL) a product, the most important step is to communicate with your users. Ideally, you plan the communication in stages that map to a gradual progression of feature sunsetting.  

A common framework for this progression looks like this:

Starting from General Availability (GA) when your feature or product is available to everyone the first step in sunsetting is to stop selling the feature or product. This is also a great time to communicate the planned timing and progression of the rest of your sunset or EOL process. The following stages are End of Support and then removal of code. 

For features and products with established user base or Enterprise scale customers there is often an Extended Support period required depending on contractual obligations or customers that are willing to pay increased rates to avoid moving to a new product or workflow. 

At each stage communication is a superpower in maintaining positive user opinion. And your observability tooling is the key to understanding actual usage and which users/customers may require additional communication to help them move to the new version or reminder of the scheduled end of the functionality. 

The type of communication will vary based on the type of software you’re building and the expectations of your users. For Enterprise software this could be email and a call to the customer from an Account Executive. But for a video game this could be an in app message or channel broadcast on a Discord server. The key is to know your users and how best to communicate. In the case of sunsetting, it is best to assume that there will always be users that need a little extra incentive or nudge to move to the next version or new workflow. Communicating directly with those users can help them understand the urgency and also allow them to feel valued. 

Technically, it is just Rayleigh Scattering

Sunsets in nature are so amazing due to a physics principle known as Rayleigh scattering. This is the scattering of light by particles much smaller than the light’s wavelength (like atmospheric molecules), causing shorter blue wavelengths to scatter more than longer red ones, this means that during the day the sky appears blue a at sunrise and sunset as more of the blue wavelengths are scattered the sky appears more orange and red.

To achieve the equivalent moment of zen on the technical side of your software sunset, feature flags can provide an excellent mechanism of feedback and control that using the inverse of the process for rolling out a new feature you can progressively remove access to a feature or product to a select cohort of users. 

Leveraging a Feature Management platform (LaunchDarkly, Statsig, Harness, etc.) you can integrate the progressive removal with observability tooling as well as Marketing tools for communicating with your users. This also has the added value of providing visibility across teams internally to understand what a user is experiencing at a particular stage in the feature removal.

Green Flash! (with the right conditions)

While some software is worth the investment to keep running without changes, most software is not. Changes in hardware, operating systems, integrated applications, or just people stop coming to your store to rent VHS tapes. As software has eaten the world, the rate of  change is only accelerating and it is increasingly difficult to find aspects of our lives not impacted by software.

When the sunset process is handled with meticulous care—when you have successfully guided your users to the next version and minimized harm—you achieve an outcome as rewarding and rare as a meteorological wonder. There is a meteorological phenomenon called a ‘green flash’. As the last sliver of the sun drops below the horizon there is a flash of green light due to atmospheric refraction. It is as breathtaking as it is rare.
If we take the time to observe and communicate with our users we can create the right conditions for them to appreciate the old version and embrace the new—a green flash sunset.