Building new features in your product can seem simple at first.
But building features that really work for your customers is an incredibly difficult process, and one that requires stepping back from the superficial. Good features come from focusing on the customer and their problem before ever touching a line of code or a pixel of the user interface.
How a bad feature begins its life
We’ve seen plenty of features progress from inception for the wrong reasons. Here’s a common example of how bad features get off the ground.
They don’t start with the customer
Often, bad features will start from an internal discussion, rather than a genuine customer need.
They’re perceived as being easy to implement
Sometimes bad features seem easy to implement and on the surface they may look small and focused.
They’re not designed thoroughly enough
It’s easy to draw a screen – the screen that customers will see when this feature is working exactly the way you imagine it to. This is the most obvious piece of the design process. But good features are not born out of designing a single screen.
Too many compromises are made in development
If there’s a lack of design and thought early on, the development of the feature inevitably suffers. Decisions that would normally come easy and naturally to the engineering team, become challenging because the high level goals and vision for the feature are not clear.
What are the warning signs of a bad feature?
Bad features cause problems because they’re not thought through deeply enough. More often than not bad features start with failing to think about the “Job To Be Done” the customer is hiring you for.
It is sometimes possible to build good features without extensive customer research and user testing, but it’s generally more difficult. When you rely solely on your instinct and empathy for your customers, sometimes you can get it right. But chances are you won’t.
Even when you’re building something with the best intentions, it’s still easy to execute poorly on an idea for a feature. You can forget to design key elements of the user experience that are essential to the product feeling complete.
The closer a feature gets to production, the easier it gets to evaluate whether it’s a winner or a loser.
The announcement of the feature is difficult to write
When there aren’t well defined reasons for building the feature nor a clear target audience, it’s hard to articulate how it could be valuable and helpful to your customer base.
The feature is received by customers with a mediocre response
With an unclear announcement, a muddled development process, and a lack of vision for the feature, the response from customers will most likely be underwhelming. Not only in the audience reaction on social media, but in actual usage – customers don’t engage with the feature and they don’t see the need for it.
When a feature wasn’t built for a specific pain point your customers were experiencing, they don’t find the need to use it. You’ve built a feature for the wrong people, the wrong problem, and the wrong reasons.
How to avoid building bad features
Have a clear idea of what job the customer is hiring you for
Most importantly, does this feature deserve to exist? Why are you working on it?
If you’re embarking on a new feature primarily because you’ve seen a competitor release something similar, then you probably haven’t thoroughly considered or even identified the problem you’re trying to solve. If you’re jumping into a new feature because it seems like “it wouldn’t be too hard to do” that’s great, but does it actually deserve to be built right now?
We utilise the “Jobs To Be Done” framework extensively to focus on the problems we’re being hired to solve. This means we’re building features that form part of a logical workflow that helps our customers. We also use live chat for continuing communication with customers – we regularly ask them questions, but often they approach us requesting changes and improvements that we’re always evaluating against our own roadmap.
Write a simple explanation of why this feature is valuable to the customer
Amazon famously writes their press releases for new products before they start working on them. We’ve always found this to be a helpful process to go through before embarking on building new features – write at least a few sentences to outline why customers will benefit from the work you’re doing.
Aside from helping with the product development process, writing the press release first helps with the marketing and sales when the feature finally hits production.
Design the screen before and the screen after
Most features are part of a flow. Rarely is there just one static screen to design. Run through the feature step-by-step to find out how you arrive at the feature, what happens when you interact with it, and where the user goes after they’ve used the feature.
Using a prototyping tool like Marvel helps encourage you to think about how the feature fits into a flow – you have to design the interaction and go beyond just a static screen.
Design the empty state
It’s easy to think of a feature in use with all the data and information in the screen when everything’s fully set up. But many users never get to your “dream” state – they’ll likely see the feature when it’s not yet being used. Have you thought about the feature when it’s not being used? Designing the empty state of a feature can help encourage users to interact with the feature in the first place.
Design the error state
Things don’t always go to plan. Considering what happens to a feature when an API is throwing an error or when the user’s internet goes offline helps ensure the feature feels solid and reliable.
It’s easy to forget the error states when designing in a protective environment (like on a local machine with super fast wired network access), but when your product is used in the real world real problems happen. It’s easy for an entire product to start feeling brittle and fragile if you don’t consider error states and fallbacks.
Good features start with problems
If there’s one sure-fire way to spot a bad feature, it’s when the value to customers isn’t immediately obvious. Whenever you’re struggling to explain why a new feature is going to help your customers, stop and run through these points to check you’re not building for the wrong reasons.
Good luck, go build something great!
