8 Lessons We Can Learn from the MySpace Incident - Balance, Vision, Fearlessness

A surprising amount of heat and light was generated by the whole Micrsoft vs MySpace discussion. Why people feel so passionate about this I'm not quite sure, but fortunately for us, in the best sense of the web, it generated an amazing number of insightful comments and observations. If we stand back and take a look at the whole incident, what can we take a way that might help us in the future?

1. All computer companies are technology companies first.  A repeated theme was that you can't be an entertainment company first. You are a technology company providing entertainment using technology. The tech can inform the entertainment side, the entertainment side drives features, but they really can't be separated. An awesome stack that does nothing is useless. A great idea on a poor stack is just as useless. There's a difficult balance that must be achieved and both management and developers must be aware that there's something to balance. All pigs are equal. 
2. All business failures are not technology failures.  If management doesn't value people, or know what they need, or give their people the necessary control and responsibility, then you will fail. On the flip side if the development staff doesn't push to do the right things because they either don't know or are intimidated by management, then you will fail. There's that creative balance theme again.
3. Don't setup destructive incentives that destroy innovation. Justin Kruger with a great illustration: By pegging revenue to page impressions it made increases page views more important the pruning tuning and tightening the site.  The deal soured with Google because the terms were around pageviews and clicks. MySpace and Fox decided to target those terms to maximize revenue. The result was that MySpace added unneeded page flow for just about every user action. It destroyed UX and pissed off Google. Our team kept joking with management that we were going to create a MySpace-Lite as a side project from our REST APIs and to get rid of all of the crap. It's highly recommended to use a service oriented architectural internally from the start for just this sort of reason.
4. Enterpise Programming != Web Programming and Intranet != Internet. While there was a surprising consensus that the Microsoft framework was not to blame and that the MySpace programmers weren't either, it's clear there's a vast divide between the tools and development practices required to develop scalable websites versus those required to build enterprise applications.  Enterprise technologies can't be employed out of the box to implement a top internet site. It just won't work. Your developers have to get that. Chuck McManis has the most marvelously insightful comment describing the differences: 
   • When I worked at NetApp we had customers in both sides of the world, what we discovered was that the 'enterprise' guys often had a cadence, it went something like grow, identify challenges, coast, upgrade, repeat. That cycle was built around taking the latest release of 'big player' software, qualifying it, then putting it into production, growing a bit, figuring out where the problems were, talking with their vendor, waiting, getting a new release and then repeating the cycle. But the cadence at 'web' players was sporadic at best and often frenetic, feature request, test, iterate, feature, iterate, test, coast, coast, coast, feature, feature, feature, test, coast, Etc. As ideas struck the 'web' infrastructure folks they would would immediately implement some sort of prototype or test case, then rapid fire come up with features the infrastructure needed to support to maximize this feature. But sometimes they would go long periods, months, where nothing would change (in the infrastructure side, web pages, UX, etc sure but same servers and storage assets). 
   • What I learned from that was that while it was great to have some other company own the burden of the 'base infrastructure' in terms of operational expense (hey you don't need Linux hackers if your not changing stuff at that level, so its a savings in staff etc etc) it imposes a hard limit on the change derivative. What happens if you try to change faster than the infrastructure can change, is that you end up hacking around the limits, and that builds up technical scar tissue that over time slows your mobility still further.
   • So bottom line, you can't continue to pivot faster than your infrastructure, if you're hacking your way around the infrastructure to change, then your ability to change will die by a thousand hacks. If you find your self thinking you need to hack around your infrastructure, listen to that warning and start planning for a more agile base to work from now rather than when we're struggling to keep an old system working while developing a completely new one.
5. Don't let backwards compatibility stop you from going forward. Teyc goes beyond the ugliness issues of the UI saying how it was really the UI architecture that hindered improvements: One key aspect of Myspace is how customizable it is. As any programmer can tell you, this limits the ways features can be rolled out. For example, you want to have a new layout? Too bad. It will break the users customization. You want to add a new button? Too bad. There is not a coherent place where you can add it. You want ajax? How will that break users layouts? 
6. Success doesn't last - change fearlessly. Justin Kruger describes MySpace's management culture as one afraid to innovate and move forward: We also had management that didn't want to piss off users and so we would have 2 or 3 versions of the site out there, and we required users to upgrade to new versions. What MySpace had was Cultural Debt, and a fear of destroying what they had. Facebook won because they were Socratic to the core. Might have hurt Digg, but that doesn't mean they weren't right for trying. Companies like Faceook, Apple, Google, and Amazon are continually releasing new features. If you don't obsolete yourself then someone else will. MySpace responded slowly to the competition, for reasons of technical and/or cultural debt, both processes that set in motion the forces that bring about destruction. 
7. Don't rely on a single customer. Once Google pulled its advertising deal, which was the majority of MySpace's revenue, layoffs began which drained the momentum out of the company. Build a diverse portfolio of revenue sources so you are not held hostage to one company. Or at least put yourself in the position of being independent before that source of funding runs out.
8. Decide what you are. Refocus on where your competition isn't. This is what the new CEO is doing by making MySpace about music discovery instead of being a social network, Facebook has that won for now. This strategy may or may not work, but it seems reasonable. It's easy to say after the fact, but it is the common trait of successful companies to have that vision and use it to shape all decisions and strategies.

Related Articles

• MySpace’s death spiral: insiders say it’s due to bets on Los Angeles and Microsoft by Robert Scoble.
• HackerNews - MySpace’s death spiral
• HackerNews - Did the Microsoft Stack Kill MySpace?
• Did The Microsoft Stack Kill MySpace?

Comments

[Victor Nicollet]

I believe you meant to write "Intranet != Internet".

More seriously, though, I don't really see how a service-oriented architecture can help against higher-ups requiring longer page flows for every operation... this was a misguided corporate strategy issue with no possible technical solutions.

[HighScalability Team]

Whoops, thanks Victor. Agree completely on the higher up issue. But the myspace-lite idea would have been much easier to implement if the backend was architected around services.