When you think about a Minimum Viable Product (MVP), you should visualize something very simple. Something you can give to the very first set of users you want to target to verify if the product will deliver any value.

Before you even start building a minimum viable product, it’s important to do some research and, most importantly, talk to your potential users – it sounds so simple, right? 

Testing your product with users and running research doesn’t mean you have to go into a three year kind of research situation or have 10 years of experience in the industry. But a little conversation won’t do any harm. Better still – it will even more helpful if you are the target user too. That way you can already tell whether your product is working for you. 

I often get this question “how do I get my first users?”. It always kind of confuses me because theoretically you decide to solve a problem that you know someone already has.

The way you get your first user for your MVP is to talk to a person who has a certain problem to fix, and you know how to solve their problem. If that person with the problem is you, it’s even better.

How to set up a minimum viable product (MVP) pre-launch?

Step 1: Launch quickly

Most entrepreneurs spend too much time on planning and thinking rather delivering simple products in the shortest time possible to actually check if the users really need it.

Step 2: Get your first users

Focus on getting your first users that will try out the product, Don’t try to execute a huge plan that will somehow bring millions of them. That way you’ll see if the product already brings value so that you can further iterate on it. Very few founders understand this rule, that’s why so many startups fail way before a single user even tried the product. It’s very common so please get past this step it’s extremely important. 

Step 3: Talk to your users 

Once you have launched the MVP, go get some feedback! Let me tell you how founders imagine feedback in the early MVP stage. Once they have an idea of what they want to build as their final product, their gut is telling them that if their MVP will be of low-quality with few features, collecting feedback on it is worthless. Right? Wrong! Collecting feedback on your MVP is crucial. Remember that building the final product takes 3 years, a team, and millions of dollars… so feedback on the little thing should be very important.

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 flexible. Why? Because it might turn out that the full thing that you want to build isn’t what your customers want at all. So hold the problem you’re solving tightly, hold the customer tightly, hold the solution you’re building loosely.

Step 4: Never stop iterating

It’s very important to distinguish between iterating and pivoting. A lot of founders after building an MVP fall in love with it and if it doesn’t work for a certain set of users they start thinking: “I wonder what other problems this thing can solve.” Well you know the screwdriver is not actually good at screwing in anything, but I wonder what other problems are there that could be solved. As a result, they’re like: “Oh, maybe you can use it to cook, maybe you can use it to clean.” Well no, the problem was I need to screw something in. Your user is like a mechanic and if your screwdriver doesn’t help the mechanic solve the problem you should still stick to the mechanic and the problem, because the user still needs to screw something in. You just need to fix the screwdriver first because that’s the thing that is broken, it’s not a mechanic or that they need to screw something in. So iterate and continue improving on your solution until it actually solves a problem.

Minimum Viable product done right

How To Build Lean Minimum Viable Product?

Build it fast 

Most entrepreneurs should build a very lean MVP and be able to build it fast in weeks, not months. This can either involve software or a landing page and a spreadsheet. 

Limit the features

You need to condense down what your initial user needs to a very simple set of things. It means that you shouldn’t address all problems for all users. Just focus on a small group of users and their biggest problems and ignore the rest. Build a vision for everyone later. The bottom line is, get a small MVP that solves the initial problem and iterate on it. It is just a starting point, it doesn’t have to be special in any way, you just have to start, so please make sure you don’t feel like your MVP is too special.

To back it up with an example. Look at Airbnb’s first landing pages in 2008. There were no online payment methods. To pay for your stay, you had to pay the apartment owner in person. It was an inconvenience but they started without payments and no map view. Everyone tells these kinds of magical stories about how everything was perfect from the beginning; Airbnb was not perfect from the beginning.

Second example, Stripe, which wasn’t stripe it was called /Dev/Payments because why not, let’s make a name that is really easy to remember. Stripe on day one:

  • No bank 
  • Almost no features 

If you wanted to use Stripe, the Stripe founders would come to your office and integrate it for you. How nice is that! They were just desperate to get anyone to use it and that was their way of finding bugs before users would.

These are the cases in which you’d build a “heavy MVP”:

  • The industry poses some significant regulations – It becomes a thing if you’re in an industry with significant regulation like insurance or banking. It’s harder to launch if you have to pass through a dozen of regulatory bodies. 
  • Hardtech – if you are building a rocket, it is hard to build a rocket in a couple of weeks. Biotech – it is hard to invent a cancer drug in a couple weeks, if you’re in that situation please remember that your MVP can start with a simple website that explains what you do. It’s helpful when you talk to people and interact with them so that they can refer back to something. That can be your start and you can build a simple website in days, not weeks. 

Launch your MVP

A lot of founders have this misconception about launching their minimum viable product. They see big companies launch stuff and they assume that’s what startups do. In fact, they see companies they kind of think about startups, Facebook is not really startup anymore, but they see them getting a lot of press and getting a lot of buzz. They think that that’s what a successful company looks like when they launch. But do you remember the day that Google launched? No. How about Facebook? No. 

Twitter? No. 

So if you have this magical idea of your magical launch, throw it away – it’s not that special.

The number one thing that’s really important is to get some customers and to make people feel better.

Try to look at it in a different way. How about calling it a success if you get any customers?  You should push the press launch off and push to get any customers really soon – that’s your 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 product you want to build can solve their problem. If you put the product in front of your users and it doesn’t solve their problem you’ll know it right away. All the research in the world is good but until you put something in front of people, you won’t know if it works.  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.

Hacks for building a MVP quickly

Here are some do’s and don’ts for building a minimum viable product quickly and efficiently:

Timebox your spec

The spec is a list of stuff you need to build before you launch. For instance, if you want to launch in three weeks, the spec should clearly state what needs to be delivered within these three weeks. This makes life so much easier, allowing you to skip the features you can’t build in those three weeks. 

Write your spec

This seems really straightforward but most people fail at this one. Why? Without having stuff written down, it’s easy to change what you’re working on before the launch. You start working on something, you talk to a user and 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 you decide to change what you are working on. And you never wrote it down, so you don’t even remember what you should work in the first place. You don’t know what you’re changing and instead of a 3-week plan, you end up with a 3 month plan. If you write it down at least you can be honest with yourself that you’re changing your spec all the time. 

Cut your spec

A week into your 3-week sprint, you probably realize that you added too many things to your spec and you’re not going to meet your deadline. What you do now is throw our or simply skip the tasks that aren’t the priority. The goal is to get anything out in the world. Because if you don’t have anything out there yet, chances are you’re going to delay, delay and delay.

Don’t fall in love with your MVP

Way too many people fall in love with the vision in their head. Please don’t fall in love with your MVP. Why? Because it’s just the first step in a journey, you wouldn’t fall in love with a paper you wrote in the first grade, which is the level of impact often your MVP has. 

Wrap up

Your customers are the key to your business and you should never stop listening to them. However, don’t lose focus of your roadmap. Of course, this doesn’t mean that once you launch your minimum viable product, the communication will end.

All in all, if you want to grow your product, the best way is to ensure the customer centricity culture among your team. Make everyone on the team listen to what customers complain the most about, what they find hard in the flow, etc.