Don’t go out and build actual stuff.
When Eric Ries published is now seminal book1 that coined the movement “Lean Startup” back in 2011, I devoured the book and became an immediate fan. I still am.
I also still see myself spending significant time explaining the inner workings of the Lean Startup to product managers.
Getting the MVP concept right
I quickly got over the first pitfall: misunderstanding the term Minimum Viable Product (MVP). It seems as if the majority of product people using the terms lean startup and MVP hasn’t really read the Lean Startup book. In most cases, they didn’t even bother to look up the concept on google, and just take it as face value: the smallest product we can launch with.
In their minds, MVPs quickly become an excuse for launching the smallest (and crappiest) product they can get away with. In essence, they are trying to build the Minimum Feasible Product (MFP), not the minimum viable.
Building an MFP will more often than not leave customers confused and wondering about the purpose and flawed execution and move on to try an alternative offering.
Introducing the term Minimum Marketable Product (MMP) help set the right target for the first launch: a product build for scale with product-market fit.
Chances are very small that you are going to get it right the first time.
MVPs are supposed to be built for learning, not for scaling. The focus of MVPs is learning what constitutes product-market fit to increase our likelihood of launching a product customers will love.
In the beginning, you are merely searching for the right business model. Before you get it right, you’ll undergo 10, 20, 50 variations – if not more. Chances are very small that you are going to get it right the first time.
You create MVPs to de-risk product success.
A Minimum Viable Product is not a product
The most important question isn’t what is left?, but what is unknown?
A Minimum Viable Product (MVP) is not a product. It’s a process. It’s a process of experimentation, repeatedly asking two questions:
- What’s my riskiest assumption?
- What’s the smallest experiment to test it?
The most important question for your team isn’t “what is left?”, but “what is unknown?”
Getting the Build-Measure-Learn loop right
Years later, I discovered that I had been applying another of the core principles in a way that was far from what the lean startup cult would call lean. I had the build-measure-learn loop wrong.
Depictions of the Build-Measure-Learn loop leading to popular misinterpretations by Eric Ries - first in his book and later on his official Lean Startup website.
In his seminal book, Eric Ries depicts the build-phase as resulting in delivering a product1. On his official website, Eric Ries depicts the same loop as the build phase delivering code2.
But building doesn’t equate coding. In the very beginning, we don’t want to go out and build actual stuff. In this stage, we are building for learning, not for scaling. In fact, when we are first starting out, we want to go out and do things that don’t scale 3.
That is a very expensive way to go around the loop.
Misinterpreting the build-phase, leads to misunderstanding the measure-phase. If the build-phase gets too bloated, take months, and end with launching an actual product to the public, that in turn increases work required to collect, measure, and interpret data. To match a bloated MVP, advanced data-gathering often needs to be set up in order to learn anything relevant after launch. Data gathering becomes a project in itself and an abundance of assumptions are tested at the same time with a bloated project.
That is a very expensive way to go around the loop.
According to Eric Ries1, the main learning we want to focus on going around the loop is whether we should pivot or persevere. That is: should we abandon (pivot) the current direction or continue testing (persevere).
In most cases, the main learning is not around getting new ideas for more stuff we can build, but whether we are on the right track or not. If we are on the right track, we often want to test the same hypothesis again using an even more sophisticated experiment to increase our certainty or move along to the next experiment.
In a few cases, we will gain new insights which will lead to new ideas. However, in the early phases, our MVP efforts should be on building more granular and precise evidence. Focusing solely on the new ideas we gain from research, will force an incremental mindset of constantly building and releasing new features and neglect the iterative mindset of perfecting the features we already have.
Objective: Minimize total time through the loop
Instead, we should focus on minimising the total time through the build-measure-learn loop. Instead of building actual stuff, we do experiments. Experiments do not have to involve any engineering work or any code at all. Not even a designer.
In the early stages, we do experiments to learn about the world. To establish the baseline. To get the numbers, so that we at some point down the road can put it in the business plan.
A much more accurate depiction of the build-measure-learn loop would look like this:
A more accurate depiction of the Build-Measure-Learn loop
If we misinterpret build, and build actual stuff, this phase gets bloated, slow, and expensive. We don’t want to build actual stuff as that will only set ourselves up for failure.
In the very beginning, when we don’t know what kind of numbers we can expect, we should focus on establishing a baseline4: to get a grasp of what we can expect later in the game and have something to compare and contrast to.
Instead too many product managers set fictional fantasy numbers to hit – just to have some kind of goal. They are setting themselves up for failure. When you are just getting started, forget hitting any numbers: there’s no way, you’re going to be right the first 10 times.
Sources
1 Ries, Eric, 2011, The Lean Startup
2 Ries, Eric, 2011, The Lean Startup Principles.
3 Graham, Paul, 2013, Do things that doesn’t scale.
4 Toxboe, Anders, 2019, When business plans are a waste of time
