One common strategy for establishing this initial relationship is what is sometimes known as the “thin edge of the wedge” strategy (aka the “tip of the spear” strategy).  This strategy is analogous to the bowling pin strategy: both are about attacking a smaller problem first and then expanding out.  The difference is that the wedge strategy is about product tactics while the bowling pin strategy is about marketing tactics.

Sometimes the wedge can be a simple feature that existing companies overlooked or saw as inconsequential. The ability to share photos on social networks was (strangely) missing from the default iPhone camera app (and sharing was missing from many third-party camera apps like Hipstimatic that have popular features like lo-fi camera filters), so Instagram and Picplz filled the void. Presumably, these startups are going to try to use mobile photo sharing as the wedge into larger products (perhaps full-fledged social networks?).

Sometimes the wedge is a “single player mode” – a famous example is early adopters who used Delicious to store browser bookmarks in the cloud and then only later – once the user base hit critical mass – used its social bookmarking features. Other times the wedge lies on one side of a two-sided market, in which case the wedge strategy could be thought of as a variant of the “ladies night” strategy. I’m told that OpenTable initially used the wedge strategy by providing restaurants with terminals that acted like simple, single-player CRM systems. Once they acquired a critical mass of restaurants in key cities (judiciously chosen using the bowling pin strategy), opentable.com had sufficient inventory to become useful as a one-stop shop for consumers.

Critics sometimes confuse wedge features with final products. For example, some argue that mobile photo sharing is “just a feature,” or that game mechanics on geo apps like Foursquare are just faddish “toys.” Some go so far as to argue that the tech startup world as a whole is going through a phase of just building “dinky” features and companies. Perhaps some startups have no plan and really are just building features, likely with the hope of flipping themselves to larger companies. Good startups, however, think about the whole wedge from the start. They build an initial user base with simple features and then quickly iterate to create products that are enduringly useful, thereby creating companies that have stand-alone, defensible value.

This is changing rapidly as new data collection mechanisms are implemented – what engineers refer to as instrumentation. Common examples of instrumentation include thermometers, public safety cameras, and heart rate monitors.

Smart phones are one obvious new source of potential instrumentation.  A person’s location, activities, audio and visual environment – and probably many more things that haven’t been thought of yet – can now be monitored.  This of course raises privacy issues.  Hopefully these privacy issues will be solved by requiring explicit user opt-in.  If so, this will require creating incentives for people to do so.

Foursquare instruments location in an opt-in way through the check in. The incentives are social and game-like, but the data produced could be useful for many more “serious” purposes.  Fitbit instruments a person’s health-related activity. The immediate incentive is to measure and improve your own health, but the aggregate data could be analyzed by medical researchers to benefit others.

In manufacturing, there has been a lot of interesting innovation around monitoring machinery, for example by using loosely joined, inexpensive mesh networks.  In homes, protocols like ZigBee allow devices to communicate which allows, for example, automation of tedious tasks and improved energy efficiency.

In the next decade, there will be a massive amount of innovation and opportunity around the big data stack. Instrumentation will be the foundational layer of that stack.

The next step in this evolution is to create web services that are both federated (APIs) and extensible (Apps).

In my ideal world, the social graph would not be controlled by a private company. That said, Facebook, to its credit, has aggressively promoted a fairly open API through Facebook Connect. Facebook has also been a leader in promoting Apps. For Facebook, creating extensible, federated services would mean providing a framework for Facebook Connect Apps – apps that extend Facebook functionality but reside on non-Facebook.com websites.

Consider the following scenario.  Imagine that in the future a geolocation data/algorithm provider like SimpleGeo takes Facebook Places check-in data and, using algorithms and non-Facebook data, produces new data sets, for example: map directions, venue recommendations, and location-based coupons. The combination of Facebook’s data (social graph and check-ins) and SimpleGeo data/algorithms would create much more advanced feature possibilities than either service acting alone.

With today’s APIs, if, say, Gowalla wanted to integrate Facebook plus SimpleGeo into their app*, they would basically have 3 choices:

1) Embed Facebook widgets in Gowalla.  These are simple iframes (effectively separate little websites) that don’t interact with SimpleGeo.  Gowalla would just have to sit and wait and hope that Facebook decided to bake in SimpleGeo-like functionality.

2) Pre-import SimpleGeo data. This significantly limits the size and dynamism of the SimpleGeo data sets and doesn’t incorporate SimpleGeo algorithms, thus severely limiting functionality.

3) Host an instance of SimpleGeo’s servers internally.  This requires heavy technical integration, undermining the main benefit of APIs.

In a world of extensible APIs (or “API Apps”), Gowalla could instead send Facebook data back to SimpleGeo.  The data flow would look something like this:

(Note how there are three parties involved – @peretti calls this a “data threesome”). This configuration is much simpler to integrate – and potentially much more powerful and dynamic – than the other configurations listed above.  You could implement this today, but it would create user experience challenges.  For example, Gowalla would be sending Facebook data to a 3rd party (step 3), which might (depending on the data sent) require explicit user opt-in. Things become more onerous if SimpleGeo wanted to share its own user data with Gowalla. That would require an additional oAuth to SimpleGeo (authorizing step 4).

Allowing websites to be federated and extensible will open up a whole new wave of innovation.  Ideally some spec like oAuth could include the multiple authorizations in a single authorization screen.  Facebook could also do this by allowing 3rd parties to be part of the Facebook Connect authorization process.  Inasmuch as Facebook’s seems to be trying to embed their social graph as deeply as possible into the core experiences of other websites, allowing extensible APIs would seem to be a smart move.

