MVP
The way of making '100' people love your product.
In my previous post, I focused a little on how the very first days of a startup might look. One of the key steps which every founder needs to take is to release an MVP - Minimum Viable Product. I want to double click on that subject today.
Before launching an MVP, founders need to understand well what are the problems potential customers experience. The best way to notice those is by either experiencing them yourself or witnessing among people you spend a lot of time with.
An MVP is the best solution, I know of, which allows starting a conversation with customers about solutions to their problems.
There are a couple of interesting questions one might ask:
Who are the first customers and why are they willing to use an MVP of a product?
In other words - who are the people willing to try a rough first version of a product created by an unknown company that has just started? The answer is pretty simple - these people are experiencing a problem today, and the solution to that problem is so inadequate that they're willing to try anything which could improve their lives. So even if an MVP is extremely simplistic, almost to the extent that founders feel ashamed of it, if it does improve their customers' lives, those customers will be willing to use it.
How to determine the right scope of an MVP?"
Actually, I’m not sure if it’s possible to know that before launching something and getting customer feedback. Very often, some parts of an MVP solve a customer challenge, and some don’t. Based on the feedback it’s much easier to understand what needs to be done. So the right scope of an MVP is usually determined only after a few cycles of improvements. Those cycles are possible due to learning coming from customers who experience the first versions of an MVP.
The paragraph above may sound like, “you can launch anything, give it to customers, listen to them, and fix what doesn’t work”. That’s obviously not what I wanted to convey.
An MVP needs to address a fundamental customer problem. So, it’s critical to deeply understand what customers are struggling with first. Often, they struggle with many different things, and it's the founders' job to learn that. The next thing is to understand what is the most important challenge which needs to be addressed first. An MVP typically tries to address a challenge like that.
How to know if the development of an MVP is going in the right direction?
If your first customers keep using the product there is a good chance that it does go in the right direction. If they do, it must mean that the current way their problems are solved is better than before, and they don’t want to get back to the previous solutions because of your product.
What is the goal of an MVP?
It’s to get to a place where a handful of customers use the product and they love it. The number doesn’t need to be large. Folks at Y Combinator suggest that it's better to have 100 people who love your product than thousands who like it a lot. I love an approach like that. Passionate users are more likely to engage deeply with the product, provide valuable feedback, and become loyal advocates. Their enthusiasm can drive organic growth through word-of-mouth recommendations - which is a powerful way of acquiring customers - specifically for early-stage startups with limited marketing resources.
Launching quickly vs polishing the first version of an MVP?
In the beginning of a startup journey resources that founders have are limited. Typically founders themselves are the only people who work on a startup. There are no customers and revenue. All investments are coming from the founders’ pockets. Since resources are scarce it’s wise to limit the amount of unnecessary spending. Launching quickly usually means shorter development by addressing only the most critical things first. Polishing typically is related to increasing the scope of the first version and extending both the time and the cost of the first release. The key challenge before the first launch founders face is that there is really no way to be sure what are the features which are mandatory for customers and which are only nice to have. Because of that uncertainty, it’s far better to launch quicker, get the product into the hands of the first customers, get their feedback, and only later decide on what needs to be done further. This approach makes it much easier to avoid the cost of unnecessary work.
How to distribute an MVP?
Since the goal of an MVP is to get to a place where a handful of customers love the product, the simplest way to do it is to manually reach out to early adopters and then onboard them. There is really no need to worry about further distribution before the product is used and loved by a handful of people. Building something a few people love is difficult enough and tackling it before anything else is the most important challenge.
So the framework of launching an MVP goes as follows:
Noticing a problem people experience.
Launching an MVP quickly, which addresses the problem.
Getting the product into the hands of customers.
Learning from their feedback.
Improving the product.
Repeating steps 3 to 5.
Following the steps above allows launching quickly and avoiding building a product which no one really wants, which by the way is a common situation startups find themselves at.
One other question that always bothered me related to building startups - how is it possible that companies, which are already on the market, allow startups to create successful products in the first place?
Startups seem to be so vulnerable: they don’t have customers, money, brand, or credibility, and they are often run by people who have never built companies before, yet many manage to succeed.
After working at and observing larger companies, it becomes clear that they are simply unable to move fast. There is a lot of inertia, complex decision-making, and existing commitments. The demands of existing customers are a key priority. Large companies are really tied to their past successes.
Startups on the other hand are free to move quickly, to iterate, to adapt, to address problems before their larger competitors even spot them on the horizon. They can change their products quickly and focus on smaller markets that big companies might not pay attention to.
Big companies just don't have the privilege of moving fast and being flexible, and that is one of the reasons why the best way to build an MVP is to ship it fast and start iterating.
In summary, the most important goal of an MVP is to ship the first version quickly and, based on customer feedback, iterate to bring your startup to a point where '100' people are in love with your product. This requires building the right set of initial functionalities, releasing them, and ensuring that these functionalities resolve the most critical problems of your early customers in a better way than their existing solutions. It's a hard one to accomplish. It's difficult enough that focusing on anything else is a distraction at this stage. Distribution and scaling naturally come later, but it doesn't make sense to focus on them before the MVP is ready.
I’m open to invest and/or help your startup grow. If you have any questions or thoughts don’t hesitate to reach out at bart@founderspond.com or DM me at @kiszal on Twitter.