rlucas.net: The Next Generation Rotating Header Image

tech_and_market_reflections

Myspace: Exemplifying the "Worse is Better" Principle

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?)

The Paradox of Quality Site Visitors

Last month I met with a friend who complained to me that his website — a high quality hobbyist community site — received X page views per day, but was turning over less than X / 2 dollars per year in revenue. Doing the math, that turns out to under .15 cents per page view.

Exacerbating this, he then cited a conversation he’d had with a domain squatter (domain troll), who also was receiving X page views per day on a network of typo domains and similar. That domain squatter was making more like X * 5 dollars annually — more than ten times as much money as my friend with the valuable, sticky community!

The paradox, it seems is this: in a pay-per-click driven world, site visitors who want to stay on your site — due to it having the once-much-lauded quality of “stickiness” — are worth much less than those who want to flee your site because it’s clearly not valuable, and hence will click through to somewhere else.

Picoformats – The Lazy, Curmudgeonly Answer to Microformats

I like the idea of Microformats — they’re essentially loosely standardized schemata with a strictly standardized syntax (which plays nice with (X)HTML — hence the “h” in front of hCard, the new groovy Microformat version of vCard). They’re 90% of the way to my new Nirvana of all-text interoperability (I no longer trust binary formats unless the readers and writers are Open Source and old).

But I hate angle brackets, and I hate having to do crap that the computer should be doing.

So, I’m defining Picoformats. It’s like this. You can do a pReview, or pCard, or pCalendar, or whatever — we’ll call it a pThing. If there’s a corresponding Microformat or other similar format defined, you SHOULD include the constituent fields that the format defines as required; if not, you SHOULD try and include the same fields when do you do the next pThing.

You SHOULD write in plain English, or whatever you like. You SHOULD write in the format you like, but you MUST NOT hand-code more markup than necessary, memorize any XML namespaces, or be tied to special-purpose tools.

You SHOULD prefix the constituent parts of your pThing schema with the name of the field, set apart in some reasonable way, like being the first thing on a newline before a comma, like this:

Name: Bob Smith  

or with some easily-added formatting, like this:

Name Bob Smith

or whatever happens to work for you. You MUST NOT freak out if the word you use to represent the field is not exactly the same as in the corresponding schema, although it’s AWFUL NICE if you keep it real close (like “Date Reviewed” instead of “dtreviewed”).

You SHOULD keep all the schema fields in the same document, right up next to each other, and delimited in some easy to dig way like starting on newlines or something.

You MUST trust that Google and its heirs will help people find your pThing, and that smart people like Ana-Maria will help computers understand your pThing. You SHOULD help them both out by writing a parser to a standard format if it’s easy to do.

Now: to write a pReview or two.