Product Managers: Thank the Feature, Then Discard it!
In the world of managing products, sometimes you need to seek out features that no longer spark joy, thank them for their service, and then discard them.
There’s an ocean of amazing knowledge out there on how to become a rockstar Product Manager. You learn to empower cross-functional team, gather information, experiment, iterate and all that other good stuff great Product Management is made of.
But there’s one skill that gets very little love. Way way way too little: the art of seeking out and discarding features that are no longer needed.
Some of these were awesome features in an earlier stage of your business, others vessels of learning about your market. But now, they mainly incur different types of cost without providing significant upside.
Build, build, BUILD!
We’re taught that constantly shipping things is the only way to learn (yes, this is true) and that a good product development team endlessly cranks stuff out.
Leadership assumes the hallmark of a great team is how much they deliver net new capabilities. They even reward and incentivize that as a behavior. High velocity! GREAT!
We’re taught to assess the cost/benefit (or ROI) of a feature by tallying up of how many person days it takes to develop it vs. what impact it will have.
We get caught in the Build Trap.
What gets ignored are all the actual costs of shipping a thing. These come in many flavors, including:
1. Complexity
Every time you add something to your product — be it code, process, reporting etc— the overall complexity of your system grows. Even if the addition is well documented, it’s yet another factor to be taken into consideration when any changes are planned in the future.
Any pivots, rebrands, rearchitectures or other shifts you want to execute in your business, product, or technical architecture, become exponentially more difficult based on how many components (technical or otherwise) have to be accounted for.
You also pay a hefty fine for complexity when onboarding new employees. The more complex you allow your business to become, the harder it will be for any employee, individual contributor or manager, to fully grasp the big picture.
2. Bugs, Security and Maintenance
Anything you release into the wild will tie up a nonzero amount of people’s time and expose you to risks. Every second of available attention you have to allocate on fixing and maintaining, you’re not allocating on things that really move the needle.
The costliest mistake of all is leaving products or features without owners. For every single thing out there, somebody needs to own it explicitly. Even if it’s one of the many things they own.
Ownership piles on and distracts. It’s yet another potential reason why a team is unable to focus on their primary mission, stalling your growth.
3. Support, Sales and Process
There’s a world of cost out there beyond Product Development (tech + product + design). Every feature or product in your portfolio is another thing that creates customer support emails or calls. These suck up real time from real people and that generates real cost.
You also have to have processes in place to support everything out there. That is a real cost. Maybe the product has a manual onboarding process. Maybe it’s an awkward distraction in your sales collateral. There are always hidden costs you might not be accounting for.
4. Customer Perception and Competitiveness
If it’s a part of your suite, it’s a part of the whole that customers will judge you by, and that you need to remain competitive with.
At worst, disappointing features or products can be a major driver of churn. Minimally, they impact your brand negatively.
The last thing you need is to add unnecessary cognitive load on your customers.
5. Infrastructure
This should be the most obvious one. Pretty much anything you run costs money. Especially with the easy scalability of cloud platforms like AWS, it’s really easy to run up your tab without realizing it.
Some of these costs are straight-up COGS (cost of goods sold). They should absolutely be accounted for when deciding the viability of building something new (or keeping something existing alive).
Others are nastier hidden costs that only really seasoned people will know how to account for. They may seem innocuous in advance, but those are the ones that really end up getting you in the end. They will slow down your time-to-market, incurring opportunity cost and other means of grinding your ability to stay nimble to a halt.
Ignoring these will lead to some dreaded product footprint creep. Here are a few tips to prevent it.
1. Bring Marie Kondo’s Life Changing Magic of Tidying Up to the world of Product Management
Have a consistent process of asking yourself on every feature whether they “spark joy”. And by “joy”, I naturally mean revenue, profit, or other meaningful impact on a metric you care about.
If not, thank the feature for what it has given you, and discard it. Put together a plan for sunsetting it. More on this later.
Make sure you set the bar high. “OK” is not good enough here. Unless you’re some weird magical unicorn company, you’ve got some forms of scarcity to deal with: money, people, or time. Most likely all of them. Wasting any of these on B+ assets is a waste. You should deploy your resources and people on your A-game.
Don’t just look at product metrics. Make sure you cross-reference all data available in your organization. Examine sales pipelines (Salesforce), work management data (Jira etc), the marketing funnel, customer service tickets (Zendesk etc), accounts payable (Netsuite, Workday etc). You need to have a larger view of things to make decisions here.
2. Have a culture of get-out-of-market
Every company knows how to do go-to-market operations. When product is ready to bring something new for sales to sell, the symbiotic collaboration between product, engineering, sales, marketing, and customer support locks into formation like a flock of birds migrating south for the winter.
But when it’s time to end the journey of a feature… 🤷
Make sure your company embraces and understands the process of sunsetting things when necessary. Have a playbook for it. Evangelize viewing these as a natural part of evolution, not shameful failures.
Celebrate the fact that you’ve prevented unnecessary drain on the company, thus enabling something more existing to happen. Removing baggage is enabling growth!
3. An ounce of prevention is worth a pound of cure
Obviously the best results happen when mediocre stuff never makes it into production to begin with, right?
Just like projects only miss their dates when people don’t account for things in advance.
Lucky for us, we’ve figured out that unless you’re a wizard, predicting the future is darn tricky. Reality has a habit of not giving a hoot about your plans.
That’s why we experiment, and embrace learnings and change.
The thing with experimentation and learning is, that it’s highly likely that you don’t always like what you learn. We overlook this when we swap stories of successes, forgetting that they suffer from dramatic survivor bias.
The trick here isn’t to not do bad things. If you’re not failing, you’re not learning. Or you’re not taking chances.
The trick is to be equally prepared for failure as you are for success.
For every MVP, experiment, pilot program, proof-of-concept or whatever you conduct, make sure you’ve got a plan for every scenario. You should also have very clear definitions of what constitutes an end-state that triggers a failure. Then, you should have a plan in place to get rid of everything created with it (except any learnings).
This includes:
- Code + database
- Process
- Reporting
- GTM collateral (landing pages, microsites etc)
- Customers
The last bit is extra hard! People don’t like to give up something they received. Especially if you contractually obligated yourself to delivering it.
Anything short of that, you just ended up adding to the footprint and incurring an in perpetuity cost.
4. Make sure the whole team is on the same page and don’t over-commit
In the Lean age, a common problem that creates infinitely supported mediocre products is Product Development creating experimental products that Sales goes around selling as full-blown mature products.
As a calculated tactic, this is of course perfectly fine. Who cares if the engine room is populated by trained monkeys if the facade is shiny and squeaky clean.
But the risk is over-committing. If the Product Development team is building a product to learn, it’s really risky to sell it in a way that creates hard long-term commitments!
In almost every single company I’ve ever worked at there have been products kept alive for the sole reason that there were a few customers that they had been sold to and the company was unwilling to risk losing these customers by shutting something off.
Until you’ve fully validated the long-term viability of a product or feature, do NOT sell it with a long-term commitment.
Make 100% sure the whole organization involved in go-to-market is aware of the status of a product.
5. Beware of the sunk cost fallacy
The past is the past. It doesn’t matter if you invested a lot of time, effort and 💰 on something.
If the future projections don’t make it viable, you just have to write that investment down.
If you can balance the fine art of how and what things to build with the dark art of when and how to sunset things, I can guarantee you’ll have an easier time scaling than most. A lot of companies hitting hard times growing their revenue beyond $50MM are unknowingly trying to run with a mountain strapped to their back. Their CEOs are running around screaming after lost velocity and the agility of early days. Yet, nobody is shining a light on the cost of running all the gazillion things the company built when ship, ship, ship was the name of the game.
Sunsetting products or features is never fun or easy. Twitter has met a huge backlash whenever it’s restricted it’s API use in favor of its 1st party offering. Pinterest users’ workflows were hurt short term when the company removed its like-button in favor of a simplified user experience. I won’t even get into Google Reader.
There will always be some form of short term repercussions from removing things. Customers will get angry. Some metrics may point down for a while. Employees will bemoan losing a thing they’ve worked on.
These are natural, but usually temporary problems. As long as you have a plan and are fully able to articulate the rationale of the choice, you’ll be fine.
There is a saying among engineering that rings somewhat true:
I would like to propose a bit more pessimistic, yet far more accurate version to help us keep it real:
Most features are a liability, all code is a liability.
Now, go find something in your portfolio to kill!
Like What you Read?
- Join my Email Gang on TinyLetter! One weekly email, no spam, no ads.
- Please join the discussion in the comments below!
- Read more about why I’m writing these posts:
