How to Build a MVP to Start a Startup

Building an MVP is hard. When there is no structure or guideline, it becomes a really long and empty road. I think MVPs are designed for building quickly and iterating fast. But its essence or meaning gets lost with different types of MVPs.

Building an MVP is hard when you are a beginner. It takes a lot of time to understand and get a grip on the structure or process of an MVP. But it teaches you a lot of things with time, it teaches that the next time will be a bit easier, a little more organized and with a better structure, but most of the time context changes things and all of a sudden it starts to feel like it is a different thing from the first MVP. It's because they are designed in a way that makes them different every time.

But what exactly is an MVP.

What is an MVP?

MVP is an abbreviation for “minimum viable product.” It is a product that is created and released with minimal functionality rather than as a full-fledged solution.

At the core of the MVP development approach lies the idea of creating a product with just enough features to be functional. Later, when customers try the product, the owner collects user feedback to make further integrations based on user needs.

Therefore, MVP development allows entrepreneurs to assess the viability of their product based on customer experience. In the end, there are two possible paths: scale up with clients’ needs in mind or shut the project down at an early stage if the product doesn’t appeal to its target audience.

Why Start From an MVP?

Why would you launch a product with limited functionality when you can offer your users a bundle of features from the very beginning? Well, there are many reasons why startups and established brands may be in favour of starting with an MVP, including:

Idea Validation

Starting with only functional features allows you to determine whether the solution deserves a chance to exist. In other words, you can never know for sure if your product is going to deliver value to the market before testing the idea.

Lower Costs

Each added feature means extra resources. It’s always better to start with essentials and enrich the product with the necessary functionality later to cut the initial development costs and reach the ROI earlier.

Faster Launch

Full-fledge applications require a lot of time to develop. Therefore, users will have to wait for the product’s launch. With an MVP, you can access the market earlier, outperform your competitors, and gain a share before them.

Data-Based Scalability

You can’t know for sure what features users want and need. Often, the users themselves don’t always realize what they want until they try out the product. An MVP allows users to get acquainted with the product early and provide you with prudent feedback. Based on this feedback, you can make a more informed decision on further scalability.

Early Marketing

It’s never too early to start marketing. With marketing, the sooner, the better. An early marketing approach allows brands to engage with customers and develop users who look forward to the final product.

In addition to these five reasons why many opt to use an MVP product development model, there is an extra advantage for startups seeking third-party investments. For instance, imagine you are an investor who is ready to make a hefty donation to a promising developing project. Which option would you invest in a theoretical idea or a viable, tangible product? The latter, of course.

This is the same thing I did with Brytebook. I wanted to share the idea in a minimal viable product, so we created a product with just enough features to be functional. Later, I opened up an Instagram account and followed some of the bloggers (target audience) for them to try the product, then collected user feedback from Instagram's direct messaging feature to make further integrations based on user needs.

This approach of work worked in the context of bloggers. However, no approach is perfect, and that doesn’t exclude MVPs. Limited functionality raises the risk of losing some customers who aren't satisfied with the offered functionality. To eliminate this threat, you need to think through the features you plan to include in your MVP so that your product solves a problem and its features contribute to usability.

How to Plan a MVP

"MVP is the first thing you can give to the very first set of users to see if you can deliver any value to them." — Michael Seibel

MVPs are centered on solving a problem for an initial small subset of people (these people should also be your first users). MVPs are simply a starting point for how you plan to solve the problem.

Planning an MVP should be the most important priority because without a plan there will be no structure. MVP is the first thing you can give to the very first set of users to see if you can deliver any value to them. It's important to understand the problem before building an MVP. Understanding the problem comes from talking to a few potential users or it's best when you are a user.

For getting your first users, you should know immediately who they are because you are building the MVP for them!

Goals of a Pre-Launch Startup

Goals for the Pre-launch should be simple, achievable and time-bound. It is really easy to lose track of time when making an MVP. Every goal should have a deadline.

Launch quickly (MVP)

There are different ways to launch like, a Silent launch or a community launch and more on that in this post. Likely no one will care about your first launch. But, postponing your launch will likely lead to some serious future problems.

