
Don’t Add Features to Make Customers Happy (2011) - Mitt
http://zurb.com/article/561/don-t-add-features-to-make-customers-happ
======
orky56
Just a few days ago, Steven Sinofsky of a16z addressed some of the great
points in this article. All the more relevant since he was in charge of some
major MS products early on.[1]

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-...](http://blog.learningbyshipping.com/2014/04/17/shipping-is-a-feature-
some-guiding-principles-for-people-that-build-things/)

------
greghendershott
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.

~~~
bostonpete
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.

------
dm2
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](http://www.uie.com/articles/death_of_relaunch)

~~~
Yardlink
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.

~~~
gavinpc
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/](http://xkcd.com/1205/)

------
Yardlink
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.

~~~
dm2
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.

------
jermo
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/](http://insideintercom.io/product-strategy-means-saying-no/)

~~~
talklittle
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._

~~~
jermo
> 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.

------
hibikir
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.

------
userbinator
> 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. :)

------
omarhegazy
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.

------
bertil
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?

~~~
mkal_tsr
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.

------
weixiyen
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.

