Why you should stop focusing on adding just new features to your product

Related Articles

In my past life as a conscript soldier in Singapore, I learnt the importance of being lazy.

It was nightfall during an overseas training exercise, and the camp was a abuzz with soldiers getting ready for the next day. Suddenly the routine was interrupted by a shout — the S3 (staff officer for operations) wanted to talk to the battalion.

It turned out to be a tirade; a lecture on our carelessness. Apparently, many soldiers had been losing important equipment, which was disrupting training.

The singapore armed forces is mostly made up of conscripts Photo by <a rel=noreferrer noopener aria label= opens in a new tab href=httpsunsplash Com menglong target= blank>menglong bao<a> on <a rel=noreferrer noopener aria label= opens in a new tab href=httpsunsplash Com target= blank>unsplash<a>

We all knew the S3 was a nice man; someone who never lost his temper, but that night he looked irritated. He rarely addressed the battalion. This time he said:

“Let me tell you about myself. I’m a lazy person. In fact, I’m so lazy, I refuse to do any unnecessary work.”

He pointed out that we could have avoided the effort of finding lost equipment if we hadn’t lost them.

I recall being amused — did a senior staff officer just confess his laziness to an entire battalion? It was the military; we weren’t supposed to show weakness. I dismissed it as a roundabout way of reminding us to be more careful.

Avoiding complexity

Much later, working as a project manager/product owner, I stumbled upon Edmond Lau’s excellent article on the hidden costs of complexity, which reminded me of what the S3 said. I recommend reading the full text, but if I had to summarize it in three points:

  • Adding new (engineering) features = adding complexity
  • Complexity incurs hidden costs, such as more manpower needed to support the new features
  • Therefore, avoid complexity; design for simplicity
Complexity = bad Photo by <a rel=noreferrer noopener href=httppicsbyjx target= blank>picsbyjx<a>

About the same time, I read this adage:

“No code is better than no code.”

In other words, if you don’t need the code, don’t code it.

So S3 had been right! Unnecessary work was a burden to avoid. No code is better than no code. No work is better than no work.

These lessons struck a chord. I was managing multiple projects, most of which involved adding new website features. I realized I was adding complexity and incurring hidden costs such as:

  • The need for more customer support hours to answer queries about the new features
  • The need for current staff to spend time learning and maintaining the new features
  • Another point of failure in the customer journey

And all this was on top of non-hidden costs, such as money and manpower.

Not all the new features were unnecessary or complex, but I resolved to take a stricter stance on accepting new projects and as Lau says, “resist the urge to add more complexity.”

How do you know it’s time to STOP building new features for your product and only focus on what you already have?

* When Your Audience Tells You To
* When You’ve Run Out of Pain Points
* When A/B Testing Goes Wrong
* When You’ve Lost Sight of Your Purpose
* When You Have a “Minimum Lovable Product”
* When It’s Not Backed by Actual Feedback
* When Your Customers Don’t Know What You Do
* When the Product Ceases to Be Attractive
* When Money Isn’t Coming In
* When You’re Satisfied (aka: Never)

Feature bloat and cognitive bias

Adding more features results in feature bloat. Beyond additional complexity, the cost is obvious: wasted money, opportunity cost and poor customer experience. Bloatware is fast becoming a major problem, with telcos, laptops and mobile apps packing features that no one needs. Outside of software, businesses add complexity by making unnecessary products as well.

If the costs are obvious, why is feature bloat prevalent? Poor business decisions are likely the cause: companies are not selling the way their prospects are buying, or their market research wasn’t robust enough, leading to designing the wrong features.

Cognitive biases play a large role in these poor business decisions. For instance:

  • Sunk cost fallacy/escalation of commitment: Not removing an old, unused feature because a fortune had been spent on developing it.
  • Endowment effect/loss aversion: Similar to the above; overvaluing a current product because of prior ownership. This leads to being too precious about features and maintaining unnecessarily
  • Availability bias: Acting on a vocal minority’s demands for new features
  • Intervention bias: Product owners add new features to assure themselves of control, or even worse, prove their worth to stakeholders.

Preventing feature bloat

We can prevent feature bloat from happening in the first place with a well-defined product roadmap. How do we, as product owners, app designers and businesses decide what features are worth adding?

Before adding a new feature, consider:

  • Is the feature a solution to a problem that doesn’t exist? This was a common complaint about the Apple Watch, which reviews have labelled as “useless”.
  • What are the hidden costs of adding this feature? Do they outweigh the benefits?
  • Is my reasoning backed by solid market research, or distorted by cognitive bias?
  • Play devil’s advocate: why should we not develop the feature?
The apple watch a solution for a nonexistent problem Photo by <a rel=noreferrer noopener aria label= opens in a new tab href=httpsunsplash Comlukechesser target= blank>luke chesser<a> on <a href=httpsunsplash Com target= blank rel=noreferrer noopener aria label= opens in a new tab>unsplash<a>

Having structured procedures for adding new features also helps. Consider Agile frameworks such as Scrum, where the iterative approach helps to dodge potential high-cost, low-impact commitments. Extreme Programming also espouses courage — we need to be brave enough to cull unsuccessful practices in development.

We can also consider the opportunity cost of new features. Try viewing your product in terms of power law distribution: 80% of your revenue/signups/downloads come from 20% of your features — these are the core of your product. Therefore, the most benefit comes from focusing on the essential 20% of the features, rather than spreading yourself thin on new features that yield small marginal benefit.
Gaining hidden benefits instead

What should we put in our product roadmap then? If no code is better than no code, what do our coders do? Consider these alternatives to adding new features:

  • Pivot: coined by Eric Ries, pivot refers to “changing your strategy without changing your vision”. Companies can maintain an existing product while testing new strategies and making incremental changes to achieve the vision. This could mean launching a separate side product that doesn’t jeopardize the core product. Also see the different types of pivot.
  • Market research: your product may have previously unknown customer segments. Try looking at your product from different perspectives, such as first principles, design thinking or jobs to be done.
  • Improve current features: Remember the power law? Focus on improving the core 20% of your features for greatest impact.
  • Focus on customer service and retention: Customer acquisition is costly, whereas customer retention confers multiple benefits. Instead of adding new features, it may be more beneficial to reduce churn.

A good role would be Buffer with their transparent roadmap. They’re good at what they do, and don’t try to be anything else.

Lastly, you always have the choice of trimming the product. Beyond “no code is better than no code”, I’ve also heard:

“Good programmers write good code. Great programmers write no code. Zen programmers delete code.”

It may sound cheesy, but deleting code makes sense. By decreasing complexity, you reap invisible benefits — the opposite of the hidden costs mentioned — in the long run.

Tying it all together

Overall, it isn’t a good idea to have your product be everything to everyone — trying to please all parties is the key to failure. Instead, keep your product simple and dare to remove features that make little sense.

Now, whenever I consider a new feature, I think of that night with our S3, and how I can be lazy at the right time and refuse unnecessary work. Given the burden of invisible costs, the default answer to new features should be “no, unless…” rather than “yes”.

Perhaps that’s why smart and lazy people make good officers.

You should never stop thinking about or building new features. It doesn’t mean that you should have too many features in your product. Rather, you should always be on lookout for replacing some of the features that do not perform up to your expectations. If you feel you have too many features, you probably do, and likely most of them aren’t working. Re-evaluate them, but never stop thinking about new stuff. Innovation is the lifeblood of a product, so keep it flowing.

HomeCareersEducationWhy you should stop focusing on adding just new features to your...