I’d been holding out as long as I could, but the time finally has arrived when I have no excuse any longer not to have a Myspace account. Considering that it’s impossible to hear a Web deal pitch these days without some reference to the 800-pound, Goth-dressing, emo-listening gorilla that is Myspace (be it as an exit comp, a business partner, a go to market venue for reaching a demo, or whatever), it was clear that having some first-hand knowledge of the beast would be to Voyager‘s advantage.
Nonetheless, I had hesitated up until this weekend. Prior to that, I’d visited Myspace perhaps ten times total — usually coming across someone’s personal page that ranked highly for some obscure Google query — and I really felt that each time my browser started rendering the mix of self-administered webcam stills, cacophonous and concurrent music and video widgets playing over one another, ill-considered typographical conventions, and color schemes from visual artists’ professional purgatory, I was actively losing IQ points.
(Nerd alert: I always thought one’s .plan was a perfectly good way to put up a personal profile that your friends could check and that you could, in turn, obsessively monitor to see who’s been checking you out and when. Alas.)
Well, no longer. Speaking with a couple of musician friends who use Myspace to promote their bands finally convinced me to take the plunge (along with the imperative thoroughly to understand the thing for business reasons). And, grudgingly, I must admit, the signup process beat my extraordinarily low expectations for aesthetics, etc. That is to say: the default color scheme is mercifully legible, and there are no Snoop Dogg vids playing while you register an account.
Still: judged by any reasonable standard, Myspace is terrible software. While registering an account, a field failed validation, and the form came back with the checked status of the checkboxes reset to defaults. The password is emailed to new users in plaintext. The cookie / session scheme is inconsistent and various pages “forget” that you are logged in from time to time. The most basic types of usability enhancements — like, say, making the automatic hyperlink to searching on the title of a favorite movie search under “movies” (and music under “music,” etc.) — are unimplemented. In-band signalling proliferates, facing the user with odd directives about pseudo-tags to include in text blocks to toggle HTML escaping.
All in all, the implementation of Myspace would probably get a “D” in Philip‘s MIT class on Web apps. But you can hire an awful lot of “A” earning MIT grads for $580 M.
The lesson here, I believe, is emphatically not that architecture and quality of implementation doesn’t matter. But it does prove that such quality is neither a necessary nor a sufficient condition for outsized success under the right circumstances. The distilled version of the lesson is probably something like this: if you have a credible shot at an acquisition exit (based on some non-earnings and non-quality metric, like user signups), and if you have hit the “hockey stick” of user uptake, then you should not throttle user growth (your putative value metric) in favor of fixing the problems — just do the bare minimum to keep things working while you stoke the fires.
Most startups hold their breath after launch wondering if they can get the dogs to eat the dog food. But if the dogs are ravenously devouring your dog food, however crappy the ingredients may be, it’s no time to worry about QA on the unidentified meat parts. “Just keep shovelin’ it out there” would be the Myspace motto.
Of course, I must return to the “under the right circumstances” caveat from above. Myspace’s growth curve overlapped nicely with a period of compressed risk premia and renewed enthusiasm in acquisitions in the Web space. If Myspace had “blown up” in, say, 2002, and had needed to demonstrate staying power for three years until the M&A environment was ready for an exit — well, then, the kind of archictecture / scalability and user experience issues I mention above may well have been its downfall.
So, entrepreneurs of the world: worse is better in Web software (except when it’s not). And, the answer as to when it is better probably has more to do with macroeconomics and industry trends than with your technology and user demographic. Yet another example of the difference (and the not uncommon incompatibility) between the skills of building a superior product, creating a great and thriving company, and making a huge return on investment.
(Thank heavens for the fact that not all entrepreneurs focus as single-mindedly on the third skill (huge ROI), for many times the ability of companies to reap such rewards is dependent upon the skillful borrowing of innovations from companies that have focused on numbers one and two (product and culture). Identifying such skillful borrowing in the Seattle technology ecosystem is left as an exercise for the reader. My question for economists is, is it possible more justly to apportion the rewards of innovation to the innovators?)