2 Mistakes to avoid when building your MVP

Building the first version of a product (MVP) is to validate the hypothesis. To validate your ideas. As many of you know, the idea of an MVP is to build only the core functions of the product. However, in the past, I mistook 'core function' with 'easiest function'.

Mistake #1
I built around the lowest hanging fruit, which wasn't the core function, so whereas I had a product in the market, it wasn't directly connected with the core offerings/functions. It was just a waste of time.

So if it went on to be successful, it wouldn't have told me much about the receptivity of the original idea. I had to scrap the entire thing and start from scratch.

To give more context, think about Uber (or another ride-hailing app) building their MVP, but the app only lets you see drivers around you, but you can't book any rides. Booking rides is the core function. So, even if millions of people downloaded the app only to view drivers around them, it wouldn't matter, because the core function (book a ride) isn't included.

Building an app that allows users to only see drivers is the easiest thing, but not the core thing. That's the mistake I made. I thought the MVP was about looking for the easiest thing to build. I've learnt that it's Minimum Viable, not Minimum Difficult.

---

Mistake #2
Another mistake I've made in the past is building an MVP without setting metrics to track. In the aforementioned example, that would be like building the MVP of your ride-hailing app, but not building allowance for tracking how many people are requesting rides and booking rides. You need to know how many people downloaded the app, how many people booked a ride, how many successfully completed a trip, etc. These are data points that help you make effective decisions about the product's next iteration.

What you build after your MVP is HEAVILY reliant on the data you get from the MVP, so don't neglect setting those metrics.