Thursday, September 27, 2007

Compare yourself to open source, not proprietary offerings


I often hear from enterprise IT focused startups that one of the reasons they are going to be successful is that they will have a lower price than [name of top vendor in their product class]. This is very tempting today because its easy to use commodity hardware, put some software on top, and sell it with healthy margins way below what the larger enterprise server/software/networking/storage vendors do.

Unfortunately these types of product plans usually fail for two reasons. First, using commodity hardware isn't a cost advantage, since its available to anyone. You'll have competition at that lower price point, lots of it.

The second reason is open source and advertising supported online services. Its increasingly hard to find product categories that are not addressed by one or both. To beat free you need to have functionality that people prefer. If you're free too, well you still need to have functionality that people prefer.

If you're reading this and you're from a web company or have experience with open source, all this will seem obvious to you, but judging from the list of recently funded startups, there are many entrepreneurs and VCs that haven't grokked it yet. If you come from the enterprise IT world, either as a vendor or a customer, you might look around at the enterprise's Microsoft .NET web infrastructure, their Oracle database, their EMC storage, and think that open source is just a cute toy used only by the long hairs. The problem is that today the enterprise is a late adopter - not a good indicator of where opportunity lies for startups. The late adopters aren't going to buy your widget because you don't have 50 site references, integration with their legacy stuff, or a sales force that can take them on boondoggles to Pebble Beach. So you have to be able to beat the open source or free online competitor used by the early adopters. The early adopters are other startups, government research labs, academia, and web companies. And the software stack for early adopters is rapidly converging on 100% open source, with whatever they've developed in-house layered on top. On the hardware side, its getting harder and harder to find proprietary stuff beyond Intel servers, SATA disk, and a few routers and load balancers.

So if the product segment you're targeting has open source (or free online) competitors, compare yourself in terms of price performance to the open source solutions, not to the proprietary stuff that the late adopters are buying. Does this mean you have to be open source as well? Maybe. Open source conveys so many benefits beyond price that early adopters now prefer it because of superior (and free) support from the community of users, ease of customization, performance, and quality. If your widget is an order of magnitude better on a dimension critical to users, you might overcome these advantages despite being proprietary, but you better be really sure users value your product.

How to determine if your product will sell, part 1

Over the last two years I've consulted with a number of startups, sometimes helping them launch products, sometimes writing product plans, sometimes helping them raise funding. I've also looked at over three dozen product plans either via interviewing or competitive analysis. Most of these companies are founded by people smarter than me with Ph.D.s from fancy computer science departments.

Despite the quality of the teams, I've found that many startups seem to miss one fundamental principle. That is that the product has to deliver value that a customer cares about. Seems pretty obvious huh? Unfortunately I'd say about half the startups are working on products that don't deliver any value that a customer cares about. Even after they test the product with customers or launch the product and get minimal adoption these startups continue on, sometimes for years, with the same product plan. Hope springs eternal, perhaps because the entrepreneurial bias towards optimism clouds a frank analysis.

Determining value is not rocket science - do some focus groups, test the product yourself, compare the product to competitive solutions. One source of the confusion seems to come from how to measure "value to the customer." Something that I see often is the customer is asked "Do you want X?", where X is a feature that is unique to the product the startup is working on. The customer usually says yes, because more is better. This yes is taken as proof that the product plan is a winner, if only [fill in obstacle of the month].

So how do you measure value? Obviously adoption is one clue, but usually we need some indication early on when designing the product. The thought process I use is

                differentiation x customer's problem rank
value =    ______________________________

                  relative price


Differentiation is the feature set unique to your product - presumably these features solve one or more customer problems. Customer problem rank is the priority of the problems the product addresses. For example, if you're selling a product that solves three minor annoyances near the bottom of the customer's priority list, chances are your product will not be noticed. On the other hand if it solves the top priority, chances are your product will be purchased. Relative price is the price of the product, compared to both competitors and to substitutes.

Again the above seems pretty simple, but most of the time these components are not accurately grasped. To measure the priority of the problems the product solves you really have to understand the entire environment the product is used in. Maybe you're selling a new type of ethernet router which is undeniably faster than every other router. But the customer won't buy it if their bottleneck is in the server.

To address this I explicitly ask the customer what their problem ranking is at the start of every customer interview. Not just about the category of products I'm working on, but overall. If the customer says something vague like "Its important", don't take it as a given that the benefit is high on their priority list. For an item to be high on the priority list two things are usually true:

1. There has to be a visible monetary benefit to the customer that will substantially impact their business bottom line. Dollars saved or dollars earned. This is of course an business focused question - for consumer goods, there are other considerations.

2. Ask the customer where they would use the product. If the customer is really interested in your product, they will immediately begin thinking about this anyway. If they aren't thinking about it, they're probably not serious. This question will also help identify dependencies and integration points that can make or break your product.

Often product categories go through adoption cycles that may last years - during the 90's enterprises and ISPs were buying routers like hotcakes because the router was a bottleneck. The faster router could win the deal, but after a while, the category ceases to grow, the vendor list shortens to two or three, and upstarts won't get much traction regardless of how differentiated their product is because the customer simply doesn't have any issue with that category of products. If your startup is working in a category like this, you either have to be an order of magnitude cheaper, or you should consider a different market.

