How bad features are born

Spot bad features before they make it to your customers

Avoid building bad features

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

The wrong way to get ideas for features

Often, bad features will start from an internal discussion, rather than a genuine customer need.

They’re perceived as being easy to implement

Features can seem easy to build at first

Sometimes bad features seem easy to implement and on the surface they may look small and focused.

They’re not designed thoroughly enough

Jumping into development too soon is dangerous

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

Too many cooks can spoil the broth in development with a lack of design

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

A blank page is a sign that you do not know why you built the feature

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

If customers do not care is it a good feature?

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

Jobs to be done helps build better features

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

Write the press release first

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

Design a flow of screens rather than just one screen

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

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

Design the error states

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!

Subscribe to the GoSquared newsletter.

Join 15,000 people. Get our latest posts delivered to your inbox every week.

  • Tabitha Grayson

    I really enjoyed this article.

    You can do your research, though, and customers may not like the new feature. Every time you put something in front of an audience it can fail, especially when the change is a big jump forward.

    A/B testing helps. If the change is an improvement, you know by how much. If it fails, you learned something new and your next feature will be even better for it.

    While bad results are painful, the deeper audience knowledge and skipping the bad features makes testing well worth the pain.

    Some shameless self-promotion… I write about this in more detail in my book “Six Steps to a Winning Website” – https://www.amazon.com/dp/B01KPERHM4

  • Hi Tabitha, thanks for sharing your book – it looks like a highly relevant read. Thanks also for the kind words on the post.

  • John Henry Müller

    Great post, James!

  • Thanks so much man! Hope you’re well, cheers for stopping by!

  • I worked for a startup with a large development team that added more and more features. The problem was it wasn’t based on the needs of customers, who weren’t using existing features. It was a throw spaghetti at the wall approach, which failed spectacularly.

  • Hi Mark! Yes it seems this is surprisingly common – even with smaller teams, and was a big reason why we wrote this piece. It’s easy to slip down the slippery slope of adding feature after feature, even if those features aren’t benefitting customers. Thanks for sharing your experience!

  • Really good advice – especially like the practical tips around designing the error messages, product release notes and the “empty” state.

    Key takeaway for me is definitely the importance of understand the customer pain point. Customers use the feature request as the currency for describing a pain point – it’s completely natural to think about a problem in this way. Because of this, it’s important people who build software always dig deeper to get to the real issue. I wrote an article that explores that in more depth here:

    https://www.receptive.io/blog/2015/11/30/feature_request_not_a_feature_request.html

  • Hi Hannah!

    Thanks for sharing that post – it’s great! This is one of the points that drove us to write this piece. People love building features, and often make knee-jerk reactions to customers asking for things.

    But if you’re not careful you end up with 1,000 features and STILL no happy paying customers. It’s always a fine balance of giving customers what they want vs what you as a company want to build – the two are often in contention with each other.

    Thanks for stopping by, Hannah!

  • Yes, totally agree James – customer vs company priorities can be difficult to handle but I liked your article because it brings this to light. It can be a hard lesson for new product managers to learn !

  • derrenster

    Great post, James. Resonates well with me. If you have not read it yet, have a look at John Cutler’s post “12 Signs You’re Working in a Feature Factory” (https://hackernoon.com/12-signs-youre-working-in-a-feature-factory-44a5b938d6a2#.z5qoq1m1s) which hits on the same topic.

    It’s also great to hear that you are applying the “Jobs To Be Done” framework. Would be interesting to know how this helps you with making decisions on Product features, e.g. which new features to build and which existing, unused features to kill (if you do that)., and Marketing messaging. Perhaps for another post?

    Cheers!