Prioritizing software requirements

Prioritizing software requirements – am I hot or not?

By Scott Sehlhorst | February 17th, 2006

Campfire image

Prioritizing software requirements

Jason at 37signals recently posted about essential vs non-essential requirements – the software equivalent of Am I hot or not?*
He talks about the prioritization decisions their team went through as part of bringing Campfire to it’s launch. Campfire is an online collaboration application that just launched today. We will talk about how their prioritization approach affects the greatness of their software.

A great way to spot non-essential stuff is to run it through a filter. If the feature is attached to “wouldn’t it be nice if…” or “It would be cool if…” then it’s usually non-essential. Nice and cool are definite red flags.

[Update: Another post at 37signals about how some features just don't matter and how that applies to Campfire]
37signals seems to have a (ruthless | spartan | minimalist) approach to determining features for the 1.0 releases of their products. If the feature isn’t essential, it doesn’t happen. On future releases, they again tend towards the simpler software that can be much easier to use.

Is this “release minimally functional software” approach the exact opposite of what we propose in Getting past the suck threshold. In that post we focus on the critical importance of making sure we have great stuff for the users in the product as soon as possible.

No. The two approaches are very well aligned.
Kathy Sierra’s point (the original source of the suck threshold meme) is that you want to maximize the rate at which you get user adoption. 37signals is doing exactly that, by putting fewer features in the software.

Fewer features in the 1.0 release means getting the product to users earlier, who then provide feedback faster, allowing the tool to be improved more quickly.
For new software, there are no expert users, just novice users. By building the first interface with a single user-class in mind, they can present a clear intuitive interface for those users. As the users evolve, 37signals can add more functionality to support this new user class.
There is an optimal level of complexity/functionality in an application. Some applications fall short (most server log stats packages) by not giving us enough functionality, while others go way too far and become convoluted bloatware (Lotus Notes for example) by trying to be all things to all people. The people at 37 signals seem to be very anti-bloatware. By providing enough functionality for most people to use the application easily, they help those users cross the suck-threshold. By not providing the extra clutter and capabilities for those power users, they don’t make the software better for power users – but they don’t make it worse for the majority of users either.

We’ve shared techniques for prioritizing requirements in the past. We should update that list to include “Build this first” as another approach.

*Likely not a worksafe site (inappropriate content)

5 Comments

Deepak Singh

Posted February 17, 2006 at 2:05 am

As a former product manager, I found the 37Signals philosophy very intriguing. I am still not completely conviced though. I am a heavy backpack user and I like its simplicity. Similarly for Google. The question in my mind is what one means by “minimally functional”. To me that means having sufficient functionality to be usable for the most common tasks the majority of users want to perform. Is that consistent with the 37Signals model? I am not sure. There is also the possibility of a key customer skewing that set of functionality.

Reply to this comment
Scott Sehlhorst

Posted February 17, 2006 at 7:24 am

Thanks Deepak for commenting.

I had a similar sense of “wishing for more features” when looking at Basecamp about a year ago. Although these applications may not be providing the set of features you or I want, 37signals’ success leads me to conclude that they are providing the right set of 80/20 features to get heavy user adoption.

Their market success demonstrates that they are doing something right.

Google is another great example. The delete button that they just added is a great example of your second point. There’s been a loud shout of “thanks” (or “finally!”) in response to the delete button’s introduction. Clearly a valuable feature that many people have wanted. I believe there was even a greasemonkey script that added a delete button to their site.

Thanks for reading and posting. What do other folks think?

Reply to this comment
Scott Sehlhorst

Posted February 17, 2006 at 11:45 am

Also – here’s a good article from eWeek, Why features don’t matter any more, which talks about how hard it is to do what 37signals does, and also talks about why they would want to do it.

Reply to this comment
Michael

Posted February 20, 2006 at 9:50 pm

Having done product management and marketing for five different companies, I can see the value in the “simpler is better” approach taken by the Basecamp folks.

My complaint with most sotware that has been around more than 5 years is that they suffer from insane feature-bloat, not that they’re missing features. A great example is QuickBooks – it used to be insanely weas-to-use about 6 years ago. Now it is practically unsuable for a new user!

I like the 80/20 rule in general. I’ve seen some folks make an argument for “hiding” power-user features under “Advanced” menu – which is a nice enough idea.

BTW – for those interested, I made a detailed post at my blog on some practical challenges in prioritizion that I’ve faced ( http://michael.hightechproductmanagement.com/ ) – and I haven’t necessarily overcome! :)

Reply to this comment
Scott Sehlhorst

Posted February 21, 2006 at 1:40 pm

Thanks Michael!

Quickbooks is a great example of bloat-ware – and even better than Lotus Notes in terms of the feature-creep making it hard to do simple stuff. At least with Notes it was still easy to do simple stuff.

ICQ is another good example.

Great post too. I just subscribed and expect to read more great stuff!

Scott

Reply to this comment

One Trackback

By Regelwerk » Interaction Design und BRM on March 27, 2007 at 1:12 pm

[...] Weiterführender Lesestoff: Prioritizing software requirements – am I hot or not? Prioritizing Software Requirements with Kano Analysis Alan Cooper: The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity. [...]

Prioritizing software requirements – am I hot or not?

5 Comments

One Trackback

Post a Comment