Michael: My name is Michael. I work here at Y Combinator. I help run the accelerator. Before that, I did two YC startups, one in 2007 and one in 2012. And today, I'm gonna talk to you about minimum viable product, so MVP. We always yell at founders to not use jargon, yet we have this whole set of stupid startup jargon, and MVP is one of them. When you think about an MVP, you should think about something ridiculously simple. This is the first thing you can give to the very first set of users you wanna target, in order to see if you can deliver any value at all to them. That's all it is. It's extremely simple.
I know you guys had a talk last week about how to come up with ideas, how to come up with problems you want to solve. What I will tell you is that it is helpful to talk to some users before you decide to build your MVP. This doesn't mean you have to go into a three year, kind of, research situation, or you have to work in industry for 10 years. But some conversations are helpful. It's even more helpful if you're your own user, so you can tell whether your product's working for you. I always get this strange question of how do I get my first users, which always kind of confuses me because theoretically, you decide to solve a problem that you know someone has. So the way you get your first users, you talk to that person that you know has the problem. And if it's you, it's even easier. So if you are building a product for a mysterious set of users that you have no idea who they are, question that slightly. Very slightly.
Okay. So, the goal of a prelaunch startup is extremely simple. Step one, launch quickly. This is something that's been part of the YC ethos from the very beginning, and it's been great advice for 10 years, and it continues to be great advice. If you can walk away from one thing from this presentation, it's launch something bad, quickly. That's it, like, literally the rest of what I'm gonna say is basically gonna be re-summarized versions of that same thing.
The second thing that an early stage startup needs to do is get some initial customers. Get anyone using your product. You don't have to have a vision of how you get everyone using it, but just anyone interacting and seeing if they get value out of the product. You'd be surprised at how many founders' journeys end before a single user has actually interacted with a product they've created. It's very, very common. So please get past this step. It's extremely important.
The next one is, talk to your users, any of them, after you've launched this MVP, and get feedback. This is one that's also extremely common mistake, because most founders in their heads have a idea of what they wanna build. And so they kind of have this weird feeling that if I haven't built the full thing yet, getting feedback on the shitty initial thing is kind of useless. "Of course, it's not gonna work. It's not the full thing. The full thing is gonna take three years, $10 million, a whole team. So feedback on the little thing is useless."
The reality is that, in some ways, the full thing is this really awesome idea in your head that you should keep in your head, but it should be very, very flexible, because it might turn out the full thing that you wanna build isn't what your customers want at all. So, I have this saying: Hold the problem you're solving tightly, hold the customer tightly, hold the solution you're building loosely.
And last and most important, iterate. And I like to kind of distinguish between iterating and pivoting. A lot of founders, once they've figured out how to build something, fall in love with it. And so if it doesn't work for a certain set of users, they start thinking, "Well, I wonder what other problems this thing can solve? Well, you know, this screwdriver is not actually good at screwing in anything, but I wonder what other problems it could solve." And they're like, "Oh, maybe you can use it to cook. Maybe you can use it to clean." And it's like, no, like, the problem was, I need to screw something in, the user was, like, a mechanic, and if your screwdriver doesn't help the mechanic solve the problem, keep the mechanic, keep the problem, I need to screw something in, fix the fucking screwdriver. Like, that's the thing that's broken, right? The broken thing is not the mechanic, and it's not the fact that they need to screw something in. So, iterate. Continue improving on your solution until it actually solves the problem.
In most cases, most people should be building a very lean MVP. So by that, we mean you should be able to build it fast, in weeks, not months. This can either involve software, or honestly, we see startups just start with a landing page and a spreadsheet. But most startups can start very, very fast.
The second, extremely limited functionality. You need to condense down what your user needs, what your initial user needs, to a very simple set of things. A lot of times, founders wanna address all of their users' problems and all of their potential users, when in reality, they should just focus on a small set of initial users and their highest-order problems, and then ignore the rest until later. You should have a vision of everyone. You should have an MVP, very small. All this is is a base to iterate from. That's it. It's just a starting point. It's not special in any way. You just have to start. And so, please make sure you don't feel like your MVP is too special.
Okay. Here is a classic example. This is one of Airbnb's first landing pages, in 2008, I believe. One of the things that you might be interested in about in Airbnb's first product is that there were no payments. When you found place to stay on Airbnb, you had to exchange money with the host in person. Needless to say, that was a pretty fucking big problem, but they started without payments. No map view. You know how when you search Airbnb, you can see where the house is in the city? You don't have that. Sorry. And, the person writing all the code, Nate, was working part time. Okay? So everyone tells these kind of magical stories about how everything was perfect from the beginning. Airbnb, not perfect from the beginning.
The next one, Twitch. This was what Twitch looked like day one. Not very familiar. Well, maybe a little familiar. There's some video there, and there's some chat there. Other than that, nothing else. Twitch launched as Justin.tv, which was a online reality TV show. There was only one channel, Justin. You had to follow his life. If you didn't like his life, you had to leave the website. That's all there was. The video was extremely low resolution. It was funny, a founder asked me back in the day, like, "Oh, like, wasn't it weird, you guys had video in your apartment. Weren't there all these, like, secret documents and things that, like, people would be able to see?" And it was like, you could barely recognize our faces, let alone documents that we had. And most importantly, there were no video games. No video games, except if we decided to play video games in our apartment. Like, that was the only time video games ever appeared. And so, say you can do that quickly. When you think about Twitch, it's much more complex now.
Last, Stripe, which wasn't Stripe. It was called /dev/payments because, why not? Like, let's make a name that's really easy to remember. This was Stripe day one. No bank deals. I won't tell you exactly how they process payments, but it was in a very startup-ey way. Almost no features, and even cooler, if you wanted to use Stripe, the Stripe founders would come to your office and integrate it for you. How nice is that? Half because they were just desperate to get anyone to use it, and half because it was a great way to find bugs before the users found bugs. Integrate yourself.
So these are just three examples of extremely simple, extremely fast-to-build MVPs. All of these are billion dollar companies, and they all started with something that most people would say is pretty shitty. In very few cases, you have to build a heavy MVP. I just invented that term, heavy MVP, when I made this presentation two days ago. So, you know, maybe it becomes a thing. If you're in an industry with significant regulation, like insurance or banking, sometimes drones, although sometimes not, it's hard to launch. It's harder to launch. You have to pass through a bunch of regulatory bodies first. If you're doing hard tech, if you are building rockets, it is hard to build a rocket in a couple weeks.
Biotech, it is hard to invent a cancer drug in a couple weeks. Moonshots. Well, fill in all the other blanks. It's hard to bore tunnels in the earth and have extremely fast vehicles that replace cars in a couple weeks. So, if you're in that situation, please remember that your MVP can start with a simple, simple website that explains what you do. It's helpful, when you talk to people, interact with people that they can refer back to something. So, that can be your start, and you can build that simple website in days, not weeks. So, many ways, maybe your heavy MVPs are faster than your lean MVPs in some weird, strange way.
Now, I wanna talk about launching for a second, because a lot of founders have this misconception about launching. They see big companies launch stuff, and they assume that's what startups do. In fact, they see companies they kind of think about like startups, Facebook's not really a startup anymore, but they see them getting a lot of press and getting a lot of buzz and yada yada yada, and they have in their head that that's what a successful company looks like when they launch.
Well, let me ask you this question. How many here remember the day that Google launched? No. How about Facebook? Okay. How about Twitter? No. Great. So it turns out that launches aren't that special at all, okay? So if you have this magical idea of your magical launch you wanna do, throw it away. It's not that special. The number one thing that's really important is to get some customers. So, to make people feel better, let's use different terms. How about launch is when you get any customers, and how about, like, press launch, press launch, really impressive, is when, like, people write about things and it's all exciting and you get all this buzz. Let's push the press launch off, and let's push the get-any-customers launch really, really soon. That's our goal here.
It's a lot harder to learn from your customers when they don't have a product they can play with. You know, you can talk to your customer all day, but you have no idea whether the thing you wanna build can solve their problem. If you put the thing in front of them, and it doesn't solve their problem, you know right away. And so, all the research in the world is good, but until you can put something in front of people, you have no frigging idea whether it's gonna work. So spending all that time on a pitch deck is not as valuable as spending your time building anything that you can give to a customer.
Finally, some hacks for building an MVP extremely quickly. First, time box your spec. So, your spec is the list of stuff you need to build before you launch. Time box it. Say, okay, what happens if I want to launch in three weeks? Okay, well, the only things that could be on my spec are things I can build in three weeks. That makes your life a lot simpler. It allows you to remove all the features you can't build in three weeks.
Second, write your spec. This seems really straightforward, but most people fuck this one up. It's really easy to change what you're working on before you ever launch it, because you never write it down. You start working on something, you talk to a user, they say, "Oh, I would never use that," or God forbid, you talk to an investor and they say, "Oh, that could never be a company because investors know everything." And so you decide to change what you're working on. And because you never wrote it down, you don't even really realize you're changing it. And so your three week plan turns into a three month plan. If you write shit down, at least you can be honest with yourself that you're changing your spec all the time.
The next one is cut your spec. A week into your kind of three week sprint, you probably realized that you added too many things to your spec, and you were not gonna make your deadline. That's okay. Just cut the stuff that clearly isn't important. And if there's no non-important things, start cutting important things. Most of the goal here is just to get anything out in the world. Once you get anything out in the world, the momentum to keep anything going is extremely strong. Once you have any, if you don't have anything out in the world, it's very easy to just delay, delay, delay, delay. And then last, don't fall in love with your MVP. So many people fall in love with the vision in their head. And none of the products I showed you before was the initial vision, what it ended up being. So please don't fall in love with your MVP. It's just step one in a journey. You wouldn't fall in love with a paper you wrote in the first grade. And, like, that's like the level of impact often your MVP has. Okay. That's the talk. I have a little bit of time for questions. Any questions? Perfect. No questions. Oh, go ahead.
Woman 1: I'm finding, talking to users, I have several subtype segments, and of course each one wants a particular thing, and another one wants a particular thing. So, the numbers are so small that they kind of even out. So how...
Michael: Great question. So, you talk to users and they have all these things that you want to build, and there isn't a lot of overlap between them. So, I will give you kind of the meta answer: Never ask users for features. Never ask users to tell you what they want. It's not the user's job to come up with features. That's your job. The user's job is to give you problems. And so, I would assume that if you were talking to these users, there's some continuity in the problems that they have. They probably have no idea how to solve the problem.
And so they're probably giving you a long list of potential features they think can solve the problem, as opposed to spending a lot of time just talking about what their problem is. How often do they experience it? How intense is it? Are they willing to pay for a solution? Do they know other people who have the problem? So, like, those are the questions I'd be trying to get out of someone. And if you see someone sneaking into feature zone, like, "Oh, you know, I love Microsoft Word, but I wish that, like, someone could build something that lets me do blah, blah, blah, blah, blah," right, that you've gotta scoot it back down to, "Oh, well, why do you wanna do blah, blah, blah, blah, blah? What problem do you have? How often do you encounter that problem?" And, like, get it back to the problem. That's how you avoid feature death. It's extremely common.
Woman 2: I find myself walking that very thin line between staying focused on my MVP, but changing it up because I'm finding one thing better. So, I started off on my MVP talking to all my potential users, and I'm, "No, no, no, no. We gotta do this, we gotta do this, we gotta do this." So, like, do I take my ADD medication and just keep going with what I started with, or when do you stop and say, okay, this warrants a change?
Michael: Oh yeah. Sorry. So the question is, I'm stuck in this cycle where I keep on changing my MVP and I don't launch. Obviously, a lot of people are stuck in that cycle, and there are a lot of startup problems where the answer is, "stop doing what you're doing." Just stop it. Like, you don't have to keep on changing your MVP. One of the reasons why perhaps you're changing your MVP is because you think it's special. If you didn't think it was special, you would stop changing it. You'd stop editing it.
Woman 2: I don't understand. Explain that again.
Michael: If you think your MVP is special, you think it has to be perfect. If you think it has to be perfect, you spend a lot of time messing with it. If you assume that it has to be really shitty, right? Like, if you think, like, "Okay, like, I'm literally trying to find a shirt in my closet that I can paint with and then destroy," you don't spend a lot of time tailoring that shirt, right? So, if you think your MVP is less special, you'll spend less time tinkering with it.
Man 1: Say you launch an MVP and you're looking for feedback, what are the key things you want to ask your users?
Michael: This is a really simple question. What's the key thing you wanna learn when you wanna get feedback on your MVP? Does it solve the problem I want it to solve? That's it. You can find 80 different ways of answering that question, but if you clearly understand the problem you're trying to solve, then it's a pretty clear...oftentimes, you don't have to ask. If it's in front of the user, you can see whether they're, like, doing the thing you want them to do or, whether they're, like, not. Oftentimes, you can see it in the numbers. If it's a problem they have every day, and you introduced a user to it, did they come back the next day? I've never really seen a product that solves a problem people have every day, that actually solves the problem, where a user just stops using it because, like, whatever. So, there are lots of, like, weird nuances here that are completely irrelevant. Does the user do the thing, solve the problem that you want them to solve? Other questions? In the back here?
Man 2: How long should an MVP last? I mean, you start growing, and then what are the next steps?
Michael: You know what's fun about startups? I don't like thinking about timelines, and I don't think linking about roadmaps. Like, for people who are in the pre-MVP stage, like, who knows? Launch something. Figure it out. You decided to do a startup, and one of the characteristics of startups is that how to get from A to Z is not gonna be clear. And so, if you're too focused on like, "Oh, well I understand getting to MVP is step B, but I'm really focused on steps C, D and E," I would tell you, like, "Hey, how about solve the problem right in front of you first?" Yep?
Man 3: So, how do you balance, for example, improving the MVP to grow the retention of customers, versus betting on efforts to grow acquisition and regeneration, in terms of problems?
Michael: Post-MVP, should you work on growth, or should you work on retention? I love this question. It's the funnest question in the world, because it allows me to give, like, a ridiculously canned answer. Both. Yeah. Here's what happens. A lot of founders kind of fundamentally understand the startup is a multi-variable problem, but multi-variable problems are hard. So they try to reduce it to a single variable. So they ask the, like, secret advisor, like, "Oh, what's more important, growth or retention?" And it's like, what's more important, like, taking a shower or going to the bathroom and, like, do a number two? I'd like you to do both. Sorry. Both are important. As a founder, you're gonna have to juggle multiple things. Yeah. Okay.
Man 4: Okay. Can you share a story with, like, a startup that couldn't talk to the end users because end users didn't want to talk about the problem and how they overcome that, if you know.
Michael: Let's be clear. The question is, how do you talk to your users if they have a problem they don't wanna talk about? Why don't you tell me, is, what that is?
Man 4: Type two diabetes.
Michael: Type two diabetes. I am perfectly confident that you can find 10 people who wanna talk about their type two diabetes. And I question you starting a startup to help type two diabetes people if you don't know anyone who's got type two diabetes who's willing to talk to you. So I think that's, like, one of those false setups. Like, I reject the premise of the question. All right, next question. Go ahead.
Woman 3: How many people would be enough to sign up, or how many active users would it be good to have in the MVP before presenting to investors, for example, based on which metric ... market size or?
Michael: That's a great question. If I were to summarize, I would say, how far along are you before you talk to investors? I'm also going to punt on that answer. I think there's gonna be a whole lecture on when you should talk to investors. And so, I will say, wait for that lecture, and whoever gives it will do a great job at answering that question.
Woman 5: My question is, what type of numbers or traction should you look for before your product is validated?
Michael: I'll rephrase that question. How do you know when you have product-market fit? Okay. The classic answer, which is actually correct, and founders really hate, is that if you're asking, you don't have product-market fit. What tends to happen when you have product-market fit is that people start using your product so much, you transition from doing anything, other than just keeping it online. That's what product-market fit tends to look like. So, you stop thinking about new features. You stop thinking about improving your, like, conversion through funnels. You stop thinking about how to get better distribution. And you are literally just, like, "Holy shit, I don't know how I'm going to serve the people who are coming to my product tomorrow. I'm at a loss. And next week, I'm at a loss. And I'm pretty sure that we're gonna die, because we're have too many users."
And what's funny is when I put it that way, it's not hard to know whether you're there or not. And the such a horrible reality is that almost no one gets product-market fit. Almost no one. Almost no one. So, like, a lot of people like to throw around the term, and a lot of people like to redefine it as, like, "Someone's using my product." That's not the term. The term for someone's using your product is, "You have a user." Which is good, but it's not product-market fit. In the back.
Man 5: The more users we talk to, the definition of the problem keeps on getting bigger, bigger and bigger. So, when figuring out MVP, where do you start? We started working with just one user, and we tried like just one small experiment with them, but we learned more attributes of the problem itself.
Michael: So, what happens if you learn more about the problem, and the problem expands as you start interacting with users? That's totally fine. That's expected, in fact. What I would say though, is that where founders usually make the mistake is they think they have to solve the problem for all users. And so, most importantly, if you have one user with a set of problems, a nice thing to do would be to try to figure out, is there anyone else like them? And, like, one fun thing you could do is just ask them, "Hey, do you know anyone else who's got your exact same problem?" Any problem, when you kind of scoot back and you think about the vision of any founder, it actually encompasses, like, a whole subset of problems. And I think the thing that gets people really screwed up with their MVP is that they have a vision that's big, and they're not willing to have an MVP that's small.
They feel as though if they're not addressing all of the potential users up front, then they're somehow failing. And, like, there are a lot of things that a startup has to do, a founder has to do, where they're keeping two things in mind at the same time, right? Vision big, MVP small, right? Grow, and retain. One thing we talk about at YC a lot: your investor pitch, and your customer pitch, very different. And, right, founders always want to smush these things together or kill one, because it's so much easier to think of it as a single problem, like, single thing in your head, versus two opposing things in your head. How could it be true that we want to do payments for everyone, and have a little API that's so hard to use that we have to install it for people, right? And it's like, both things are true, and you have to be comfortable with that. All right. One more.
Man 6: In the pharmaceutical space, will my users be scientists, or will they actually be patients?
Michael: In the pharmaceutical space, who are your users? I think that that's a question for you. You were starting the company, you know what you're building, you know a problem you're solving, you know who has the problem. I don't know any of those things. All right. It was great talking to all of you. Thank you very much.
The year was 1999. There was a young guy who wished to own a particular pair of shoes. He went to a mall close to his place but, unfortunately, he was unable to find the pair.
Frustrated, he came up with an idea to sell shoes online and that’s where it all started.
Minimum Viable Product (MVP) was born.
Rather than conducting extensive and expensive market research, he built a basic website. Then, he approached a shoe store, clicked pictures of shoes, and placed them on his site. Upon receiving the order, he purchased the shoes from the store and shipped them out.
Although he lost money on every sale, it was an incredible way to test a business idea. Once he inferred that customers are willing to purchase shoes online, he started to turn his idea into a fully functioning business.
This is how Nick Swinmurn built the company Zappos, which was later acquired by Amazon for $1.2 billion USD.
The approach that Nick followed is what is termed MVP Development in today’s time.
What is an MVP (Minimum Viable Product)?
An MVP (Minimum viable product) is a basic, launchable version of the product that supports minimal yet must-have features (which define its value proposition). An MVP is created with an intent to enable faster time to market, attract early adopters, and achieve product-market fit from early on.
Once the MVP is launched, initial feedback is awaited. Based on this feedback, the company will reiterate to fix the bugs and introduce new features that those early adopters suggest.
The MVP approach allows for:
- Making an early market entry which leads to a competitive advantage
- Enabling early testing of the idea with actual users to check whether the product is able to solve their problems efficiently
- Working effectively towards developing a fully-fledged product that integrates user feedback and suggestions
What is the MVP Development Process?
Minimum Viable Product (MVP), is exactly what it says on the label: the product in its smallest, least featureful avatar. An MVP has just the basic functionalities that demonstrate the product and its ability to solve a user problem. Eric Ries defines it in the following way:
Minimum Viable Product is that version of a new product that allows a team to collect the maximum amount of validated learning about customers with the least effort.
In mobile app development, MVP is a basic version of a mobile application. MVP is a process of building a new product with core functionalities and important, minimum features, to test how the target audience would respond. Then, the building of the actual product takes place with the full set of features after a series of iterations, with feedback from early adopters.
P.S.– It is building a slice across the whole development process rather than one layer at a time.
MVP helps in testing, designing, and delivering the final product. MVP Development plays an important role in web development and designing. Several businesses have pitfalls while trying to launch a Minimum Viable Product for a mobile or web app. That’s why it is important to understand the vital question: what is the best way to develop a Minimum Viable Product?
Purpose of an MVP
The purpose of building an MVP is to launch a product quickly, based on an established idea, with a small budget. This approach allows a business to collect users’ feedback for the primary product and include it in future iterations. With the help of an MVP, one can find the right audience, pull the ideas based on experience, and save time.
Building an MVP implies finding the right balance between what the business is offering to users and what users actually need. The purpose of the MVP is to test the hypothesis that the product will solve a user problem. MVPs also allow businesses to minimize errors in the development process. An MVP helps in collecting maximum quality feedback by targeting specific groups or user types.
Business Benefits of MVP Product Development
What if we found ourselves building something that nobody wanted? In that case, what did it matter if we did it on time and on a budget? – Eric Ries
To survive in today’s cut-throat, Darwinian business era, releasing a product faster and within a budget is a prerequisite for a successful new product development process. The following are the benefits of building an MVP:
1. Focus on Building the Core
An MVP app focuses on one idea, and it does not include any other function. The approach of the MVP belongs to the ideology of a lean startup: building the right product with a minimal budget in a given time. Having only some of the high priority, but minimum features can reduce the cost of MVP development. The MVP then allows the app to be tested, with minimal risk.
2. Early Testing Opportunity
It is good to find out from the beginning if the product idea will work without investing the entire product budget.
3. User Intelligence and Gathering Feedback
The MVP offers the possibility to find out potential users’ opinions, and what they want to see in the final product.
4. Allows Market Validation
An MVP helps a business understand whether the app is right for the target market. An MVP should present the company brand well to the users, and show them how this product is unique compared to what the competitors are offering.
5. Takes Less Time to Develop an App
Less development time means lower app development costs. The faster the mobile app is launched to users, the faster the business will receive feedback. This means they can work on the improvement of their app, and release an updated version quickly.
6. Budget-Friendly
Another important advantage of developing an MVP early in the new product development process is that this approach is budget-friendly. Using an MVP allows businesses to test their idea before spending their entire budgets on things that may not work.
Research shows that, in 2017, the mobile app market grew considerably.
Very few apps are actually downloaded out of many available on the play store and iOS store because of issues in their user interface and poor performance. It is advised to create an MVP as it is an easy way to enhance the mobile development strategy.
The Need to Build an MVP
The fundamental activity of a startup is to turn ideas into products, measure how customers respond, and then learn whether to pivot or persevere. – Eric Ries
While starting up a business or launching a new product, people often invest a large amount of time in the initial idea screening and approval phases. Once the idea is approved, the MVP Development process is the right solution to quickly turn that idea into a bare-bones product that can be launched and tested.
Stats Emphasizing the Need to Build an MVP
- 29% of startups fail because they run out of cash
- Startups that scale properly grow 20 times faster than those that scale prematurely
These stats explicitly show the benefits of beginning the new product development process with an MVP. However, there are more reasons to build a Minimum Viable Product which include:
- Creating an initial model that provides a starting point for discussions and offers clear visual points of reference
- Conducting initial idea approval which includes sharing the model with a few prospects, and testing it with genuine users. This helps in understanding the issues that may become apparent with the product
- Starting the actual building process of the product after dedicating months to improving and refining the software idea is a large and motivating step towards building a fully-fledged product
While building a mobile app, a business must understand that the whole idea to build an MVP is divided into two main parts, which include:
- Business and Marketing: An MVP allows the business to launch a survey to identify the best marketing approaches and advertising platforms that could be used for the advancement of the product
- Proof of Concept: By building an MVP, the business will gain important technical insights from important programming and designing a minimum feature set, which, in turn, will help them make their app unique
How to Build a Minimum Viable Product?
Queries like “How unpolished can my minimum viable product be?” trend on Quora; Hackernoon writes, “The MVP is Dead. Long Live the RAT.” Google’s autocompleting suggestion says: “MVP is dead.”
Reid Hoffman said: “If you are not embarrassed by your first product, you launched too late.”
And this quote of Hoffman allowed start-up founders, especially the first-time entrepreneurs, to focus mainly on ‘M’, and almost ignoring ‘V’. The result is a below-average product, rather than an excellent one.
For instance, startups come up with a free sub-domain website with almost no content and call it a startup. When it fails to attract visitors, they call it a failed MVP and look for a solution to the so-called MVP problem.
However, the real problem lies in the lack of understanding of the steps involved when it comes to the MVP Development process. It is necessary to follow all of the steps involved described to successfully build an MVP:
Step 1: Start with Market Research
At times, ideas will not fit into the market needs. Before a business initiates an idea and embarks upon an MVP Development process, they should ensure that it fulfills the target users’ needs. This can be accomplished by conducting surveys. At the end of the day, the more information a business has, the higher the chances of success. Also, do not forget to keep an eye on what the competitors are offering and how the product idea can stand out.
It is not enough to do your best; you must know what to do, and then do your best. – W. Edwards Deming
A survey conducted by CB Insights revealed that the number one reason for a startup’s failure was a ‘lack of market need.’ In a nutshell, if the product doesn’t nail the problem, customers won’t go along with it to find a solution.
Step 2: Ideate on Value Addition
What value does the new product offer to its users? How can it benefit them? Why would they buy the product? The answers to these questions can help define the value proposition of the app.
It should also be clear what the essential estimations are for the product. As MVP implies, the product in its most basic state has to introduce value to the people. Begin by outlining the users and build the MVP based on their needs.
Step 3: Map Out User Flow
The design process is an important MVP stage.
Design the app in a way that is convenient for users. The business needs to look at the app from the users’ perspective, starting from opening the app to the final process, such as making a purchase or delivery. In addition, user flow is an important aspect to consider because it ensures nothing will be missed while keeping the future product and its user satisfaction in mind.
To define the user flow, it is necessary to define the process stages. For that, it is essential to explain the steps needed to reach the main objective. The focus should be more on basic tasks such as finding and buying the product or managing and receiving orders rather than features.
These are the goals that the end-users will have while using the product. When each of these procedure stages is clearly laid out, it is time to define the features of each stage.
Step 4: Prioritize MVP Features
At this stage, prioritize all the features that the MVP will support. To prioritize the MVP features, ask questions such as: What do the users want? Is this product offering them something beneficial? Etc.
Next, categorize all the remaining MVP features based on priority: high priority, medium priority, and low priority. Another essential step is to arrange these features in the product backlog (priority-wise). It is time to begin building an MVP. If a business wants to see how their future product will look, they can even create an MVP’s prototype.
Fun Fact: Steve Jobs was out of his job because of avoiding the stage of prototyping while building the Apple Lisa. The result was a disaster as it failed to achieve a favorable number of sales.
Step 5: Launch MVP
Once a business has decided upon the main features and they have learned about the market needs, they can create the MVP. Keep in mind that an MVP is not lower quality than a final product, but still needs to fulfill the customer’s needs. Therefore, it must be easy to use, engaging, and suitable for the users.
The main reason why products fail is that they don’t meet customers’ needs in a way that is better than other alternatives. – Dan Olsen
Step 6: Exercise ‘B.M.L.’ — Build, Measure, Learn
Everything is part of a process: first, define the scope of work followed by moving the product to the development stage. After the completion of product development, the product needs to be tested. Quality Assurance engineers, who work to improve the quality of the product (even if the product is not released) conduct the first testing stage.
Review everything thoroughly after launching the MVP. That is, the business must collect their client’s reaction to the release. With their feedback, they can determine the acceptability and competitiveness of their product in the market.
5 Development Mistakes to Avoid While Building an MVP
In today’s highly competitive digital commerce world, Darwin’s ‘Survival of the Fittest’ theory offers a fitting description. Business leaders are following the MVP development process to test the worth of their product without constant outflow of money or time.
However, to build a successful MVP, it is important to dodge a few development pitfalls that can result in an epic business failure.
1. Choosing the Wrong Problem to Solve
Before spending months of effort towards developing a product, the initial step is to determine whether the product is worth creating or not.
Once a business has analyzed the pain on which their startup will be built, they should ask themselves these questions:
- Who is this for?
- What problem will this product solve?
- Is the proposed idea an effective solution to that problem?
If they intend to target everyone, they will end up getting no one. Find the doors first, then start to build the key. A great-looking key is not useful if it can’t open the right door.
After cracking the right target audience, if the answer to the second question is positive and a confident ‘Yes’ for the third, then the business has the problem and solution juxtaposed effectively. It’s time to start pressure-testing their idea.
2. Skipping the Prototype Phase
Prototyping is the conversation you have with your ideas. – Tom Wujec
Imagine building a car without referring to a visual model. It is quite impossible, right? Jumping straightway to the development process without defining the requirements is just as difficult.
A vital part of product development is the evolution of the idea from a unique concept to a fully working product or service. Between the idea, and the full-fledged product lies the prototype that focuses on the ‘How’ part of the product.
Consider prototyping as an MVP to build an MVP: not a fully functional version, but a version to help visualize the user experience of the Minimum viable product.
The ideal prototype should be of Goldilocks quality. If the quality is too low, people won’t believe the prototype is a real product. If the quality is too high, you’ll be working all night, and you won’t finish. You need Goldilocks quality. Not too high, not too low, but just right. – Daniel Burka, Google Ventures Design Partner</span
3. Targeting the Wrong Segment of Persona
The main reason why products fail is because they don’t meet customers’ needs in a way that is better than other alternatives. – Dan Olsen
Once a business is ready with an MVP prototype, it’s time to validate it through testing. At this stage, it is necessary to acquire comments and feedback from the target audience. It is important to keep in mind that everyone is not the targeted user.
Do not ask friends or relatives to be involved in this stage unless they are potential customers. It is important to avoid irrelevant feedback that could lead to the product/service getting dumped for the wrong reasons.
The Importance of Feedback in Building an MVP
It is important to realize that the end-users are the ones who can tell what is lacking and what is redundant. Once a business collects feedback from the users, they can start improving the product. Once improvements have been made, they will once again test, learn, and measure the quality. This process repeats until the product is finalized.
Example: The feedback from the potential users after the prototyping stage helped Nike to understand that it is hard for users to locate the call to action (CTA). The feedback from prototyping prevented them from releasing a product that was difficult for users to engage with.
4. Inappropriate Development Method
There’s a way to do it better find it. – Thomas A. Edison
Jumping directly into the process of MVP development without prior knowledge of the correct development method of building is one of the major reasons for startups giving up the project in the middle. This is one of the major contributing factors to why nine out of ten startups fail.
Generally, there are two approaches for MVP product development: Agile and waterfall.
When compared to Waterfall (Traditional Method), Agile product development is far more efficient and offers better results. Agile offers speed to market and offers a flexible approach as it focuses on incremental and iterative development.
5. Confusion Between Qualitative and Quantitative Feedback
[Triangulation is an] attempt to map out, or explain more fully, the richness and complexity of human behavior by studying it from more than one standpoint. – Cohen and Manion
Qualitative and Quantitative feedback are two ways to collect data from the target users. However, relying on one of them and neglecting the other can hinder the business’ ability to reach an accurate conclusion.
Both types of feedback have a different role to play and hence it is vital to hit the right balance between these types to come to a well-rounded conclusion that can help to inform intelligent changes.
- Qualitative feedback consists of findings that are associated with the quality and user-friendliness of the features of the product/service. It directly assesses the usability of the system by helping developers to analyze the specific problematic UI elements
- Quantitative feedback is in the form of metrics that pinpoint whether the tasks were easy or difficult to perform. It indirectly assesses the usability of the design. Such feedback can be dependent upon the performance of the user on a given task (i.e., success rates, number of errors, etc)
| 1. Questions answered | Why? | How many and how much? |
| 2. Goals | Both formative and summative: Inform design decisions Identify usability issues and find solutions for them | Mostly summative: Evaluate the usability of an existing site Track usability over time Compare the site with competitors Compute ROI |
| 3. When it is used | Anytime: during the redesign, or when you have a final working product | When you have a working product (either at the beginning or end of a design cycle) |
| 4. Outcome | Findings based on the researcher’s impressions, interpretations, and prior knowledge | Statistically meaningful results that are likely to be replicated in a different study |
The ideal approach is the amalgamation of qualitative feedback with quantitative feedback. This is known as “Triangulation Feedback” and describes the process of gathering data for an overall accurate interpretation that takes a variety of different factors into consideration.
This approach boosts the chances to control the threats that can result in product failure. If both the feedback methods come to a common conclusion, then the developer will be more confident with the success of the product.
Tips to Target the Right Market while Building an MVP
Beautiful product development in an ugly market segment simply makes no sense. – Dan Adams
Imagine how to sell a minimum viable product of an air conditioner in Antarctica. This is definitely a challenging task. The same rule applies when a business is on a mission to build an MVP. No matter how good the product/service is, it will fail if the business is unable to solve the other half of the equation: finding the ideal target market for the MVP.
Most startups begin to build an MVP with a sweet assumption that “everyone” will rush to buy their products or sign up for their services. Soon, they become one of the references for various studies and researches. For example, this report from HBR reveals that 85% of 30,000 new product launches failed because of poor market segmentation.
1. Analyze the Competition
It is important to dive deep into the competitor research to find out what the product will be up against. It’s nearly impossible to build an MVP that doesn’t already exist in the market. Even if a startup has unique ideas, they will still be joining an existing and competitive industry.
Therefore, they have to figure out how to place their Minimum Viable Product within an industry where competitors are already doing what they are trying to do.
To find this out, the startup will need to conduct research on the competitors. Evaluate their strong points and weaknesses. Figure out their target audience and what they are offering to them. The startup can go ahead with the same target market their competitors’ chose or they can concentrate on a group that their competitors might have overlooked.
Look at the image above as a reference. There are 4 basic options for any startup in successfully competing in a given industry: cost leadership, differentiation, cost focus, and differentiation focus.
2. Geographically Segment the Customer Base
Once the startup has found the right customer base for the MVP, the next task is to focus on geographical segmentation. This is an effective strategy used by businesses to get familiarized with the location-based attributes that comprise a specific target market. Analyzing the location of the ideal customer base can be a real game-changer while on the route to build an MVP.
For instance, what’s the purpose of initiating the search from Southern California if the minimum viable product is a winter jacket. The winter varies between moderate to warm at this place.
Target consumers that live in different geographic regions have different needs and cultural characteristics that can be individually targeted for better and more efficient marketing. Once the startup becomes aware of the geographical location of their target customer, they can better design their MVP by finding answers to key questions such as:
It is evident from the picture above that there are various factors, dependent upon geographical location, which play a vital role in the success of an MVP and product development.
3. Find the Motivation Behind a Purchase
After geographically segmenting the customer base, the next task is to understand their motivation behind the purchase. This will help the startup perfectly balance its MVP positioning.
The easiest way to achieve this is to run a survey. Keeping the Minimum Viable Product in mind, come up with relevant questions that circle around the points that were discussed above. Once ready with a survey, it can be run in a number of ways depending upon the budget.
Measuring Success After Building an MVP
There are several approaches to give a real prediction of the future success of a product. Here are the most common, effective, and proven ways to measure the success of an MVP:
1. Word of Mouth
Traffic is a useful metric to predict success. Another way to track success is by interviewing potential customers. Begin by listing the problems a customer is facing or is likely to face, and then ask what they think.
2. Engagement
Engagement enables a startup to measure not only the current value of the product but also the future value. Engagement helps to improve the user experience based on feedback.
3. Sign-Up
Sign-ups are a feasible way to gauge user interest. They may also convert to revenue, based on the results of measuring interest in the product.
4. Better Client Appraisals Based on the Feedback
The number of downloads and launch rates show the interest of users in the app. The lighter the app is, the more downloads it will get.
5. Percentage of active users
Download and launch rates are not the only factors that measure the success of an MVP. It is important to study users’ behavior and regularly check the ratings of active users.
6. Client Acquisition Cost (CAC)
It is imperative to know how much it costs to acquire a paying customer. This helps a startup stay updated on whether their marketing efforts are effective, or if they require changes.
CAC = Money spent on traction channel / Number of customers acquired through the channel.
7. Number of Paying Users
Know the average revenue per user (ARPU), and keep track of products that bring revenue.
ARPU = Total income for the day and age/Number of active users
8. Client Lifetime Value (CLV)
CLV demonstrates how much time a user spends on the app before uninstalling or discontinuing their use of the app.
CLV = (Profit from a user *App usage duration) – Acquisition cost
9. Churn Rate
Churn shows the level or percentage of people who have uninstalled or stopped using the app.
Churn = Number of churn per week or month / Number of users at the beginning of the week or month
Minimum Viable Product Examples
Here are a few notable companies that launched MVPs successfully. These examples go on to show what startups focus on when it comes to developing a key MVP feature set.
1. Facebook
When Facebook was launched, an MVP was done just to connect students of schools and colleges all together via messaging. The idea was just to connect friends through a social platform, and organize gatherings. Facebook, in its early days, was built on the basic model of an MVP containing the needed functionality to fulfill its goal.
This application was launched to test among users, and it gathered lots of feedback. This resulted in making the application extremely popular over the internet. Currently, Facebook has over 1.3 billion active users.
2. Twitter
The widely popular social media platform, Twitter, involves a unique approach. After Apple released iTunes, Odeo, a podcasting platform, experienced tough times. They organized hackathons to figure out what to do next. During one of their hackathons, they came up with an idea to create an SMS-based platform.
It was initially known as “twttr”, and was a product for internal use only. However, employees were spending several dollars on SMS to post to the platform, in order to test it among users. Finally, Twitter was released to the public in 2006 and a year later it was a hit. Twitter increased its user base and became the second most popular social networking site after Facebook.
3. Amazon
Amazon started to sell books online by challenging the Barnes and Nobles’, of the world who were largely stuck in the ‘bricks and mortar’ age. Originally designed in 1994 to focus on books at a low price, their easy web design based on the minimum viable product was all they needed to develop and establish their organization in the retail market.
4. Groupon
Using the old concept of vouchers and discounts combined with the idea of sharing and socializing, Groupon has attained new heights. Initially, Groupon came to existence using WordPress, where regular PDFs were emailed to users that were already subscribed. In this case, testing with the help of an MVP proved successful. Afterward, Groupon built its voucher system and backend, further driving it to a great achievement.
5. Dropbox
Before launching Dropbox, the co-founder and CEO Drew Houston, was aware that there were tons of existing cloud-storage startups. Therefore, he decided to create an effective MVP based on the video, explaining how to use the application. The video played a crucial role in reaching out to the right audience, as it received a large number of views and comments. Dropbox even received 70k email addresses from potential users in a single day, which gave the company a green light to launch the product.
The above-mentioned MVP examples can inspire start-ups and entrepreneurs to start with MVPs, in order to make their journey a massive success.
4 Tips to Move from Minimum Viable Product to Full-Scale Product
You know that old saw about a plane flying from California to Hawaii being off course 99% of the time — but constantly correcting? The same is true of successful startups — except they may start out heading toward Alaska. – Evan Williams
It is the same story that repeats time and again. Initially, a team comes up with an idea to launch a startup. Next, they invest some time and money in the MVP development process, arguing which features to include in and which to leave out while building an MVP. Finally, the MVP gets launched in the market and, if everything moves as per the plan, the startup comes up with a stable and mature product.
So what’s wrong with this fairy-tale success story? In reality, over 90% of them fail.
So, why do many startups still fail?
Because they don’t understand that MVP is not just a product that is worked upon for 2-3 months and then launched. A considerable amount of effort goes into the process even after the launch of an MVP. Once done with launching an MVP, the list of the to-do tasks is long.
1. Collect Feedback
Up until the MVP launch, the MVP was based upon features the startup thought was important when considering the needs of the users. However, as soon as MVP lands on the market, they received better advice to follow: the direction shown by the actual, potential customers using the MVP.
The job is to collect the ‘real data’ after launching an MVP to the market in order to discover why potential customers bought the product or why they didn’t.
By tracking the metrics or user behaviors critical to engine growth, a startup can measure and learn from user interactions. This helps to decide which features to improve, add, or delete.
2. Prepare to Scale
In the world of startups, there seems to be a belief that building an MVP, means an important aspect of technical scalability can be avoided. All startups worry about testing their assumptions, validating the same in the market, and gaining huge traction. The factor of scalability comes as a concern at a later stage.
Unfortunately, this blind belief has led to some brutal startup failures. A home-service startup, ‘TaskBob’, which had raised around $5.7 million in funding in 2014, had to shut down in the year 2017 because they were unable to scale up and generate profits.
However, it is good to always be prepared and optimistic. There’s a chance of your MVP catching on quickly and the signups rolling in.
For instance, Dropbox decided not to launch any product at all as an MVP. Rather, they came up with a simple explainer video about what the product does.
The video actually worked and helped them increase the beta signup from 5000 to 75000 overnight. The real question is whether they were ready to entertain such a huge number of users.
Rajiv Eranki, head of server engineering at Dropbox, explained in a RAMP Conference presentation that the Dropbox team made use of Python for virtually everything.
This means that the whole platform “could get to 40 million users without having to write thousands of lines of C code.”
3. Get the Pricing Right
During MVP development or even after the launch of an MVP, startups mostly choose to defer the ‘pricing quotient’ because they think that their product is not ready yet. They often argue with the definition of an MVP wondering how a company can possibly charge for a product that is ‘minimal.’
However, even if the product is still in the MVP stage, if the top pain points of the customers have been addressed and the startup follows a customer development process, they are set to go on a journey of success. A minimum viable product is not the synonym of a half-baked or a buggy product.
Buffer, for example, identified this winning strategy. First, they analyzed the demand for their product with a basic MVP (a landing page) amongst the potential customers.
Once their landing page started gaining traffic, they instantly added one more page that carried the pricing plans to their signup process. As a result, they analyzed the demand for the product and found an optimal monetization approach.
4. Don’t Shy Away from Marketing
As discussed, MVP is not a final product, but a package in an early stage of product development. However, once the MVP gets launched in the market, the startup should be ready with their marketing strategy to let the world know that their product is finally live.
It is better to start with the promotion of the product as soon as the MVP is launched. However, there is a difference between marketing an MVP and marketing a final product.
Mint, a personal finance app, is a good example of how to utilize a perfect marketing medium from the MVP launch stage in order to witness the light of success in the future.
The marketing plan of Aaron Patzer, the founder of the Mint app, was “Whatever we can do, basically, for cheap or for free.” And the channel they chose to market their product was Content Marketing. They began with a personal finance blog to build an audience for Mint.
Eventually, the app hit a milestone of 1,000,000 users in just a span of two years since its launch.
By simply placing an email subscription form at the end of each article, the startup accrued about 20,000-30,000 emails from potential customers in just around 9 months, while their app was still in the development phase.
Conclusion
By now, embarking on a first MVP Development journey should not be as intimidating. Remember, it does not have to be perfect! Follow the described steps and strategies to build an MVP for the product.
Note, MVP is an approach that empowers startups to discover a lot about their users with the help of a working product, without overspending valuable time and funds. All that is required is to plan a business hypothesis, identify the main MVP features, know the target audience, and partner with the right MVP Development company.
0 Comments