Every Project is a Startup

On a recent trip to Oslo I talked to several developers who were working on large projects inside big companies. I had just articulated the Flight of the Startup model and I was struck by how congruent the concerns were between the startups I had been thinking about (and running) and these large projects. Both a startup and a project need a genuine purpose, a path to realize value, the ability to scale, and, in the end, the ability to generate profits.

Here’s what the Flight of the Startup model looks like applied to projects inside companies.


The flight model identifies four phases in the life of a startup (project):

  • Taxi–discover a genuine need
  • Takeoff–identify an economic proposition
  • Climb–scale the technology and organization
  • Cruise–realize profits

In a startup, survival is optional, so a funnel is a good metaphor for visualizing how many organizations make it through each phase. (The percentages here are pulled out of the air.)

2% of startups achieve profit

2% of startups achieve profit

The primary strategy for maximizing value in a startup is capital efficiency. The more experiments you can make for a given amount of money, the greater your chances of survival. If your first idea turns out not to be the basis for a viable business, if you’ve been efficient you can take the remaining capital and apply it to another idea. There are so many unvalidated assumptions at the beginning of any startup that the chance of success without experimentation and adaptation are vanishingly small.

Projects in Companies

Capital efficiency matters to established companies too. Certainly not all companies are wise in their investments, but they would perform better financially if they were. On the negative side, even large companies can run projects so big that their failure would have serious consequences.

A difference between companies and startups is that companies generally have a cushion. There is a magical moment in a startup where you look at each other and say, “We have three months cash left and what we’re doing isn’t working. What can we do differently for three months that has a chance?” The lack of a safety net fully engages the team. Sometimes astonishing results ensue. More often, as evidenced by the funnel, the team discovers that the idea didn’t support a business.

In a company, by contrast, when a project comes to the end of its money it’s generally granted more money. I consulted with a project that started with five people and six months. Eighteen months later it had grown to more than a hundred people and it had never delivered any value. Each time the pot ran empty, bigger promises were made and bigger checks written. Projects in companies only reach a moment where there is no alternative to delivering value now when they have gotten very big and very late.

Projects as Startups

Projects that don’t deliver are a waste of money, time, and human potential. Much of the waste comes from focusing on survival. If projects are supposed to survive, they invoke the Sunk Cost Fallacy: we’ve spent so much already we can’t stop now.

Focusing on capital efficiency provides a different perspective on running projects. What if most projects were supposed to fail? Instead of survival rates for a single idea, what were percentages become survivor counts:

2 projects survive

2 projects survive

Small Matter of Implementation

The flight of the startup could work inside a company, but it would require a substantial culture shift for most organizations. Experimentation certainly happens in the companies I’ve worked with, but it happens before projects are publicly acknowledged. Only a few projects are approved, and those are backed regardless of delays and obstacles.

To treat projects as startups, the organization would first need to learn to celebrate failure: “Here’s our employee of the month. She started twelve projects in the past twelve months, all of which were cancelled.” If those cancellations saved the company millions, twelve cheap ones is worth celebrating. The team that learned to rapidly validate the assumptions behind a project and act accordingly would be the most valuable.

One practical barrier is that per-project overhead is one or two orders of magnitude too large to treat projects as startups. Transparency and accountability are more important to projects run as startups than the “few, big projects” model. The startup/project needs that moment of impending doom to encourage maximum creativity and the moment of actual doom to stop spending money on ideas that aren’t going to work. Tracking hundreds or thousands of projects and quickly cancelling those whose assumptions don’t match reality is an organizational as well as a cultural challenge.

Another objection to startup/projects is reputation. If you have an organization with a reputation for finished, polished products it can be quite a shock to deliberately deploy less-than-complete projects as a way of gathering feedback (I encountered this going from JUnit to JUnit Max). Companies have evolved several strategies to address this. Google, for example, starts products in Google Labs, then the products enter beta testing and eventually (so the story goes, at any rate) become full-fledged products.


My first job was at Tektronix, an electronic equipment manufacturer. When I got there Tek had gone through a string of product cancellations, often late in the product cycle. As a consequence there were engineers and managers there who had never pushed a product out the door. Tek’s management responded by forbidding any product that wouldn’t reach $50M in annual revenue. This resulted in bigger projects based on bigger promises but still staffed by people who’d never shipped. The results of the compounded risks were easy to predict, even though the policy was created with the best intentions.

Software and the capital efficiency enabled by the web and the cloud provide the foundation for an alternative response. Start a slew of products. Explicitly validate the assumptions on which they are based by deploying concrete products frequently. Cancel the ones that don’t check out without predjudice to the participants. Back the winners with the full resources of the organization. Having written it down I see that the startup/project reproduces the proven innovation model of 3M: swarms of projects; fast, cheap validation; ruthless thinning. In an uncertain world, this strategy is the best you can do to achieve capital efficiency. Just ask any successful startup.


Jonathan RasmussonJuly 23rd, 2009 at 8:18 am

Great analogy Kent.

Many project could improve their efficiency and value if they brought this attitude to the work place every day. Thx for the post.

CodeJustinJuly 23rd, 2009 at 5:52 pm

This is a GREAT post mate! I must say that I had the “same” idea about this a few months back and planned on doing a lot of little projects for VERY cheap (since I do all my projects for about $0 – $20) but I got caught up in one big project which was going good but something stopped it… which was ambition.
I know it’s very opinionated but if your talking indie/start-ups (obviously not in THIS post) but using this method I think another factor for solo developers or even really small teams is loosing ambition. So I think the quicker you can get into the second/third stage the better.

Just my 2 cents and I want to thank you for this post since it has inspired me to start on small projects and use this “funnel” effect. Today on my blog I actually just posted that I lost ambition for the project I’ve been working on and so far I have gotten a good amount of serious responses, so I’m not alone with loosing ambition so I think that putting in ambition into the equation would make sense in some cases.

ALSO I can’t seem to find a contact address for you so if you could please send me an email becuase I would like to offer something.

KentBeckJuly 23rd, 2009 at 7:38 pm


Thanks. Finding the right balance between hanging on in case the next feature or the next customer turns the tide and moving onto the next idea is tough. People took me to task for dropping JUnit Max after seven months, but I felt like I had enough data to make that decision.

I think “product a week” is a great place to start, but you also need to be prepared for success. If one of them takes off, how will you recognize it, how will you exploit it?

My email is mailto:kentlbeck@gmail.com.

[...] Every project is a startup — 7:48pm via Google [...]

Catherine LouisJuly 24th, 2009 at 9:06 am

I love this post. I love this quote “The startup/project needs that moment of impending doom to encourage maximum creativity and the moment of actual doom to stop spending money on ideas that aren’t going to work.”

soooooo true!!!


Ellen GottesdienerJuly 25th, 2009 at 7:25 am

Thanks for you excellent post, Kent. Business managers who sponsor software projects for internal use need to think like product managers (as if the are funding for-profit efforts). They turbo-charge their value using your exquisitely put “swarms of projects; fast, cheap validation; ruthless thinning”.

Herb LainchburyAugust 20th, 2009 at 7:26 am

Excellent post Kent. Thank you. I have just discovered your blog so am catching up. I have been thinking these same thoughts for some time now. I think the ability to run lots of projects, test assumptions, and fail as quickly as possible is the best strategy and I am currently transforming my company to do just that. There are so many ideas and I myself am subject to the tendency to work in a cave for months before putting my idea out there because a part of me doesn’t really want to know that the current idea is flawed. And THAT strategy almost guarantees that my best ideas will never see the light of day. No more.