Latest Tweets

Laura Klein

6 Reasons Users Hate Your New Feature

You spend months on a new feature for your existing product: researching it, designing and building it, launching it. Finally, it’s out in the world, and you sit back and wait for all those glowing comments to come in about how happy your users are that you’ve finally solved their biggest problems. Except, when the emails, forum posts, and adoption data actually come in, you realize that they hate it.

There is, sadly, no single reason why your new feature failed, but there are a number of possibilities. The failure of brand new products is its own complicated subject. To keep the scope narrow, I’m just going to concentrate on failed feature additions to current products with existing users.

Your Existing Product Needs Too Much Work

Ah, the allure of the shiny new feature! It’s so much more exciting to work on the next big thing than to fix bugs or improve the user experience of a boring old existing feature.

While working with one company, I spoke with and read forum posts written by thousands of users. I also used the product extensively myself. One of the recurring themes of the complaints I heard was that the main product was extremely buggy and slow. The problem was, fixing the bugs and the lagging was really, really hard. It involved a significant investment in infrastructure change and a serious rewrite of some very tricky code.

Instead of buckling down and making the necessary improvements, management spent a long time trying to build new features on top of the old, buggy product. Unfortunately, the response to each new, exciting feature tended to be, “Your product still crashes my computer.  Why didn’t you make it stop doing that instead of adding this worthless thing that I can’t use?”

Now, you obviously don’t need to fix every last bug in your existing offering before you move on and add something new. You do, however, need to be sensitive to the actual quality of your product and the current experience of your users before adding something new. You wouldn’t build a second story on a house with a shaky foundation. Don’t tack brand new features onto a product that has an unacceptably high crash rate, severe usability problems, or that runs too slowly for a significant percentage of your users.

Before you add a new feature to a product, ask yourself, “Have I fixed the major bugs, crashes, and UX issues that are currently preventing my users from taking advantage of core features?”

Your Product Interface Is a Giant Mess

Remember the old Saturday Night Live spoof commercial that advertised, “It’s a floor wax! It’s a dessert topping!”? It’s not as funny when it’s true. Products cannot do everything, and when they try, they end up with interfaces far too complicated for the average user to navigate.

I see this happen all the time, especially with startups looking for a way to make their product appeal to more people. Instead of improving their core product and adding features that enhance that experience, they add unrelated feature after unrelated feature, often stolen directly from more successful companies with larger user bases. Their goal is to find something that makes them blow up huge, but they just end up with an overly complicated product that tries to do too many things and doesn’t do any of them well.

It’s not just startups that suffer from this. Products that have been around for many years often get bogged down with feature after feature, all of which have to be supported because some fraction of the user base still uses it. These products then become vulnerable to new challengers with more focused, easy to use interfaces and smaller feature sets.

Of course, there are times when companies have to take their products in a new direction. For example, Flickr started as a set of tools for an MMORPG called Game Neverending. The game has ended, but Flickr lives on as an entirely different business.  PayPal began as a way to make PDA to PDA mobile payments, but that feature got killed years ago when they realized that web payments were a far better business model.

When you do find that killer feature that’s going to change your whole business model, commit to it and make it a serious focus rather than burying it under dozens of less popular features. Don’t try to be all things to all people, or you will end up with nothing but a giant, unusable mess.

Before adding a new feature, ask yourself, “Does this enhance my current product experience or just add to an already confusing and cluttered interface?” And, if it doesn’t fit with your current product offering but you still want to do it, ask, “Am I prepared to cut other features to make this part of my core offering and simplify my experience?”

You Didn’t Build What They Asked For

Let’s face it, sometimes your priorities are different from your users’. For whatever reason, be it a new business partnership, a need for a new revenue stream, or the desire to attract a different group of users, sometimes you’re going to build something that your current users don’t want and didn’t ask for.

This isn’t always a bad thing. For example, something that annoys your current non-paying users but attracts a whole slew of new, paying users is worth a few nasty emails to your customer service department. Just make sure that the new feature is really going to do what you think it will. It sucks to piss off your current, paying customers to build a feature that never really fulfills its initial promise. Trust me on this.

Before building a feature that potentially has more benefits to your company than your current users, ask yourself, “Am I prepared to deal with the fact that this is going to annoy some of my customers, and what is the real likelihood that I will get more out of this than I will lose?”

You Built EXACTLY What They Asked For

I know. It doesn’t seem fair. They’re angry if you don’t do what they want, and they’re angry if you do what they want.

The truth is that users will often ask you for a solution when it would really be more helpful to tell you that they have a problem. I’ve written more extensively about when you shouldn’t be listening to your users, but the upshot is that users aren’t great predictors of which brand new features will be big hits. Sometimes users will tell you that they want a toaster in their car, when what they really mean is that they don’t have time to make breakfast in the morning.

Before building a new feature that your customers are demanding, ask yourself, “What known user problems is this solving, and is this the best way to solve it for everybody?”

The Feature’s Not Finished

Now, I’m all for building the minimum viable product, getting it out in front of users, and then iterating on it to improve it, but some features just aren’t ready for prime time. By launching a half baked feature without key functionality, you’re running the risk of turning a lot of people off on the idea before they ever get a chance to really try it out.

Remember, your customers aren’t in the conference room with you when you come up with your grand vision. They don’t know where you’re going with this neat new idea. They’re judging the feature based on their first experience with it. Make sure that the first version is at least usable and hopefully that it’s far enough along that users can see the same promise that you do.

