You’re a startup founder with a product idea, but no clue what to do next.
Or maybe your next steps are to sit in your basement and build for months, because that’s what’s comfortable for you.
By the end of this article, I hope you’ll have a clear picture of how to get from your idea to a minimum viable product (MVP) in a way that doesn’t require you to sit in your basement for six months guessing at what to build next.
And if you stick around till the end of this article, I’m going to tell you about a pretty clever minimum viable product that was used to validate an idea for a company that later sold for more than billion dollars.
Your first question might be, what is this MVP minimum viable product?
A minimum viable product is the minimum thing that you need to build to show to customers or to have customers use to validate your next hypothesis. This does not have to be software, and often it’s not a simpler or final version of your final product.
In This Article:
Purpose of MVP
The purpose of an MVP is to figure out if the problem that you’re trying to solve is worth solving at all, and if the approach that you’re considering is headed in the right direction.
Without building an MVP, you’re taking a lot of guesses.
If you’ve talked to potential customers and they tell you they need a problem solved, you don’t know how badly they really need that solved because people will accidentally lie to you or they’ll tell you something to make you feel better and showing people mockups or asking them, hey, if I built this, would it solve your problem? It’s just messy data. In addition, even surveying or doing customer interviews, you never really know until you put something in front of a customer and you see how they react to it, something that actually tries to solve their problem in a minimally viable way.
When to build an MVP
You might be wondering, when should you build an MVP?
Usually it’s when you’re trying to solve a problem that you think exists, but you’re not quite sure if it’s a desperate pain point or you’re pretty convinced it’s a pain point.
Hopefully you have some data to back that up through conversations, or you’ve seen it firsthand at a workplace, or heard someone complain about it and validated that with other folks, but you’re not quite sure about the right way to solve it. The idea behind an MVP is to spend the minimum amount of time to get to the point where you’re getting data and information back from customers that aren’t just conversations. Obviously, talking to customers is important, but that MVP is the next step of validation.
Now, if I were building a startup today, and I knew there was a desperate pain point, and I had ten people lined up to try my product, right, to try the solution that I was looking to build, I would still actually build an MVP. I would build the minimum viable product to validate that next step. Because the problem with most startup founders is we’re way too overconfident that we know what will work, that we know it’s a problem, that we know how to solve it, when realistically, everything should kind of be a hypothesis until proven otherwise. And that’s something that an MVP can help you do. Remember, an MVP may not require any code, and an MVP is usually not just a simplified version of what you imagine being the final solution.
Three approaches to building an MVP
Human Automation
The first one is one I call human automation. Some folks call this the wizard of OZ approach, based on the quote from wizard of OZ:
Pay no attention to the man behind the curtain
In essence, this is where you have a service that appears to be automated, might appear to be software, but in fact you’re taking in an input, and then you have folks on the back end that are doing work.
You have humans that are slicing videos or sorting and cataloging things and then returning with a response. One example for this is what if I wanted to sell sales leads to freelance web developers and I was going to go crawl and scrape the Internet to try to get these leads to hand to these freelancers? I could either build a huge scraping engine, spend a lot of time doing that, or I could literally have human beings, maybe some virtual assistants in the Philippines or somewhere else that’s relatively inexpensive. I could have them crawling the Internet and doing it manually and gathering these into a Google sheet or a CSV.
Now, is that scalable? Is it profitable? No, very likely not. But what you’re doing is you’re testing the hypothesis. Will anyone pay for this? Will people remain subscribed? Does this solve a desperate pain point? Going and spending six months in your basement building a scraper? So that was human automation.
Use No-code
The second approach to building an MVP is to use no code.
These days with no code, this type of thing, where it’s a pretty simple create, read, update, delete, workflow notification. You can build that in no code. And the reason I know is because we’ve done that.
Sometimes no code is the best approach. If you are going to go the no code approach, the main platforms most people use, I mean, there are hundreds of no code tools, but the major players in the space are of course bubble, airtable, zapier and make. And you’ll find that you can build pretty robust, especially project management type tools in these no code apps.
Full Code
The third approach to building an MVP, of course, is full code.
If you’re a developer yourself and you want to spend a few months building something, and that is the minimum viable way to do it, you might need to break out the elbow grease and write some code. Now, if you are not a developer, the odds are stacked against you. I’m just going to be honest, like finding a developer co founder is probably the path that I would personally pursue.
If you eventually want to build a SaaS startup, you’re probably going to want a co founder. Hiring a developer or an agency. It can work, but realistically, what I’ve tended to see is if you’re not a developer, you don’t know how to evaluate a developer or an agency, so you trust them when they say they can build great software.
Most people don’t build great products. And so after six months or twelve months, you have all this technical debt. You have to start over, rewrite it from scratch.
I’ve seen multiple non technical founders have to go through this. And I’m not saying don’t do it. I’m just saying the odds are stacked against you.
How do you know your MVP is ready
When building an MVP, how do you know it’s ready?
It’s usually when you believe it solves the minimum pain point that someone might be willing to pay for, or at least might be willing to engage with you.
Maybe they’re not willing to pay for it yet, but it’s, it’s the first link on the chain, so to speak.
You have to think about what can’t you ship without? What is the core feature or features that you need? There are a lot of features that you don’t need in an MVP. Even if you’re building software, you don’t need billing. You can run billing manually.
You can literally have people Venmo you money, sign up for a PayPal subscription, give you a check, send them a stripe payments link. You don’t need to build billing code in order to have a minimum viable product. You don’t need to be able to do refunds.
You don’t need password resets. Oftentimes you don’t need delete buttons anywhere. You can go manually delete things.
There are so many things that you can cut corners on in an MVP and still have a viable product. No matter how I was building an MVP today, whether it’s human automation or no code or writing code, I would want to get the scope of the MVP into writing. And I would want to have conversations with customers validating that this is going to solve a problem that they think is worth solving. And in a way you think that they might want to pay for. And then scope that out, try to keep it small and build it out.
How long should an MVP take to build?
Some people ask, how long should an MVP take to build? Of course, it depends.
Some people can get an MVP out in a weekend. You hear the great examples of launching a quick AI wrapper that you can use to chat with your PDF’s over a weekend that was probably an MVP. Other times it might take you a few months of nights and weekends to cobble something together.
I think if you’re spending more than, I don’t know, two or three months putting an MVP together, it depends on if you’re working nights and weekends or if you’re working full time. But by the time you get into the hundreds of hours building one you may either be tackling a problem that’s too complex or you may be overbuilding your MVP.
Conclusion
Creating a Minimum Viable Product (MVP) in 2024 is a strategic approach to launching successful products in a competitive market.
By following the step-by-step guide outlined in this blog, you can validate your ideas, minimize risks, and ensure your product meets real user needs. Remember, the key steps include thorough market research, defining core features, developing a prototype, and continuously gathering feedback for iterative improvement. Embrace the MVP process as a dynamic journey of learning and adaptation, setting a strong foundation for your product’s long-term success.
With careful planning and execution, your MVP can pave the way for a scalable and impactful solution.