A great starting point for practicing agile ideology in startups is The Startup Holy Trinity:

• Agile development for high-velocity product execution
• Cloud deployment for managing operating costs
• Customer development for achieving product/market fit

Pick a methodology and, unless you are already an expert in it, follow it blindly for two iterations. Put incentives that support your team’s blind faith. Make it fun. Make it competitive. Make it understood exactly when blind faith will go away.

Unless you have a very good reason or two why your product can’t be running on infrastructure-as-a-service (IaaS) or, even better, a platform-as-a-service (PaaS) provider, try the cloud. Take the top two reasons why you think you can’t deploy to the cloud and question the assumptions they are based on. Early stage startups don’t have Innovator’s Dilemma but their founders do. Don’t be like those to looked at Windows 3.0 in 1990 and thought they needed their Unix workstations or like the those who laughed at the Web’s clunkiness in 1994.

Customer development is the tricky one. The methodology is iterative and self-regulating but the iteration lengths can vary. It’s easy to know when to initiate blind faith but not so easy to know when to stop. It’s an issue a number of us are starting to think about and one we’ll cover at Customer Development: The Second Decade.

Where I will deviate from the traditional lean startup thinking is on the topic of bootstrapping. I simply do not see the type of fundamental, long-term transformational benefits coming from bootstrapping that I see from agile development, cloud deployment and customer development. Don’t get me wrong, I like bootstrapping, have used it and have recommended it to others in the right circumstances. But bootstrapping has an opportunity cost and there are common anti-patterns that lead startups to under-perform in bootstrap mode.

• Setting the wrong bootstrapping objectives. Prototype? First paying customer? CFBE? I often meet with startups that are bootstrapping to a particular objective with the expectation that it will allow them to achieve something. For example, get a first paying customer and raise venture capital or get to CFBE and then you can recruit an amazing team to take you to $100M in revenue. The problem is that often achieving the objective doesn’t enable the follow-on result. For example, VCs may appreciate that you have paying customers but may not be interested in investing if your market opportunity is small or if the team is not strong. One particularly common mistake is failing to build strategic value. Cash, customers and revenues are important but often it takes something else to build strategic value. It may be critical mass. It may be achieving particular positioning.
• Miscalculating the opportunity cost of bootstrapping. Every additional month of bootstrapping generates some benefits but also has an associated opportunity cost. It’s another month of selling without a sales guy. It’s another month of delaying the roadmap. It’s another month of traction for your well-funded competitors. It is very difficult to accurately estimate the cost of bootstrapping. My first startup, Allaire, bootstrapped on $18K to being funded by Polaris the following year. We got a great deal but in retrospect, we should have raised venture capital sooner. One insidious form of miscalculating the opportunity cost of bootstrapping is ignoring the market. You started bootstrapping four years ago. You are now at CFBE with $5M in revenue. How happy are you? The answer should depend on what has happened in the market you are in. Many bootstrapped companies have a very internally-oriented, sales-driven perspective. They are focused on specific customers, active deals and bringing in cash. What they don’t have is a market-oriented perspective. As a result they end up poorly positioned for growth or, in extreme cases, becoming irrelevant in the grand scheme of things, living dead despite their happy customers, revenues, etc.
• Getting the wrong type of customers. There is such a thing as bad revenue. It comes from customers and partners who you decide to deal with because you are so focused on cash. I don’t disagree with the importance of bringing in cash but there are consequences for dealing with folks who are not aligned with your long-term objectives. They can be a distraction. They cause friction. They force you to make changes to your roadmap. This is a particularly common and dangerous issue for service businesses. The best startups, bootstrapped or not, know the power of saying “no” to customers that are not a good fit. In order to do this and survive, startups need to focus on demand discovery (making it easy for the right customers to find you) more than demand generation (convincing people who you think should be your customers to buy).

Sometimes, trading speed and efficiency now for cost and effort later helps startups reach some form of initial scale which buys them either enough capital or time to fix things before the next stage of growth. Other times, the same repeated trade-off puts them farther and farther behind the 8-ball. Nowhere is this more visible then when a product (or site) has to go through a major re-architecture (re-platforming/redesign).

