Build Only What You Need - The Unneeded Feature

Creation of unnecessary code is not just attributed to enthusiastic engineers, often features are designed and added to a product which are neither wanted nor needed by the clients. Adding the right feature will add value to your product, but misjudging and adding the wrong feature can result in damage to the product and clients demanding the previous version of the product be reinstated.

So why would we do this? Why would we spend our time creating something that no one needs?

To help illustrate, we'll use an example of a low frequency automated money transfer feature, similar to a real example of a feature that was not needed, and take a retrospective look at what we could have done to detect this earlier in the process.

Why Do We Create Unneeded Features?

There are many reasons for pursuing a weakly justified feature. That reason could simply be ‘It’s a great idea’, ‘Our competitors do that’, or sometimes it is just the pressure to deliver something.

Similar to the creation of additional code at the engineering level, there are no bad actors here deliberately trying to waste time.
The issue is an eagerness or urgency to progress, mistaking writing code as progress, and placing an output ahead of an outcome.

Value?

Features add value to the product, because a client values the feature. High value features remove pain points for clients and improve their lives. What value is the feature intended to deliver? It’s relatively simple to retrospectively measure the success of a feature. Retrospective measuring isn’t ideal, you may hopefully do some learning, but it’s a harsh lesson, and we’d be in a better place if we were able to discard low value ideas earlier rather than later.

The value add requires an honest evaluation from the organisation, for example would a takeup by 20% of users be a success, or possibly even as low as 1% of users. This value will vary between organisations and vary again for each feature.
In some cases zero value is easy to detect, the take up of the automated money transfer feature was zero, not a single user. Even two years after the release the takeup remained at a steady zero. How did such a feature come to be released at all?

Cost

So what’s the problem, there’s been a bit of effort expended on an unused feature, mistakes are made, we can hopefully learn and move on… Well, it's not quite so simple to just shrug aside and move on, there are consequences.

• Delay in releasing higher value features. Your engineers could have been working on another feature which your existing clients actually needed, or a feature required to attract new clients

• Complexity. Complexity breeds bugs and confusion, both of which need to be avoided. Bugs.. obvious enough why we want to avoid these.

• Confusion. The confusion created by complexity will not only impact your engineering team, but your support team, your product team, and your sales team, but worst of all the confusion will spill out externally to your users (more than likely before the confusion is noticed internally). Confused users are not happy users.

• Team morale. Engineer apathy, working around features which are known to be unnecessary does not make an engineer feel they are doing something worthwhile.

• Time, a clear by-product of additional complexity, measurable in all departments involved with the feature;

Prevention

How do we prevent unnecessary work on unnecessary features? Validation of the feature is the answer. We’ll take a retrospective look at the automated transfer feature referenced earlier and suggest a few ideas that could have saved the team a lot of trouble.

User engagement

Engage with the users. Have the users expressed a need for this feature. Does this remove a pain point? Beware user feedback may not be entirely accurate, have the users understood the need and not the want? Have you inadvertently led the users?

Further validation - manual

In some cases it may be feasible to test out the feature prior to the coding stage. The automated money transfer could have been offered to a limited test group of clients, with the product team performing the task manually. There are a couple of really useful data points to observe if using this technique: The first data point, did any clients want to take part in the trial, are you addressing an obvious need or did you need to work hard to sell the idea? The second, when doing this test, it’s key to seek feedback from the users. What was their response?

Light touch product changes

An alternative to the full manual approach would be to provide the illusion of the feature being implemented and observe client takeup. We still want to keep the implementation as light as possible, so we could offer up a UI which allows users to opt-in, captures the payment and scheduling needs, but does nothing more. The transfer is still performed manually, so we’ve deferred the effort of implementing the feature until we are convinced of the users’ need for this function. As with the manual version, we keep the test group small so as not to overwhelm the team - a form of A/B testing. We can adjust group size as we see fit, perhaps including different client personas to fully explore the need of this feature. It’s important that you remain in control of the validation process, scale the group as you see fit, but beware of trying to prove yourself right over valuing the feedback from others.

Build on your learnings

The learnings we have taken from the client engagement and the experiments provide valuable insight. We can make an informed guess as to the value add that would be provided if we were to go to implementation. Or, we may have learned that we had missed the mark slightly and the shape of the feature needs to change. Or, we may have learned that the need simply does not exist and we end our investment in this feature and move on.
Whatever we learn, we can be confident that we’re focussing on the needs of our clients and that will lead to more value.

View this article on our Medium Publication.