Since price is often a differentiator claimed by startups, I'll address price in a future post.

Wednesday, September 26, 2007

Synchronous Communication + Profiles + ?

The last few months I've been working on a Facebook application that brings together some ideas that seem under-developed on the web. The idea combines synchronous communication with Facebook (or MySpace) profiles, a people matching algorithm, and a variable fourth element. The fourth element defines the "for what" interaction between the people.

One example of this idea is a "web presence" application that works with a browser plugin. The plugin detects the URL you're browsing at any given time, and it finds other people who are browsing that same URL. It then creates a toolbar on one side of your browser and shows you the profile pictures and names of other people browsing the same URL. If there are many users on the same URL, it employs a matching algorithm to show only those who have similar interests. Where does it get the pictures, names and interests? The Facebook API.

So if you're single and watching a video on YouTube, you might see a cute woman's picture come up on the toolbar, you click her image, send her an IM and/or the IM client will setup a 1-1 audio and video link between the two of you so you can talk about the video. Much like meeting someone at a party. The matching algorithm ensures that you only meet people in your geography, age, and interest group. On a more serious note, maybe you're reading your favorite programmer's blog, and you see the name of another programmer reading the same blog post about Rails fragment caching techniques. You click on his image an initiate a conversation about solving similar problems on your respective projects.

There are several sites and plugins that do part of what I just described. Weblin and Peeko Chat do some of what I just described, but don't integrate the essential element of existing Facebook profiles. These are key for two reasons - first Facebook provides a potentially viral distribution mechanism, and second the application is just anonymous chat without it, which just not interesting. On the other hand, most of the IM clients like MSN Messenger and Skype enable synchronous communication but you can only talk to people whose screen names you know, not strangers who share the same interests. These clients also have a laborious contact -add procedure, so are not good for spontaneous conversations with people you don't know.

Social networking sites are growing like weeds around us, but few leverage real time two way interaction - sites like facebook, digg, youtube are all about asynchronous exchange of information. Asynchronous interaction is somewhat of a legacy of inadequate technology - we humans tend to prefer real time interaction and real time gratification, so its safe to predict that the general concept will see adoption. One example is sites like http://www.crunchbase.com/company/woome who are making online dating a real time application.

Given that the backend infrastructure for live 1-1 video, audio, and chat is non-trivial and applicable to many types of sites, this also means that offering a turnkey backend infrastructure as a service might be a good idea.

Anyone interested?

Tuesday, September 4, 2007

Rails Restful Routes for Facebook

So you start a new Ruby on Rails application specifically for Facebook. You want to hang with the cool kids, so you're using RESTful routes, but you find out that all facebook callbacks are POSTs, which doesn't work with the default Rails RESTful routes because the default paths rely on the full vocabulary of HTTP verbs to disambiguate actions.

To address this I first tried using resources options such as


:member => { :edit => :post }

This added the needed routes based on POST, but left the url helpers creating GETs. So instead I went with named routes, creating a new set of url helpers prefixed with the name of the action. All the helpers except index act on and thus refer to the singular resource. I googled around for an example specific to facebook with no luck, so the below might save someone some time. Lets say you have a users class, and each user has_many gifts. To setup the users class to work with facebook, put this in routes.rb:

map.with_options :controller => 'users' do |user|
user.new_user 'users/new', :action => 'new', :conditions => { :method => :post }
user.index_users 'users/index', :action => 'index', :conditions => { :method => :post }
user.show_user 'users/:id/show', :action => 'show', :id => /\d+/, :conditions => { :method => :post }
user.create_user 'users/create', :action => 'create', :conditions => { :method => :post }
user.edit_user 'users/:id/edit', :action => 'edit', :id => /\d+/, :conditions => { :method => :post }
user.update_user 'users/:id/update', :action => 'update', :id => /\d+/, :conditions => { :method => :post }
user.destroy_user 'users/:id/destroy', :action => 'destroy', :id => /\d+/, :conditions => { :method => :post }
end


Next, you want routes for gifts, nested with users, so add this:

map.with_options :controller => 'gift' do |gift|

gift.new_gift 'users/:user_id/gift/new', :action => 'new', :user_id => /\d+/, :conditions => { :method => :post }

gift.index_gift 'users/:user_id/gift/index', :action => 'index', :user_id => /\d+/, :conditions => { :method => :post }

gift.show_gift 'users/:user_id/gift/:id/show', :action => 'show', :user_id => /\d+/, :id => /\d+/, :conditions => { :method => :post }

gift.create_gift 'users/:user_id/gift/create', :action => 'create', :user_id => /\d+/, :conditions => { :method => :post }

gift.edit_gift 'users/:user_id/gift/:id/edit', :action => 'edit', :user_id => /\d+/, :id => /\d+/, :conditions => { :method => :post }

gift.update_gift 'users/:user_id/gift/:id/update', :action => 'update', :user_id => /\d+/, :id => /\d+/, :conditions => { :method => :post }

gift.destroy_gift 'users/:user_id/gift/:id/destroy', :action => 'destroy', :user_id => /\d+/, :id => /\d+/, :conditions => { :method => :post }


end

Run 'sake routes' to see the routes produced. Nice.