I understand the point behind this entirely.<p>The Swiss Army Knife metaphor, however, is, in fact, a bad one, thought it seems all right initially.<p>The key bit is this:<p><i>"By combining many products of low utility, it [the knife] becomes a product of some utility."</i><p>False. The basic 440 stainless blade is of <i>immense</i> utility. So much so that many, myself included, choose to carry a pocket knife that contains nothing but a single blade. The Swiss Army knife sacrifices a small amount of the utility of a good blade (by making it slightly smaller and the handle less ergonomic) in exchange for significant additional functionality.<p>Sure, the saw pretty much sucks, and the scissors are of minimal use, and so on. That's not the point, though, <i>at all</i>. It's that a Swiss Army Knife allows you to have those things <i>at all</i> in unexpected situations. It fits in your pocket and can help you build a lean-to significantly faster than with only a blade.<p>The take-away, of course, is that what's important is not the feature list, but the <i>use case(s)</i>.<p>Joel Spolsky, via arethuza on this page [1]:<p><i>"Unfortunately, it's never the same 20%. Everybody uses a different set of features."</i> [2]<p>For those who end up choosing a Swiss Army Knife as their best friend, having all that "bloat" around is <i>precisely the point</i>.<p>[1] <a href="http://news.ycombinator.com/item?id=2922104" rel="nofollow">http://news.ycombinator.com/item?id=2922104</a>
[2] <a href="http://www.joelonsoftware.com/articles/fog0000000020.html" rel="nofollow">http://www.joelonsoftware.com/articles/fog0000000020.html</a>
I love this way of prioritizing. At the moment I am looking at "essential features" to do most important task for v1. Then I add another important scenario and I add the related features.<p>What the approach given in the article teaches me is: what features should I really pay attention to. How can I improve the top right corner rather than adding a top left corner feature?<p>This insight, although obvious to many, was what I got out of the article.<p>I am going to list the most used features and make them great.<p>Thanks.
Truly useful features require truly useful data to support them. Many devs are incredibly creative at using the data at hand in innovative and even beautiful ways. The Swiss Army knife syndrome, which I have seen in shopping apps, comes from moving into area features where the data is relatively easy to get, but the usefulness to the shopper is dubious.<p>So, in some cases, the syndrome's cure will be found in finding ways to collect, measure or count something new before adding another widget to the screen.
A classic from Joel:<p><a href="http://www.joelonsoftware.com/articles/fog0000000020.html" rel="nofollow">http://www.joelonsoftware.com/articles/fog0000000020.html</a>
I was just thinking about this yesterday. I was comparing Dropbox with Box.net. I use Dropbox--it's simple and works well. The website is the same.<p>Then I went to Box.net. The list of features was overwhelming. I was interested in whether they had a Linux client and what Mac OS support was like. I gave up.
James Lindenbaum of Heroku used a similar metaphor to describe their development philosophy in this excellent talk - <a href="http://www.youtube.com/watch?v=3BhDLm9jo5Y" rel="nofollow">http://www.youtube.com/watch?v=3BhDLm9jo5Y</a><p>Use a Machete, not a Swiss army knife.
Good points in there - made me wonder how many times is your diagram revisited by a web app's maintenance crew? Probably never. Leading to the question: over how long will app maintenance melt your crisp, clean app into a fudgepile of useless utility?
I wrote a blog post about not building Swiss Army Knives a little while back myself.
What i like about your approach is that you gave actual practical advice on how product focus should be achieved, whereas my post was more philosophical in nature.