Building new features: it's easy to add, but hard to take away

In a previous post, I talked about how product teams should focus on solving their own customer's problems in a really effective way, rather than building a swiss army knife by bloating your product with features that your competition has. This post elaborates on that.

Product people often have a bias for action, which, on the face of it, is great.

These people not only want to deliver on business outcomes but also make a positive impact on customers's lives - sounds dreamy right?

Even when the going gets rough, they have a laser-like focus to create experiences that are right for their users (I like to think of PMs as Samwise Gamgee from LOTR - always when called upon, supportive and willing to take a back seat when close to the finish line).

So innocent... (source)

But beware. This might be obvious, but it's far easier to add new functionality or features to your product than it is to take it away.

There are many costs to adding new features to your product:

  • Cost to conduct discovery, research, document, and share

  • Cost to maintain new functionality over time

  • Cost to train up support to deal with customer issues

  • The opportunity cost of building X over Y (lost outcome)

  • Cost to market and launch

  • Some colleagues or departments may be wedded to this feature (relationship cost)

  • Cost of additional testing required before releasing (for launch and ongoing)

  • Cost of having to refactor at some point down the line

Despite all of these costs, I feel many PMs (and squads to be fair) have a bias to the shiny new thing, rather than improving what you already have. And if you do decide to build a new feature, without the necessary groundwork, it's likely to fail. 72% of new products or services are likely to fail to deliver on expectations.

Once you build something, and it's out in the wild, it can also be difficult to remove. Maybe a handful of customers get really high utility from this feature. Or certain colleagues think it's the best thing since slide bread. Or maybe it's tightly integrated into the code base, and it's a can of worms to remove. Humans also suffer from loss aversion - "losses loom larger than gains" as Kahneman & Tversky pointed out in 1979.

So despite it being easy to add new features, most of the time they fail. Quite an interesting paradox!