What we mean when we say startup

From this perspective, the classic startup of three kids holed up in Dad's basement isn't so different from a division of a large company tasked with designing a new product line for a market it doesn't know.

What's the formula for a successful IT product?

Dazzled by the myth of the visionary entrepreneur (someone able to see a project through relying on nothing but their own intuition), this is the process that is often held up as the model:

1. Identify a problem or need to address
2. Prepare a detailed investment plan/business plan
3. Seek funding and potential partnerships
4. Build the complete product, with every feature
5. Obsessively polish every detail of the product to get it ready for prime time
6. Official launch

The reality is that about 90% of startups fail, and the strategy just described is one of the main causes of this dramatic state of affairs.

After endless discussions with investors, months of development and huge investments, the poor entrepreneur often discovers at launch a complete disconnect between the imagined scenario and reality: the market doesn't respond as hoped, users struggle to grasp the product's value proposition, and half of the “essential” features go completely unused...

Meanwhile, users show completely unexpected behavior, asking for features in directions no one had considered! “These would be really interesting leads to pursue,” people say, if only the budget weren't nearly gone, leaving nothing to do but watch helplessly as all that time and money goes to waste.

Failure rates this high, and the same mistakes repeated over and over, can only point to a systemic problem: the classic business strategy borrowed from the industrial world is clearly unfit for an environment like that of startups, which by definition operate “under conditions of extreme uncertainty”.

The classic business plan, however detailed, is a wholly inadequate tool for modeling the many variables at play in this context and for assessing such a high-risk investment.

A moment of “extreme uncertainty” is the worst time to make high-risk decisions.

In 2008, after years in the California startup scene as both an employee and a startup founder/advisor, and after experiencing firsthand the failure of many projects despite good software and sound ideas, Eric Ries launched a “movement” called Lean Startup, later formalized in a book of the same name, with the aim of finding an alternative development strategy better suited to the unique traits of startups.

Lean Startup rests on this premise: given the extreme uncertainty, a startup's purpose is not yet to build software, make money or serve customers, but to validate its hypotheses about the value it offers, its potential uptake and its growth.

Only then, with a less uncertain business model in hand, can it go back to conventional tools like the business plan to assess realistic growth over time.

The breakthrough of the Lean movement was precisely to apply the classic empirical cycle of “hypothesis, thesis and proof”: dropping the view of a startup as a “bet” based on the entrepreneur's gut feeling, in favor of a scientific approach built on experiments, however small, and objective measurement.

No matter how sure we are that our idea is good, the mandatory first step is to find the fastest and cheapest way to put it in front of its potential audience to gauge how much interest it generates and capture useful feedback as early as possible.

The initial vision that drives an entrepreneur to pursue an idea is only the starting point of a process of discovery. Based on real-world feedback, the hypothesis itself can be continuously changed and refined, ultimately producing a sustainable business prototype grounded in hard data and evaluations, and drastically reducing the initial uncertainty.

The Lean approach advocates short, iterative and incremental cycles aimed at running small, continuous experiments that test in the field every element of a product's vision. A startup's unit of progress is therefore not revenue but the acquisition of knowledge validated in the field.

The key steps of the Lean cycle are:

1. Define a single goal
2. Define an objective metric that represents the goal (number of visits, mailing list sign-ups, users reaching the last page of a funnel, etc.)
3. Build the smallest prototype that lets us run the experiment
4. Run the experiment
5. Analyze the resulting metric

Step 3 is called the Minimum viable product (MVP), and it is the fastest way through the build-measure-learn loop, with the least possible effort.

The shorter and faster the cycles, and therefore the smaller the MVP to build, the less waste there is and the more progress the startup makes.

So the unit for estimating development shifts from the “month”, for a complete product, to the “day/week”, for an MVP.

At the end of each build-and-measure cycle, whether or not it succeeded, what you gain is new knowledge validated in the field.

But what happens when you realize that a hypothesis doesn't work?

History shows that a startup's initial strategy is rarely the one that leads it to success. Products we all use every day, like Flickr, YouTube, Groupon or Twitter, started out “to do one thing” and turned into something else entirely (for the curious, here's their story).

The pivot is one of the defining, natural moments of a Lean startup: the point at which, having gained a higher level of validated knowledge, you decide to drastically change strategy while keeping the original vision intact.

The product, then, keeps adapting to enable new experiments, while remaining a “secondary” byproduct of the process.

This is a “mantra” we hear from many prospective startup clients who come to us asking for a kind of partnership we don't see as being as necessary as they think. Starting from a minimum product that can deliver short-term results means, besides the benefits described above, first of all a smaller upfront investment: it means being able to afford it, and not wasting money needed for future development. It also means not having to tie yourself to a technology partnership, leaving room for in-house development only when the right conditions, and a real need, arise.

As an agency, we care a great deal about building quality products and being able to tell success stories. A big product that “dies” shortly after launch is hardly a success, nor a good story to tell. So we would rather help clients spend less and test their ideas, convinced this can lead them to more solid, longer-lasting results.

This makes it easier to build success stories together. We love the philosophy that it works well only if it works for everyone!