Read the original version of this article about MVP on SoftFormance https://www.softformance.com/blog/mvp/

Rome wasn’t built in a day. The same works for software products and starting any kind of business, including MVP. The formula of success is to lay bricks step by step.

You may think that such businesses and apps like Airbnb, Facebook, Uber, Amazon, or Spotify were born to be successful and just rushed into this world already popular and swam in money. But only some remember how these apps looked when launched.

Indeed, it is hard to imagine that those software giants started from an MVP with a plain design and limited functionality. And it can be even harder to understand that they gradually grew their business.

Unfortunately, according to Forbes, 90% of startups fail.

And an obvious way to improve your odds is to start with a minimalistic version of your idea before you know it’ll work.

So you start with the MVP:

#MVP: What is an MVP?

A minimum viable product (MVP) is a product with a limited number of features that solves at least one issue of your targeted customer. It helps you to validate a product idea in the early stage and receive feedback from early adopters.

Frank Robinson first established the MVP concept in 2001. However, it became popular only in 2011, thanks to the Lean Startup Methodology introduced by Eric Ries.

According to Ries, MVP was called to drive, develop, and grow a business with extreme acceleration.

He says that the primary purpose of an MVP is to be “a version of a new product that allows a team to collect the maximum amount of validated learning about customers with the least effort.”

Interpreting it in a more business-beneficial language, your company can opt for MVP development because you are eager to:

• release your product quickly
• test your business idea before wasting a large budget on the full version that may fail
• discover what appeals more to your target market and what is best for their needs
• iterate it and improve your final idea

Having defined the MVP term in general, there is a need to understand what MVP stands for: what “minimum” and “viable” parts mean.

So, let’s take a closer look at the “minimum” and “viable” parts:

The combination of “minimum” and “viable” in MVP

Minimum means that we include only essential, most critical functions. It does not mean that we create a terrible or poor product — minimum calls for solving only one issue out of a maximum range.

Viable means that your product still delivers enough value to your early users. The product stays interesting, fast, and useful for a targeted customer.

Minimum and viable mean that your product is without extras but with core functionality. You can think of it like pizza and cheese in your software: all necessary ingredients are included.

But in the final version, you can add tomatoes and chicken.

It turns out that a balance between a minimum and viable is crucial for your success.

You usually cannot build something huge before making a tiny version of it.

You have to build it gradually.

The car on one wheel will not go, and it will not be a full-fledged vehicle.

Thus, we recommend you start small and improve future versions of the product.

Firstly, we learn how to build a skateboard.

As soon as we see that the user is interested, we improve the product, turn it into a scooter, then into a bicycle, and finally, we deliver a car.

[todo: custom image with the above idea]

But, you now may say, “yeah, that’s great, but how can I apply this approach to my specific case?”

And the best way to answer this question is through a few great examples:

#Famous MVP stories

There are four main reasons to start lean:

1. Save money and reduce rework

The founder of Zappos, Nick Swinmurn, did not have enough money to develop software.

Moreover, he did not even know whether people would buy shoes online. So, he decided not to invest a great fortune at first.

Instead, Nick started a simple website with one key feature.

He uploaded photos of shoes he took in local shoe stores. And once someone clicked the “buy” button, Nick went to the shop, bought shoes, shipped them, and handled payments.

He did most things manually at the beginning. It all started as a several-hundred-dollar business.

Now, Zappos has more than $1 billion of revenue.

In shape Zappos is now, it’d take millions of dollars to build.

But Nick did a smart thing. He started small, invested little money, and reduced the total amount of work for the first version.

Most startups change their directions multiple times before they find product-market fit.

It takes less effort and money to make all these pivots with a smaller product and feature set.

So with lean MVP, you save not only once when you launch it but also whenever you redesign your product.

2. Release fast and save time

Imagine that you’ve decided to develop a web app with a maximum range of features. You put in tons of effort, spent a lot of money, and MVP development took two long years.

Eventually, you launched, and nothing happened.

All your efforts in building any kind of traction fail. People are not interested in using your product. There is no real need on the market, and it’s far from revenue and profit.

It’s the worst nightmare for any founder.

If your startup is going to fail, it’s better to do so within three months instead of three years. No?

MVP is called to minimize the time for software product launch.

Apart from that, a sooner release is a prerequisite for success.

The Linkedin co-founder Reid Hoffman once said: “If you’re not embarrassed by the first version of your product, you’ve launched too late.”

LinkedIn MVP was launched just after six months of development.

The fast release of LinkedIn helped it to differentiate itself and gather early adopters’ feedback quicker than its competitors.

