Lessons learned on building MVPs

There is a lot of uncertainty when building something new. To start with you will need to choose a specific problem to solve and group of users to serve. Then, questions like these will pop up: Is this a real problem for my set of users? Would they care about my solution? Even better, would they pay to have it solved by my software solution?

Just to add some context, the rate of startup failure in 2019 was around 90%. Even though the majority of these startups are made out of pretty smart people, the risk of not finding sustainable demand for new products seems to be incredibly high.

A common startup advice to mitigate the risk of building something that nobody wants is to create a Minimum Viable Product (MVP) to validate any initial assumptions.

Having built several MVPs with varying degrees of success over the years, below you'll find a list of lessons that I have learned:

First, talk to your users.
Appeal to a small set of users.
Do one thing well. Ignore the rest.
Launch quickly.
Get some initial customers.
Finally, iterate.

👂 First, talk to your users

Let’s pretend that you have identified a problem that some users experience and would like to adress it with software. This initial stage will fill you with enthusiasm as you'll be able to generate a vision and would be eager to start working on it.

Before you start building the product, it is helpful if you talk to your users. Literally. Go and talk to them. Engage with them. Actually, get to know them and offer your help with anything. No product at this stage. Just be all ears.

Appeal to a small set of users

Oh, this is a biggie. You might think that by building a generic product that addresses the needs of several user groups you might increase your odds of success.

Please don’t. You can’t please everyone. Having a well-defined set of users needs is like a compass that will help you to hopefully build the most pressing features for your target users. Generic MVPs result in lots of half-baked features with relatively poor adoption.

Instead, focus on a specific set of users. Go niche. Find out where they hang out and get to know them as much as you can about them.

With luck, they will become your early adopters and will understand the vision that you are selling ass they live with the pain that you are trying to address every day.

Do one thing well. Ignore the rest

Your MVP should be lean. Think of something ridiculously simple. Once you have decided on the small set of users that you are willing to serve, condense down your offering for them. Address their highest order problem and ignore the rest.

This will help you build a small solution that will be laser focus. If you build a product that delights a small set of early adopters, they

Launch quickly

I'd argue that this is one of the most important points once you are set on a specific problem space. For your initial MVP, choose something that you can build in weeks, not months.

Sprinting to put something in front of your users so you can learn from their reactions should be your main goal.

The first version of your product will probably be quite off anyways. What you want to do at this stage is measuring their early reactions (analytics plus good old conversations) will help you understand whether you are on the right track.

Get some initial customers

This is important too.

Once you have that simple version of a product and are ready to start collecting feedback, leave your code editor aside andstart scouting the internet for people to use your product.

Don’t wait too long. Get anyone using your product and listen deeply.

You won’t believe the number of people I talk to that is building an MVP with hardly any paying customers using it. Avoid over-engineering the product until you have paying customers (you don’t need too many)

This is a great quote by Ben McRedmond on the subject 👇 I couldn’t agree more.

And finally, iterate

Every tip that you have read so far were simply steps leading to this point. The main reason why you decided to build an MVP was to get at this stage.

You now have a lean product (probably not much of a product at this stage) that is collecting valuable early feedback from a small set of users.

This process is called the build, measure, learn cycle and it is best described as a loop that starts from ideas that get turned into code so you can measure how it was accepted by your users.

Stay in this critical step as much as possible. Kickstart the tunning machine and keep listening, analysing and measuring as the insight that you gather with each addition to the product will help you make a decision on what to do next.

Recap

The main goal of an early-stage startup building a new product is to minimise the time that they need to get validated learning.

While the main tendency will be to wait until the product feels right, I would encourage you to don’t wait too long before you put it in front of users and start learning from them.

The process might seem painful at first but you will get the facts before it’s too late. The insight generated from your early adopters will help you improve on your solution until it hopefully gets traction and solves the problem.

Thanks for reading,
Manolo
@recio_sjogren

For those of you wanting to dig deeper on the subject, there is a great video by Michael Seibel from YCombinator that I highly recommend watching! 👇

If you found the content from this post valuable, consider sharing it with friends, or subscribe if you haven’t already 🚀