I think the insight here for entrepreneurs is that 'web' is not 'enterprise'. Microsoft has spent billions targeting 'enterprise' (to compete with the big software players like SAP, Oracle, Salesforce, Etc) which is structured and deployed very differently than 'web' (where big users are Google, Facebook, Etc.)
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.
This is a fantastic comment, and advice that should be seen by everyone -- especially scrappy startups on YC that have aspirations to turn into said dreaded enterprise.
There is a balance that one has to achieve between agility and stability - but that balance, the agility and stability can all be compromised based on early infrastructure choices.
Sadly, early infrastructure choices are 99% of the time predicated on available budget.
Due to this, there is one infrastructure choice, policy really, that can be made that will provide you with the best available path throughout the life of your companies infrastructure: VIRTUALIZE EVERYTHING
I spend a lot of time in the weeds of infrastructure as I design the physical cable-plant and data center environments that people shove all their stuff into - I cannot virtualize physical cables - but I design the plants around the idea of virtualization.
This means that you want to collapse your traffic to as fat a pipe as possible as quickly as possible. Allowing you to run minimal physical cabling.
as you grow as a company, and you get to a point where your services will transfer from hosted infrastructure to owned infrastructure maintain as much virtualization as possible which will allow you to pivot easier higher in the stack.
With virtualized storage now, the only thing you cant virtualize is your actual transit.
It's funny how net diags now just look like a bunch of tiny clouds linked together then simply to larger clouds.
Is the biggest takeaway from why Myspace cratered really that they migrated their technology to a .NET stack?
That seems ridiculous to me.
The being in L.A. thing might be less ridiculous, but I also find it hard to believe that there aren't boatloads of developers in L.A. who couldn't add value to a social networking site.
The reasons that come to mind for why Facebook initially started to attract users away from Myspace are that its profile pages didn't look like the Trapper-Keeper of a 14 year old, and the fact that it had exclusivity from being associated with Universities.
edit(I forgot this one as well): Also the shift from having to seek out your friend's pages to having their updates show up on your main page seemed like a big differentiator.
You can chalk the enhancements made to Facebook after that point to their underlying technology, but I really don't think ASP.NET was responsible for why Myspace sucked.
Agreed -- even the technology problems he mentioned seem to have a lot more to do with MySpace's own architecture than the underlying platform.
That said, I think he could have better put it by saying he thought MySpace needed rock star developers, and that they had a harder time getting rock star .NET devs. I'm still not sure that's actually true, but at least it's a little more reasonable.
Anyway, I'm pretty sure Facebook was already eating MySpace's lunch before they even made the asp.net switch. Maybe not in pure numbers, but definitely in momentum.
Edit: Not that I think MySpace needed rock star developers, just my take of what Scoble was trying to say.
I usually like what scoble writes, but this is such nonsense. Myspace would like to believe that they were let down by Microsoft or LA, but the fact remains that they were playing with marbles compared to Zuckerberg's chess.
They could have matched Facebook feature to feature and that too the very next moment. I can guarantee that it would not have changed a thing. Google came out with numerous social plays with better strategy, scale and speed without much success.
Finally if Myspace could not change fast enough it cannot be attributed to the platform. In hindi we have a saying, "naach na jaane aangan tedha"(calling the floor crooked, when you don't know how to dance).
Silicon Valley might be awesome for its talent, but I would bet that there are enough awesome developers in any metropolis to make any web company successful. You need to be a place which needs to be able to attract such people. Being in SV would not have changed a thing, as no good person would have wanted to join Myspace.
I'd say a startup based in LA and on MSFT makes life tougher, but not impossible. Developers in LA are scattered and there's probably less of them than SF. And there is less info and components out there to do complex stuff in the MSFT stack. (I work at a MSFT-based startup in LA, so I speak from experience).
At any rate, you can still make it work. Google has an office with developers in Santa Monica (west LA). And StackExchange is a great example of making the MSFT stack work.
By the way, any MySpacers here that got laid off or looking to jump ship?
I'm a developer at Leads360 in El Segundo, CA. And we're hiring developers right now! I've interviewed several MySpacers already and extended offers to a few. We hope to get more :)
To suggest that MySpace couldn't have changed their product due to a technology stack they moved to (I'm speculating a bit here) rather late in the losing-out-to-Facebook is pretty silly.
Even if close to true, it would be their specific architecture, not the stack.
You can try to blame Myspace's "death spiral" is due to their tech stack, moving to L.A., but the root cause is their inability to innovate. It was virtually the same site in 2010 as it was in 2002. Think of how many new features Facebook has launched and relaunched in that time. There was a time when many people enjoyed their custom designed profile pages. But then they grew up and MySpace didn't.
I attended a ColdFusion conference back in 2004-5 time frame where one of their top guys was brought in to talk about their success with BlueDragon.NET to allow them to run CFML on .NET as they transition to Microsoft's stack. They talked about how they were posting dozens of revisions a day and things would break regularly. He joked about how when the site went down a little flash game would come up and people started asking for the site to go down again so they could play the game.
Sounded like a mess and other developers in audience felt the same way. Then I signed up and saw how bad it really was as half my searches resulted in errors and the design sucked, among various other issues. Facebook was just awesome in comparison. I think MySpace's death spiral can be almost completely attributed to their lack of professionalism, for lack of a better word, from the start and the only way to remedy would have been to start from scratch.
Wow - weird that highscalability put up and edited version of my comment on Scoble's blog.
I have a bunch of friends from MySpace and one common theme I do hear is that they feel that a better architecture (not connected to the stack) would have let them ship stuff quicker.
The interesting thing here from Nick Kwiatkowski's comment on that page is MySpace did a lot of things you'd often see on advice posts here - like "Rearchitecting/rewriting from the ground up is almost always a fool's errand". It seems like there is a limit to technical debt you can endure. If you rewrite too quickly, you'll be made fun of as the company which killed their product by trying for a massive rewrite/re-engineering effort. Take too long and somebody like FB gets to ship features very quickly and leap ahead of you.
"It wasn’t lost on me that yesterday when I was at Y Combinator several of the folks involved there bragged that Ashton Kutcher visited the headquarters a few weeks ago."
What on earth does this mean? I thought the ashton kutcher meme was simply down to his meteoric popularity on twitter, but this implies that there is something startup-specific about it.
To be honest with you, I don't care for Ashton Kutcher as an actor -- but I am very impressed with him as an angel investor.
I don't know who his tech handler may be (if any) but they get him exposed to some very interesting projects, and I think that he has made some great choices on his investments. Further, his lending of some of his celebrity to (twitter and otherwise) is a good thing for those that he invests in.
I can say, that if I were in his shoes, I would be doing exactly what he has done -- take the money made in his industry and invest heavily in tech.
In fact, based on his broad range of exposure alone, I would be very interested in his opinion as an angel investor in my projects as I do think he has a pulse on contemporary tech and how well it could be adopted.
Whether that is due to his own acumen, or that of some staff of tech advisory (or just friends) that introduce and connect him to deals is unknown.
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.