I have written previously that given the huge scale of the Internet, services that might historically have been considered a feature can now be companies.   There is a critical success factor though to achieving Internet scale that I think is being widely ignored: intentionally keeping a service “underdetermined."  What does that mean?  A service is underdetermined if it allows for many use cases including ones that were never possibly anticipated during the creation of the service.  Conversely, a service is overdetermined if the creators have a very specific use case in mind and build lots of features to support exactly that use case.

The growth of an overdetermined service is heavily constrained.  If the features don’t meet someone’s needs, then the more features there are, the harder it will be to "co-opt” the service for their use case.  When I talk about this with entrepreneurs, I jokingly give the example of where Twitter would be today if the service had been built strictly as a way to share information about baseball games.   I then go on to describe a bunch of awesome features for selecting which game, which inning, which player the information is about.   It’s easy to see how you could come up with a myriad of features to support this one narrow use case.  That would be an extreme example of being heavily overdetermined.

Being underdetermined is hard though.  Much harder than it would appear.  First, it is generally much easier to have a specific use case in mind.  Second, early adopters often use a service in a particular way and tend to be power users who want more features added to the service to support their own use case.  Third, if a service isn’t taking off immediately, there is a temptation to add features as a way to drive usage (“if only we had feature x, people would start to use the service”).  That tends to be a fallacy most of the time, unless x is actually critical to any use of the service.

I am not sure that there is or even can be a recipe for building a successful underdetermined service, but there are at least three lessons that I can identify

First - question every feature.  Does this feature support one highly specific use case or is this something that supports many use cases?  When in doubt, leave a feature out.

Second - avoid “pollution” from use cases.  If someone is using the service in novel ways, their usage shouldn’t pollute the service for others.  For instance, services such as Tumblr and Twitter make that easy because if someone uses it in a way you don’t like you simply don’t follow them (or unfollow them).

Third - and this one should not be controversial - launch with an API or make an API available shortly after launch.  This lets others add features for supporting specific use cases on top of what you are doing.

There is an important corollary to all of this for entrepreneurs.  If you are starting something new and you describe your startup as “this is [like service] x for [use case] y” – make sure to ask yourself whether use case y really requires a separate service or is already sufficiently well covered by (possibly underdetermined) service x.