James Lewis is the Head of Product at DigitalBridge in Manchester, UK. James also helps to organise Leanconf, Europe's largest Lean Startup conference. Here,James shares some epic thoughts and wisdom on what exactly a Lean Startup is....
Lean Startup is a term that is often talked about in the world of startups and technology but is not necessarily always fully understood.
Some people think lean is simply about spending less money, building something quickly or failing fast. The methodology introduces often-heard terms such as “MVP”, “pivot”, and “build, measure, learn”. Whilst this jargon may be familiar to many people, it is often misused which further muddies the understanding of what Lean Startup is.
In actual fact, Lean Startup is a scientific methodology introduced in a book by Eric Ries to be implemented when starting and managing a new business. The principled approach aims to enable entrepreneurs to build a successful and sustainable startup.
Ah, I see… wait, what’s a startup?
Eric Ries defines a startup as…
“a human institution designed to create a new product or service under conditions of extreme uncertainty”
Ok, so what does that actually mean? Well, a startup is a team of people who are setting out with an idea that they hope can become a viable business.
They believe that the idea is feasible, but they cannot be sure. This is the ‘extreme uncertainty’. They need to find out if their idea will solve a real life problem and if there are enough people out there who will be willing to pay for it.
Although the Lean Startup concepts were devised for startups, the methodology has been proven to work for existing businesses and products. Even large enterprises, such as GE have successfully applied the principles to improve their projects and innovate like a startup.
But why should I care about Lean Startup? I just want to get on and build my product!
A typical approach for an entrepreneur is to think of an idea that she believes people will want to buy. She then spends months or even years to build a team and a product, often at great cost, according to her grand vision.
During this process the team will make many assumptions; about the problem they are solving, the solution they are building, the people they are building it for and the business model they will employ to make money.
Typically, the team will never actually speak to the proposed customers. They will never find out if the problem is real, or painful enough for the customer to consider using their product. They will never discover whether the proposed solution is actually better than how the customer currently solves the problem.
Because of the assumptions made and the disconnect from customers, the product is launched but never resonates with the market. It sees few registrations and paying customers and eventually is abandoned as yet another failed startup.
Ok, so how can Lean Startup help to stop failures such as this?
The Lean Startup methodology looks at the business you are about to embark upon and instead of asking “Can this product be built?” it asks two—more critical—questions: “Should this product be built?” and “Can we build a sustainable business around this product?”
Lean Startup argues that a startup exists to learn how to build a sustainable business. And it should aim to do that in as small a number of steps as possible. Those steps are done by conducting experiments and learning from the outcomes. Lean Startup calls this validated learning!
How does it work?
A core component of Lean Startup methodology is the build → measure →learn feedback loop.
The first step is to determine what you want to learn, and build an experiment to find out if what you believe is true or false.
Next you run your experiment and measure the results.
Finally you analyse the data and learn insights from the results.
If that all seems a little abstract we’ll look at a concrete example shortly.
The Minimum Viable Product
The minimal viable product (or MVP) is probably one of the most misunderstood concepts of the Lean Startup. It is often assumed that the MVP is just a very basic version of the final product. It might be bug-ridden and will offer the user a poor and ugly experience.
A Minimum Viable Product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.
In actual fact, the MVP has a single purpose: it is the smallest solution that enables you to learn whether your assumptions are correct.
The MVP must be usable, and should offer true value to the user, but rather than building out all the possible features you can think of, an MVP focuses on the core solution to the core problem that you are addressing.
Putting the theory to practise
Let’s take an example.
Say you have an idea for a mobile app that finds the best parties and hotspots in town by monitoring Instagram photos and tweets for any particular location. Currently you’re guessing that people are having to move from venue to venue, trying to find the best place to enjoy a night out. Your hope is that if the app can see a lot of photos being posted from a particular bar, you can assume there’s a lot of people there having a lot of photograph-worthy fun!
Users will be able to see where most of the action is happening and browse the tweets/photo streams as they are happening to be able to judge for themselves.
Last (but certainly not least), you decide you will monetise the app by allowing venues to pay for sponsored posts, pushing their party into the user’s party-feed.
I’m going to call this fictitious app, InstaParty! (You should probably find a better name for your product) and the unique value proposition will be:
Instantly discover the best parties happening in your city right now!
The typical way to approach this idea would be to start building an app that does what I just described. Either you’re lucky enough to be a developer with an eye for detail and UI and you would build it yourself. Or you would put together a team to design and build the product. Either way you’re going to be investing time and money to build this product.
Finally, you launch, ideally with some PR and buzz and hope that your idea is so good that enough that people want to use it, repeatedly.
There are a lot of assumptions being made here. Here’s just a few:
People have a problem in that they don’t know how to find the best spots when heading for a night out.
A good night spot can be determined by the number of tweets and Instagram pictures being sent from there.
People want to find party spots using an app.
Venues will be willing to pay to be featured.
The best way to methodically map out all the assumptions that you are making is beyond the scope of this article. There are some great methods though including the Business Model Canvas, and my favourite, the Lean Canvas.
Once you’ve identified your assumptions, you can start validating them.
But how do I validate whether people have a problem when they go out on the town?
It’s simple, really. Just talk to people and ask them.
One of the major mistakes many startups make is that they don’t involve their potential customers from the very beginning. Take time to sit down with a few people from your target market and spend 20 minutes with them over a coffee finding out how they go about a enjoying a night out. Ask them to recount some recent examples and stories. Try to understand their motivations and frustrations. You will be amazed how it unearths problems you didn’t know exist and make you realise that your original assumptions may not have been accurate.
Be careful not to bias your interviews. Try and keep questions open and non-leading. Avoid questions that ask the interviewee to imagine a future scenario (“Would you ever use a product that…”) and instead concentrate on how they solved problems in the past (“Tell me about a time when you…”).
Again, customer development is a topic worthy of its own book, so I won’t go into more detail here.
By doing this though, we have started our journey along the build → measure → learn loop.
You build an experiment to test your theory. In this case you are writing a questionnaire that will test your assumption.
You measure - you have a conversation with a number of people using the questionnaire that you created.
You learn - you review the answers to all your interviews to gain insights and learn if your assumption holds true.
Armed with these new learnings, you can start the feedback loop again by updating your assumptions and validating again. Once you feel you understand the problem to be solved and the people that you are solving it for you can begin to build your product.
Instead of building the complete solution though, you should seek to build an MVP which can be used to learn if your solution is on the right path.
What would an MVP look like?
It all depends on what you’re trying to learn. Remember the MVP is just the smallest thing you can build in order to validate your hypotheses. Let’s look at some examples:
You have proven that there is interest within a small group of people that you have talked to and you now want to validate that your UVP resonates with people at scale. Build a sponsored (paid for) Twitter campaign. Measure how many people engage with the advert. Learn if you need to change your message or angle.
You have determined that people are interested in your idea. You now need to validate if people are still interested once they learn about your complete solution. Build a “smoke test”, a simple one-page website that explains your product benefits and asks users for an email address to join a beta launch. Measure the amount of page views versus email submissions and learn if your offering is working. A happy side-effect of this experiment is that you start building a list of email addresses of potential customers, but this is not the reason we are running this page.
You believe you now have enough understanding of the problem you are tackling, who it is for, now you need to validate if people will find value in your offering. Build a super-basic very lean version of your product for a single city. We’re not developing an app yet, just building on top of existing technology that everyone has access to. In this case we will manually scan Instragram pictures posted in the city and email your early adopters with where the hotspots seem to be. This kind of manual implementation is known as a “concierged” MVP. Measure clicks within the emails and learn how people are engaging via analytics and user feedback. Yes it will be hard work, and of course it won’t scale but you can get this solution up-and-running in days, not months.
You have validated that people are using your product and finding value. Now you need to validate whether you can build a product that can start to scale. Now is finally the time to develop the first true version of your product. You are armed with the validated learning of your previous experiments. You know the crucial core features that must be built to satisfy your customers versus the nice-to-have features. So build those crucial features and launch to your early adopters. Measure how they are using the product through analytics and customer conversations. Learn what you need to improve it.
Each time you go round the build → measure → learn loop you will realise that your assumptions are correct or, more likely, need adjusting. You will need to tweak your experiments and run them again.
It may seem like overly hard work or even unnatural to do all of this before you even start development. Your first instincts might be to brew a pot of coffee, open your laptop and start coding. You just want to get your product built and launched to the world as soon as possible. Whether this will be successful though will mostly be down to good luck.
Using the Lean Startup process is a lot safer than building a product that nobody wants.
I hope this introduction has helped explain some of the concepts and thinking behind the Lean Startup methodology.