Feature Sequencing

One of the biggest mistakes I've seen companies make over the years is improper sequencing of feature sets.

For instance, if the users themselves are the hubs of a social network, then why would you launch a social networking application before giving people a reason to come to the site in the first place? That's like saying, "Hey, come to my nightclub tonight...nobody's here, you won't meet any women/men, but it'll be popular one day so just drop by and keep coming back until we get hot!"

FAIL!

I prefer to think through feature roll outs in a very methodical way -- I don't take any credit for this either, it's been done many times by many successful entrepreneurs over the years. I just happen to enjoy copying what successful people have done in the hopes of one day becoming successful as well.

In fact, I once attended a talk given by Joshua Schachter of Del.icio.us fame and he pretty much said the exact same thing I'm about to share with you...building the right features at the right time is critical to the success of a product.

In my mind this can be boiled down to a three step framework and if applied properly, could mean faster roll outs, higher quality products, greater user satisfaction and more opportunities for revenue generation.

Here's the framework in a nutshell:

Utility - First create a product that's useful for a single user. For instance, Del.icio.us was valuable long before you were able to see other user's bookmarks. In its first iteration Del.icio.us simply allowed members to store their Favorites/Bookmarks remotely, thus allowing them to retrieve these pages from any computer they happened to be on. Later on they exposed the social content discovery components that turned the service into the viral success it has become today.

Network - After you've made a product that's useful for a single person, there's a good chance that MANY individual people will find it useful. When you attract a large audience of individual users then all you have to do is pull back the curtains and allow them to start interacting with one another. It's obviously more difficult than that, but you get my drift.

Ideally you'd want it so every piece of data one of these users contributes to your site somehow adds value back to the whole network. For instance, on Del.icio.us, each time a user bookmarks a URL it adds to that URL's popularity across the system which provides all kinds of useful information for new users, visitors and members who already have that URL bookmarked. It also allows like minded people to find one another and use these new connections as a way to discover new content (e.g. if another member has a handful of the same bookmarks as me then there's a good chance I'll want to see what else he has in his favorites).

And then this leads to (hopefully) the final step in the feature sequencing framework: Revenue.

Generating revenue has become an all elusive component of this framework. I think there are a number of reasons for this but first and foremost it's because most people save this step for last while it should probably be right up there with the problem you're trying to solve.

While this may be the final step in this particular framework, it should be one of the first things a businessman thinks about. Granted, you can have a wildly successful product (and ultimately, a wildly successful business) by simply building something people love, locking them in through the network effect and allowing the revenue model to reveal itself as time goes on, but in my experience you'll dramatically increase your chances of monetary success if you think this through from the beginning and iterate on it just like you would the software.

Ultimately you'll want your utility, network and revenue models to dovetail nicely into one another - e.g. Google and contextual advertising - so it'll pay to think through this framework in a holistic manner.

What This is NOT

This is not a bullet proof way of thinking through your product development plans. It doesn't even begin to address the many nuances of conceptualizing, building and launching a product. It doesn't address user needs, market size, etc.

Simply, think of this as a "back of a napkin" way of testing your product roadmap. Conceptualize your utility, then figure out how that contributes value back to a network and then think about how to monetize that.

I know it may sound simple and probably pretty obvious, but I can't tell you how many times I've been sitting in on product development meetings and someone is pounding the table demanding that every feature plus the kitchen sink be included in "Product Version 1.0".

By testing your product roadmap against a time-tested framework like this one, you'll stand a much better shot at getting a successful product out the door in a shorter period of time, period.