Should you build it, or abandon it?
Tags: features, planning, technology
Published: 2021-04-29 21:28:43

Over time a product will accumulate many features. Some are core features. Some are proofs of concept that have yet to be validated. Some are proofs of concept that failed. Some were once extremely relevant but are no longer fit for purpose. Some are a work in progress.

The point is: features accumulate, and when it comes to determining their relevance and maintainability, no two are the same. But one thing most features _do_ have in common is that, at some point in time, someone thought they were a good idea.

We've all maintained poorly designed features. If we've been lucky (or maybe unlucky, depending on how you look at it), someone else was responsible for them. We've all looked at something and thought, 'Who built this, and what were they smoking?'

Hindsight is a wonderful thing.

And so the question presents itself: when confronted with the option of building or not building, of maintaining or abandoning, how should you proceed? How can you avoid becoming the guilty party at the other end of the 'What were they smoking?' jibe?

This question is particularly pertinent for early-stage companies, where resources are considerably more finite and the potential impact of every feature (positive _or_ negative) is considerably larger.

It can be helpful to take a step back and answer two simple questions as bluntly as possible:

* Did users ask for it?
* Are users actually using it?

Or, if the feature has yet to be built:

* Have users asked for it?
* Have we validated that they actually need it?

The answers to those questions can help you categorise the current state of the feature; it may be: **Mission Critical**, a **Stroke of Genius**, a **Waste of Time** or a reminder that, often, **Vision ≠ Reality**.

![A graphic with four quadrants, asking on the X axis if users asked for a feature and on the Y axis if they are using it. Quadrants are labelled as follows: top-left is 'Stroke of Genius', top-right is 'Mission Critical', bottom-left is 'Waste of Time' and bottom-right is 'Vision Does Not Equal Reality'.](https://blog.maidment.dev/uploads/ff4fd53b-b1f5-4bbe-9bf4-abd8b885980b.png)

The obvious takeaway may be: _Spend most of your time building Mission Critical features and have game-changing innovations_. However, it is important to understand that other types of features will end up in your product and to be realistic about your ability to consistently innovate.

By understanding the qualities of each quadrant, and how a feature may be masquerading as a different type, this process becomes easier.

## Mission Critical features

These are the features your users have asked for, you have duly built and everyone uses. They are the bread and butter of your business and should be no-brainers. If you are a car manufacturer, these features are engines, airbags and steering wheels.

The decision to build these features comes from a combination of thorough market research, common sense and (if you are doing things right) dogfooding your own product.

However, as obvious as these features seem, it can still be worth challenging your assumptions about them. Especially if they are the product of well established received wisdom.

Do they represent an extremely ineffective way of doing things that your users have come to accept as an inevitable part of life? This is a hard question to answer, as it requires really thinking outside the box.

If the answer is 'yes', then also ask yourself whether an opportunity exists to remove the feature (it may actually be a **Waste of Time** that people have become accustomed to) or, even better, make a radical departure from the norm and disrupt the status quo by evolving it into a **Stroke of Genius**.

As the quote often attributed to Henry Ford goes:

> 'If I had asked people what they wanted, they would have said faster horses.'

## Stroke of Genius features

When you shake up the industry and create something no one realised they needed, you have a **Stroke of Genius** on your hands.

Features (or often, entire products) that fall into this category usually take two forms: entirely new inventions, and things that are suddenly possible because of a larger paradigm shift brought on by those new inventions.

Most of our innovations will not fall into the _new inventions_ category. As much as we like to think that our idea will change the world, very few ever do. So it helps to be realistic about the scope of whatever you are building.

Much of what we build instead rides the waves of new inventions. At the moment, the invention that many products and features piggyback off is the Internet. Many industries have been disrupted in a way that no one ever thought possible, largely down to the new abilities the Internet brought with it. Banking, shopping, photo processing, TV and film are just a few industries that now operate in entirely new ways.

So apply that thinking to your own product. Maybe you'd love to build a widget that helps to automate people's lives. The technology to build it has always been science fiction (maybe some kind of advanced AI?), and no one has asked for it because humans have been successfully living their lives for hundreds of thousands of years without it. Then suddenly the technology to build it becomes available; you're ready to change the world.

Simple, right?

Perhaps not. With a product no one has asked for, you will find yourself fighting against years, decades or centuries of established status quo. You'll have to convince _everyone_ that they've been doing it wrong all this time. And no one likes to be proven wrong.

Just because you build it, it doesn't necessarily follow that they will come. You may even find building the feature to be the easiest part of the process, with huge amounts of time, effort and money required to run a successful awareness campaign to obtain even your first few hesitant users (electric cars might be a good example of this). This is where a **Stroke of Genius** risks becoming a **Waste of Time**.

To combat this, aim to work in MVPs and spend the least time possible to get a workable version of an unvalidated idea out into the world. Take feedback, iterate, but don't commit huge quantities of time to it. By operating in this way you can run far more high-potential experiments in a given period of time and will feel less guilty about axing one of them when the numbers don't add up.

It is also worth keeping perspective on the uniqueness of your idea. If it's been possible for a while to build your feature and no one in the market is currently doing so, this may not be an indication that you have a unique idea, but instead that it is a _really bad_ idea that others have already tried and failed at. Take this into consideration when deciding how much time you're willing to sink into an MVP.

## Waste of Time features

Your users haven't asked for the feature, you built it anyway and they aren't using it. This is a waste of your time and resources, and such features will always benefit from being put on hold.

A **Waste of Time** _may_ be an unrealised **Stroke of Genius**, but probably not. Even if you are certain that you are onto something—something visionary and years ahead of its time—it is still worth limiting the time you spend on these features while you carry out market research (which may take the form of user feedback loops) and explore the implications of an awareness campaign.

For anything that falls short of _game changing_, do not be afraid of culling these kind of features from your product backlog before anyone gets a chance to build them. If an idea truly is worth building, you won't be able to keep it from reappearing time and time again in the backlog.

## Features where Vision ≠ Reality

What a user _wants_ vs what they _need_. Features that fall into this category are those that are prescribed to be essential by users who do not yet have a use for them. This is sometimes due to ignorance, sometimes wishful thinking.

These features may present themselves as being **Mission Critical** due to received wisdom, especially in industries that have not recently been disrupted.

Suppose your company builds an advanced web analytics suite. You came from a background in Big Marketing where this was an essential feature. But your clients have ended up being mostly small businesses. Like you, the folk at the small businesses are thinking big; they dream of the game-changing insights you might help them uncover. But in reality, they have almost no data for you to work with and all they really need is a way of correlating banner impressions with online sales.

Features that fall into this category may also be the product of a vocal minority. If those taking part in your market research do not accurately represent your target audience, you may end up building 90% of your product for 10% of your users. Beware those who shout the loudest, and try to avoid launching into Build Mode as a knee-jerk reaction to every shiny new feature request.

## Start with the obvious, then experiment

When you are trialling new ideas or deciding what to do with old ideas, objectivity is key.

Build the obvious **Mission Critical** features and spend the time needed to validate your **Stroke of Genius** ideas. Work in cycles and advance your bold ideas a bit at a time, doubling down on them when the data shows you're onto something, and cutting your losses when it's obvious you made a mistake.

Always avoid the temptation to build shiny and complex things where **Vision ≠ Reality** just because they excite you, and make a habit of frequently—and brutally—culling unvalidated **Waste of Time** ideas from your backlog.

As a business _and_ as an individual, you only have so much time and money, so use both wisely. Keep it simple, triage features with a detached objectivity and avoid the obvious traps.