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.)
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:
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.