Building a Minimum Viable Product: the Lean Way
What’s an MVP and why should I build one?
Minimum viable product development has become a staple term in entrepreneurship to describe the lowest energy form of an idea. When you have an idea, your first thoughts are generally about whether or not it’s a good one; after all, why spend time and energy on something that doesn’t have any potential?
Lean MVP development focuses on digging deeper into these assumptions and testing them as a means of delivering what customers actually want instead of what you might initially think they want. Traditional thinking tends to push us in the direction of perfection--if my product doesn’t look and feel perfect, how can my customers respect me or my business?
Building a minimum viable product isn’t about creating perfection. It isn’t even about initially gaining customers. MVP’s are important because they allow you to understand your customers and industry before you’ve invested your life’s savings into an untested idea, and they’ll give you knowledge of how to do so when the time is right.
Identifying Test Points
Most people think of MVP development as the creation of either a physical product or piece of software. It’s often linked to tangible things rather than just pieces of information--however as an entrepreneur it’s important to understand that you’re looking for concept validation (as opposed to product validation).
Remember, you’re building an MVP to decide whether or not the idea can be built into a successful product through adaptation, not that it already is one (frankly, chances are it isn’t yet). This is why building a minimum viable product starts with identifying your assumptions. These can range from who your customers are to the key features that they might like.
Let’s establish a running example. Say I’m looking at starting a company that connects university students to each other through a mobile app with the goal of easily finding and creating study groups to help them with challenging course-work. Based on this concept, let’s identify a few key assumptions that I’ve already made:
Significant numbers of students are actively looking for help with their studies.
Students are willing to help each other in courses graded on a curve.
A mobile app is the best way to connect these students in a sustainable and scalable way.
An inexperienced business developer would not consider the above points early on. Often times they will be blinded by their passion; thinking about how they can convince people to want what they are offering instead of how they can offer what people already want. Their MVP will be a fully developed application with full device functionality, all the UI/UX bells and whistles that you can imagine, and a hefty advertising budget to “spread the word”. They’ll spend months or years developing their product only to find that they’ve missed the mark completely.
It’s best to learn that your assumptions are wrong before you’ve done this, and building a minimum viable product allows us to truly put them to the test.
Breaking Open the Assumptions
Let’s go back to our example and take a look at our first two assumptions: a significant number of students are actively looking for help with their studies and students are willing to help each other in courses graded on a curve. These are what I call Class A assumptions in MVP development; that is, an assumption that can be verified or denied to a reasonable extent based purely on simple data gathered from end-users.
Perhaps we create a survey that we send out to students about their university experience. Do they feel that they spend too much time learning concepts that could be taught to them by a knowledgeable colleague much quicker? Are standard lectures long enough to clearly explain material? Where do they go to get help now (if anywhere)? Do they hesitate to help others because of competitive pressures? Of course you’d want to go into detail on this to ensure you’re getting reliable data, and it’s always a good idea to do some observational testing as a secondary source of validation to see if your subjects actually behave as they indicate in the survey. In summary, to take care of these assumptions we’ll implement a survey component into our MVP.
The third assumption: a mobile app is the best way to connect these students in a sustainable and scalable way. is where our MVP development really takes shape because we’re going to need to spend a bit of time creating what could eventually become our end product.
This is called a Class B assumption; it will required some MVP development and testing to be verified. When dealing with Class B’s, we take on a great deal of self-control and must learn to control our entrepreneurial urge to make everything perfect. In the case of an app of piece of software, we’ll want to focus on functionality and the specific features for which we’re gauging interest instead of aesthetics. We’re looking to spend as little time as possible to learn as much as we possibly can--this is the essence of the minimum viable product and what makes it such a powerful tool. Put this unfinished prototype in the hands of trusted end-users, be up-front about where you are in development and what you’re trying to do, and you’ll be surprised how much you’re able to learn. Most importantly, you’ve now got a road map for how to proceed in a productive way.
Moving Forward and Adapting
I’ve written this post as a means of explaining the general process of lean MVP development and the methodology behind it--if you’re looking to get into a real-life venture, you’re going to want to really dive into the assumptions your making and spend some time coming up with solutions for testing them.
At the end of this process, you’ll be able to reflect upon what you’ve learned. You’ll now have a much better idea who your target customers are, what they want, and most importantly for developers, how they want it. Maybe you discovered that instead of targeting all university students, you’re more interested in those doing poorly and those doing exceedingly well. You now understand that you can build a monetization model around connecting these students for mutual benefit, and if you’ve done a good job on your MVP you might even have a strategy for making that happen. Perhaps through feedback about the MVP app you developed you learned that students are more interested in one-on-one tutoring meetups instead of group-based sessions, and so you focus more resources on developing this side of the app.
At this point your product may look nothing like you had originally envisioned; this means that you could be at the start of developing a powerfully adaptive business venture.