Struggling with MVPs? Tips on the right MVP approach!
We have all encountered the mantra, “Let’s focus on MVP!” In my product journey, I've built a Minimum Viable Product (MVP) many times in various settings, such as in hackathons, in sprints, and over the course of a quarter. I want to share my experiences, lessons learned, research findings, what went well, what didn't, and my overall insights about building MVPs. Reflecting on these experiences will hopefully help me in planning better for the next MVP project.
First, let's cover the textbook definition. What is an MVP? The concept of an MVP (Minimum Viable Product) involves creating the simplest, most cost-effective, and least complex version of a product to demonstrate its viability. This typically starts with formulating a hypothesis and setting an attainable Key Performance Indicator (KPI) for the MVP.
Now, really what is an MVP based on your experience? When there are numerous priorities to manage and limited resources, let’s create a quick and basic version of a product feature. This ends up helping the product team to add more items to the roadmap, gives the development team a chance to deliver on time, and reassures the business that more features are coming soon. Isn't that right?
I want to talk a hot second to stress about the intentions of building an MVP!
Lately, at least the product folks I've spoken to have mentioned that, it looks like teams always want to build an ‘MVP’. More and more, and there are MVPs out there that live forever without further iterations.
So, what should be the appropriate benchmark for determining the MVP of your product? How do we assess whether building an MVP is the right approach, or if we need a refined product to address the specific problem we are trying to solve?
When do we need a polished full product suite? This is necessary when all features need to function together to solve the problem, or when one feature cannot exist without the others. In these cases, it's crucial to say NO to the MVP.
The MVP, in simple terms, is the most basic version of what you are trying to build. It comes into play when you understand the core of your offering or when you delve deep into the problem. It should be capable of collecting the maximum amount of validated learning about customers with the least amount of effort. It's not a one-and-done approach.
How do you define the MVP? This is always my favourite part—asking questions! What are the goals? What is the specific problem you want to solve? Is it viable? Who is the target audience? How do you measure success?
Make sure:
You are setting an expiry for your MVP
You have the next iteration of your MVP in your roadmap (approved)
You are ready-set-go for v2 as soon as v1 is launched - including a backlog of features, the next design iteration, and the necessary tools to measure KPIs.
By following these guidelines, you'll be better prepared to build successful MVPs that not only meet immediate goals but also pave the way for future development.
Cheers,
Ebin.
