

Practicing Product Minimalism - brlewis
http://garry.posterous.com/practicing-product-minimalism

======
sriramk
I've seen three big impediments to doing this in teams in a medium to large
environment

\- First, there's too much ego associated with features. If a feature is
someone's 'baby', it is just very hard to get them to accept that that feature
needs to go. Even with all the data in the world, it becomes confrontational
and ugly very easily.

\- Second, companies rarely tend to reward removing things. It is hard to have
a performance review or a stack ranking/calibration meeting where your major
accomplishment was removing features. This is obviously a broken performance
appraisal model/culture but just happens to be prevailing culture in several
large organizations.

\- Third, a lot of products and features don't lend themselves to measurement
very well. Without measurements and data, deciding what to remove comes down
to subjective opinions. Contrast this with new features where you often have
lots of data (emails from users, tweets, market research, etc).

~~~
rantfoil
Yup, agree completely. But that's precisely why teams should be small.

Apple is living proof. Some large chunks of the iPhone are actually done by
half a dozen engineers. When I was a PM at Microsoft, our whole team was
something like 40 people on data synchronization.

~~~
a4agarwal
teams at apple are TINY. Mail is like 3 guys. iChat is 1. Address Book is 1.
iPhone apps (non web based) is like a 3 person team.

Final Cut Pro was around 15, which is still incredibly small given how big our
application was.

~~~
ruff
That's not quite the case any more--those teams have gotten larger over the
years (from what I've heard). That said, building the right features/product
is often a lot about focus and focus is much easier to obtain with a smaller
team. Apple's are definitely smaller than Microsoft's but Apple, imo, also
tends to hire developers who are more considerate of or passionate of
customers than Microsoft's more tech-oriented engineers.

~~~
a4agarwal
I worked at Apple for 6 years. Believe me, the teams are still very, very
small and focused. If you have a small team, you don't need to worry so much
about feature creep: you don't have time to work on the less vital stuff

~~~
ruff
Yeah, should have been clearer--I do think the dev teams at Apple for the same
product tend to be smaller than the equivalent team in Microsoft (just,
specifically, I know that some of the teams you mentioned have grown). The
small teams at Apple probably enforce all sorts of interesting functions such
as not chasing half-baked features and leveraging more platform/shared code
rather than Microsoft's often NIH approach to things.

Apple lets go of a number of things that Microsoft chases such as a religious
concern for backwards compatibility, globalized features (not just
localization but geo-specific features), and deep product extensibility with
corresponding dev support. No judgment on those decisions but I'd argue that
the size of MS teams isn't directly reflected in the product or features most
folks consider as users of Microsoft's products and I wouldn't criticize MS
based on those team sizes (as the author of this article does). Instead, I'd
criticize the PMs or other managers inability to bring focus to those teams to
clearly tackle the right problems at the right level of investment at the
right time. It takes a lot of discipline to say "no."

------
ars
"Perfection is achieved not when there is nothing left to add, but when there
is nothing left to take away." - Antoine de Saint-Exupery

One of my favorite quotes.

~~~
uggedal
This is an often used misquotation. Her is the original passage with context
from Antoine de Saint Exupéry's _Wind, Sand and Stars_ (1967):

And now, having spoken of the men born of the pilot’s craft, I shall say
something about the tool with which they work, the airplane. Have you ever
looked at a modern airplane? Have you followed from year to year the evolution
of its lines? Have you ever thought, not only about the airplane, but about
whatever man builds, that all of man’s industrial efforts, all his
computations and calculations, all the nights spent over working draughts and
blueprints, invariably culminate in the production of a thing whose sole and
guiding principle is the ultimate principle of simplicity?

It is as if there were a natural law which ordained that to achieve this end,
to refine the curve of a piece of furniture, or a ship's keel, or the fuselage
of an airplane, until gradually it partakes of the elementary purity of the
curve of a human breast or shoulder, there must be the experimentation of
several generations of craftsmen. _In anything at all, perfection is finally
attained not when there is no longer anything to add, but when there is no
longer anything to take away, when a body has been stripped down to its
nakedness._

~~~
bmelton
Color me simple, but I honestly don't see how that's dramatically different
from the parent's "misquote".

~~~
jcl
...especially considering that it's being translated from French. The exact
wording varies by translator and is therefore irrelevant.

------
jwilliams
At one stage I was very into metrics and this was one of the more interesting
aspects. As a very general rule, removing features basically amounted to the
same effort as adding them (i.e. a feature that takes 5 weeks, generally took
5 weeks to remove).

However, the payback in testing and regression was usually a no-brainer. You
could make back your investment in removing something in 1-3 product cycles...

Somewhat contrary to what you'd expect, this was often a better payback than
adding features - of course you could take this to a variety of absurd
conclusions... However, what it generally meant is that in most situations
products will tend towards "feature bloat".

------
varikin
Removing features is very hard when there is always some paying customer is
using that feature.

~~~
joubert
A feature is just an indirection for getting something done. There are often
better / newer ways of getting that same thing done, sometimes part of a
bigger flow context. So the "feature" is a tidbit that can be removed.

------
ruff
As someone very familiar with the PM process at Microsoft--I don't totally
agree with the conclusion. PMs can be incredibly valuable to a team and are,
in a different way, a creator/do-er. Unfortunately, most PMs construct
obstacles and walls rather than bring focus and help a development team
navigate their direction.

Also, one thing I see a lot of PMs who follow the "minimalist" approach
confuse is that the idea isn't really to remove features to strip the product
down to it's bare capabilities in the name of minimalism or elegance (while
not a bad exercise, can make certain types of differentiation challenging in a
competitive space). Instead, it's about good design and delivering quality on
the core user scenarios rather than allowing yourself to stray to "it'd be
cool to do this" without fulling thinking through the needs of your users, the
resulting user experience, and the dilution of effort on your dev and QA team
by chasing those edge scenarios. It's that lack of focus and discipline that
ultimately leads to features that need to be removed.

------
rokhayakebe
When launching a new product it is very safe to cut down the functionalities
to the absolute necessary features. If not you may end up finding that users
actually need feature x to behave differently. Sometimes changing that single
feature means changing 3 other features or the application will be flawed.

