A ‘jack of all trades’ product management approach for a company with a ‘focus’ strategy (i.e. airline manufacturer, oil refiner, software producer) is probably trouble.

But for a company with a ‘Diversify’ strategy (Convenience store, supermarket, Web portal, stock market, newspaper, etc) this Jack of all trades may not be a bad approach.

Average functionality is weak functionality. Average meaning is meaningless.

But if you have a core platform, and evolution is through plugins, it works, and also self-evangelizes since you also open up your product to a larger community of developers, outside of your walls. Brings in silver-lining of free marketing through all those dependent developers and ultimately fans (and their community).

Whoa! collaborative PM, development, marketing… so cliche – but it really does work in great ways, if the base system supports, and works to develop the rest (the community – which does not happen auto-magically).

I mentioned Mozilla and Atlassian – how about Apple, if that’s not a great example of success on this model, I do not know what is.

You think if you add one more feature, you will be able to add more potential interested consumers to your base. And maybe you will, but at the risk of muddying your product proposition for your core consumers.

Most of the time, it’s not worth the trade off.

Mozilla has proved this, Atlassian proves this daily – both REALLY well – not to mention the larger good feel ecosystem they are building in terms of additional business opportunities for plugin developers to hone in on your original point: plugin focus to solve a specific problem.

But if you take a step back as a PM of the base product – I never think of Atlassian or Mozilla’s base foundational products as the start all end all.

Their products are GREAT because of the external (and internal) plugin development adding to their product.

To top it off – everyone benefits:

customers benefit, the “host application” company benefits (reduced dev, support, and mktg support), and certainly the third party plugin developers benefit.

Result: Best of breed, and perception of “Jack of all trades” for the host application company (which they rightly deserve by building the host infrastructure).

Good PMs invest alot into this strategy, I think.

This is an important point, because the *perception of performance* is a far more important factor in user preference with retail consumer products than it is with interactive products, where *actual performance* (i.e., the user experience) is paramount.

I think using this study to justify design decisions in interactive products is a mistake. Interactive products do not derive their customer perception of value based on their marketing campaigns and bullets-on-the-box like grocery store consumer products do. Toothpaste is largely about brand — are you a Crest family or a Colgate family? For software, this is increasingly irrelevant. This used to be true when we bought software in shrinkwrapped boxes and had only the bullet-point feature promises and the graphic design of the box to make our buying decisions on — but it’s a fast-disappearing strategy in today’s era of user-experiences-that-sell-themselves, where you can use software for real before buying into it. While Proctor and Gamble may differentiate one product from another exclusively on the brand promise, interactive products succeed or fail based on their actual user experiences, experiences that users can feel and touch and make real judgments on.

That said, I *do* intuitively believe that the conclusion of this post — that having fewer & focused features is better than trying to be all things for all people — is completely correct. The study cited, however, is not the right evidence for it. I would love to see the right evidence presented to show that Microsoft-type feature-bloat is losing ground to the Web 2.0 paradigm of modular, focused excellence.