View profile

Lessons learned on building MVPs

Lessons learned on building MVPs
By Manolo Recio Sjögren • Issue #2 • View online

✨ Hi all, my name is Manolo Recio Sjögren and I am a technologist and designer based in Sunny London working with startups and tech companies of all sizes and shapes ✨
I will be sharing personal updates and tips on how to bring successful products to market. Hit the button below to subscribe 👇
There is a lot of uncertainty when building something new.
Some of the questions that might come to mind after setting on a problem to solve and a set of users to serve are:
  • Is this actually a real problem for my users?
  • Would they care about my solution?
  • Even better, would they pay or subscribe to it?
Just to give you an idea, the rate of startup failure in 2019 was around 90%. These startups employ pretty smart people but still, the risk of not finding sustainable demand for new products in incredibly high.
I have experienced this myself a couple of times. Different teams, different products, different timescales but similar outcomes.
One way to mitigate these concerns and avoid wasting time and resources building something that nobody wants is by creating an MVP (minimum viable product).
In plain language, an MVP is the minimum amount of work that you need to build to see whether you can deliver any value at all to your first set of users. — Me with a bit of help from Eric Ries and Wikipedia
Lessons that I have learned the hard way
While I don’t have all the answers, I have built many of them over the years with varying degrees of success. You will find below a consolidated list of lessons that I have learned the hard way:
  1. First, talk to users.
  2. Appeal to a small set of users
  3. Do one thing well. Ignore the rest
  4. Launch quickly
  5. Get some initial customers
  6. Finally, iterate
First, talk to users
Let’s pretend that you have identified a problem that users experience and you would like to solve it with software.
This initial stage will fill you with enthusiasm. You will quickly 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.
To increase the odds of people wanting your product you might decide to build a product that addresses several problems for relatively generic users.
Please don’t. You can’t please everyone.
It will take you a long time to get there and by the time you do, you will probably have 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
Very important.
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 off anyways. 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.
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,
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! 👇
Michael Seibel - How to Plan an MVP
Michael Seibel - How to Plan an MVP
If you found the content from this post valuable, consider sharing it with friends, or subscribe if you haven’t already 🚀
Did you enjoy this issue?
Manolo Recio Sjögren

Thoughts and principles on product development straight to your inbox. Subscribe to improve your product skills!

In order to unsubscribe, click here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Powered by Revue