How applicable is the Lean Startup method? I always go back to the original writing.

*This was originally published on LinkedIn on Jan 17th, 2024

We were fortunate at Pulse Energy to have Eric Ries come and spend an afternoon with us around 15 years ago. This was in the early days of thinking around the Lean Startup method before his book had been published. In the intervening years, I've thought a lot about how to apply Lean Startup principles when building everything from a B2C application to B2B software in two heavily regulated markets (finance and utilities.) I occasionally find myself thinking that the Lean Startup method doesn't apply in a situation or hearing the same from others that are building software products. Time after time, when I go back to the original writing, I realize that it adds value in almost any situation.

Here are three key things that I believe every founder and product manager should consider:

1) Eric Ries first shared his thoughts in a short post in September 2008 (https://www.startuplessonslearned.com/2008/09/lean-startup.html). While developing his book, his thoughts evolved and expanded into five principles:

- Entrepreneurs are everywhere

- Entrepreneurship is management

- Validated learning

- Innovation accounting

- Build-measure-learn

I find that it is not uncommon for the principles of the Lean Startup method to be confused with specific implementation practices. Most commonly, the specific implementation practices that are cited are those from the prototypical example of a B2C online application which are often inappropriate for other types of businesses. In particular, extremely rapid iteration cycles and frequent large scale A/B tests are challenging to implement in an early stage B2B environment. It's important to always go back to the five original principles and then determine the implementation practices that will make sense in a specific context.

2) The Minimum Viable Product (MVP) is a part of the Lean Startup method that generates the most debate. The purpose of defining an MVP is to be thoughtful about what needs to be learned through experiment and to then figure out the fastest and most economical way to run that experiment. There are a few key points:

A) In some cases, the risk is not related to the definition of the product itself. There are situations where the founders understand the problem and desired solution so well that it is fruitless to run experiments to further validate that need. However, in those cases, there are often other types of risks such as price sensitivity, willingness to adopt a new solution, ability to achieve distribution, etc.

Eric covered this well in a blog post in 2009:

https://www.startuplessonslearned.com/2009/04/validated-learning-about-customers.html

"But learning is a tricky thing to quantify, which is why the word “validated” is so important in this definition. Validation comes in the form of data that demonstrates that the key risks in the business have been addressed by the current product. That doesn’t always mean revenue, either. Some products have relatively obvious monetization mechanisms, and the real risks are in customer adoption. Products can find sources of validation with impressive stats along a number of dimensions, such as high engagement, viral coefficient, or long-term retention. What’s important is that the data tell a compelling story, one that demonstrates that the business is on a solid economic footing. (It being so easy to convince yourself that you’re in one of these “special case” businesses, I do recommend you give revenue a long, hard look first.)"

B) An MVP in one company will look very different from an MVP in another company. Even within a single company, the form of an MVP will vary over time based on the experiment that is being run. It is not uncommon to see someone reject the Lean Startup method because they cannot create an MVP in a few days and so they think that the method can't be applied in their situation. In reality there is nothing the matter with an MVP taking months if that is the time that is appropriate and required. The main principle is to identify the key risks and to then find the fastest way to eliminate those risks through validated learning.

Eric wrote about this in another post in 2009.

https://www.startuplessonslearned.com/2009/08/minimum-viable-product-guide.html

"Second, the definition's use of the words maximum and minimum means it is decidedly not formulaic. It requires judgment to figure out, for any given context, what MVP makes sense. As I talked about in a previous interview, IMVU's original MVP took us six months to bring to market. That was a pretty big improvement over a previous company, where we spent almost five years before launching. Yet in another situations we spent two weeks building a particular feature that absolutely nobody wanted. In retrospect, two weeks was way too long. We could have found out that nobody wanted the product a lot sooner. At a minimum, a simple AdWords smoke test would have revealed how utterly bad the concept was."

C) Just because it is an MVP, doesn't mean it can or should be low quality. There are cases where a low quality MVP is appropriate and there are other cases where a high level of quality in an MVP is important.

Eric covered this well in a post in 2015:

https://www.startuplessonslearned.com/2015/01/mvps-and-excellence.html

"When people hear the phrase “Minimum Viable Product” they sometimes forget to ask: minimum in regard to what? They worry they’ll need to do the same amount of work in less time by cutting corners. They fear they’re being asked to create a low-quality product that will put their reputation—or even people’s lives—at risk.

This is a misconception. “Minimally viable” does not mean operating in a sloppy or undisciplined way, building bad code that’s going to result in a lot of technical debt, or ignoring safety or health concerns. An MVP is not an excuse to throw our beliefs about quality out the window; it’s simply an experiment on the way to excellence."

3) It's almost impossible today to not adopt some of the Lean Startup principles. When founders and product teams talk about whether they will use the Lean Startup method or not, I think it's important to establish a fair reference point for comparison. In 2008, AWS had only been around for 2 years, continuous deployment was not yet widespread, and it was generally accepted to operate in stealth mode and rely on big-bang product launches. Fast forward to today, and even start-ups which claim to not be using the Lean Startup method are adopting many of the principles that set the method apart from the status quo in 2008. One point of view is that the only fair way to assess whether a company is adopting the Lean Startup method is to compare it to how companies operated in 2008. From that perspective, a lot of companies look more like a Lean Startup than they may initially appreciate.

Do you have any examples of where the Lean Startup was applied in a situation that seemed particularly rigid and challenging?

Cheers,
Steve