Don’t Add Features to Make Customers Happy (2011)(zurb.com)
zurb.com
Don’t Add Features to Make Customers Happy (2011)
http://zurb.com/article/561/don-t-add-features-to-make-customers-happ
10 comments
This is important advice for consumer-ish software. But in other areas, it works differently. A product "grows up" as its original user cohort grows up, and that's OK.
I saw this in the music creation software space. Products start simple out of necessity. They are a good fit for a cohort of users with simple needs. But as the user cohort advances, they need and want more powerful features. Typically companies add the features to create a "more professional" product, rather than see their existing users jump to a competitor.
Of course after (say) 5 years of this, the product is no longer such a great fit for "beginners". So it creates space for a new product to step in, and with a fresh approach. Of course that new product will eventually accrete more features, too. Some manage it better than others, but they all become more complex. And so the wheel turns again.
At the same time, plugins provide a safety valve, as well as a way to form partnerships. Plugins can be a way to give certain features an "audition" before maybe rolling them into the product itself (or bundling the plugin, maybe with somewhat tighter integration than before).
TL;DR Products have a natural cohort of users. If the users grow up, the products do, too. Also plugins.
I saw this in the music creation software space. Products start simple out of necessity. They are a good fit for a cohort of users with simple needs. But as the user cohort advances, they need and want more powerful features. Typically companies add the features to create a "more professional" product, rather than see their existing users jump to a competitor.
Of course after (say) 5 years of this, the product is no longer such a great fit for "beginners". So it creates space for a new product to step in, and with a fresh approach. Of course that new product will eventually accrete more features, too. Some manage it better than others, but they all become more complex. And so the wheel turns again.
At the same time, plugins provide a safety valve, as well as a way to form partnerships. Plugins can be a way to give certain features an "audition" before maybe rolling them into the product itself (or bundling the plugin, maybe with somewhat tighter integration than before).
TL;DR Products have a natural cohort of users. If the users grow up, the products do, too. Also plugins.
I agree that it's common for products to become more difficult for beginners as more and more features get added, but I don't agree that it's unavoidable. I think it's possible to package advanced features in such a way that they don't add additional complexity for the novice user. The problem, IMO, is that developers lose sight of the importance of such users in the process of trying to keep their existing/expert users happy.
The innovator's dilemma, happens in all industries. Great management teams recognize this and keep their products simple or at least modular.
This is so true!
Be very careful when adding too many features, because if you ever want to take them away (to simplify the site / UX) your users will hate you.
Just changing the look of a page will usually make people go crazy. Ebay's yellow background story is something that developers can learn from: http://www.uie.com/articles/death_of_relaunch
Just changing the look of a page will usually make people go crazy. Ebay's yellow background story is something that developers can learn from: http://www.uie.com/articles/death_of_relaunch
Absolutely. The worst ones are special purpose features that help you do one narrowly defined task very efficiently. One way to add special new things is a 'labs' option like Google where you put easy requests in which don't fit with the rest of the program and it's clear to the user they aren't proper stable features.
A good client understands why you shouldn't optimize for doing "one narrowly defined task very efficiently"; for the rest, I've tried to resolve matters diplomatically.
Yet — for my own work, I will barely hesitate to build a tool for one narrowly defined task that I know I'm going to have to do repeatedly.
The irony is that, in the latter case, I'm facing an ROI that is capped at 1:1 (see xkcd [1]); whereas in the former case, you're leveraged at 1:N, where N is the number of users (who are doing the narrowly-defined task).
One of the perks of "learning to code" is that you have a programmer on payroll who gives you preferential treatment.
[1] http://xkcd.com/1205/
Yet — for my own work, I will barely hesitate to build a tool for one narrowly defined task that I know I'm going to have to do repeatedly.
The irony is that, in the latter case, I'm facing an ROI that is capped at 1:1 (see xkcd [1]); whereas in the former case, you're leveraged at 1:N, where N is the number of users (who are doing the narrowly-defined task).
One of the perks of "learning to code" is that you have a programmer on payroll who gives you preferential treatment.
[1] http://xkcd.com/1205/
"One way to add special new things is a 'labs' option like Google where you put easy requests in which don't fit with the rest of the program and it's clear to the user they aren't proper stable features."
That's where I'm headed with my start-up. The first feature that was going to be put in there was a userbase-sentiment / survey system with historical charts ... it wouldn't override my decisions and roadmaps, but it'd give me quick and historical insights into exactly what the users think (and then allowing me to drill down into the data further to find trends).
I've found transparency and open-communication with users is pretty much the #1 thing you can do from day-0 to build a good relationship with them.
That's where I'm headed with my start-up. The first feature that was going to be put in there was a userbase-sentiment / survey system with historical charts ... it wouldn't override my decisions and roadmaps, but it'd give me quick and historical insights into exactly what the users think (and then allowing me to drill down into the data further to find trends).
I've found transparency and open-communication with users is pretty much the #1 thing you can do from day-0 to build a good relationship with them.
Speaking of a "labs" feature, you should check out http://tai.st which offers "Labs as a Service".
I joined a small company that had made this mistake horribly and many times over. The entire product was just a mess of half-baked incoherent features. It looked like many were put in to satisfy customer requests while others were just there to be able to say "It's got X!" without thought to the rest of the product. There were even two duplicated features in different places with different names. The worst part (well, best from my point of view) was that a lot of them didn't actually work correctly. They didn't have testing. That gave me license to chop a lot of it away with the justification of "If anyone was using this they would have told us it was broken. They didn't so they aren't. Get rid of it.". In those days we had feedback like "It's free and worth every penny". Now it's more like "I introduced it to my colleague and he was impressed, expect another sale soon". The feature set now is smaller than it was then, and looks less impressive when it's itemized, but what's left is more focused on a narrower type of user in one profession, more powerful and cleanly integrated into an elegant, usable product.
The concept of starting with an MVP is very important.
You're not going to build a better Facebook by adding more features than they have, the only way to do it would be to create a simpler platform and focus on the users who find your site the most useful (for Facebook it was college students, now it's families and old friends).
Just think if HN started to allow pictures in posts and comments or allowed a wider variety of posts (lolz look at my cat), the site would likely be ruined instantly. It would have also never been as popular as it is if it allowed these types of posts from the beginning.
There is also the method of adding that one feature that the big companies can't add, because it's one of their main sources of revenue. Look at DuckDuckGo, they started as a much simpler version of Google Search except it promises as much privacy as possible.
You're not going to build a better Facebook by adding more features than they have, the only way to do it would be to create a simpler platform and focus on the users who find your site the most useful (for Facebook it was college students, now it's families and old friends).
Just think if HN started to allow pictures in posts and comments or allowed a wider variety of posts (lolz look at my cat), the site would likely be ruined instantly. It would have also never been as popular as it is if it allowed these types of posts from the beginning.
There is also the method of adding that one feature that the big companies can't add, because it's one of their main sources of revenue. Look at DuckDuckGo, they started as a much simpler version of Google Search except it promises as much privacy as possible.
I once worked on a large application whose features were driven largely by customers and it wasn't pretty. You easily end up with a bloat and 'death by preferences' [1]. So I agree, your product vision should drive your features.
What I didn't realize at the time (and I think many don't) is that when you have customer requests for features that don't align with your vision you should consider making your product extensible. Keep a small core product and provide plug-ins for additional features. Customers pick the plugins they need or write their own.
[1] http://insideintercom.io/product-strategy-means-saying-no/
What I didn't realize at the time (and I think many don't) is that when you have customer requests for features that don't align with your vision you should consider making your product extensible. Keep a small core product and provide plug-ins for additional features. Customers pick the plugins they need or write their own.
[1] http://insideintercom.io/product-strategy-means-saying-no/
YeahKIA: You appear to be hellbanned, FYI.
YeahKIA's comment: Plugins is an interesting approach. But I wonder how friendly it is to non expert users. Same with the writing your own part.
YeahKIA's comment: Plugins is an interesting approach. But I wonder how friendly it is to non expert users. Same with the writing your own part.
> But I wonder how friendly it is to non expert users.
Can't say from my own experience but browser extensions and IDE/Editor plugins seem to work well. If your customer is a business they might have developers to implement plugins.
Naturally it all depends on the type of product and type of customers. If your product is an online service then an API is your extension point.
Can't say from my own experience but browser extensions and IDE/Editor plugins seem to work well. If your customer is a business they might have developers to implement plugins.
Naturally it all depends on the type of product and type of customers. If your product is an online service then an API is your extension point.
Plugins is an interesting approach. But I wonder how friendly it is to non expert users. Same with the writing your own part.
Sure, adding features that hurt your stability and your chances of growth is a terrible idea. Many a company has made that mistake before, and ended up with an unworkable product.
We do have to make sure that, with the features we have, the product is actually viable though. There's also many projects out there that just won't get anywhere because there is no compelling reason to use them over the alternatives.
For instance, I know of a small data visualization project that happens to have far better performance than KineticJS and D3: It was built precisely because those two libraries were tried, but just didn't provide the right frame rates for what a team was trying to do. The problem is that the current implementation's only interactive features are pan and zoom: Not even an event on mouseover. Want to highlight something based on a search? No dice. This makes the library so narrow in its applications that the project just can't capture users.
an MVP should be minimum, but we can't forget it must also be viable.
We do have to make sure that, with the features we have, the product is actually viable though. There's also many projects out there that just won't get anywhere because there is no compelling reason to use them over the alternatives.
For instance, I know of a small data visualization project that happens to have far better performance than KineticJS and D3: It was built precisely because those two libraries were tried, but just didn't provide the right frame rates for what a team was trying to do. The problem is that the current implementation's only interactive features are pan and zoom: Not even an event on mouseover. Want to highlight something based on a search? No dice. This makes the library so narrow in its applications that the project just can't capture users.
an MVP should be minimum, but we can't forget it must also be viable.
> No, your customer will not get angry if you don't implement all their suggestions.
Actually, they probably will... and then either they'll go find a better replacement for your product, or implement it themselves/find someone to (this happens with various proprietary web apps I'm forced to use. :)
Actually, they probably will... and then either they'll go find a better replacement for your product, or implement it themselves/find someone to (this happens with various proprietary web apps I'm forced to use. :)
Not bogging down your service with unneeded features is a feature in it of itself. And often times the best feature.
Also, ditto with it not being the rule that customers know what's best. Customers are for the most part good judges of their own happiness, but it's a heuristic, not a hard-and-fast rule : take it with a grain of salt. If you know what you're doing, you, as the designer of the product, should know more about it than the user, the layman who uses the product, so you know what'll be the best in the long term better than the user.
But another thing about being the designer of the product is that you spend so much time with it you start staring at it from a millimeter away, losing sight on the grand purpose. It's something you can't prevent even if you're aware of it; as the artist, it's your job to focus on detail. It's why programmers initially thought Dropbox was just "rsync and ftp with a neat UI, what's the big deal?". The more you focus on detail, the less you focus on the big picture, which is an important perspective to have -- which is why it's also important to keep tabs on what the user says h/she wants.
They hated the News Feed when it was originally released and they shat on the iPad when it originally came out.
But they also thought OK Soda would be a good idea.
Maintain a balance.
Also, ditto with it not being the rule that customers know what's best. Customers are for the most part good judges of their own happiness, but it's a heuristic, not a hard-and-fast rule : take it with a grain of salt. If you know what you're doing, you, as the designer of the product, should know more about it than the user, the layman who uses the product, so you know what'll be the best in the long term better than the user.
But another thing about being the designer of the product is that you spend so much time with it you start staring at it from a millimeter away, losing sight on the grand purpose. It's something you can't prevent even if you're aware of it; as the artist, it's your job to focus on detail. It's why programmers initially thought Dropbox was just "rsync and ftp with a neat UI, what's the big deal?". The more you focus on detail, the less you focus on the big picture, which is an important perspective to have -- which is why it's also important to keep tabs on what the user says h/she wants.
They hated the News Feed when it was originally released and they shat on the iPad when it originally came out.
But they also thought OK Soda would be a good idea.
Maintain a balance.
The point is interesting, and follows the more general Lean approach. I can easily see how to decide not to implement a feature — what is less clear is how to address such requests: any public forum, related to features or not, will have tons of those, and they are usually the most voted comments (because they are positive, lead to discussion and refer to unmentioned aspect of the service).
Should the company be silent? Should they say that those are further down the pipe than other, non-visible aspects (better synchronisation, platform compatibility); should they say that those have been considered and will not be implemented in the foreseeable future?
Should the company be silent? Should they say that those are further down the pipe than other, non-visible aspects (better synchronisation, platform compatibility); should they say that those have been considered and will not be implemented in the foreseeable future?
The way I approach it with my users is there is a link on every page to report bugs and request features. Bugs get attention, features get considered. I also follow a [ feature ] -> [ tech-debt && bug fixing ] -> [ optimizations ] -> [ repeat ] and my users know that. Generally what I look for in the feature requests are trends and clusters of topics or pain-points and then I try to find the more common case that those multiple requests are all unified by. Once you find that, it's a lot easier to see if it fits into your overall roadmap / vision, and allows you to execute on it better.
What if it's the most requested feature by most customers and your data is telling you it might be a good idea? It would be crazy not to try.
Here's the part I most enjoyed: "The bottom line is a decision has to be made. A decision means to not do something, and to achieve clarity in your design. The classic way this used to come up (and still does) is the inevitable “make it an option”. You can’t decide should a new mouse wheel scroll or zoom? Should there be conversation view or inbox view? Should you AutoCorrect or not? Go ahead and add it to Preferences or Options. But really the only correct path is to decide to have the feature or not. Putting in an option to enable it means it doesn’t exist. Putting in an option to disable means you are forever supporting two (then four, then eight) ways of doing something. Over time (or right away) your product has a muddled point of view, and then worse, people come to expect that everything new can also be turned off, changed, or otherwise ignored. While you can always make mistakes and/or change something later, you have to live with combinatorics or a combinatoric mindset forever. This is the really hard stuff about being a PM but the most critical thing, you bring a point of view to a product—if a product were a person you would want that person to have a clear, focused world-view."
[1]http://blog.learningbyshipping.com/2014/04/17/shipping-is-a-...