It makes me think of a general rule of technology: if something is going to be commoditized, in order to keep your money-flow stable, you want to be an infrastructure provider. That is, you want to create the raw materials used by the people making and selling the commodity. But more importantly, you want to centralize that raw material.
Middle-man for Questions
Even in a seemingly peer-to-peer environment like the Mechanical Turk, there’s a point of centralization: the middle-man who connects together the node asking the question and the node who have the answer. Because the Mechanical Turk is a service instead of a downloadable server, they can avoid be commoditized out of the market, as with email servers: even if the nodes on both ends of the question/answer loop get really big and popular, they’ll still have to go through Amazon, who can slice off a little take.
Web 2.0 Services Are Middle-men
Most these fancy new apps that are on-line services that cater to developers (check out Udell’s comments in the beginning of the latest Gillmor Gang for more on that) can be, and are, in this middle-man position. What’s different from the middle-man gambits of “yore” is that the middle-man are making it easier and encouraging developers on either side of the service to layer on value and functionality.
Older web companies focused on being both the infrastructure and the sales-man. That is, they made the widgets and they did direct sales to customers. On the web, it’s easy to do both (among other examples, as Amazon and eBay do to much success), but if you have to choose one, it’s usually better to choose providing just infrastructure, and letting a bunch of other people figure out how to monetize it.
Spreading the Risk
There’s a huge amount of risk that no one will take up your service, but then again, once more than one person starts putting nice UIs and products on top of your serve, you’ve spread your risk over those two people: if one of them fails, you still have the other.
So, back to the Mechanical Turk (which is always fun to type), Amazon is hoping that someone else will figure out how to make killer apps (or, at least, “stunning apps”) out of the infrastructure it provides. And once those people figure it out, they’ll take little slices of the revenue.
Many people, Google included, have already built question/answer platforms, but, in my mind, they haven’t really done too much with them. The reason, as some of you wonks out there might thinking, is because things like Google Answers aren’t really extendible: they only do the one thing, you can’t microchunk, free, syndicate, and monazite it.
The Closed Doors of Enterprise Apps
Does enterprise software have a dog in this fight? In consumer software, this line of thinking makes a lot of sense. Profit in consumer software relies on volume: the more people using it, the lower the price you can charge, the lower the price you can charge, the more people will buy it, and the more money you’ll make off the thin margins. (Of course, you might be lucky to be in a story only market, and then price isn’t as much of an issue. I’d suggest that few in technology [Apple] are lucky [or smart] enough to be in that kind of market.)
In enterprise software, you don’t have that many users. Indeed, the more users you have, the more support you’ll have to provide, and the less money you’ll make. This support trap is even more terrible because you usually won’t realize it’s hurting you until it’s too late. (It’s a well know, dirty secret of this type of software that it doesn’t really want users, it wants money. But that’s a discussion for another time.)
So what is it that enterprise software can do with this? The problem with a service as a middle-man strategy is that vendors would have to change their perspective from being the one-stop-shop to being
maintainers of entire ecosystems built around their product. This idea is always thrown out there (hence the whole VAR and partner industry), but enterprise vendors don’t seem particularly adept at applying it: like Tony said, “you want me to take it out of your part of the take?”
All value creation is locked in the company, and extra-company developers can’t easily create new ways of using your software. Essentially, you’re leaving a lot of innovation (in the sense of “new software we could sell”) on the table.
Fat and Happy, Slow and Dumb
The problem is that once you build yourself into a one stop shop, you start getting fat and happy. And after getting fat and happy, you start getting dumb. And the next thing you know, you’re loosing money like blood from an axe to the head.
Building up an ecosystem of partners, sub-vendors, and customers can keep you from getting in this slow and dumb state. Everyone says things are speeding up now-a-days: there’s so many moves in the market, so much information, blah, blah, that you just can’t keep up! From my perspective, it’s not stuff is speeding up, it’s that all these people complaining have gotten slow, and the little dudes at the bottom finally have a way to get a dog into the big-time fights.
This of course, is the old disruption angle. While it’s getting tired to hear, it’s getting even more tiring to see how slowly large vendors respond to it.
So, if you believe the idea the threat of disruption, my suggestion is that you move your mind set from defending the chasm to building toll bridges across the it: instead of preventing others from profiting from your innovations and technologies, help them profit from them, and take a cut. The quickest way to provide that help is to simplify your systems, making it easier for other to latch onto the functionality the systems provide; that is, to make your system into a service that other layer on top of.
The Half-baked Part
The half-baked part of all this is that there isn’t really a know, effective way, to convert a company from fat-and-happy to outgoing-and-smart. So far, it seems like the only way to make money/survive in software with this type of strategy is to sell to Yahoo! or run your company so small that making gobs of cash doesn’t matter.
The Paradox of Success
That’s the Paradox of Success for enterprise software: the more successful (money) they get, the bigger they get, the more it costs to sustain them, and the harder it become to do something different, to change, because the risk of disrupting that sustaining revenue is huge. Change is a bad word at large companies, sometimes even a taboo.
The hard part of finding examples of large companies adopting ecosystems is that it’s easy to repackage old technology in new boxes. Marketing can successfully craft the story that a technology has fundamentally changed, when really, it’s just names and packaging that’s switched around. In those cases, it’s only the low-level coders who know the truth: they know they haven’t coded anything different into the systems, it’s all just the same stuff.
So then — aside from the verbosity of all this — the half-baked part is figuring out how to move a large company from the one-stop-shop to an ecosystem’ish based approach. There’s two parts: (1.) how do you sustain the revenue flow to keep feeding the fat-and-happy monkey, and, (2.) how do you change your people’s mindsets fast enough to deliver this type of market and systems that can thrive in it.
Destroy XOR Embrace
On gloomy days, I think the only way it’ll work is to apply The Kinman Doctrine, aka, FtF, that is, “Fire the Fuckers.” On sunnier days, it seems like it’s just a matter of exposing people to the ideas and giving them enough time to absorb and believe them.
It’s the classic fire and brimstone vs. love approach. Too bad the first way always seems to win out.