52 Bicycles

For me, it was March 28, 1999. The day I left corporate life and began the entrepreneur game. Or, as my mother puts it, “the last time you had a real job.”

We as entrepreneurs often get into this game to be independent of the corporate structures that we otherwise find confining. So maybe it’s natural that we resist the idea that there should be any dependencies to the businesses we start. Especially software businesses, which we are sometimes are coaxed into thinking have no suppliers because the code itself springs from our brains into the machine.

But we do. Sometimes we have to think a little non-traditionally to figure out what those upstream dependencies are, but they’re there.

In his recent response to my deep-in-left-field “mashup” idea I used to illustrate a point in an earlier post, Mike at Blinklist (who seems to be doing a lot of things right, and is a guy to watch) says the following:

For example, I think that just being a tool for del.icio.us would be a very big mistake. You cannot build a business that is 100% dependen[t] on another service.

But even we software companies are dependent on other products, services and companies. Not every supplier is a commodity that can be switched out. In fact, a lot of great businesses have been built with upstream dependencies. So vying for independence in that form doesn’t make sense.

Under the surface of our conversation is a dichotomy: platforms vs applications. Those who aggregate reader-generated data are creating sustainable competitive advantage that can be applied to a number of applications. Thus the database owner is the platform, on which the applications run. And that’s appealing to a lot of the dreamers out there: the path to being the next eBay or Microsoft.

If so, the game needs to be establishing credibility that the platform is available for applications. Because there is no way that the company that excels at being a platform can (in the short term) excel at providing the applications as well. And generally in the early market there is no need - witness delicious, with a mediocre application, gathering a huge userbase and database.

But being the “killer app” is a position of power, because it controls how the platform crosses the chasm. Aldus saved Apple, and took a lot of the profits from whole product sales particularly in the early years of the Macintosh. Lotus made a mint with 1-2-3 driving 8088/DOS purchases. (Am I showing my age yet?) Both these companies grew pretty large - even though they were applications (largely) dependent on the platforms.

So the question is, can you do it all? Can you be both the platform and the application? In an early market, multiple platforms will not survive, but multiple applications will. And the platforms that survive will be those that surround themselves with the elements of a “whole product” that includes the key applications for their customers. And I don’t think that a startup can avoid integration by building it all. Certainly we don’t.

Mike says that BlinkList does both of these (platform in the form of quickblinks, and application in the form of quickstart) “fairly well.” Maybe - I had a generally ok impression of what I saw in the 15 minutes I gave it. But even granting the premise, “good” across the board is far less interesting than a single point of “great.” And as long as one is spreading one’s precious few resources all across the value chain, the likelihood of the latter is diminished.

Let’s all get off the absolutist “just a tool” and “100% dependent” hobbyhorse. All things are relative, and, the radical wording of my deservedly-named “weird idea” notwithstanding, of course there remain possibilities to hedge platform risk, and we all are well-advised to hedge supplier risk in general and platform risk in particular whenever we can, which is not always.

Rather than dependence vs independence, the real question is which is the core of the business: the platform or the application? Is this a platform with an application out there to encourage very early adoption while we seek out applications to construct the various whole products for market segments, or is this an application that is hedging its platform bets (perhaps through supporting multiple platforms)? If the answer is “both” we are attempting internal vertical integration in an emerging technology, and that’s a (forgive me) tall order. Understanding the interdependencies of our enterprises and capitalizing on them is far better and more productive than trying to eliminate them.

Finally, let me make a nod to the “it’s more complex than that” argument, because it’s true in general. And some of the claim of “web 2.0″ in particular is that all the companies and technologies are creating data, all are applying it, so everyone is both platform and application. Hence the idea that mashups are very “peer-to-peer.” I don’t think so - one is an application hedging platform risk, or a platform hedging application risk, but trying to be excellent at both risks both internal complexity (through a high degree of vertical integration) and external complexity (through making it hard to integrate with other platforms and applications). [Note to self: this is an idea worth giving some more thought.]

Embrace your dependencies - Happy Independence Day!

This entry was posted on Monday, November 14th, 2005 at 12:09 pm and is filed under Technology Business. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed. Reddit This