Practicing Product Minimalism
garry.posterous.com
Practicing Product Minimalism
1–10 of 20 posts
Re: Practicing Product Minimalism
#2At 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".
Re: Practicing Product Minimalism
#3"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.
Re: Practicing Product Minimalism
#4When 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.
Re: Practicing Product Minimalism
#5I'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).
Re: Practicing Product Minimalism
#6I'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 pe…
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.
Re: Practicing Product Minimalism
#7Removing features is very hard when there is always some paying customer is using that feature.
Re: Practicing Product Minimalism
#8I'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 pe…
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.
Re: Practicing Product Minimalism
#9Earlier quoted context omitted.
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?
Re: Practicing Product Minimalism
#10Earlier quoted context omitted.
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.
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.