To the untrained eye, James Harden has nothing to do with building software. Harden – a 10 time NBA All-Star and former MVP – is not only one a surefire future Hall of Famer, but is also one of the NBA’s most polarizing, dramatic superstars, having forced his way out of not one, not two, but three different cities over the last four years. Between his gaudy statistics, historic playoff collapses, and cantankerous off-court personality, he has been the subject of countless podcasts, talk radio segments, and general basketball fodder discussing his value as an NBA player. He has never, however, been discussed as an inspiration for Product Managers in tech. But in the wake of his latest forced exit, as we watch his former team blossom into one of the best in the NBA and his new team spiral into disarray, it serves as a great reminder that sometimes, the best new feature is actually just the removal of an old one.

For those who haven’t been keeping up with this NBA soap opera, Harden was a standout point guard for the Philadelphia 76ers last season, leading the league in assists while averaging 21 points per game and helping teammate Joel Embiid secure his first MVP. However, after a disappointing second round exit in the playoffs, Harden found himself entangled in a battle with Daryl Morey, Philadelphia’s President of Basketball Operations. While no one is entirely sure what happened behind the scenes, the general consensus is that Morey promised Harden some sort of handshake deal during last offseason’s contract negotiations, and when it came time to pay up, Morey reneged on the deal. The ensuing drama led to Harden very publicly declaring that Morey is a liar and that he would never play for the Sixers again.

After a standoff that lasted about three months, Harden finally got his wish and was traded to the Los Angeles Clippers for two first round picks and four players, all of whom would best be described as role players and NBA journeymen.

By simply looking at the statistics, a casual observer would think that the Clippers made out like bandits. Just last year, Harden was arguably a top 15 player in the league, averaging 21 points, 11 assists, and 6 rebounds. On the other side of the deal, the Sixers received four middle-of-the-road players, none of whom have averaged anywhere close to Harden numbers at any point in their career.

How, then, did the Sixers rip off six straight wins following the trade while the Clippers lost their next six? Why is the NBA buzzing about the Sixers as potential contenders for the championship, while the Clippers appear to be heading in the opposite direction? And what the hell does any of this have to do with software development?

The answer is the same to all of the above: sometimes, the best addition, whether it’s to an NBA team or a SaaS product, is a simple subtraction.

In the case of the Sixers, removing Harden from the equation was the key to opening up more opportunities for budding superstar Tyrese Maxey. In Harden’s absence, Maxey has been able to blossom into the NBA’s next star and the early favorite for the Most Improved Player award, improving his scoring from 20 points per game to 26 and doubling his assists from 3.5 to 7 from last year to this year. But in addition to its on-court impact, shipping Harden off to LA has also resulted in a massive improvement in the intangibles. While it might not be visible in metrics or statistics, anyone who has watched this team can see they are having much more fun this year as they enjoy the ball movement and drama-free environment.

The same is true for shiny, problematic feature areas. Most who work in software can probably think of a feature or three that they would describe as their “problem child.” These problem children can come in different forms, with each requiring its own special remedy, but I have generally found that it will come in one of three forms:

1. The Goldie Locks option: Can we avoid moving on completely by simply cutting down on the complexity of the feature and going back to MVP status?
2. The James Harden option: Do we sunset this feature, remove it from the product entirely, and risk alienating the small number of customers who rely on it?
3. The Tyrese Maxey option: Do we invest the necessary resources to properly support and enhance this feature?

Goldie Locks: Turning a Problem into a Role Player

The feature doesn’t always need to be James Harden, a future Hall of Famer. Sometimes, it’s more of a role player, but a problematic role player, nonetheless. These types of products never garner major attention from customers and never create a significant impact to the business, but somehow always seem to pop up at the top of Customer Support reports.

While these features often have great potential, if they are unable to gain traction with users, continuing to drag them along does a disservice to the engineers who have to support them, the CS reps who have to justify and explain them, and worst of all, the customers who have to struggle through them.

In these cases, going with the Goldie Locks option is often the best first step. With this strategy, we can remove the complex parts of the functionality to ease the burden on Support and Engineering, while still providing the core value of the feature to our users.

Instead of battling through bug fixes and band-aid resolutions, go back to basics to see if you can continue to add value without the headache, and use the resources you would have spent fixing those bugs on integrations or alternative ways to solve the core problem.

Best case scenario, your customers will be happy with the stripped down version. On the other hand, if customers abandon the feature entirely without the extra bells and whistles, then you can move on to the Harden option and get rid of it completely. And if customers start clamoring to bring back the old functionality, then maybe it’s time to go with the Maxey route and invest real resources into the feature. But first, see if moving the feature into more of a supporting role can get the job done. After all, role players are necessary parts of any winning formula, whether it’s a basketball team or a SaaS product, as long as everyone – customers, employees, and leadership – knows they are role players.

James Harden: Hall of Famer to Some, Problem to Many

Features with relatively low impact and low usage are easy to sunset or strip down. Barely anyone will miss them anyway. But what if you have functionality that a couple executives or customers – often very loud, high paying customers – absolutely love, but it doesn’t fit with your overall product strategy and is consistently draining resources?

Maybe it’s a legacy feature that was part of the original product, the one built by the company’s founders, and carries a certain sentimental value. Maybe you have a feature that was built specifically for one customer, and despite your best efforts, doesn’t seem to align with anyone else’s needs. Maybe, like Harden, the engagement numbers are pretty good on paper, but the underlying technology is a brittle house of cards, and the ensuing onslaught of bugs is causing a massive drain on Support, Engineering, and the customer experience.

Despite its its business value to a handful of customers, its sentimental value to a handful of executives, or its seemingly engaging vanity metrics, in these instances, the Harden option is often the best bet. Like with the former MVP, the distraction is often not worth the trouble.

For the executives or founders who might have a tough time parting ways with the feature, its our job as Product Managers to craft a compelling enough story that convinces them that a tough decision in the short-term will be better for everyone in the long-term. And if there are some customers who rely on the functionality, despite it not fitting with your product strategy? Then maybe you’re better off in the long-term without those customers, too.

Tyrese Maxey: Clear the Way for a New Star

But if a feature does align with your overall strategy, and solves a core customer need, then you need to do everything you can to clear the runway and let that feature blossom. Just because a feature has a lot of bugs or requires a lot of resources does not mean you need to ship it out of town – sometimes you just need to remove the noise around it.

Maybe the answer here will be in the tech debt that engineers can finally focus on now that they don’t have to support the other nagging problem children, or the UX debt that designers can now address because they aren’t constantly answering questions about how the old legacy features are supposed to work. Maybe customers will simply use the core functionality more once they aren’t distracted by unnecessary options and buttons.

Whatever the case may be, removing distractions and creating focus on core functionality that is aligned with your product’s long-term vision and strategy will benefit everyone, internally and externally.

We are a long way from declaring final victory on the Harden trade. It’s certainly possible that the Clippers turn it around and go on a long winning streak of their own, and it’s possible that this version of the Sixers flames out before realizing their full potential. But if my experience with sunsetting problematic software has taught me anything, I am guessing the trends we have seen thus far will hold. Addition by subtraction is a winning formula, and for that reason, I continue to Trust the Process.