Also, good enough to ship doesn’t necessarily mean good enough to remain in your product long term. A big part of shipping early is continuing to improve the feature once it’s been out for awhile. One company I worked with had the tendency to ship early versions of features and then let them just sit there gathering dust, rather than iterating on them until they were truly high quality. What they ended up with was an enormous product that all seemed about half finished and a lot of unhappy customers who didn’t believe features would ever improve past version 1.0.

Before shipping a new feature, ask, “Is this good enough that users will get why they should care about it? And, if they do care about it, am I committed to improving it?”

The Feature’s Not Finishable

At many of the companies I’ve worked with, features have tended to evolve before they even get built. What generally happens is this: you have an idea based on something you’ve heard from users; that idea gets brainstormed and grows based on internal input; UX and visual designers spec out the whole idea, often expanding on the original idea; then engineering gets involved and gives a time estimate of how long the feature will take to build; finally the whole thing gets cut back by about 80% based on the estimates.

Unfortunately, the 20% you end up implementing may not solve the original problem. That means, when you finally announce your great new feature, users who originally asked to have that particular problem solved are justifiably upset.

Before drastically cutting your new feature back, ask yourself, “Does this still solve the original problem I was trying to solve?” If it doesn’t, ask, “Can this problem be solved with a reasonable level of investment?” There’s no shame in answering no to either or both of these questions, as long as you decide not to go forward with the new feature.

The Secret to Making Everybody Love Everything You Make

I’m joking. There’s no secret. The truth is that it’s almost certainly impossible. But by asking yourself the right questions during your feature development phase, you can dramatically cut back on time spent creating things your users hate.

And never forget, when you do build something they hate, acknowledge it, apologize for it, and fix it. It will go a long way toward making your users happy again, and it might even get them to like that neat new feature you just shipped.

Interested? You should follow me on Twitter.

For more information on the user experience, check out:

Share with


  1. If you looked at your frequency of use, you’d find that you have a long tail or power law distribution on your hands. The hits end of the long tail will be features from your platforms like Windows and Explorer. These hits are your hubs. They need to be stable. Your product should have a few hubs, features that are used in conjunction with other features, of its own. The rest of your features will be at asymptotic end of the long tail. These features can change with much less impact on users than your hubbed features.

    Too much of the churn in features just amounts to noise. That noise costs your users time, so to save their time, they never get around to using your new features. It doesn’t mean much more than they just don’t have time to deal with it right now.

    Your portfolio of features is also a zero-sum game. When a new feature is being used, some old feature isn’t being used.

    Your mention of product adding feature upon feature is what we call feature bloat. Feature bloat is critical for the product when it faces the early mainstream, IT, market. But, moving into late market, the UI must be sublimated, made simpler for the non-geek. There is no general rule that says sublimated is better for all markets. Each market presents its own requirements.

    posted by David Locke at 12:31 pm on 11.13.09
  2. Laura, when I read this I couldn’t stop thinking that you’d spent some time in my head. What a great article!

    The biggest problem I’ve had in developing new features has always been adding them to shaky basics which never seem to be a priority to get right because of the constant desire to meet vicious product role out schedules.

    My favourite analogy is of the film industry: how much pre-work is done down to the finest of detail prior to the decision to commit finance and give the go-ahead to shoot? Of course, not all films are box office hits, but the ability to plan properly surely minimises the chance of getting it completely wrong.

    Thanks again for a great article.

    posted by Kelly at 2:18 am on 11.17.09
  3. Laura: I totally agree with you here: “You Built EXACTLY What They Asked For”.

    It’s very frustrating when this happen, but we should learn from that.

    posted by Ariel Di Stefano at 5:43 am on 11.17.09
  4. Brilliant formulation “You Built EXACTLY What They Asked For”. I experienced the same when managing a Cultural Information Office: users didn’t know how to ask what they REALLY wanted, so, if you didn’t guess, they didn’t get what they really needed :))

    posted by Conxa Rodà at 6:11 am on 11.18.09
  5. Another brilliant article, Laura.

    Do you have any tips on knowing when the minimum viable product for a first release is really that? That is, when the promise is shown enough.

    Would you ship early and supplement the UI with visual indicators or help links about stuff that’s coming soon?

    posted by Yoav Shapira at 9:49 am on 12.11.09
  6. Thanks all for your comments!

    Yoav, knowing when a product is at the MVP stage is a really tough question. I would give you this vague and probably not very helpful answer: it’s a minimum viable product when it solves an important user problem. The trick is, you have to learn about real customer problems by observing users dealing with the problems you’re trying to solve. I find contextual inquiries a really great way to do this before I start designing a product at all. Observing problems and formulating solutions is a much better research method than asking users about either problems or solutions.

    And I think you can ship early without visual indicators that stuff’s coming soon, unless you’re absolutely 100% certain that it is the next thing to be shipped. In fact, in many cases you might not want to commit yourself to adding specific features to your MVP. If it really is a minimum viable product, you can ship it, let it stand on its own, and immediately do more customer development to find out what features really should be added next. You want to iterate based on customer feedback rather than on the plan that you created before you shipped your product.

    Also, do be careful with promising your users new features that are not yet built, since this has bitten me more than once. Sometimes, the feature you think is absolutely going to be built next gets pushed back for all sorts of reasons (some good, some bad), and this can disappoint users who will feel they were promised the feature.
    Of course, there are exceptions to this, so I don’t want you to feel like you should never put in a placeholder or help text!

    Thanks again for reading. I think figuring out when you’ve got a minimum viable product is a great topic for a future blog post. But I’m not promising anything!


    posted by Laura Klein at 11:54 am on 12.11.09
  7. […] Bread Board » 6 Reasons Users Hate Your New Feature – […]

Leave a comment