Transmutable Postmortem

Now that I have the perspective of a little time away from being a freshman CEO, I'd like to record a few thoughts about my time at the helm. You can read the nitty gritty details in the company and personal blogs so I'll forgo a history and just dive into what lessons I learned.

Though I did (and still do) a fair amount of talking and reading about how to manage startups, I made a lot of the typical production-manager-turned-CEO mistakes:

I didn't reach out to local startup and funding communities. I have a network of startup folks in the bay area so even though I live in Seattle I didn't make time to attend local startup events. While this did save a huge amount of time, I didn't get to know the people nearby who can help out with non-core competencies (see below) and it also left me without local sounding boards when it came time to decide between going for investors or shutting down. I also worked out of my home office for most of the life of the company, but I should have started by renting space in one of the coworking offices downtown. I've heard that isolation kills more companies than red ink and I can believe it.

I bit off too much technology for our tiny bootstrap budget. I think we were onto something with our platform, but I was pretty aggressive in terms of thinking about scalability and the future of the cloud. We built on the (at the time) raw Amazon EC2 cloud, we were pushing the idea of 3D simulation on the web, and I believed that we could wrangle applets into not sucking. Even though I was very careful about scope and our focus on product, I underestimated the time it would take to get to a V1 and then inject it into the market.

I picked the wrong community of peers. I formulated the main ideas for the company while taking part in the game-centric virtual world community, so that is who I talked with the most. There are some brilliant folks in that crowd so it was stimulating, but in the end I spent a lot of time in groups of people who didn't believe that the web was about to consume 3D spaces like it consumed text, audio, and video. We were a web centric company so what I should have done was put out django-sim as quickly as possible and then rally forward thinking web developers around that flag.

I didn't outsource non-core competencies. This was partly fallout from the funding error I mentioned above because there just wasn't room in the budget to pay someone to make our product look like anything other than a developer driven prototype. Combine that with our "build it and they will come" mentality (a typical engineers' outlook) and the result was clearly not up to my personal or professional standards and had very little marketing push to get it in front of our target customers.

I worked myself too hard. I worked long hours and when I wasn't working I was thinking about working. I got divorced and shut down the company in the same quarter. This is not a coincidence. As news spread about this I had many interesting conversations with other divorced startup folks and it's clear that many of those startup heroes sleeping under their desks are there to avoid their home life as much as to help the company.

We had an unusual legal structure. There were good reasons for each decision about our legal and IP structure, but when talking with someone about investment you really don't want to be a scrappy LLC making open source platforms and creative commons licensed art which underpins your relatively small layer of proprietary product. Right or wrong, it's a red flag to many investors.

Luckily, not all of the lessons I learned are based in pain: I hired very carefully and the people I worked with were unbelievably excellent. Bootstrapping has a place in the pantheon of funding strategies, and I better understand which sorts of business model it can support and what a engaging business culture it can create. I fought against the usual communication firewall between my customers and my team and it more than paid for itself in understanding and community support.

It's hard to see these lessons recorded in black and white and they're a lot easier to identify in retrospect than in situ, but I think it's important to get them into the memepool for me to remember and others to read. Also, the folks in my next startup can now linkslap me if I start to make these mistakes again.

Comments

[Ian Smith]

Trevor's list is excellent and very well thought through. I will reinterpret a couple of his points with my own spin.

If you are bootstrapping, I'm not convinced that "build it they will come" is better than taking your limited resources to Vegas and playing the craps table for a few hours. Getting the attention of end-users is extremely hard and expensive; I think there is a great deal of luck in the "viral marketing" stories you hear about startups that get huge from a garage. I'm not saying it doesn't happen, but no matter how good your product is, the background clutter is 1M times bigger. If you are bootstrapping, you need to spend a lot of time devising a realistic "exit from bootstrapping" that has a target you can actually get to without needing to roll 11 three times in a row. A good start, for example, would be to focus on a single, paying customer who is in pain and will buy what you are selling.

Pre-transmutable, I would have been the first person to argue for not solving a problem you don't actually have. However, I failed to police myself effectively on this score. Even those of us that think we are diligent about avoiding things that don't create business value right now fail at it often. To quote 37 signals, "You don't have a scaling problem." My corollary: "And if you did, wouldn't you be happy?" A good rule of thumb that I would suggest, is that any team member can "pull the cord" and stop the product development and trigger a review, if they can make a decent argument that you are solving a problem you don't really have. To follow the gambling analogy above, in a poker game you don't keep putting money in the pot because you have a lot of money in the pot already. Once you know you are beat, admit your loss and think about the next hand. Similarly, if you are 50% done with some software you don't need, just commit what you have to the source code repo and plan to come back to it when you do have the problem it represents the solution to.

I agree with Trevor to some degree about the weird business structure and IP arrangements being a red flag to investors. That said, I will disagree to a minor degree in the large. I think most experienced investors realize all deals are to some extent unique, so I think the biz structure and IP being a red flag is acceptable if there aren't a bunch of other red flags (wrong sr. team, wrong market positioning, or whatever) that add up to a "no way."

I am becoming convinced, not least by my current employers, that open-source software is now becoming a defensible business advantage for a small or medium sized firm; the leverage that can be gained by using other open-source software--which typically requires that you open-source your own software--is worth a significant number of developers. Further, I think that this advantage is defensible simply because the momentum currently behind open-source systems is going to continue for some years and folks that are not allowed (at least legally) to profit from open-source will be at a prolonged disadvantage. Compounding this is that the knowledge, experience, and frankly good taste, necessary to wade through the deluge of open-source software and find the key items of value requires a technical staff of a very different stripe and type of ability, providing a small or medium-sized software company with some differentiation in terms of their staff capabilities.

[Trevor F. Smith]

For those popping in without context: Ian was my CTO.

[Stephan Schmidt]

Nice list. There is always something to learn.

My reasons are different why I failed as a CTO, some of yours I could add to my list.

http://www.codemonkeyism.com/archives/2008/10/27/6-reasons-why-my-vc-funded-startup-did-fail/

Thanks for sharing.
Stephan

--
http://www.codemonkeyism.com