The Lean Startup method in 2 easy steps

Over this year I’ve been trying to adopt a growing number of lean startup techniques into my projects. I often try to explain how this works to people. Here are the parts which define the method for me.

Waffle

Your job is to get something built. To turn the vague, wobbly ideas of the client, team or your business partner into something solid and touchable (or clickable), you have to do a heap of work. Loads of work.

The problem is, if that original idea is wrong then you’ll spend a lot of time building the wrong thing. You’ll “achieve failure”. That uncertainty – the differences between what should be built and what everything thinks should be built, is the uncertainty of doing business these days.

Lean start ups are designed to cope with extreme uncertainty. A start up is inherently highly uncertain. You have no customers, no revenue, no history. This means you don’t know what people really want from you nor what they’ll pay you. While the uncertainty falls as you do market research but it never turns hypothetical “I would buy that” into concrete, revenue-generating “I will buy that now”.

But the certainty that a specific person will buy something isn’t enough to base a business on. I could build the most amazing product, setup the entire company and sell it to the 20 people who said they’d buy it only to find that no one else will buy it. I got my 20 sales, made a couple of hundred dollars and … that’s it.

But my market research was entirely accurate: 20 people will buy it. My inference from the market research was entirely false: that is not a representative sample.

And then there are products which simply can’t be understood by people. There are many things that people wouldn’t buy or use until they exist such as Facebook, SMS, Television, email.

If there is uncertainty in the project, the lean startup method will help minimise the waste associated with reducing uncertainty and the associated risk. There’s a lot of negative stuff in that sentence: risk, misjudgement and waste.

The risk is that you (or you client or team) have misjudged the market. A huge misjudgement means you build something that people simply don’t want while a smaller misjudgement means you don’t quite hit the spot and get fewer sales than you could have.

Importantly, the misjudgement doesn’t mean you shouldn’t both at all. It means you need to learn a bit more. We’ll come back to this later.

We all want to minimise waste because there’s nothing to be gained from waste but how do you move forward from this crippling position of uncertainty, risk and waste-aversion?

This brings us to the 2 steps:

  1. You do less. Much less.
  2. And you do it sooner.

How the Lean Startup method works

A traditional project starts a clear goal in mind and then a series of steps to get there. The goal remains fixed throughout the process – this is what we’re trying to reach because we feel sure that there’s gold over there in them thar hills.

While some project methodologies will break the project down into short bursts of work (e.g. agile, scrum) and others are monolithic, the goal remains the same. Even if your development is split into short week-long sprints, if it doesn’t get to the customer for 12 months you’ve learnt nothing about the correctness of your idea.

The defining feature of non-lean projects is that they take the goal as correct and best, never questioning it between the point of departure and the point of arrival. The goal can remain the same for years, always thinking that this way of delivering this product to these customers for this price is right.

It might be. But it might not.

(As an aside, you often here bitching and moaning within companies about the way things are done, the fact that customers don’t like something or some product that exists purely because the MD love it. These kind of theories should be aired, tested and proven/disproved early so we can all move on. More on that later…)

I visualise the traditional process as a line:

Going wrong

Once you’ve arrived at the goal, it might turn out that there isn’t as much gold as you though. If you’re lucky, maybe there is a little gold. If you’re unlucky, there is none.

The point is that: you didn’t question the goal during the journey.

Lean startups work differently. Rather than having a single plan to get somewhere, you start with a series of hypotheses which can be validated or rejected. This is a stark difference: you have a business hypothesis not a business plan.

Instead of racing off in one direction, putting 100% of your yearly development budget behind a hypothesis, you come up with some tests which get you closer to the best goal. You can visualise this as shorter tests and movements towards a better end:

photo 2

By testing and validating more often, you reduce the risk of entirely missing the best goal. Another way of viewing this is as finding a global maxima vs finding a local maxima.

Imagine being somewhere hilly and trying to head towards the top of the hill. If you do this based purely on what you can see from where you start, you’ll choose the local maxima – the highest point you can see. But when you’re walking around hills, trying to find the top you use continuous feedback. You look around. The lean method works in the same way. Rather than vehemently committing to a specific route to a pre-defined (possibly imagined) top of the hill, we look around at each stage and test what we thought at the outset.

Getting started with the lean method

Every product launch is a hypothesis: people will buy burgers for £2 from this street corner. Write down a fact and what you infer from it. For examples:

– Thousands of people walk past this point and people like burgers. Therefore, we should be able to sell burgers.
– We have a free feature which 10% of our customers use but we think it’s why 80% of them renew
– If we build this app, once it’s on the app store thousands of people will (i) find it on the app store and (ii) download it and (iii) use it and (iv) buy the in-app purchases
– If we offer direct debit as a payment method, our sales will increase

