3 Mistakes To Avoid When Building Your MVP
Building an MVP (Minimum Viable Product) is often viewed as an important step when validating your product idea or hypothesis. Your MVP helps you understand how your potential customers may use your product, what they want, and sometimes, what to build. MVPs are also relatively easier to build when compared to full-fledged products.
However, despite the minimum tools & resources required to build an MVP, there are mistakes I’ve made & also noticed other people make when building their MVP. Whereas there are many mistakes one can make during this process, I’ve come up with 3 which I believe are crucial to avoid.
Mistake #1: Building The Minimum Difficult, Rather Than the Minimum Viable
Building an MVP doesn’t mean building the easiest part of the product; it means building the minimum viable, meaning, the most essential features of the product. Say we’re building the MVP for Uber; what is essential?
Requesting rides: This is needed so we monitor how users use the product. Building the easiest, or minimum difficult, would be building an app that allows users to see drivers around them but can’t request rides. Whereas that is easier to build, it’s not the minimum viable. It doesn’t tell us anything. The only metric that matters is how many rides are requested + fulfilled. If the MVP doesn’t do that, then it’s not an MVP. It’s just a mockup.
I made this mistake when building a product in the past. I took a look at the PRD and then went for what I believed to be the lowest hanging fruit. It wasn't until later that I realised my “MVP” was missing the product’s core offering, simply because I intended on building the ‘minimum difficult’ rather than the minimum viable.
Mistake #2: Not Setting Metrics
Remember the reason we’re building an MVP? To validate our idea. Well, if we have no metrics, then how do we monitor the potential success or failure of the idea? We can’t. Metrics help us determine the state & potential of the product. Metrics will tell you how people use the product, if they hate it, if your core offering is viable, and so on.
For our example of Uber, some metrics can include the following:
- Number of rides requested
- Number of rides completed
- Number of rides cancelled
Having these numbers will help us know how our users are using the product. The # of rides requested tells us how many people made an attempt to explore our core offering, whereas, the # of rides completed may show us the ratio between those that attempted to explore the offering versus those that actually did. If the # of requests, or cancellations, for example, are more than the completed rides, then we know there’s a problem with the product somewhere.
Because we have set these metrics, we know what to fix, when to fix it, and with enough analysis, how to fix it.
Mistake #3: Not Setting Timelines
Running an MVP with no clear timeline is like getting in your car and driving with no destination. You need to know when to stop. An MVP, as I explained earlier, is simply to learn about your potential users & to validate your hypothesis. You must set a timeframe for that learning period.
The scope of your product will determine how long your MVP will run; once you have learned enough for the period and garnered adequate data from your potential users, you’ll need to meet with your team and discuss how you’re going to implement the feedback into the product in order to build what users want.
Conclusion
The process of building a product is often time-sensitive, so it’s important for us product managers to optimize the time we have by applying the right principles and strategies; and in general, doing the right thing at the right time.
You may not avoid every mistake, but even in that, you can find solace in the fact that every mistake breeds a lesson.
I’m hoping to share more on product management over the next several months, so hang around and remind me if I don’t.
I hope this helped.
