Practicing Product Minimalism | Hacker News Reader

Practicing Product Minimalism

garry.posterous.com

52 pointsbrlewis19 comments

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

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.

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.

There are several thousand people out at Cupertino - what are they doing?

There are about 20k, up from 10k when I started there 6 years ago. But I think 5k-8k of them work at the retail stores around the world.

Then take into account all the people who do QA, all the management, marketing, business, finance, and other teams.

And you're actually left with a pretty lean engineering force. Apple engineers more stuff in house than a typical company like Dell, so that plays into the head count as well

I intern'd at Apple and I would say that Apple's engineering talent is a level below Microsoft and Google. Apple combines good (but not incredible) engineering with the best product management (manager maybe...) on the planet. Microsoft and Google have much strong engineering teams but their much weaker on the PM side.

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.

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

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

not even close to ballpark numbers, sorry... :)

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

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.

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

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

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

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

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.

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.

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.

Reply on news.ycombinator.com