Skip to main content

Lean Startup, more than just paying customers

Last week I was at a coaching session with a customer who said, “Kristian, I know what Lean Startup is, I know the process and have read quite a bit about it. But I am doing an internal process improvement, how should I go about it then? In this scenario there are no customers I can interview in order to validate my idea.” It hit me then that there are many who view Lean Startup that way, in other words only internalising the lightweight version. Send out an early version of your product or service out on to the market and see if people are willing to pay for it. Due to this I find it necessary to cover the fundamental questions one should answer before a project starts when using Lean Startup.

Whether there is an external paying customer, or an internal process to be improved there will always be a customer. Either it is an internal customer or the users themselves are the customer. Would they consider changing to this new way of working? There are however, misconceptions here. The purpose for Lean Startup is to reduce the risk in large projects, that is why you incorporate the method. It is not specifically a customer centric approach but tends to address those uncertainties as that is often a source lacking clarity.

Before we look at how we can minimise risk in a project I would like to ask a fundamental question when using this method which also expands to other aspects of life.

“How do we know this?”

Too often our underlying biases lead us to make assumptions based on what makes us comfortable. By answering the question “How do we know this?” and backing up the answers with facts we can minimise risk rather than run projects with loose ends based on risk.

Let us apply this first question before starting the project. “Do enough people experience this problem?” If the answer is yes, then the follow-up question ought to be “How do we know this?”. If the answer is “Because I have this problem every morning”, then it is simply not enough. The only thing we know is that a person – you – have this problem. Time formulate the first hypothesis. “X people have this problem”, or “ X percent of those asked have this problem” from which we try to validate the hypothesis så that we may with good conscience answer “Yes this is the
problem” and on the question “How do we know that?” answer “because X% of those asked confirmed that this is a problem they are indeed having”.

The other question we should ask yourselves before starting a project is “How are people which have this problem go about solving it today?” If there is no good answer
for this then perhaps it is not as big of a problem after all? Big problems are addressed by users due to the upside that come from solving it.

The third and last question is “Is your solution a better alternative for those who are experiencing this problem?” On this question it becomes even more important to follow up with the, “How do we know this”. It is too easy to fall in love with your own solution causing you to assume your solution to be superior to whatever exists today.

When these three questions have been answered first, only then should you begin to consider what the buyer would be prepared to pay for the solution.

  1. Do enough people experience this problem?
  2. How are people solving the problem today?
  3. Is your solution superior for those who are experiencing this problem?