In 2006, I was the director of engineering at Odeo, a podcasting startup notable for birthing a side project now known as Twitter. My major contributions were doing the statistical analysis that showed that our podcasting work hadn’t amounted to a hill of beans* and then not complaining when our most reliable engineer wanted to work on a side project. Still, it was fascinating to be in the building during Twitter’s conception and then to read all of the ways that people misunderstood those early days.

Here are three lessons I learned from Twitter that nobody seems to have caught on to.

1. If people use it, it’s valuable
Have you ever looked at a piece of social software and thought, or worse, blogged, that it was worthless? Here’s a trick for evaluating social software in a way that isn’t going to make you look stupid six months down the road: assume it’s valuable if people are using it. Then try to figure out what value they’re getting.

Even professionals make the mistake of dismissing social software despite active, growing communities. Consider this early TechCrunch article, Dodgeball vs. Twitter, where the author (not Arrington) insists that the way to compare software is feature by feature. Dodgeball won the comparison but within a few months was in the deadpool and now Twitter is part of TechCrunch’s everyday coverage. Why? The features that mattered were defined by social interactions, and each user had their own customized set of features based on the social interactions that were important to them. Dodgeball had more features by the traditional measure, but Twitter had the kind that mattered, loads of social interaction.

I even find that this is a good reminder for myself. I follow a startup advice blog from Eric Ries, cofounder of IMVU. The first time I heard what IMVU did I thought it was laughably stupid. They make 3D chat rooms, (like a mini Second Life without the flying), and make money by selling virtual clothing for people’s avatars. Yet he is able to explain IMVU with a straight face and then seems genuinely surprised when people express skepticism.

Here’s the reason he can keep a straight face: IMVU gets 1.3M unique visitors a month and makes tens of millions of dollars per year. He’s not judging the idea based on opinion, which is where most people get into trouble, he’s judging based on observation. Now, I feel stupid for not keeping an open mind.

2. Product, Team, Market? Team.
This is a fun little debate, what matters most the product, the team, or the market? At the time that Evan bought Odeo back from the investors, our podcasting product was widely seen as a failure. It didn’t have any growth and it certainly didn’t make any money for the investors. Here’s how Bryce at OATV put it:

Rockstar team, smoking hot market, all-star angels — and it didn’t deliver the hyper growth traditional VCs need for their return profile.

Was it the product? A year after Ev bought Odeo back, and after zero updates to the features, Time Magazine listed Odeo as one of their top fifty websites. Today, with a very similar product, Odeo.com is the only podcast directory of note. So the product was fine.

Was it the market? Marc Andreessen argues that the market is the only thing that matters for a startup. I just made the argument that Odeo was a strong product and I’m going to argue below that we had a strong team. Since no other web based podcast directory has proven otherwise, it looks like we were in a weak market. So is the answer that the market matters most?

That would look like the answer if not for Twitter, that pesky side project we launched that has had 10x growth in the last year. Market only looks like a good answer if you’re judging individual products, in this case the odeo.com podcasting directory.

A good team, that listens to its customers, is going to find a good market and put together a good product for that market. Steve Blank calls this process customer development (explained well in his book Four Steps to the Epiphany and in this Venture Hacks post).

We could see that Odeo.com didn’t have enough traction so we went looking for other ideas. You might think it was lucky that we hit on Twitter, and as a specific product, it was. If Jack wasn’t on the team, there would be no Twitter. But the team at Odeo had lots of ideas and plenty of people capable of carrying them out. Of the 19 or so people who contributed to Odeo, 13 had started or went on to start a business or major open source project**.

• Evan Williams, founder of Blogger, Odeo, and now Twitter
• Noah Glass, Audioblogger, Odeo
• Jack Dorsey, founded a courier dispatch startup and Twitter
• Biz Stone, launch team at Xanga, founder of Twitter
• Tim Roberts, co-founded BigStep and founder and CEO of Infectious
• Tony Stubblebine (me), founded CrowdVine
• Adam Rugel, founded 71Miles and Trazzler
• Dom Segoia, founder of DollarApp
• Jeremy LaTrasse, owned a tattoo parlor
• Rabble, co-founded protest.net, co-wrote Icalico
• Blaine Cook, started Starling project
• Dan Cederholm, co-founder of Corkd.com, author of Bullet Proof Web Design, many other things
• Kellan Elliott-McCrea, Magpie RSS, icalico

