I understand the point behind this entirely.

The Swiss Army Knife metaphor, however, is, in fact, a bad one, thought it seems all right initially.

The key bit is this:

"By combining many products of low utility, it [the knife] becomes a product of some utility."

False. The basic 440 stainless blade is of immense 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.

Sure, the saw pretty much sucks, and the scissors are of minimal use, and so on. That's not the point, though, at all. It's that a Swiss Army Knife allows you to have those things at all in unexpected situations. It fits in your pocket and can help you build a lean-to significantly faster than with only a blade.

The take-away, of course, is that what's important is not the feature list, but the use case(s).

Joel Spolsky, via arethuza on this page [1]:

"Unfortunately, it's never the same 20%. Everybody uses a different set of features." [2]

For those who end up choosing a Swiss Army Knife as their best friend, having all that "bloat" around is precisely the point.

[1] http://news.ycombinator.com/item?id=2922104 [2] http://www.joelonsoftware.com/articles/fog0000000020.html

I agree with you, I should have said "high" utility - not "some utility". I'd update the post, only I'm not keen on re-writing history.

I think the metaphor is correct in that regard, I'm saying that adding on stuff works for the Swiss Army knife - but maybe not for Your Web App.

Thanks for the comment :)

I think the key thing here is to know which problem is being solved or tackled by the product. For those that require an actual swiss army knife adding more utility for them would be useful, but for other applications it would be bloat.

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.

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.

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.

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?

This insight, although obvious to many, was what I got out of the article.

I am going to list the most used features and make them great.

Thanks.

Now that I think about it, using your method, User Registration shouldn't get much love because it isused only once and would end up in the bottom right.

The chart needs the "essential" aspect of a feature or business value?

Well, it's "All of the Users" so it should get plenty of love. But I wouldn't really describe User Registration as part of an app personally. I was shooting for "all of the features inside the app" here.

You have a marketing website whose purpose is to attract people, help them create accounts and on board them successfully. I'd regard that as a separate project and do one of these out again. You'll find it scores highly there.

A classic from Joel:

http://www.joelonsoftware.com/articles/fog0000000020.html

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.

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 - http://www.youtube.com/watch?v=3BhDLm9jo5Y

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.

By all means throw in a link :)

Sure ;-)

I'd love to hear your thoughts on it because product development as a concept is something that has only recently come onto my radar and im constantly thinking about how to improve on it as a discipline.

Here was the first part: http://krmmalik.posterous.com/the-anti-swiss-army-knife

and here the second: http://krmmalik.posterous.com/the-anti-swiss-army-knife-part...

You'll notice an evolution in my thought process from the first to the second.

Enjoy ;-)