The first version of your software is always the most difficult. There are lots of unknowns. You don’t know what features you’ll need to be successful and you haven’t perfected your pitch just yet. Heck, you don’t even have an audience yet so you have no idea what type of people will be your early adopters. About the only thing you do know at this point is that your startup is going to be so awesome that even TechCrunch editors will have no choice but to write about it. This is when it’s important to have some guidelines to steer you through uncharted waters.
Two Schools
These are the two schools of thought on how to build out a product. The first camp believes every feature is another reason to use the app. These people prefer adding a bevy of features first and refining them in subsequent versions. The other school is religiously minimal when it comes to feature sets. They obsess over getting the user experience and polish of a feature right before moving on to other features. For them it’s a source of pride to launch with a singular feature.
The Debate
Meet Deepak, he’s working on a new check-in mobile app for people who go to dog parks. He’s having drinks with his friend Adam who he hasn’t seen in months. That’s because Adam has been working on a new stealth startup. Why stealth? Adam says he likes the mystery it creates and that’s why 300 people signed up to be notified when it launches. He’s sticking to this stealth thing so much that he won’t even tell Deepak about his startup. What he will say is that the first version only has one feature and he’s spent the past three months refining it.
By the second round of beers Deepak and Adam are locked in debate that goes something like this.
Deepak: Adam, why would you spend three months on one feature? If people don’t like the feature you’re toast.
Adam: Because if I don’t spend the time to get that feature right people won’t want to use it in the first place. While we’re on the topic of features. Why does your app need so many? Does your dog park check-in app really need a search function to find the closest vet? That seems like it should be a separate app.
Deepak: Because it’ll appeal to more people and it’ll get more downloads, duh.
X Marks the Spot
It’s been interesting to watch popularity shift from one of building out large feature sets in the past to the current emphasis on a one-feature, detail orientated mentality. You see this with the current stock of mobile apps and web startups. Path for the iPhone is a great example. It launched with a minimal set of features, which have been iterated on. Sites like Tumblr and Posterous are also good examples. Both make it easy to post and discover content and not much more. These startups typify the current trend of less is more when it comes to features.
Why is Less More?
The bar is higher now than it ever has been. People expect a first-class experience when they use software today. It not only needs to look great, but it needs to be incredibly easy to use and understand. That last point, understanding, is key. In the case of Deepak’s dog park app it may be difficult for a user to quickly understand the point of the app. It’s called “Dog Park-in” but when you open the app the first thing you see is a list of options, many of which are things that have nothing to do with dog parks like searching for a vet.
The Test
It’s a fine line and not one that can be easily drawn. What I’ve done for my startup, Talentopoly.com, is to create a set of mental unit tests that I run through when considering a new feature.
1. Does it help make a current feature easier to use?
Of course it would be nice to be able to post video in addition to photos in your nifty photo sharing app but c’mon, that’s not going to make it any easier to use right now.
2. Will the software still function without it?
Obviously your software needs a login function. Does it? Posterous has built a huge business around not requiring an account to get started.
If the answer is “no” to either one those tests I put it on the shelf.
Keep it Lean
I’ll leave you with this. Make new features have to prove themselves to you before you add them to the software. They may just hurt your software in the end. Keep your feature set lean, launch early, and start getting feedback.