If Ev hadn’t bet on Twitter he would have bet on something else. Three of the companies above are currently live companies that support their founders and a few employees (Infectious is funded and doing well, Trazzler is funded by the Facebook fund, and CrowdVine is profitable). I chose a vertical route for CrowdVine, but the original idea, social networks for everyone, is an idea that’s nearly as big as Twitter (as evidenced by the size of Ning).

Because of the team, Ev had other options to overcome a weak market. So if you’re looking at it from the perspective of the company, team is most important***.

3. Rails was never the problem
Twitter had well-documented performance problems in it’s first few years. Many people, including programmers, pointed the blame at one piece of Twitter’s architecture, Ruby on Rails.

First, all Rails does for Twitter is serve up web pages. The vast majority of those scaling problems came in the back end, moving status updates around and then storing them in a way that Rails could retrieve them for display. So most people aren’t even looking at the right piece of the architecture.

Today Twitter has a much better performance track record and it still uses Rails to serve web pages. The difference is the backend.

So if the backend was such a problem why didn’t Twitter launch with a better backend or at least get it fixed earlier? That gets at the heart of the problem. I’ve never heard anyone get the blame right for all of those performance problems. They stem 100% from the way that we went about switching from the Odeo product to the Twitter product.

When a company kicks off their first project they do some long term thinking and might cover topics like architecture. But how do you launch your second project? Or fifth (approximately what Twitter was)?

Was it easy for the Flickr team to choose to double down on photo sharing, which initially was just a feature inside of a web-based multi-player game? For us, it wasn’t an orderly process at all. It wasn’t even clear that we were abandoning Odeo. We were running hackathons, which led to a condition where many people had competing ideas (and implementations!) of what our next product should be. But around those hackathons we were still continuing to develop Odeo. Twitter eventually won enough that we pulled two engineers off of the Odeo team, but the rest of us kept plugging away.

If you were thrown into a fight, would you start punching or would you open up your iphone and start browsing web pages about Karate? I’d argue that Twitter was launched in the middle of a fight for what we were going to do next, and any thought for long range planning was completely secondary to getting Twitter launched and proven. Without Rails, we might not have even given Jack time to finish the prototype.

So that’s why Twitter wasn’t ready to scale from day one. However, it took almost two years until it could scale reliably, and that certainly seems like longer than necessary. I think it’s an issue of engineering management. Until the Summize acquisition, there was no true engineering manager for Twitter. I had left before Twitter was spun out****. Everyone was a little wary of hiring middle management again since it was widely seen that we had been hired too early at Odeo. The job of middle management is to promote forward progress, and it took us awhile to figure out that wasn’t what Odeo needed. Twitter did eventually hire a VP of Engineering, but he didn’t pan out.

The result was that Twitter operated for a long time (until Summize was acquired) with a gap in engineering planning, someone who could put together a plan that everyone understood and could work from. They had people who could solve problems in brilliant ways, but they didn’t have someone who could get the entire company on the same page. That gap was just an unfortunate side effect of the jumbled team that emerged post-Odeo. So what’s the right way to change your company’s direction? It certainly had nothing to do with Rails.

* Odeo was eventually acquired and is today the only podcast directory of note. However, as a venture backed concern all we had really managed to build was a site with high page rank. We had terrible numbers on repeat visitors and our experimental features (podcast studio, send me a message, audio commenting) weren’t getting any use. Maybe we could have gone after libsyn’s podcast hosting business, but overall our stats said that if we wanted to strike out in a new direction we shouldn’t feel constrained by podcasting.

** Those remaining six include a former core contributor to Rails, Twitter’s current support lead and people that worked for Apple, Google, and Flickr.

*** The idea that Twitter is the same company as Odeo gets muddied because Ev bought the company back, laid off a chunk of Odeo and reincorporated Twitter as it’s own company. But I’d argue the difference isn’t important here. Twitter was launched and run in the early years by Odeo employees who worked at the same desks and the same office that they had when they were working on odeo.com.

