One disadvantage of suffering from chronic pain is that you don’t sleep as much as you want to. But that is balanced with having a lot of time to think. And I was thinking this morning about the prior startups I have worked for, and some of the lessons I learned from each. So here they are (names withheld to protect the innocent):
1998-2000 – Content Management Startup, Denver, CO.
We had a few good development contracts, and things were looking promising, so we expanded our company – opened offices in new cities, hired more staff, expanded our marketing efforts, etc. However, the business did not come together the way we had hoped, and the majority of the revenue for the company came from a single customer. When that customer started to fade, the company was in trouble.
Lesson - don’t base your company strategy on the revenue from a few large customers. Without a diversified customer base, you are at major risk in the case that your large customers go a different direction. Base your strategy on the possible implications of risk.
2001 – Content Authoring Tool Startup, Oregon
I spent 9 months writing authoring tools in Flash, which at the time was used for nothing more than annoying web site designs. I wrote re-usable components to build UIs for business applications, drag/drop UI editors that would export HTML for site designs, and tools to tie these UIs to back-end web applications. Pretty good stuff for 2001.
Lesson - Don’t work in a vacuum Once I had my complete toolkit ready to ship, Macromedia released the next version of Flash, and the new version contained about 75% of the features that I had just written. Had I been paying attention to their direction, I could have skipped most of the development work I did, greatly enhanced the other 25% of my product, and had a great launch of complementary tools to go along with a major release of Flash. Oops.
2002 – Content Management Startup, Denver, CO
Differently flavor on the same product. But this time, it was a small Denver shop, owned by a large German consulting firm. It felt like we were doing great, adding new customers, always engaged in projects… hiring more people… right up until they fired half the company, and the CEO was begging the German parent company to not shut us down.
Lesson - be reasonable transparent in how the company is doing. Us development folk were really frustrated with how the problems were handled. We could have done more to help if we knew what the problems were. Instead, we got blindsided on multiple levels, and lost a ton of trust in the CEO. Small companies need to work together and trust each other.
2005 – Real Estate Startup
I took over development for a real estate startup, providing web sites to brokers in a SaaS model. Unfortunately, the prior dev team left us with a product that did not scale, which led to customer service disasters, and we spent all of our time trying to resolve customer issues instead of developing our product. The founder of the company had offered unlimited free support to his prior customer base in exchange for pre-payment of the monthly fees for a year. That money was supposed to fund the development of the product. It instead just funded the aforementioned customer support. We did complete the next version of the product, but we had already run out of money, and the owner refused to pay the development staff. You can guess how long the company lasted after that.
Lesson - Your business model matters, often more than the technology. A great product that is set up under a bad business model can easily fail.
Overall Lessons -
The product developed for a technology startup is a base requirement to get a company going, but once it exists, other factors become critical. You also need to have a solid business model to operate under, and a market to operate in. Leadership of the organization is critical, in their trustworthiness, their understanding of how to lead an organization, their business sense, and their adaptability.
