Your Product May Be Minimal, But Is It Viable?
When startups talk about MVPs today, the emphasis is always on minimum.
Everyone encourages founders to not wait too long to launch, to get it out there, to get feedback and to start learning from the market. That is a great advice in general, and I am personally a big fan of going fast. Yet there is a subtlety that is lost in the message, which leads to bad outcomes.
The minimum product that comes out still needs to be viable.
If a product is too simple and falls below the bar, it won't be well received, and not likely to take off. If the product is too simple, doesn't solve the problem and doesn't activate and retain customers, it is not an MVP. It may be a prototype, and there lies the difference.
An MVP is good enough, and can be improved to be great one day. A prototype isn't good enough.
Albert Einstein said that everything should be made as simply as possible, but not simpler. He implied that difficult problems are just that -- difficult -- and ultimately, some things can't be simplified.
A great MVP isn't only simple, it is also sufficient. It embodies the solution to the problem, or an elegant approximation to a solution that is good enough. Sure, it lacks features. Sure, it is raw and unpolished, but a good MVP can be recognized as having the potential to fully solve the problem.
If you look up the word viability in the dictionary, you will see that it comes from Latin word vita -- life. Being viable literally means being alive.
How can a product be alive?
Products that we fall in love with have a vital quality to them. They feel great, respond right and delight us with their simplicity and the way they solve problems. They feel different. They feel alive.
A branch of science called complexity studies patterns across disciplines and seeks to understand the dynamic of different systems.
Roughly speaking, Complexity distinguishes between systems that are in the state of chaos -- dead and alive. Systems that are considered alive are close to the edge of chaos. They have enough interesting dynamics built in, but they aren't out of control.
The analog for an MVP is that you can have a product that has too many features and is chaotic and hard to understand. On the other extreme you can have a product that just doesn't have enough built in. It is not good enough. It is not alive.
It is in the middle that you find your great MVP. It is minimal and vital, and key to vitality are feedback loops.
How to think about your MVP
It turns out that the key to vitality are feedback loops. This is what makes natural systems alive and this is what makes great software alive as well. Take these steps:
- Talk to customers to confirm you are onto something. Do the unscalable things to validate the market.
- Map out the MVP based on your gut and understanding of the market.
- Remove features that feel unnecessary.
- Combine features that can be combined and simplify.
- Check the flows and feedback loops. Are you solving the problem you set to solve? Is the system dynamic enough? Will it be alive?
What you are doing is focusing on a minimal set of features, but not at the expense of viability. Sometimes after removing a bunch of things you may need to add some things back.
How exactly you make your MVP viable is as much art as it is science. But there is science to it, for sure. For more details on building your MVP, go read this awesome guide. Below is an image from the post.
Compute your MVP
There is a method to a great MVP. It captures and brings to life the minimum, yet sufficient version of your solution to a business problem. Don't rely on luck or minimalism to get your to your MVP. Compute it.
MVP is a product computation on a napkin or a whiteboard. MVP is not about furiously typing code. Rather, a great MVP is about rigorously thinking.
We can't predict the future, but we can do better than roll the dice. We can be intelligent about our MVPs, make them simple, build in feedback loops and make sure they have a shot at being alive.
Please share your MVP experiences in the comments section below. What worked and what didn't?