By now, if you've begun researching ways to make your app, software or tech product go from being an idea in your head to a real thing, you know that it takes more than just a set of wireframes to kick off the process. And you may also know that it's a lot more involved than simply hiring developers.
If it's time to do this and do it right, you're ready to undergo the process of creating an MVP.
What is an MVP?
MVP stands for Minimum Viable Product. The term came from the customer development and lean startup movement championed by author and business leader Eric Ries. The concept: To build a product around a customer need or problem and test whether it's viable.
After decades of work in software, apps and tech products, I've come to understand that an MVP is very, very important for creating a successful product.
When an entrepreneur comes up with an inspired idea, the very next thing they want to do is ideate with a list of features to make it work. They're also often eager to start building.
Swept up in that initial fervor that comes from beginning to make your idea come to life, an entrepreneur will often assume that the rest of the world will find the product valuable and love it automatically. But very rarely do these brainstorming sessions include customer validation. Most validate their ideas with friends and family, but very few have actually talked to their first users.
In this scenario, blind confidence leads the way, and no customer research is done. Then, wireframes are created, developers and designers hired, and the team works in a cave for 6 to 12 months building an amazing product.
Finally, the product is released into the world. And 90% of the time, nothing happens. Nine times out of ten, the entrepreneur will lose all investment, hard work, design and development.
Of course, this is not a scenario we want. And this is why the MVP comes in handy.
Beginning the MVP process
It's absolutely vital to start from the user's perspective. Before we do any ideation or create a features list, wireframe, business plan, prototype, or MVP, we learn about the customers. This saves us a lot of time; we avoid taking shots in the dark and trying to figure out features and improvements before we need them.
Identifying the customer involves running down a list of questions: Who's going to use this, and why? What problems or pain points will this product solve? Who is most likely to benefit from this idea?
It's not an easy process. Very often, it feels unnecessary or like we're exploring the obvious. We're not. We want to build an MVP that will determine if the idea is going to be successful, or at least get us to that first step to discovery.
It's also not about asking people what they think of your idea; people can appreciate your work and innovation indirectly, but the true test of whether you have a successful product will come from the way it impacts those who need it.
It helps to think about your idea as a business, with the app as just a small part of it. Now that you're committed to your idea, suspend your perceptions of what it looks like and be open to the ultimate goal the product has of fulfilling the needs of others.
With this in mind, we track down our first viable customer through networking, marketing, or any means at our disposal. We don't stop at one; we gather as many users as we feel we need to validate. It helps to set a goal of finding 10 users and expanding from there.
Once we have our pool of users, we interview them and come out with a list of helpful questions and ideas about themselves, their tech use and how they feel this product could solve a problem for them. After that, we can begin to build.
To be clear, an MVP is not a prototype. Its purpose is to answer a business question: Does my idea solve the problem?
Actually building the MVP
OK: we've established that an MVP and customer validation are important, we've done our research, and we have a sense of what we need to do to create a strong, validated minimum viable product. What now?
In my next post, I'll discuss what goes into creating the actual product: the design sprint, the choice of a platform or coding language, deciding what skill set you need, and creating a balanced team to do the build. Then I'll explain the challenges of testing and validating the MVP once it's come out into the world.
By the way, I love feedback. If you have any thoughts, ideas or MVP pitches to share, send me an email.