5 common "lean" misconceptions

Eric Ries wrote "The Lean Start-up", a book that has hugely inspired people from all sorts of industries and backgrounds. His Lean Start-up methodology is pretty much world famous by now. "Do one important thing: make better, faster business decisions. Vastly better, faster business decisions. Bringing principles from lean manufacturing and agile development to the process of innovation, the Lean Start-up helps companies succeed in a business landscape riddled with risk." (Eric Ries)

There are however a lot of things that get misunderstood, so I decided to list here the top 5 that I encounter most commonly (not necessarily at work, but also with friends).

1. "Lean" means "cheap"

Lean is about reducing waste and being super efficient, it has nothing to do with your budget. If you have $50 to invest in your new product, then it might not be enough depending on what the problem is that you're trying to solve. Then again $500,000 might not be enough either! This is far more about learning quickly what works and what fails. If you hire a cheaper, inexperienced team to build your MVP, it will cost you more later down the road. It might be cheaper in the long run to hire in a very experienced, much more expensive team to do the work. You're more likely to get something you can test much faster with them, plus it'll be high quality and this is important.

2. Lean is only for software start-ups

You can apply this methodology to any industry and any size of company. The bigger your company is and the more history it has, the more you are going to have to think about change management of course. People love a fresh idea and usually get very excited about thinking about a new way of working. What tends to happen is when the reality of it sets in, there can be resistance. This is only natural, change is described as the root of all human suffering after all. Don't underestimate the change that your organisation may have to go through. Factor that in early and use lean to figure out a way to proceed.

3. Minimum viable product (MVP) is quick and dirty

It is simply a product with the minimum features required for it to function as intended. It needs to provide enough value to users/customers, and your code needs to be good enough to maintain and build upon. Otherwise you are setting yourself up for problems and high costs later on (i.e. you'll need to rebuild the entire codebase.) You are not going to be able to test hypothesis in a timely manner if it takes 2 weeks to make a change. This will slow down the whole process and before you know it you'll be in an unhappy place. You are still going to need to think about branding, SEO, communications and all that stuff too, or whatever is applicable to your solution. It is not a case of "build something crappy and they will come". Think high-quality and high-discipline, but only on the minimum features required for you need to test your idea out. There's a whole bunch of stuff that will still need to get done that has nothing to do with features too.

4. "Customer Development" is just feedback

If you are going to use Lean, then you need to get on top of proper user testing methodologies, and apply them effectively. You can't invite 3 people in every week and just ask them what they think. You have to test by seeing how they interact with the solution. You will also need verbal and emotive feedback. There are a lot of ways to do this well. Throwing down some poorly thought through questions in an email and calling it a survey is not going to fly. The point here is not always to validate your hypothesis, but also to find out what you don't know. A user interview is not a chat. You need to plan and prepare for this so that you can rely on the information that you are getting out of it.  A focus group is not usually the most effective way of getting information. Get users in regularly to work with the team on what a good solution looks like from the beginning, and vary the types of users you invite. See extreme users as well as those who fall in the middle and those who don't see the point in your invention. Don't spend all your time talking, get them to draw, prototype, role play the solution and watch and listen attentively. If you have never done this, either step onto that learning curve or hire someone in who knows how to do this.

N.B: It's also not just about what the user wants, but also about what's viable financially for you, and what's feasible technically too.

5. "pivot" means throw the baby out with the bathwater

You need to validate your idea properly and accurately. You should do everything you can to check your assumptions, and if they prove to be wrong, you need to drop the bits that are not working…not the whole thing. If you decide to abandon the entire project and start an entirely different one…that's not a pivot. It may be exactly what you need to do, but it's  new start. An important bi-product of lean efforts is learnings. Make sure that you use your new knowledge effectively, this is valuable stuff. Ensure that your analytics are set up properly before using them to make business decisions, and ensure that you are not misunderstanding what they are showing you. As a rule of thumb, I think that you should always make business decisions based on at least 2 different sources of data (e.g. your web analytics and also real user testing).

6. Bonus number 6: "Just start and we'll figure it out later"

A lot of people are eager to jump in and start laying down code or drawing up  solution straight away. In some cases there's nothing wrong with this (in fact in one case it was the only right thing to do), but for most of those I have witnessed, it was not the right thing to do at all. You need to make sure that you understand the problem space as much as possible before investing further. Resist coming up with solutions until you have thoroughly understood the entire problem. This is going to either save you time and effort, lead to an even better idea, or/and save you a lot of unnecessary expenditure.

What you are trying to understand is whether the problem is worth fixing or not. It takes as much time to solve a bad problem as it does a good one. Don't waste your time.