Another great example is Etsy, a marketplace for craftspeople.

Founders launched the first Etsy version just after 2.5 months of development. Now, they are estimated at 2 billion dollars annual revenue.

One more time, fast release led to success.

1. Test business idea and learn about your customers sooner

One more great example here:

Back in 2006, Spotify’s goal was to gain traction for their music streaming service.

At that time, pirate services like LimeWire and The Pirate Bay were the primary reasons people were not paying for the tracks.

So, Spotify founders Martin Lorentzon and Daniel Ek were thinking hard about making people pay for the music online.

But they haven’t spent months in analysis paralysis.

Instead, they launched a very minimalistic MVP version in a short time and started getting honest feedback from real users.

Fortunately for them, the idea exploded, and these guys proved that people were ready to pay for an ad-free experience.

The lesson of this story is that MVP lets you quickly test your software idea and learn from real users faster than implementing a full-featured product.

4. Attract investment

According to CBInsights, 42% of startups fail because they don’t appropriately respond to market demands, while 29% of startup ideas fail as soon as they run out of their own money.

So to improve your odds, you need to attract money earlier.

These days investors don’t put money into ideas. They put them into traction, working prototypes, and revenue-generating MVPs.

So the best way to fund your startup is to quickly launch the MVP, test the market and show them the functional product with an early adopters base.

This is how Airbnb, Amazon, and many other famous tech businesses were started.

Now you can see how MVP will leverage your software startup process.

Still, the MVP concept has its nuances

Over time, the MVP term got mixed up in the startup community.

Some startuppers say that MVP is the smallest piece to be delivered.

E.g., they confuse a blog post, landing page, email newsletter, ad campaign, or marketing survey with an actual MVP.

These are just tools to collect preliminary user feedback or small marketing experiments. And there is no product behind it.

Without a doubt, marketing is vital for an MVP, especially during the product strategy part. But a marketing experiment cannot be an MVP itself.

Finally, it’s almost impossible to assess the extent of the product’s viability.

As follows, viability does not distinguish between what is viable and what’s not. It is a vague term that describes an abstract concept.

That’s one reason why we don’t like the word “viable” in the MVP term in our agency.

Some other teams use “lovable” instead of “viable.” But can you define any of these words?

The use of “lovable” does not change the vague sense. Still, it means nothing but an abstraction.

That is why we have our concept for this. It allows us to approach a volume of tasks for the first version more specifically.

We call it MSP.

#MSP Welcome to the Minimum Sellable Product (MSP)

Before the 1990s, people were using the waterfall methodology for building software. It was about planning every little detail of the product upfront and showing results only at the end of the project.

After Waterfall, we switched to the Agile methodology.

Agile is about short quick iterations and showing small results fast.

As follows, Agile is a set of high-level guidelines which we can treat in different ways. And in practice, there is a multitude of implementations of Agile methodology.

The most popular among them are Kanban and Scrum.

These practices provide Agile methodology with a set of direct instructions and artifacts. E.g., two weeks sprints, backlog grooming, retrospectives, multiple meeting types, etc.

Similarly, the MSP term we invented in our agency takes the MVP approach and makes it more concrete.

MSP comes in hot when there is a need to add a practical value to the abstract MVP term.

So, if you want to have a detailed step-by-step process to implementing an initial version of your software and increase your odds for success, we’d highly suggest following our MSP process.

Now, you may assume that MSP is only a fit when you are planning to sell software. No, that’s not true.

You can use the MSP process also when you build software for your company usage. It might be some automation tool, CRM, ERP, or customer support-related app.

In this case, you still need to sell it to your employees and convince them it’ll be a time saver or pain killer.

So let’s dive a bit deeper into how the MSP process works.

How to MSP?

MSP is a process that deepens the MVP concept and adds practical steps to the abstract word “viable.”

If you are indeed wondering how to build an MSP that will differentiate, here are three components that we use with our clients:

I. Define specific goals for your initial launch

At the beginning of our agency life, we did numerous projects for founders who did not even know why they started their software products. And a lot of their startups failed in the end.

As follows, the business must have a direction to succeed.

Goals help founders to make all other decisions and take marketing steps.

But how to set goals?

It’s pretty easy.

We recommend our clients start with personal goals.

It’ll define what kind of tech business they should start with.

Let’s say you want to have a healthy work-life balance, spend a lot of time with your family and financially support your loved ones.

30-50k monthly income and a lot of spare time will do the work for you.

Then you should probably bootstrap a relatively small software idea that you can quickly build and sell in a small market.

You’re looking for the market where you’ll be a big fish from the very beginning — for example, PM software for plumbers. And maybe you will start with your city at first.