Have you heard about Amazon’s latest re-platforming project? No? Not surprisingly since Amazon hasn’t had one of those… Great products/sites can evolve and take on best-of-breed capabilities/technologies in a way that’s almost transparent to their users. Amazon is a great example. The site is constantly being worked upon by lots of people. WordPress is another great example, showing the power of the open-source community. Good products/sites can be re-architected or re-platformed with relatively benign levels of user disruption. MySpace is a good example. MySpace had to significantly evolve their initial architecture (a web site built on one ColdFusion server) to end up where they are now. Others, say, the first-generation Friendster and many e-commerce sites, make it painfully obvious to their customers that it’s taking them too long to evolve & improve. Some die in the process.

A common pattern I see is that many successful technology companies have figured how to use what I like to call fluid architecture to manage the balance of trade-offs between the present and the future. Fluid architecture is not just about software. The core certainly is about good software architecture but there is also a continuous improvement process component and a cultural component. The cultural element has to do with two things: (a) a mindset of ongoing, explicit, open and honest discussion about the trade-offs that are being made and their future implications and (b) a commitment at all levels of the organization (not just inside the product group) to not end up behind the 8-ball. Companies that embrace this broader concept of fluid architecture can rebuild themselves on the go and move at the pace of today’s business.

My personal experience with fluid architecture has been very positive. For example, every major release of ColdFusion between 2.0 and 7.0 required re-architecting large parts (20-90%) of the server core while preserving 100% backward compatibility. ColdFusion 6.0 (a.k.a ColdFusion MX, which was the first release after the Macromedia acquisition) was a complete, from the ground up re-build on a Java as opposed to C++ codebase. Those were great examples of fluid architecture at both the product and at the company level. Our technology was excellent but we had done a number of things wrong initially–easy to do when you are the first Web application server and have nothing else to compare yourself to and you bootstrapped on $18K. What we did have, however, was a focus on continuous architecture improvement. We had lofty goals for the company and knew that great architecture would be the basis of our ability to evolve ColdFusion both for itself and to serve as a base for other products (anyone remember Allaire Spectra?). We also had the fortitude to break the bitter pill in pieces and take smaller cost/timing hits release after release so that we never had to take the bitter pill all at once.

Which, in a roundabout way, brings me to the second topic of this post. ColdFusion 8 won the Jolt Award for Web Development. I find that pretty impressive for a product that defined the category back in 1995. Remaining relevant–let alone cutting edge–for such a long period of time is something very few products achieve. The reason, I think, is more than a decade of commitment to fluid architecture.

Fluid architecture is ever more important in the Web 2.0 world of quick and cheap experimentation where prototypes overnight become production web sites after your blog post about the private beta makes it on the front page of Digg.

It is fair to say that we are in a Renaissance of the Web Hacker (v2.0). (The main difference with Bubble 1.0 is the the Web 2.0 Hacker listens to KanYe West while the Web 1.0 Hacker listened to 2Pac. Well, there is AJAX, Web services and a few other bits and pieces but they are less important.) One of the issues I consistently find with some of the startups I’m seeing these days is that they are making important trade-offs about technology, product roadmap, user experience and go-to-market implicitly as opposed to explicitly. That is a core violation of fluid architecture principles and, potentially, a recipe for disaster. Invariably, when I start a discussion on this topic, the team tells me that this is not a problem because they are agile. I beg to disagree. Agile development by itself won’t prevent a company from risking its long-term success through a series of convenient short-term decisions. Embracing a fluid architecture approach in addition to all that Web 2.0 technology goodness is one way for startups to better position for success.

The trouble with the topic, as I’ve written before, is that there are very few strategies for startup success with a high batting average. And startups, unlike blackjack hands and day trades, take a good piece of an entrepreneur’s life. A strategy that is successful 55% of the time will work wonders on Wall Street and in Vegas but may cause an entrepreneur to repeatedly fail her entire life.

Hey, let’s not get gloomy. There is a silver lining. It’s called luck and timing combined with assembling a great team that continually performs quick & cheap experiments. Esther Dyson says: “always make new mistakes”. Make them quickly and cheaply, I’d like to add. 

I ended up giving three talks in one at Yankee today:

• Strategies for Startup Success
• Why Do Startups Succeed or Fail
• The Startup Environment

The questions from the analyst team were excellent. I hope to continue the discussion here.