An MVP stands for Minimum Viable Product and is often attributed to Eric Ries, a Silicon Valley entrepreneur and the author of the book “The Lean Startup,” published in 2011. In the book, Ries emphasizes the importance of quickly developing and releasing a product with the minimum features necessary to gather validated learning about customers’ needs and preferences. It’s an approach that allows startups to avoid wasting a lot of resources on building a product people don’t want. You have probably heard the term thrown around a few times by now, as it’s widely adopted in the startup community and beyond as a fundamental principle for product development.
What is a minimum viable product?
It depends on many factors, but the fundamental idea is to figure out the minimum amount of work you can do to verify that your product suits the right people.
In Ries’ book, he outlines how his startup spent an entire year building a plugin for a chat. The book reflects how he could have validated his idea with minimal resources. He concluded that he could have drawn the idea on paper and shown it to people. This would have saved him and his team a year of work.
You can’t always draw a picture to validate if there is a market. But in general, you’d want to know whether your idea is solving someone’s problem before you bring the perfect solution to market, and often, you can do this with a simple conversation.
The next step is to build the minimum viable product. There are many different schools of thought when it comes to the MVP. At toddle, we believe you should be ashamed of some parts of your product, otherwise it’s too polished before you get it in customers’ hands. An MVP should be shipped early because the point is that you’ll want to understand if you are solving a problem or improving a process as fast as possible. An MVP should validate or invalidate all your assumptions about your solution, and it’s time to identify which of your ideas hold water and which do not. Depending on your product, there probably are a few things that you’d need to build, but there is undoubtedly a lot that you do not need at all.
Why build an MVP?
The main reason is money and time. When you build a product exactly how you envision it without customer feedback, there’s a chance that what you have created isn’t valuable to potential customers. You may discover that your assumptions about people and their problems weren’t wrong, but they aren’t quite right. An extraordinary number of incredibly well-written web apps on the internet don’t do what their makers intended them to do, for better or worse.
One of the best examples is probably Google Wave. When Google introduced this product, it was supposed to disrupt our online collaboration. Where we used email in the past to communicate asynchronously, we now communicate in real-time. It was groundbreaking and later led to the introduction of collaboration in Google Docs, inspiring many of the features we now see in applications like Slack and GitHub. The big problem: People didn’t want to work this way. It turned out that people didn’t like others to see the email they were about to author.
Google spent enormous resources introducing a magical product with incredible engineering that no one wanted. In Google’s case, they spun out some of the features to their other products, but not everyone has that luxury. Most developers will benefit when they validate early and often, as it gives you a higher likelihood of building a product that people will use.
Don’t rely on friends and family.
Friends and family are suitable for many things, but not product feedback on a tool you are building. In the MVP process, you look for clarity. Friends and family often add unnecessary noise to encourage and support you. While support is excellent, you are trying to build software people will use and buy. One of the secrets that unlock quality feedback is that the second people need to pull money out of their pocket, they start to provide genuine feedback.
“Oh, I don’t think it’s a great product for me, but I could see someone using this.” When you hear this reply, you are asking the wrong person. Validate with potential customers, and state your intent early. Ask questions like: “How much is this worth to you?” “How much would you pay for a service like this?” or “How much time and/or money would this save you?”
The sooner you can get your potential customers to engage in a conversation about the commercials, the sooner you’ll get better quality hints to guide the direction of your product. In these cases, you also better understand their problems.
Getting people to use your product and eventually pay for it is the most critical stage for any company. In the primary example from the book “The Lean Startup,” they even tried to pay people to use their product, and people said no. This company made reasonable decisions along the way; they just didn’t validate their ideas. Don’t go to that extreme; get honest feedback early and often.
The desire to do good work leads us into a trap.
There’s an innate desire, primarily for technical founders, to do good work. You want to show off your craft and make things that load fast, are well put together, and handle all the edge cases. I spent six months building a queuing system for automobile dealerships in a previous startup before we realized no one wanted it. Six months is an eternity for a bootstrapped startup. In many cases, it’s the entire runway of the company. We based the whole company on one person’s idea. We partnered with a guy from the automotive industry who told us he could get us everywhere. When we had built the product and deemed it worthy of outside input, we realized that our partner had a non-compete clause in his contract and couldn’t get us in anywhere; we also realized that no one needed the product we had built. It’s a common issue and why there’s so much emphasis on building an MVP.
Get varied feedback.
Don’t rely on feedback from five users. Once you’ve identified a pattern, broaden your search and determine how well the product you want to build serves others. The more people you can convince to use your product, the better. You’ll want to understand the various use cases and challenges your customers solve with your product.
How do you get to an MVP?
Use design prototyping before you get to an MVP to verify that the idea is a thing.
The next natural step is to figure out how early you can get to something that’s usable and could be a standalone product. Many services are out there that let you build MVPs quickly. Typeform is an excellent example of an easy tool that will soon get you to an MVP. SwagUp was constructed exclusively with typeform until it reached around $5M ARR, and that’s when they decided to create a web platform that could better service their customers’ needs. When you onboard users to your product, you immediately get a more straightforward path toward building your product. It’s not always possible, but you should strive to get signups and have people use your product before creating it.
Some products or advanced use cases require some finished product version. In these cases, I recommend exploring some of the no-code tools. Several tools will help you build a product in a day or a week. One of my favorites is Glide, which will get you started quickly. It does come with some limitations, such as design and functionality. You may not be able to build exactly what you were hoping for, but that is the purpose of an MVP. We’d rather validate today than next month.
In extreme cases like toddle, where you almost need a fully-fledged product to get to your MVP, toddle is a great tool. It allows you to customize every aspect of your app fully, and you don’t have any throwaway work. You simply build your MVP and continue from there, whereas, with other tools, you may have to rebuild your app once you need it to scale, as in the case of SwagUp. An example our colleague Vakis gave me was from his time at Google. When they built the mechanism to serve ads on Gmail, they created an entire system outside of Adwords to validate that advertisers would buy ads on Gmail. Once they had reached $500M in revenue, they considered it validated and built it into Adwords, but they had to scrap all the work they did to enable advertisers to buy ads before it was part of Adwords.
When is an MVP ready?
An MVP is a product that has a place in the market. An MVP is a product that you can charge people to use. There are a lot of different definitions of an MVP, but I define it as a product that you can convince people to buy. There are many stages of an MVP, but you can make a simple solution good enough to convince someone to pay, and that’s the whole point of an MVP.
What are the three elements of an MVP?
If you boil down a Minimum Viable Product to the basics
- It’s valuable enough to use and buy.
- It satisfies and retains early adopters.
- It creates a feedback loop that guides future development.
If you stick to these three points, you’ll go a long way. You must consider the best tools for your product but find a healthy line between fast shipping and minimizing throwaway work.
Build something users love that’s simple, not bad products.
An MVP is not a broken tool with a bad user experience. It’s a simple product that validates your hypothesis that you can expand upon. An MVP is a product you’ll eventually scale, not a poorly built product. If it takes 10 seconds to load your website and half the buttons aren’t working, then it’s not an MVP. It’s a terrible product. Instead, reduce the amount of buttons and boil it down to the necessary features to validate your idea.
MVPs are temporary.
An MVP is temporary, and as soon as you’ve validated it, you should build upon it and focus on the aspects that make it a great product.
Don’t be discouraged if your idea doesn’t work out. Try to tweak it based on feedback, and don’t fear adverse outcomes. If there’s one thing Silicon Valley has taught us, it’s good to fail fast and fail often, as long as you learn and reflect on your actions. As you decide what to build, I highly encourage you to make great products and avoid building things no one will use. Your time is too valuable.
Originally published at https://toddle.dev.