Now, let’s imagine your goals are entirely different.

You have ambitions to influence the whole world and millions of people with your business. You want to become a multi-millionaire, own expensive sports cars, and yachts.

Then your idea needs to have the potential for worldwide expansion.

Yes, you still need to start small, but at some point, you’ll need VC money. And for the first five years, you’ll be working on your business 24/7. No work-life balance. Period.

You’ll never start a small tech product with low potential if you have massive personal and business goals.

Thus you need to align your software product goals with your personal goals. And then all the subsequent decisions will be much easier.

After you set your goals, you’re ready to restrict yourself:

II. Start with restrictions

Everything in this world exists and thrives because of restrictions.

Only constraints allow a person and a business to flourish and discover new solutions.

Limitations define what can be done and what is not feasible.

That is why we suggest our clients define a strict budget and timeline for the initial software version even if they feel no supply shortage on any of these resources.

The most frequent guidelines we recommend for first-time tech startuppers:

• ideally, not to cross the $50-70k budget (max 100k)
• release MSP not later than 3 to 6 months after starting the development

Invest more than that, and you’re at risk of implementing excessive features, building them not in the most efficient way, or losing an opportunity on the market due to delayed launch.

Budget and time constraints allow shaping the development team most productively.

As the old adage says: “Work expands to fill the time allotted.”

Quick example: if we have a three-month project, we allocate not more than 1-2 developers.

Three developers on a short-term project require 30% extra investment but will not output 30% additional results. Bigger teams require more communication, project management, and bug fixing time.

Also, having a 3-to-6-month deadline will guarantee you’ll not pick too complex or too big software idea.

When we launched our first own product Socialinsight.io, we developed it within two months. But the second one, Opesta.com, we were building for almost 12 months. We deserved it.

Thus, we suggest picking a bigger software idea only if you are doing this for the second time and know what kind of business you are in.

In other cases, there is a significant risk of not finishing the MSP version or being too late to the market.

III. Our 6-step MSP Process

After you have defined your goals and set specific limitations for your MSP version, you need to follow our 6-step process.

You can review this process with an in-depth description here.

But to cut a long story short, here is a quick overview of this step-by-step process for initial software launch:

1. Setting Foundations

According to New York Times, Olympic athletes use imagery as a form of mental training. The same works for setting foundations in a tech startup.

We launched our product Opesta.com by setting foundations in 2019. Before the initial launch, we considered few ideas and chose the one that targeted the audience we had experience with.

Also, our co-founder Ethan had previous experience with Facebook ads and marketing, so it would be easier for us to sell the product. This process we applied to our product we call idea generation.

After we picked the idea, we started to spread the word among our friends-marketers. Simultaneously, we worked on competitor research and defined the significant competitors who, at that time, were ManyChat and MobileMonkey.

Plus, we interviewed Ethan’s existing clients and asked whether they would need to automate their FB messenger marketing activities.

After a range of interviews, we understood that we needed to define a narrow niche not to compete with ManyChat. So we shifted to FB messenger API marketing platform for eCommerce after the idea validation stage.

Further, we wanted to make sure that this idea is technically feasible. And thus, we asked one of our senior programmers to check whether Shopify and Facebook APIs allow us to develop the needed functions.

The latter mentioned process is called technical filtration. It guarantees that we’re starting a doable project. Also, it gives a high-level prognosis on the turnaround.

After technical filtration, we understood that this project would take more than six months. We usually recommend building MSP within 3-6 months. But this was not our first startup venture, so we were ready for a bigger idea.

Technical filtration also gave us a specific budget number. We decided to fund this MSP with our own money coming from other client projects. Yes, we wanted to bootstrap it.

Finally, we wanted to see if the whole idea makes sense from the business side. We spent a couple of minutes putting together a quick business plan. We always use the LeanCanvas approach for software products.

We also brainstormed and projected how many paying users we should have and the subscription price to profit.

After just a week of work, we set good foundations for our new software venture and were ready to build a detailed product strategy.

1. Product Strategy

The average software product loses 50% of its new users after the first use and more than 80% of its users in the next 30 days.

Product strategy is the way to mitigate those losses. It consists of 5 key elements:

1. User Acquisition
2. User Activation (or Onboarding)
3. User Retention
4. Referral System
5. Revenue

While 3 of them are pretty hard to guess at the beginning of your software journey, you still need to put together a detailed plan for User Activation and User Retention.

These are the main things that will help you solve the problem with losses during new user signups.

For one of our software products, SocialInsight.io, we learned it the hard way.

