Stealing MySpace is a fascinating book that chronicles the beginnings of the popular social networking site. The book is well researched and does a good job summarizing both the business decisions and sheer chance that took MySpace from a Friendster clone to the height of its popularity.
Back when MySpace first opened up its "MySocial" API (allowing you to create MySpace applications) I was hired to develop a simple app that would list jobs near a user. The API had only just been opened. Documentation was poor, patches would be released only to break functionality, and in general I found it to be about as much fun as a visit to the dentist. I was surprised that a company as large as MySpace could get away with the "build it first, let the customers test it" philosophy. I suspected that given their company culture, maybe they had always been that way.
Based on Julia Angwin's research in Stealing MySpace, that certainly appears to be true.
MySpace's philosophy was "Get it out fast, fix it later," according to chief technologist Aber Witcomb. That philosophy was the antithesis of the Silicon Valley point of view, which values in getting the technology right. [....] MySpace took the opposite approach, throwing a totally unworkable website online and trying to fix problems on the fly—all while constantly adding new features that crashed the site.
How could a company do this and gain market share so quickly, you may wonder.
MySpace users were surprisingly tolerant of the site's quirks, in part because [Tom] Anderson's humorous, self-deprecating blog postings and news updates created a sense of intimacy between them.
It's really not that surprising. Good businessmen have always known that ultimately it always comes down to the relationship with the customer.
The Software Artisan
Any good software developer knows that you need to deliver quality code to the end consumer. Bugs and crashes will drive away users, harm your image, and ultimately benefit your competitors. The culture of testing is a sign that the web development industry is maturing. There are plenty of testing methodologies out there, some of which are sold with the zealotry approaching religious fervor.
There is, however, a balance. Others have capably elaborated on this.
The Entrepreneur
The entrepreneur knows that unless you gain a market share, owning the widget with the highest-quality code is going to be irrelevant. Most entrepreneurs making an early entry into a field are focused on releasing a product that is good enough. In some areas of development culture that's taboo, but there, I said it. Good enough means:
- Sufficient Quality: Few enough bugs that it doesn't drive your customers away.
- Low Financial Cost: Developed at a low enough cost that risks are managed (cost meaning both time and money).
- Low Time Cost: Developed quickly enough to beat possible competitors to market.
As aside: "Sufficient" does not mean "poor." "Sufficient" quality must be prefaced with all sorts of conditions and requirements. Caveat emptor. Additionally, I realize that this could very quickly devolve into a discussion of the old "Good, Fast, Cheap: Pick Two" maxim. It's a maxim because it is true.
What I'm focusing on here is the "Quality." As a developer, I prefer to release code that is well-tested, well-documented, and elegant. As an entrepreneur, I recognize that this isn't always feasible. Herein lies the difficulty.
Furthermore, if you are a developer and you are aghast that I would suggest that there is such a thing as "sufficient" quality, then I hasten to remind you that whether or not you realize it, you (yes, you) have weighed the cost of quality all along. No software is perfect. At some point in the development cycle someone has to make the decision to release.
If you're still with me, then you see the problem here. "Few enough bugs" means different things for different stages of industry maturation. In a young industry, there are fewer competitors and it's more about getting to market first. In a more mature industry, you may already have competitors that are well established.
One of the reasons that MySpace won out over Friendster is that Friendster stalled development for nearly a year while their developers refactored code to make the site more stable. MySpace had shorter, faster iterations: they copied anything and everything ("Hot or Not", Evite) and released it quickly; if it didn't work or attract a user base, they took it back offline.
On the other hand, when Google entered the search engine wars their competitors (Microsoft and Yahoo!) were pretty well established. The frenzied pace would not have attracted a market share. What did work was a faster, better search engine. A parallel can be seen in MySpace's slow, inevitable decline.
What's Killing MySpace?
Ultimately, MySpace never grew up. The social networking market space matured, but MySpace never did. When they released their application platform it was in response to Facebook. Just as they had always done, they played the role of cowboy coder and release buggy code, followed by patches that just muddled the pond further, frustrating both developers and end-users. Do you see a future for MySpace as they are today? I don't.
The Takeaway
Running a business is much like life: it's a constant, never-ending balancing act. One is constantly evaluating the risk of a given decision against the potential reward; weighing the marginal cost against the marginal benefit.
A good artist doesn't want to create something that he's not proud of (which is why artists are often labeled perfectionists). Software artisans are often focused on meeting a business need with well tested, well documented, elegantly written software. What an artisan wants is perfection: but perfection takes time and money, and that increases the total cost. In a young industry, that cost is, well, more costly. It bears more heavily when an opportunity window is only open for a short amount of time.
However, as a company or an industry matures, quality starts to become exponentially more important. If your company is not maturing with the rest of your industry, then your competitors start to eat your lunch. The annals of Silicon Valley are full of businesses that were first to market and then were later devoured by their competitors.
When weighing the cost of perfection, there are many considerations. If you work in healthcare then the cost of data loss or a break-in is far greater than it would be for a social networking application. Assuming the role of cowboy can be very costly, as it was for the bookmarking service Ma.gnolia.
The bottom line is that entrepreneurs cannot afford to be methodology zealots. Entrepreneurs must be risk-weighers who are sensitive to both changes and opportunities.
Your thoughts?
I still consider myself a student of both business and web development. I find this balancing act to be fascinating and I would love to hear what you think about it. If you are both an entrepreneur and a developer, how do you balance your zealousness for quality with your attempts to crack out a market share?
Links
I'm certainly no Web developer, and only a budding entrepreneur, but I will say this tension exists in other professions.
I'm a journalist by training, and the balancing act between getting it right and getting it out there is certainly a struggle with which I can relate.
From an outsider's perspective, I'm interested in how other disciplines approach this dilemma.