**** People often ask me if I regret leaving, and I don’t. I made a list of reasons that included several that would have been sufficient on their own. Did they need me? Not at first, and I hate being idle. Was I happy? No, I was miserable. Every month I had told my team that what we were going to work on was critically important. And every month it had ended up not being important. It taught me an important lesson about what I want from work, to walk in every day believing I’m doing something important. I ended up with the opinion that the only way I could guarantee that was by owning my own company, hence CrowdVine.

Here are my notes from the small business hacks session at Web2Open. Don MacAskill, Jen Bekman, and Bryan Mason were the major guests.

Don’t discount until completion.
Bryan says that when they do pro-bono or non-profit work they don’t discount their work until the client has implemented their advice. I can relate to that. CrowdVine’s second customer got a nice discount because we were looking for reference clients and then the customer changed direction mid-project, leaving us without a public reference implementation.

Don’t ever discount.
Jen’s advice is to offer something that’s got a lot of value and don’t ever deviate from your message about how valuable it is. There’s a low priced option for her art, but there’s never going to be a discount on that option. It’s too valuable to discount.

Don’t do direct sales or marketing.
All three were relying on word of mouth and felt that gave them focus: have an amazing product. Brian said that the only cold call sale they ever made was cornering someone from Flickr at a party and begging them to let Adaptive Path do a rev on the product.

Give each employee two 30″ monitors.
Nothing says you’ll have the tools to do your job than showing up on day one and finding two 30″ monitors. That’s one of many tricks responsible for a 100% retention rate at SmugMug. Way to go Don!

Hire Customers.
Don’s other trick for retention (and also for finding kickass employees) is to hire customers. They take less training, have higher loyalty, and you can observe them before you talk to them.

There’s so much good advice that’s hard to get online but easy to get through word of mouth. It’d be nice to do a monthly small business dinner or something where we could get at these tricks.

In college I had a wonderful Humanities professor who insisted on making us write short essays so we could practice writing succinctly. After each essay she would personally sit down with us and critique our logic (and our grammar!). Her feedback to me was almost always the same, “your argument is logical and supports your conclusion but you need to take the next logical step. What does your argument imply?”

I was never able to take the next step, even when pressured. And she never took it for me. It would be fair to say that I hated her during these meetings.

Today I ended up quoting her while reading Paul Graham’s “You Weren’t Meant to Have a Boss.”

Paul’s thesis is that typical big business drains the life out of its employees because we weren’t meant to work in such large groups. It’s unnatural. To truly live, we need to be in groups small enough that we have room for creativity and freedom of action. That’s the way nature intended.

I agree. Jay and I talk all the time about how much more fun we’re having at CrowdVine than any of our other programming jobs. We’re free to build product. Programming isn’t just a job for us, it’s our hobby and passion. Being in a small group for the first time really is bliss. We’re not the only ones saying that either. Talk to people who’ve been much more successful than us like 37Signals or SmugMug. They’re not just successful, they’re happy.

So while I agree with everything Paul wrote, I found myself screaming, “take the next step, Paul!”

He’s a venture capitalist. He’s promoting programmers joining startups. Venture backed startups start as everything he describes–small companies that are great places to work and learn. But they only stay that way for a few years.

By definition the startups are either going to grow into an awful company with bosses or be acquired by an awful company with bosses (or fail). The startup founders are either going to turn into bosses (which Paul correctly points out isn’t very rewarding either) or they’re going to turn into employees with bosses.

The logical step that Paul couldn’t take is that he’s wrong for being in the venture business. The venture business depends on an ecosystem of bosses. Even if his founders feel like they’re getting a fair trade for a few unhappy years at a big company, they wouldn’t have the option of either growth or acquisition if other programmers couldn’t be pursuaded to work “unnaturally.”

The difference with companies like 37Signals and SmugMug (and CrowdVine) is that while they have the same natural working conditions, they’re structured so that those conditions don’t have to end. If Paul really wants to create good jobs he should turn YCombinator into a small business incubator.

Great discussion of this on Hacker News including responses from Paul. One commenter there made a big fuss that I was technically incorrect to call Paul a venture capitalist. True he’s a new un-labeled form of investor who’s using his own money and experience, and not using money from a venture fund. However I stand by my argument, which is based on the exit pressures which are very VC.