This post has been written, because I have not been able to find any reasonable on-line resource that would briefly and accurately describe what the lean startup is. I write this post on basis of my experience from TechPeaks.
First, the lean startup is a startup that use lean methodology. The lean methodology is more general, it is not only for startups. For example, you can use it for product development in corporations or for development of new features of existing products. A lot of people mess it up with the Lean Startup Machine (LSM). Well, I like the LSM, but LSM has been created as a weekend workshop for experiencing the lean methodology. Moreover, LSM was one of the first programs at TechPeaks. Even though it is possible to apply LSM procedures even on a real startup, it is better to understand lean methodology basics first.
Basic principles of the lean methodology build on:
- Problem x solution differentiation. A problem is something that a target group if suffering from, while a solution is a cure for the problem. Trivial? A lot of startups start with the solution and then they cannot clearly explain what they solve and if it is a real problem or not.
- Assumptions definition – when you define a problem or its solution, you make a lot of assumptions about a target group, technologies or about competition. It is necessery to write them down and order by priority. That will allow you not to forget validation of the most important assumptions at least.
- Validation – finding if your assumtions are true or not without any compromise.
- Pivot – if it happens that you invalidate your assumptions, you must re-define a problem or its solution. The process is called pivoting and its result is called a pivot.
And how it goes together? Let us look at the following scheme that should become your daily routemap to obtain good ideas, ie. ideas solving real problems with use of right solutions.
The basic validation scheme:
1. Problem validation cycle
First you have to find a problem that is really painful for customers. And that is not easy, because there is not many gaps on the matket these days. The most of ideas I have now were invented like in year 2009. For exploration of taken ideas I often use a database of startups at CrunchBase.
It is better to start with something you have insights to, something related to you. Cannot find anything? It is better to let it be, talk with friends, watch good talks, broaden horizons, freelance on various jobs or volunteer on open-source projects. It is better to wait for a while than waste your energy going nowhere (my personal experience). Once you start thinking about business opportunities, your mind set gets different and you become much more sensitite to them.
Once you select a problem, check that you are really passionate about working on it. You have a long way to go yet and for that way you will need a lot of internal motivation yet.
OK, who does the have the problem? Everyone? Wrong. That is never true. At the beginning, try to select a group of people who has the problem with the highest probability. This group is called early adopters. Of course, your will extend it later and it is right to keep such a potential in mind. However, you need to start somewhere.
It is very buck-passing to define a target group as a group of people having the problem defined by you before. It does not help you to find such people and speak to them. For example, for the problem “I need to find a girl-friend or boy-friend” you cannot define a target group as “People searching for a girl-friend or boy-friend”. Instead, you can focus on Linux gurus between 30 and 35 in age. Or you can focus on someone completely different 🙂 I hope that the point is clear.
Try to brainstorm everything that must be valid so that the problem is real. As for the example of “Searching for a girl-friend or boy-friend” it is right thing to ask if a target group has such a problem at all. Maybe you only thing about them in steterotypes. Maybe the problem does not exist or there is already a good solution for it.
Validate assumptions you have selected. You do not necessarily need to validate all of them. But do not forget to validate the most important ones. And now we get to the point. A corporation would possibly pay for a market research, but you are not going to do that. First, you have no money for that (it is not the last market research you do). Second, you would miss the most important opportunity – the direct contact with the future customer. There are few rules to keep during validation:
- Talking to friends and family is fine, but that is not any validation. I do never want hear startup pitching with “all my friends and relatives said…” again.
- Do validation only with people which you do not know, or which you do not know well. That is the only unbiased source of feedback.
- Before you start, set the number of people you want to talk to (e.g. 30 can be a good number for start) and a minimum of positive answers you want to achieve. If you focused carefully, it should not be units of percent, but something more substantial, like 50%. This also partially solves a problem with numbers deviation on small samples. If the result is tight, you can try to extend the sample, maybe it is really just a deviation. Try to test on the bigget sample that is available, but do not get sunk in validation this way.
- One of the very good methods that is taught in the Lean Startup Machine is reaching the place where you can find your target group in person. They have a nice slogan: “Get out of the building”. Once you start talking to someone:
- Unless you are talking to companies, do not start with saying you are doing a market research. Start a normal informal talk.
- Do not bias respondents. Do not ask them directly from the beginning.
- Due to a longer informal speech you will learn a context and a lot of useful information about the target group
- Try to remember everything and take notes. Write the notes down after you finish an interview. You can keep the interview informal this way.
- Once you disclose that you are validating an idea for a startup and the respondent is a lot into the problem, take his/her contact information. It can come handy while validating solution.
- Verify that you are speaking to people from the target group. If not, information from them can still be valuable, but about a different group – do not count them in then.
- Once again: go to the place where you can find the target group. To its natural environment. Do not just hunt for people at the main street in the city center as everyone else.
- If you make questionaries or write emails, try to get as close as possible to rules given for a interviewing in person. Phone is better than emails. Avoid advertisement slang in emails.
- Let fingers be cut off to anyone writting a single line of code before validation.
A difference between anonymous questionaries and interviews taken in person is immense. Once you pick a good problem and remember all the desparate faces of people you were talking to, it is a completely different fuel for your motivation. You will understand the whole problem better and it will be much easier to come up with the product that really solves the problem.
But… in most cases you will not reach the limit of positive answers and you will have to pivot. Do not be sad. Be happy! Probably, you have just saved half a year of development. Furthermore, nothing ends here. Pivoting does not mean wasting everything. You learn a lot by validation. And use should utilize what you learned in a pivoting step:
- Have you selected a wrong target group? Which aspects cause that it is not the right one? Can you come up with another target group without these aspects? Well done! Go for that!
- The target group does not have the problem you were thinking of? What if they have a different, related and still interesting problem? That is good news, isn’t it?
Well, sometimes you must waste everything. It happens. However, do not put it into a trash. Preferably, save it somewhere (e.g. into Google Docs). Maybe, one time you will re-use it and it becomes an essential source of inspiration for you in future.
2. Solution validation cycle
Now it is upon you to come up with something that solves a problem from a previous validation cycle. The solution must:
- be doable,
- bring a sufficient value to a customer (customer value proposition),
- have a reasonable business model (the solution must be possibe to implement for reasonable costs so that you will be albe to earn money on that).
Personally, I would advise not to analyze the business model in details first. It is better to have just a draft and do the first round of validation in order to find if you are going the right direction. After that you can finalize the business model, for example with use of the business model canvas. Of course, if you change the business model substantially, do not forget to validate it again, because every business model has specific assumptions.
Assumptions and validation of the solution
It is very similar to validation of the problem, but this time focus on threats to doability and business model. Automatically include an assumption telling that the value of your solution is sufficient for your customer to pay.
Ideally, validate only on people who claim that they have the given problem. The others scew results. If you can do that, you will get an exact percentil of potential customers in a target group. One way for validation could be showing them a solution in person on a leaflet.
Another frequently used way of validation is a landing page, ie. a simple web page describing the product. You can run it in parallel to other approaches. In order to save your effort, there are tools for buiding landing pages. In order to prove that a user is really interested in the product, he/she should take an action on your landing page. E.g. enter his/her email, upload a document, click on a “pay” button or create an account. Analyse visits and try to spread the link only to relevant groups. Sometimes it is hard to estimate who has been addressed via Internet. Nevertheless, if you achieve just 1 or 2 registrations, your solution is probably not the best one. If your results are not clear enough, try to increase a number of respondents and make more interviews in person.
Is that really all? Not completely, but the core is there. The main point is that the validation pays off. A lot of developers are disappointed by an initial phase and do not persist. Which is a pity, because then they develop unwanted products and waste their potential. Unfortunately, only very rarely one invents the right thing at the first shot. Pivoting a completed product is much harder and painful than pivoting an idea.
The lean methodology may also include a product development (see e.g. minimum viable product), continuous deployment and a strategy for customer acquisition. These topics, implementation details and various examples can be found in sources given below. In my opinion, they are not substantial for understanding the main principles and you could partially infer them from the methodology basis given above or learn it independently of the lean methodology.
In the end, it is necessary to admit that the lean methodology has also weaknesses:
- It happens that you get stuck in validation cycles without developing anything. It does not matter much, because you would not develop anything useful anyway. However, it is quite frustrating (confirmed by 9 of 10 participants of TechPeaks).
- Due to pivoting you can come up with a product that fills a gap on a market nicely, but does not fit into your original vision and its development does not make you happy.
- Be careful during validation. Someone could easily start considering you as a fool and a cheater. Even if you just have a landing page, stay open to your potential customers anyway.
Links to sources to find more:
- On-line article Why Lean Startup Changes Everything
- On-line motivation text of the lean startup methodology with links – The Lean Startup Methodology
- Blog of Eric Ries – better to read between years 2008 and 2011
- Book The Lean Startup (Eric Ries)
- Book Lean Analytics (Alistar Croll, Benjamin Yoskovitz)