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)