Gartner Blog Network

Remove Features Your Users Don’t Want – Not That You Don’t Want

by Brian Prentice  |  May 9, 2011  |  2 Comments

Ah, serendipity.

It’s 5am. I’ve been up for the last two hours. It seems the Tylenol PM didn’t do it’s job of knocking me out senseless for the 8 hours I needed to avoid the jet-lagged induced fog I’ll be dealing with around 3pm this afternoon.

So, I’ve been up in my hotel room here at the Hyatt Regency in Old Greenwich reading some great articles I’ve been meaning to get to. One of these is “Feature Bloat: The Product Manager’s Dilemma.” The other is “The Laws of Simplicity” by John Maeda. Both sets of authors stress the need to proactively reduce feature sets in products in order to maximize the long-term value that users obtain from them while, at the same time, increasing the organization’s brand value.

As I’m digesting the implications of this message on the way we think about software design I decided to get myself my morning cup of coffee. In fact, I’m slightly surprised I lasted this long without some caffeine cursing through my system. I look, and look…and look. No coffee machine. How could this be? So, I call down to the front desk and I’m told by an extremely polite young man that the hotel doesn’t provide coffee machines in the rooms. Instead, there is complimentary coffee by the elevators which is available from 6am onwards.

Arguably, the Hyatt Regency in Old Greenwich did exactly what Maeda, Rust, Thompson and Hamilton told them to do. They removed a feature. Namely the existence of a coffee machine, a couple of packs of ground coffee and some sugar and non-diary creamer from a guest’s room. And I can see the logic of the hotel’s management. After all, they haven’t actually removed free coffee from the hotel. They simply changed the location of where it’s obtained. And, in the process, they reduced the capital cost of putting coffee machines in every room and the ongoing cost of providing the coffee and condiments.

Win-win. Right?


See, first of all, I don’t want to have to wait for the time hotel management feels is appropriate for me to have my first cup of coffee in the morning. And, if I’m sounding a bit surly, it’s because I’m writing this before I’ve had any coffee. Second, and more important, I feel that the appropriate attire needed to make coffee in the morning is a bathrobe and a pair of glasses. However, I do not believe that the sight of a bathrobe-clad, groggy, stubble-faced middle-aged man wandering around the corridors of a hotel in some caffeine-depraved state of confusion mumbling something about Ethiopian blends is something people should have to deal with in a five star hotel. I know I don’t. So, when the coffee finally arrives, I’ll need to throw something on and make myself slightly presentable. Just for a cup of coffee.

The management of this hotel apparently sees coffee as an amenity of the hotel. They’re missing the point that the coffee is not a feature of the hotel – it’s a feature of the room. A hotel room is an experience and when it comes to the business traveler the experience they’re aiming for is a home away from home. When I’m at home I make coffee when I feel like it and in my PJs. I don’t slip some clothes on and walk up to the top of my street.

Am I then suggesting that Maeda, Rust, Thompson and Hamilton are wrong about reducing features? Absolutely not. The process of removing superfluous features from a product is as important for a hotel as it is for a software designer. The question is how you make the decision. The essence of making the right decisions comes back to the need to get the conceptual design of the product accurately defined at the very outset. What is this solution achieving for the user? Does a feature enhance, or detract from that objective for a majority of the people this solution is designed for? Do we know who those people actually are? Do we have effective feedback loops to assure our decisions are accurate after they’ve been implemented?

The less you understand about the users’ objectives the more likely you’ll make mistakes either in expanding, or contracting, the feature set of a solution.

Now, if you’ll excuse me I need to get myself ready to get my cup of coffee.


Brian Prentice
Research VP
9 years at Gartner
26 years IT industry

Brian Prentice is a research vice president and focuses on emerging technologies and trends with an emphasis on those that impact an organization's software and application strategy... Read Full Bio

Thoughts on Remove Features Your Users Don’t Want – Not That You Don’t Want

  1. Jon Spragg says:

    Good thought Brian,

    Perhaps the Hyatt Regency, being a Three Diamond rated provider rather than 5 Diamond feels more inclined to manage the functionality offered to their clients downward without risk of them being unduly frustrated – the options in their market in Stamford after all is a little limited.

    I do agee that the initial decision architecture here needs to be done, but is it possible that you are amongst the minority, i.e. a client who is up at all hours of the night requiring non standard funtionality that 95% of the rest of the customer base deems to be being managed satisfactorily?

    To understand if the hotel were right, the question might be, did you bump into any other bathrobe-clad, groggy, stubble-faced middle-aged man wandering around the corridors at 5am?

  2. I take your point. Maybe I’m assuming that my desire to have a coffee machine in my room is actually a request for a feature most people don’t care about. However, over half the adult population of the US drinks coffee. Over half the population drinks tea. Obviously there’s some overlap, so let’s just say that 70% drinks either one or the other. This is a perfect example of functional reduction you DON’T want to do. I’m willing to wager more people would prefer to make a cup of coffee in their room than drink the $5 bottle of water. I’m guessing the over-priced water isn’t going anywhere.

Comments are closed

Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.