The Startup Holy Trinity

My last post was about agile ideologies, the practice of suspending disbelief and trying something without too much thinking or tweaking for long-enough to collect quality data but not long-enough to go native and lose perspective.

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.

About Simeon Simeonov

Entrepreneur. Investor. Trusted advisor.
This entry was posted in cloud computing, startups and tagged , , , , , , , , . Bookmark the permalink.

6 Responses to The Startup Holy Trinity

  1. Pingback: Technology By Day » The Startup Holy Trinity « HighContrast

  2. sigh says:

    “Agile development for high-velocity product execution”.

    Man, you are drinking to much agile cool-aid.

    The most important thing for a startup to deliver the product as fast as possible. Let’s be honest about it: Agile, in a lot of cases, is detrimental to this goal.

    • Process should be tuned to the organization. If you are two person hacking, then, sure, you don’t need to hold a formal Scrum meeting, for example.

      I would strongly disagree that the most important thing for a startup to deliver. There are consequences to delivering products that don’t delight customers. Sure, there is learning but in many cases there are ways to learn the easy way. Facilitating this is one of the main goals of a good process.

  3. Eric Jackson says:

    I want to argue with including cloud deployment (although I’m probably on both sides of the argument). It’s the right way to go for long-term scalability, but unlike the other two, committing early can have costly consequences, especially if one goes the PaaS route. It’s easy to (a) waste a lot of time on the learning curve and (b) decide on a platform that turns out to be wrong in the long term. Although I have chosen to go the PaaS route (Azure, in my case), I’m not sure it should be a given for early-stage startups.

  4. rbpasker says:

    @Sigh and @Eric – its easy to do things wrong, so ,yes, if you do agile poorly, or choose the wrong XaaS solution, you’ll be screwed. but if done correctly, you have a huge leg up.

  5. Eric Jackson says:

    Certainly mistakes in any of these areas have negative consequences, rbpasker. However, nothing stops you from switching from agile to another development methodology or from a customer development approach to, say, a more traditional one. On the other hand, it is *much* harder to change platforms in most cases, e.g., from Google apps to Azure. My point is that future switching costs are much more in play with cloud than with the others.

Leave a Reply