There will be a fact in there – something you’re sure of. But there will also be something you’re unsure of which is conditional based on (usually) a lot of work happening first.

if:
 this huge project is done
then:
 this good thing will happen

It’s very tempting to dive into that huge thing because it’s a clear task. You can be a huge-project-matre. Woe is me for I have 6 months of late nights yada yada. Large projects, long lists of admin and tasks are good so long as the outcome

There is something comforting about starting a large project. It’s an exciting distraction front the unknowns and often (speaking from personal experience), we tend to fill up time with the stuff that we’re good at. And that stuff isn’t necessarily the stuff that matters.

(Incidentally, I would view this as a reason why there’s a gap between what’s technologically possible and what exists as products. It’s too easy, as an engineer or product developer to focus on what it’s satisfying to build rather than what’s going to be a good product in the market… But that’s for another day.)

Where to start and where to go (follow the numbers)
The first step is to produce a minimum viable product.

The minimum viable product is not what you think

It is not really a “product”.

It’s the minimum you can produce to prove your hypothesis.

The canonical example is google ads and a landing page. If users click your ads and try to buy from your landing page, you have real proof that they want what you’re selling.

With the MVP out there, it’s time to measure. Knowing where you really are is key and this is best done using numbers. Cold, hard numbers which tell you whether you’re really improving or in what way you’re improving.

So, if you want to manage it, measure it. For this reason, lean emphasises measurement and feedback from the outset. As you’d expect from a method heavy on testing on hypotheses rather than free investigation, you state your measures / metrics at the outset rather than conveniently choosing the pretty numbers after the event.

When the number come back good… wonderful. Just keep them going in the right direction. When they come back bad, perhaps you need to try something else or to measure something else.

Exactly what you measures matters. Each case is different but there are certain consistencies which are summarised in Dave McClure’s Startup metrics for pirates so named because of its AARRR initialism. This gives us:

  • Acquisition. Users come to the site from various channels. How much does that cost you and how rapidly do they come through?
  • Activation. When the come through, what percentage do anything. What percentage activate some kind of account with you?
  • Retention. And how many of those stick around?
  • Referral. And how many of those refer other users?
  • Revenue. How much does the activated and retained users generate?

This avoids what are termed “vanity metrics”. Vanity metrics are the big exciting numbers which have no baring on the project or company’s success such as total number of sign ups. You’ll notice that the numbers above focus on movement from one stage (e.g. unknown user) to the next (e.g. acquisition). By studying the rate of change through these stages, you know that you’re definitely going in the right direction.

Viewing users in this lifecycle gives you many things, which I’ll cover in more detail in another post. But two important and much clearer views on what’s really going on are:

Firstly, you get a clearer picture of how much you’re growing and where that growth comes from. For example, knowing that most of your revenue comes from new users and you have no referrals tells you that acquisition is hugely important (and your cost of acquisition matters) but also tells you that there might be an upper limit to the number of people you can reasonably reach given your budgets and the reach of your advertising.

Secondly, these metrics give you the shape of your future growth rather than the size of the current growth. If you have sudden uptake by 20 people followed by 1 referral a year per person means that in 5 years you’ll have 320 people. Not bad if the revenue part of the numbers (above) is high enough per customer to pay your costs. But uptake by 20 people with 1 referral per month per person means that in 5 years you have 571,220 people, which gives you greater opportunity of making less per user and perhaps some more interesting pricing options.

This isn’t new

Since reading up on the lean startup methodology, I’ve found that this isn’t a new thing.

In Doing Capitalism in the Innovation Economy William Janeway notes that “cash and control” are critical to any firm. This is: access to cash when it’s needed and the ability to use that cash to try out new things and get out of a difficult situation. (There’s quite a lot more to it but that’s for another time.) The similarity here is that the lean method puts huge emphasis on using less cash upfront, refining the product or company and only scaling up when you’ve hit the product sweet spot.

Another interesting and similar case is in the Innovator’s Dilemma [Ref]. In this, [some firm..?] went very wrong because they bet (almost) the company on a single new type of disk drive bringing in lots of new revenue. In contrast [another firm – who?] tested the water first by asking customers if they would buy something. Clearly the latter’s case is more lean than the former.

If you want to read more

Start with the Learn Startup book: The Lean Startup: How Constant Innovation Creates Radically Successful Businesses

I’ll be posting soon on some maths behind the metrics and case studies of lean startups.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s