Get initial customers

Initial traction from the niched users is what makes an MVP stand out, most of the time it helps to determine if the MVP is a success or not. If the users are interested in the use of the MVP, it makes it easier to identify the market for it.

Talk to your users and get feedback

Users usually give feedback on what they want the final product to be, instead, ask questions in a way where they can define their problems, not the prospective solutions in the MVP. Finding solutions should be your job.

Iterate and improve the product

Proper execution by iterating and improving is really important for a successful MVP.

Hacks for Building an MVP Quickly

Time box your spec

e.g. Only three weeks... (makes you eliminate any feature plans for things you can't build in three weeks)

Write your spec

Create a One Page Template. It looks something like this.

Cut your spec

Eliminate everything that isn't important. Important things are easy to identify and help to create momentum. The main goal should be to launch. Often, when you are building something for some time it starts to become a part of you. The same happens with MVP, don't fall in love with your MVP. Very few major products are the original vision. Just look at some famous examples.

Dropbox

Drew Houston and his team created Dropbox, a cloud storage service that works seamlessly across devices. Dropbox was no doubt great, and it offered a better solution to file synchronization. But how could Dropbox stand out in a crowd of competitors who had already won the hearts of users? The Dropbox team knew that once users had tried their service, they wouldn’t give it up. But there was another problem: How could they demonstrate the working software? Drew had a brilliant idea. He released a three-minute video that demonstrated synchronization with Dropbox. It wasn’t a simple demo; it was full of in-jokes to appeal to early adopters. Drew says this “drove hundreds of thousands of people to the website. Our beta waiting list went from 5,000 people to 75,000 people overnight. It blew us away.”

Airbnb

Airbnb started as a simple site launched by three founders who came up with the assumption that people wouldn’t be able to find a place to stay during the Industrial Design Society of America Conference in San Francisco in 2007. So they piled up all their beds in their small apartment and put up a simple ad about renting an air bed on a simple web page. Soon, they had three guests who wanted to share their apartment. Once they had proven that their idea wasn’t a waste of time and money, they started looking for how to redesign the platform. Today, Airbnb has 150 million users, 4 million listings, and is valued at $30 billion. It offers not only accommodation but provides users with lists of restaurants and events in destination cities along with feedback and ratings.

Spotify

In the early 2000s, when media piracy sites like Napster and The Pirate Bay were all over the internet, it seemed impossible to survive with a new music streaming platform. But when Napster shut down, Daniel Ek 一 the co-founder of Spotify 一 saw a great opportunity to develop a new platform where users could get legal music instantly for a small fee. Daniel Ek and Martin Lorentzon built an MVP (an app) that did just one thing: streaming music. The first to try this application were family and friends. When Daniel and Martin saw their idea was a hit, they presented the application to a larger audience. Later on, when Spotify was accepted by users, they signed more artists and expanded to more countries. Today, Spotify is an on-demand service for music, podcasts, and video streaming that’s available in 79 countries and had 83 million paid subscribers as of June 2018.

Uber

It’s difficult to remember a time without Uber, which now has 42 million users. Back in 2010, when Uber was first introduced to iPhone users in San Francisco, the company had only just started on the path of turning into what it is today. In those days, Uber focused only on connecting users with cab drivers and making in-app payments. The application was known as UberCab and offered a simple user interface. Only when Travis Kalanick and Garrett Camp were certain that their idea would work for a bigger audience did they begin to work on a better product. Throughout the life cycle, Uber has expanded the functionality of the application to GPS, real-time tracking, ratings and reviews, ride-sharing, fare splitting, multiple destinations, scheduled rides, and calendar shortcuts.

These examples apply to companies with a certain context, it may not work for you but it helps to solve the problem of not having a structure and a roadmap for what has already been done. When taking feedback, never ask users for features, ask them about problems (they likely don't know how to solve the problem). If someone mentions features, bring it back to the problem. Ask questions like, How often do you have that problem? How strong of a problem is it?

The only feedback you need for your MVP is if it solves the problem

E.g. If it's a daily problem, does the user come back to use it every day