* I have no connection to any of these companies (Facebook, Gowalla, SimpleGeo) and have no knowledge of their product plans beyond their public websites.  I am imagining functionality that Gowalla and SimpleGeo might include someday but for all I know they have no interest in these features – I just picked them somewhat arbitrarily as examples.

Facebook executed the bowling pin strategy brilliantly by starting at Harvard and then spreading out to other colleges and eventually the general public.  If Facebook started out with, say, 1000 users spread randomly across the world, it wouldn’t have been very useful to anyone.  But having the first 1000 users at Harvard made it extremely useful to Harvard students.  Those students in turn had friends at other colleges, allowing Facebook to hop from one school to another.

Yelp also used a bowling pin strategy by focusing first on getting critical mass in one location – San Francisco – and then expanding out from there.  They also focused on activities that (at the time) social networking users favored: dining out, clubbing and shopping. Contrast this to their direct competitors that were started around the same time, were equally well funded, yet have been far less successful.

How do you identify a good initial niche?  First, it has to be a true community – people who have shared interests and frequently interact with one another.  They should also have a particularly strong need for your product to be willing to put up with an initial lack of content. Stack Overflow chose programmers as their first niche, presumably because that’s a community where the Stack Overflow founders were influential and where the competing websites weren’t satisfying demand. Quora chose technology investors and entrepreneurs, presumably also because that’s where the founders were influential and well connected. Both of these niches tend to be very active online and are likely to have have many other interests, hence the spillover potential into other niches is high. (Stack Overflow’s cooking site is growing nicely – many of the initial users are programmers who crossed over).

Location based services like Foursquare started out focused primarily on dense cities like New York City where users are more likely to serendipitously bump into friends or use tips to discover new things. Facebook has such massive scale that it is able to roll out its LBS product (Places) to 500M users at once and not bother with a niche strategy.  Presumably certain groups are more likely to use Facebook check-ins than others, but with Facebook’s scale they can let the users figure this out instead of having to plan it deliberately. That said, history suggests that big companies who rely on this “carpet bombing strategy” are often upended by focused startups who take over one niche at a time.

Normally stacks are constructed from the bottom up and some layers turn out to be valuable and others do not (Christensen argues compellingly that stacks tend to alternate between commodity and non-commodity layers).

The PC is a famous stack.  In the 80′s and 90′s the most valuable layers were the processor (Intel won), OS (Microsoft won), and applications (Microsoft mostly won with Office). Assembly of desktops became a commodity which Dell exploited (you can still make profits on commodity layers, you just need to take a low-cost strategy). The PC demonstrates how hard it is to predict which layers will become valuable: otherwise IBM would never have allowed Microsoft to own the OS.

The internet is another famous stack. In the 90′s a ton of investment went into the infrastructure layer – switches, fiber, CDNs etc. Innovation on that layer continues (particularly in wireless), but mostly the action has moved up the stack to web apps.

An interesting new, emerging stack is the “geo stack.”  The first layer is latitude/longitude location detection. This is mainly provided by satellites and GPS chips which seem to be getting so affordable they will be in every mobile device soon.

The next layer is connecting lat/long to human-understandable locations. Google Maps, NAVTEQ etc. do this by connecting lat/long to roads. Location-based apps like Foursquare, Gowalla, and Yelp do this by connecting lat/long to “venues.” It seems Gowalla is building their own venue database.  I assume Yelp has built their own.  I don’t know how Foursquare gets theirs. I suspect venue databases will become mostly a commodity as they are fairly inexpensive to build and once built mostly interchangeable.

The next layer is the relationship with the user, particularly getting a user’s permission to track her location.  Apps like Foursquare require explicit check-ins at each venue. Other apps like Loopt automatically check in for you. Building this trust relationship with users could be very valuable.

The next layer is what I’ll call “recommendations”:  giving useful advice to users based on their location.  Maps do this by providing driving direction, traffic info etc. Foursquare is doing this with “tips.” I think recommendations will be critical for geo apps to appeal to Normals.  Geo apps are currently wooing early adopters with badges, games, and the idea that you might have a serendipitous meeting with your friends at a bar.  I suspect these incentives won’t work for the broader population, but recommendations could.  Recommendation data is hard to build and vast, hence could be a very valuable layer. (I am biased here as Hunch is working on this layer).

Social graphs could be a geo layer. It’s rumored that Facebook will be adding venue check ins soon.  Facebook has by far the largest (opt in) social graph.  As the recent Google Buzz debacle demonstrated, it’s not obvious that the people you email with are the same as the people you friend on Facebook.  Perhaps the people you want to share your location with are different than the people you friend on Facebook. If so, there could emerge valuable geo-specific social graphs.

Finally, monetization could be a very valuable layer.  There are (at least) two parts to monetizing location. Getting local businesses to embrace the internet has been very slow going. Companies that make money on local businesses today (Yelp, Yext, ReachLocal) use expensive outbound calling and other “push” techniques to sign up local businesses. There remains a huge opportunity to supplant the yellow pages as the default advertising platform in local business owners’ minds. If apps like Foursquare can build up enough marketing / PR momentum that every restaurant, dry cleaner etc feels like they need to “get on Foursquare” this could finally open the floodgates for local business advertising.

The second part of monetizing location is facilitating and tracking offline purchases. 90%+ of purchases are still offline, although for many of those transactions people do research and make their decisions online. The internet doesn’t get paid for these transactions.  Companies like Milo (disclosure: I’m an investor) are doing interesting things in this space and I expect we’ll see a lot more activity on this layer soon.