Microsoft - The New API Price Leader?

There was a lot of conversation today at Mashup Camp about (1) the inevitability of key Web services being re-mixed into interesting new applications and (2) the frustration that business models of the API providers are unclear, at best. This is not going to change until the market forces a change. Here’s one forcing function to consider.

My friend Naval Ravikant had a clever post recently about how Microsoft could take a whack out of Google by adding an AdSense blocker feature in the new version of Internet Explorer. While partially a joke, the idea illustrates how MSFT could leverage the difference between its business model and Google’s to the detriment of Google. However, it would probably be anti-competitive. Just blocking ads per se doesn’t create affirmative value for Microsoft. What I am about to outline does.

A major reason that YHOO and GOOG have not published business models for their web services is that their businesses are based on “direct sales” not “indirect sales.” APIs are indirect sales. End users coming to my web site are direct sales. A change in channel strategy is always disruptive in any business, particularly high P/E businesses that missed their numbers once already, as YHOO and GOOG did last quarter. It makes them even more resistant to disruptions from the number three competitor.

MSN is the clear and distant third in the consumer Internet. Microsoft’s core business remains (1) enterprise-focused and (2) developer-centered. Thus far this sensibility has hampered Microsoft’s ability to build a compelling end-user franchise, as least measured by YHOO and GOOG standards. So why not invert their consumer model and move to an API-centric strategy? And what if the APIs were free and unlimited?

MSN has a web services stack largely equivalent to GOOG and YHOO – mapping, instant messaging, search, etc. Why not center the value proposition to attract developers rather than end users? Make the APIs for all of MSN services unlimited and free. That will attract developers from Google Maps and Yahoo search in droves. Have MSN take the lead in the next generation of the Web by turning MSN into a developer-friendly platform. Build the Web around Microsoft APIs, just like the desktop is built Microsoft APIs. So far this sounds like Naval’s idea – eviscerate YHOO and GOOG by enabling developers without benefit to MSFT. So where’s the beef?

If developers adopt MSN services as their content platform, it’s a short leap to get them to adopt MSFT tools as the development platform. (Certainly not all, but a lot). More importantly, as enterprises adopt web development methodologies (mashups, RSS, etc.) to support their own IT, it’s a natural to drive MSFT software products as the internal platforms. Turn Office 12 into the user interface. Turn Biztalk into the mashup engine. Drive the enterprise to integrate business information with MSN services, e.g. mashup major customers and sales locations onto MSN Maps via MSFT CRM. Use the consumer web to drive the adoption of the MSFT tools and infrastructure stack into the enterprise.

The core of this strategy is to stop chasing GOOG and YHOO with consumers and recognize that IT developers are consumers too – consumers who hack. Get them to hack the MSN version of the Web and accomplish two objectives. Put pricing pressure on your competitors and extend your enterprise franchise in one fell swoop.

MSN has a wonderful strategic opportunity. Who’da’thunk?

Comments

[sourabh niyogi]

Not all APIs should be treated equally. There are APIs that are:
(1) monetizable today, like those from AMZN, EBAY, Shopping.com, ... where both the API vendor and the API user make money when the data is used (users clicking on the URLs etc.)
(2) monetizable tomorrow, like the Maps APIs; API users expect ads to be turned on in the future
(3) hard to monetize directly, like the Search APIs (Web/Images/Video/News/..); we see these being accompanied by limits of 1K or 5K per day, because they aren't accompanied with, well, ads.

For (1), there is no muddiness -- we can label the API user a "reseller" and ask what his value add is exactly. For (2), there is varying degree of lock-in; some of the Maps API features are now getting to the point where someone who writes a Yahoo Maps API site cannot turn it into a Google Maps API without working a few more weeks on it.

The muddiness appears in (3). I think that's where your MSFT commentary applies. Lets assume we're talking about one of the search APIs. If an API vendor were to offer such a valuable datafeed for free, people would flock to it, but what could the API vendor get out of it in return?

Some salient options are:
- offer X for free but sell X+Y for more, Y being data (Dun and Bradstreet mentality), Y being software (Flash / Acrobat mentality), Y being service. There has to be a serious tie-in between the software/service and the datafeed in the latter cases.
- offer X for free but make a paid X++ faster/unthrottled. Lots of APIs are throttled already at 1 query / sec.
- turn (3) into (1) -- give the API user a whole widget (like Adsense) rather than a datafeed. We can see widgets in MSFTs experiments already.
- fetter the API results by having paid placement. Shopping.com's API keeps the door open to have this, with a restriction like "the ordering of the API responses must be preserved".

In any case, the kind of lock-in that MSFT was able to win in the 90s (well, at least for few years) will not carry over for, e.g. the Search APIs. These APIs are of the "quick and dirty" data variety: you can very quickly replace one API vendors Javascript include with another, very quickly replace one SOAP/REST call with another, etc. For there to be lock-in, the Web APIs have to be more like, say, Flash/Actionscript, where there is a multiweek learning curve meriting a Wrox or Dummies book on the topic. The Maps APIs are getting this complex (but they are type (2)). No doubt API vendors are going to make offerings so as to make APIs of type (3) into APIs of type (1) soon.

[Xavier Casanova]

That's definitely the future but to play devil's advocate... I don't think Microsoft can do it. You're talking about something that'll take years (particularly for MS which historically likes to keep things closed). Not to talk about the mindshare issue - converting the Google and Yahoo followers. Almost as daunting as going against Google with a new search technology. Too late. Better prepare for the next battle...

[Joseph Hunkins]

Peter -

Excellent and provocative. Ironically I think the developer community does not even realize how quickly they'll switch APIs and API providers as the offerings improve, and perhaps more importantly will switch *monetization schemes* as the offerings improve. Google's big concern now should be that Yahoo and/or MSN will steal away publisher revenues with better deals. I think adsense accounts for approx 40% of Google revenues, (though less of Google profit).

[Mike McDerment]

Great post Peter...I was mulling over simliar ideas back in November in my post called, "Microsoft Getting Disrupted - What is their Strategy?" which is basically a call for them to focus on large data and free it via APIs:

http://www.michaelmcderment.com/article/Microsoft-Getting-Disrupted.html

I a word, I think it's the best strategy left to them...or at least that was my thinking in November when I was thinking about these things ;)

[Jason Kolb]

Interesting post, I like where you're going with it. However, (and I haven't posted about this yet, still gathering information and a reference implementation, etc) don't you think it will eventually end up at an open source API? Short-term I think this would be an excellent strategy for MSFT, but every time I think about this I think that one way or another we'll end up with a decentralized, open source API, that ALL vendors will have to adapt to.