If you're reading this, you are probably familiar with the idea of the MVP. At the very least you have a general idea or you think you know what a Minimum Viable Product is.

Unfortunately, most ideas don't make it past this initial stage, and a lot of founders get stuck here.

When you come across an idea that excites you, make sure to evaluate it thoroughly. Most founders get so excited about their idea that they jump right into it and work on a solution to a problem that other people don't have. Instead, you want to test your idea as quickly as possible with as little effort as possible. Usually, this means creating a landing page, talking to potential customers, and working to really understand the problem you are solving. Only then, do you think about your MVP.

If there's one thing that you take away from this, it's that your MVP serves one purpose and one purpose alone. It should, as quickly as possible, validate whether your idea can work.

What is "Product-Market Fit"? How do I know when I need to pivot? So did my MVP succeed or fail? You're MVP answers all of these questions. When you find "Product-Market Fit", it will be obvious. You need to pivot if you aren't making progress. And lastly, since your MVP has the simple goal of validating whether your idea can work, it succeeds if it gives the information you need to either push forward or pivot. It fails if you spend too much time building it, and don't learn anything of significance.

Building Your MVP

I have good news. Believe it or not, your MVP should be minimal.

When you think about MVP you should think about something ridiculously simple that can deliver any value at all. 

You should not expect your MVP to become the final product. If it does, then you messed up and should've launched sooner.

With that said, you should launch as EARLY as possible. Today if you can. Perfectionism is your enemy here and you need to fight the urge to fix every little detail, at all costs.

"If you are not embarrassed by the first version of your product, you've launched too late."  - Reid Hoffman, Founder of LinkedIn

Cool. Again, why should you launch your MVP, today?

Pros

• You start getting feedback ASAP
• Learn if your idea solves the problem you're trying to solve
• Forced to figure out how to get traffic
• Forced to think about your target customer
• Learn early on if you need to pivot, rather than building an entire product that nobody needs

Cons

• Your product probably looks bad
• You have to work a little bit today, ugh

So launch as soon as possible. Your MVP should be as minimal as possible, the most minimal version that still provides value. Seriously, this should be super minimal.

Examples of Successful MVPs

To better understand what an MVP should look like. Let's look at a few examples.

AirBnB's Early Days

The massive online marketplace connecting renters and hosts started out with almost no features. There were no maps, ratings, payments, search, nothing. You added your property and exchanged cash in-person. Yet, somehow they became a multi-billion dollar company. 

Rather than spending time on some features that might seem important, they launched what they had and got feedback earlier. Feedback is the most valuable thing an early startup can get. More valuable than acquiring users and usually more valuable than money. Though money can be a valuable form of feedback as well.

Amazon's Early Days

The trillion-dollar company, originally calling itself "Earth's biggest bookstore" started as a simple online bookstore.  It's also clear that their MVP certainly did not become the final product.

Pretty much everything that went into this MVP was thrown out over time. But Bezos learned what he needed to which allowed him to add features people wanted, test different elements, and create the empire that Amazon is today.

Advice for Founders

If there is one mistake early founders tend to admit most, it's that they wished they talked to customers sooner. Those who don't usually end up building something people don't need, ultimately wasting months of precious time. The thing you might want to build might not be what your customers want at all.

So talk to users to understand their problem and to get an idea of a solution that would actually solve their problem. Build something as quickly as possible.

Talk to users again as soon as you launch your MVP and get feedback to iterate on your product so that it solves their problem even better. Don't wait until you perfect the design. 

Don't Overemphasize Your Launch

Your launch doesn't matter. Do you remember the day Google launched?

Twitter? Amazon? Apple? Microsoft? No, nobody does and nobody cares.

Nobody remembers the launch of any large company, and odds are you will pivot and change the product to make it better over time anyway.

A launch is just getting as many people to try your product so you can get feedback to make it better. And you should in fact launch multiple times. Spend the extra time that you would put into an amazing first launch, in building an amazing first MVP.

That being said, a well-executed launch has benefits. I made a list of places to launch your startup, and it can save you time better spent making a better product.

Actually Solve a Problem

I have a technical background and I love building things. So much so, that I use it as an excuse for starting new projects without validating the idea behind them. I try to build it and then find a problem it can solve after. 

This is such a bad idea, and it never works.

A great analogy I've heard, it's like saying you have a particular screwdriver and you wanted to go around looking for a screw it could be used on, rather than identifying a screw that needs to be screwed in and then finding that particular screwdriver.

Identify problems that need solutions, and those solutions will be clear. Don't start with a solution and then try to solve problems with it.

Your MVP is NOT SPECIAL

If you think your MVP is special you will find it harder to make necessary changes to build a better solution for the problem. 

The product itself and the quality of the MVP really does not matter, unless you're building rockets.

What is more important is that you understand the problem. Your energy should be spent learning as much as you can about it, so you can develop the best solution.

Don't spend your time perfecting the MVP. Instead, perfect your understanding of the problem it solves.

Steps to Launch Your MVP Quickly

1. Timebox Your MVP Decide when you want it finished, write that date down, set it in stone. This will prevent you from scope-creep and adding more features that you don't think of right now. You don't need them to validate your idea.
2. Write Down Your Features As you build your MVP you will probably identify things you want to change about it. Sometimes these changes are necessary, other times they are not. But writing down the initial features will allow you to measure how frequently you change your initial feature list.
3. Cut Features and Stick to Your Deadline The point of timeboxing your MVP in step one is so that you guarantee you can deliver something and start getting feedback as soon as possible. This feedback is more valuable than any additional feature, so if you find yourself short on time cut features and scope the MVP down rather than extending the deadline. Releasing later means you get feedback later, and potentially even more time was wasted building features that don't address the customer's problem.
4. Don't fall in love with the MVP Your MVP is an experiment. It's not the final product. If you become too attached to the MVP and refuse to make changes, you won't be able to improve your product to better solve your customer's problems.  Paul Graham of Y Combinator made a great analogy - think of your MVP as the shirt you know you're going to throw away. Paint with it and then throw it away. Don't use a nice shirt.

Get Valuable Feedback

The feedback you get on your MVP is the reason why you build it. So here are some tips for making the most of this feedback.

When building an MVP, don't ask users for features they want. Ask them for problems they have. If users say I need something that can do X, ask them why do you need X?

The customer doesn't know how to solve their problem themselves, otherwise, they would have. You need to understand the problem so that you can create a solution for them.

Final Thoughts

Build your MVP quickly. 

Ask yourself if it solves the problem you are trying to solve. If your user comes back the next day, it does.

Got a question? Follow me on Twitter and ask away!