This is the end…or is it? How to manage the end of a product’s life cycle
When is a product born? From an idea? From the first product spec? The beta version? Launch day? While we can discuss the merits of each — all are valid starting points. But what about the end of a product’s life? When does that happen? Does it die a slow death by neglect? Is it forever relegated to a life of “maintenance”? Maybe there is a plan to sunset the product or repurpose it for new projects. The point is, the end of a product’s life cycle is a bit more ambiguous. In fact, it’s a conundrum faced by many — how you handle it largely depends on company priorities, processes, and most importantly, culture. I would argue that this last point — having a culture of user empathy spanning engineering, product, design, QA and product support (that’s me!) — is key to maintaining the integrity of your tech organization.
As members of the BuzzFeed Tech Team, we are very aware of the shifting media landscape moving like quicksand beneath our feet. What makes us successful is our agility and ability to respond to this ever-changing environment in step with the rest of our company. Practically, this means we are constantly re-organizing our teams to reflect these changes in priorities.This is especially problematic for legacy products that may be left behind amidst restructuring, in times of re-architecture, or when moving to a new stack.
At BuzzFeed, we’ve taken several approaches to managing the end of life for our legacy products. Some methods work better than others and I’m here to share a few of these experiences and what we’ve learned.
Method 1: Stop & Drop
In one case, we put development on hold for our suite of translation tools. This was a concerted decision to shift focus onto different product areas. Since these tools were in a stable condition, our engineers were able to move onto new projects without much distraction.
However, nothing is built in a vacuum and when bugs arise, we have one engineer that is able to debug these issues. The risk with this approach is known as the “bus factor”. If you keep product knowledge restricted to one set of individuals, this means they are inherently responsible for the product’s outcomes even when they are no longer tied to the product in an organizational sense. Additionally, they may eventually leave the company and this knowledge shouldn’t be lost to the ether.
So, how do we counteract this? By sharing knowledge. “The more you know” — a truly inspiring and relevant adage, thanks NBC! How best to share knowledge? Documentation is one way. Build it as you go. Have fun with it, make fancy user guides with loads of gifs, maybe some flow charts, go crazy! Have a documentation day team outing, shuffleboard anyone?
Another way? Spread the knowledge across tech. Here at BuzzFeed we have a weekly “tech talks” series where anyone in the organization can present a talk about a product they’ve been working on to encourage collaboration and sharing of insights. And sometimes there’s beer, that helps.
Finally, make sure everyone on the team, no matter their capacity, is well-versed in the infrastructure, user requirements, and expected behavior of a product so everyone can tag-team if an issue arises.
We’ve made great strides in improving the product development and engineering experience across the tech organization. We use a consistent set of technologies and approaches that reduce the on-boarding effort for any single service. This makes it easier for engineers to observe and debug any service, even if they haven’t yet worked on it.
Having the ability for anyone to triage bugs on products in “maintenance mode” is key to maintaining trust and reliability in your products and also maintaining a positive relationship with your stakeholders.
Method 2: The Slow Burnout
Sometimes you build an experimental product, which over time, accumulates a diverse set of users who incorporate it as part of their daily workflows. Great! You built a product and it’s super useful. However now, the team that built it is dispersed. But wait! Those same users are requesting features and enhancements but no one is left to work on the product. So what do you do? In this case of this tool, an asset library, it was up to product support to man the help channel and communicate these requests to…whom? That was the challenge.
The product lacked engineering resources and decision makers as this tool was orphaned during a recent re-org. Eventually the volume of requests forced our team to reassess the current usage of the product. Finally, we decided to move some of the utility from the old product to a new product that would be actively maintained.
In this scenario, it would have helped if there were established engineering and product owners that persisted amidst the various re-orgs. We’ve made efforts as an organization to keep track of who the resident experts are on certain products. It’s a good idea to have these discussions on accountability when a re-org is anticipated so that when a future decision needs to be made- you know who is responsible.
Communicating to users that you are not going to work on a product is JUST AS important as actually fulfilling their requests, this promotes transparency and trust.
Method 3: Click Refresh
Products break, there’s no avoiding it. Usually you fix what’s broken. However, when you are rebuilding your backend architecture, it makes little sense to fix what’s broken in the old stack. A better idea is to move the product over to the new stack. However, when the light at the end of a tunnel is far away and you have other high priority tools that need re-architecting, it means some products are neglected.
This was the case when our A/B testing headline tool broke. Every editor in the organization was using this tool. It broke frequently. We would fix it frequently, but there came a point where we knew we had to kill it or rebuild it in the new stack. Eventually we sat down to investigate if this was a worthwhile endeavor. Turns out total post views increased on average by 31% so we decided to rebuild it. With a sting team and a deadline, we had the MVP out and ready in a matter of weeks and it works fantastically (increased total post views by 35% and resolves tests in 20 minutes compared to 48 hours).
While the end result was extremely positive, it took us a while to make a definitive decision- kill or rebuild. Making these difficult decisions at the onset of a re-architecture period will improve the confidence of the users in your product, so that they can set realistic expectations when making requests or reporting bugs. Even if you put the decision on hold, communicate this to your users. Explain the situation, lay out a timeline- they will understand.
So, what did we learn?
The end of a product’s life is not always so clear cut. Some approaches to managing the end of a product’s life cycle work better than others, but what we’ve learned is that making a decision is the hardest part and communication is essential.
Creating a culture of open communication and transparency is the cornerstone of user empathy. Be honest and upfront with your users, no matter what decision you make at the end of a product’s life cycle. If your tool is going into maintenance mode, TELL YOUR USERS. If your product is going to be sunset, TELL YOUR USERS (and hopefully provide a workaround or make a really good argument for why it’s no longer useful). If the product is going to be repurposed, awesome! But still, TELL YOUR USERS. Most importantly — use what you build. There is no easier way to empathize with your users than by becoming one yourself.
My point is, remember why you built this product and who you built it for. Those users don’t go away even when priorities shift. You’ve likely created something totally amazing that they’ve adopted as part of their daily lives, so feel great about that. By following these steps, hopefully you can maintain trust and faith in your tech org and most importantly, create a culture of user empathy. I promise it will pay off!
