What is Lean Startup anyway?

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:

1. People have a problem in that they don’t know how to find the best spots when heading for a night out.

2. A good night spot can be determined by the number of tweets and Instagram pictures being sent from there.

3. People want to find party spots using an app.

4. 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.