We spent a couple of thousands on FB ads during two weeks after launch. We got a lot of new user signups, but surprisingly almost zero active users.

Most of them stopped in the middle of the registration process without ever connecting their Instagram account.

So we had to review the registration process.

We realized that the user interface we built wasn’t intuitive, and new users didn’t know how to connect their Instagram account.

We fixed that issue in 30 minutes by simplifying the one-page UI, and things dramatically changed the same day we pushed that hotfix to production.

Also, we provided users with a 14-day trial period. In user onboarding, time limits are set to attract customers and increase their first interest.

And you know what?

More than 20% of our users who signed up for a trial upgraded their accounts to be customers.

The lesson learned: you need to take your user onboarding seriously even before you start the development. It might dramatically influence your scope of features as well as the success of the first few weeks after launch.

But, product strategy is not the end of your software journey.

After it, you need to put together a detailed technical plan for your product.

We call it Project Roadmap.

1. Project Roadmap

You’ll be surprised, but on average, 70% of our clients’ projects we don’t build from scratch.

We often work with clients who have come to us from other devs with delayed deadlines, broken functions, and overflowing budgets.

However, those developers were not that bad, and their management process was also okay.

But what makes a difference?

It is something that other software teams did not do at the very beginning of a project.

It’s a proper project roadmap.

The road-mapping stage includes technical oversight, MSP scope definition, project specifications, the decision on tech stack, architecture design, exact budget, and time.

These days we never start any project without a proper Project Roadmap.

You can compare the project roadmap process to bungee jumping guidelines. Would you jump off the bridge without the instruction?

1. MSP Build

To successfully build an MSP version of your idea, you need two things: a good team and a proper process.

Your main task is to find and hire an appropriate development team and let them do their work.

A good team will always have its proper process. And here, you can read how to hire a team and not to fail.

But in short, a perfect fit is a team that meets three criteria:

• has similar projects in the portfolio
• takes your business side into consideration
• is not willing to perform free work
• wants to start small

We always offer our clients to start with a small paid engagement to test each other in a real-life collaboration.

Under a small paid engagement, we have a startup workshop where we undergo all the steps described above.

We don’t profit from it. Our workshop goal is to prepare our new clients for the development stage and mitigate the risk on both sides. And you know, no one of our clients regretted time spent on our workshops.

While your good development team is building your initial product version, you need to prepare for the launch.

1. MSP Launch

How many startups are pushed to the public server and then disappear?

There are more than 80% of those.

So, the MSP launch is not about pushing your software to the production server. It’s about letting people know about your software and asking them to signup.

This stage begins right after the project roadmap and goes in parallel with the MSP Build stage.

During the Opesta.com project, we started working to validate our idea, spread the word about it, and build an audience for pre-selling at the very beginning. And we never stopped these activities afterward.

And frankly speaking, the MSP launch is more about marketing than about tech things, even though it includes them both.

As follows, here is a quick check-list for the MSP launch:

1. Tech Part. Prepare and launch a production server. Take care of backups, domains, external APIs, payment gateways, etc.
2. Marketing Part. Build a pre-launch email list, feed potential users with educational content. Teach them about your upcoming product.

The goal of an MSP launch is to get your first 10-20 users. Free or paying.

Only after this can we say that you did the launch and ready to move on to the next stage.

1. Software Logistics

At this point, you can think that you did a lot of work.

But, frankly speaking, you’re only at the beginning of your software journey.

If you’re lucky enough, you might be among those few that start growing and hit their Product-Market fit from day one.

But most new software products spend months, and sometimes years, finding their winning position while doing multiple pivots.

With our Opesta product, we did multiple pivots and eventually focused on Shopify-only eСommerce. It took us more than a year of hard work and experiments.

At some point, you’ll reach the place where you have enough revenue not to worry about development costs. But before that moment, you’ll be primarily focused on these things:

1. Support and Maintenance. It includes monthly customer support, bug fixes, and new feature development.
2. Growth. Here, you try your best to find a product-market fit, grow the user base, and reduce the retention rate.

Wrapping Up

If you start your new software product with the above steps in mind, you’ll turn the wild tech world into a predictable money-generating machine.

The MSP process is a way to avoid any kind of abstractness and make your product sellable.

Following the 6-step process of building MSP, you will ensure that your users will like your product, and you will enjoy the revenue you get from it.

At SoftFormance, we used the MSP process to build hundreds of apps for our clients and even own products.

And now, we are ready to help you launch your new tech idea with our 2-day software startup workshop done for you.

Also, if you want to learn more about starting your software product, we invite you to join thousands of our readers by subscribing to our newsletter.