The beauty of working in the SaaS industry lies in the fact that you don’t have to spend years locked away in a lab or an office trying to perfect a product before it can be released into the world.
Instead, you’re free to launch very early on, with a basic version of your product, and then develop and improve it according to the needs and wants of your customers.
That early version of your software is called a minimum viable product (or MVP), and this article will supply you with useful, actionable information on how to release it and use it to earn valuable insights that will help you perfect your product ahead of its full launch.
Let’s start with the basics—deciding which features should be included in your MVP.
Identifying the Key Features
Since your MVP should showcase just one or two of your key features, figuring out what those are is a crucial step toward building a perfect minimum viable product.
A good MVP presents users with the primary solution to their problems, though without the glaze and filling of the perfect design and peripheral functions. Those can be added in the later iterations of the product.
As simple as this may seem, stripping down your idea to a single feature takes a lot of work. However, being strict about which features will make the cut is essential. The point of making an MVP is conserving time and money while still offering a viable solution.
To ensure you’re on the right track with your MVP, your decision on what features matter most should be grounded in diligent research.
That means finding out everything you can about your customers by conducting interviews and participating in conversations in communities of social media, forums, and the like.
After you’ve talked to your customer base, you should have a firm grasp of what features mean most to them.
You can also explore what the market is offering right now by conducting competitor analysis. That can help you understand where the gaps in the market are for you to jump in and offer something unique.
To sum up, the value you offer with your MVP should reflect the needs of real users and the current situation in the marketplace.
After all of this research, you should have a comprehensive list of possible features on your hands. The next step is to trim it down.
A good way to do this is to sit down with your team and start eliminating everything that isn’t essential to your product. Keep doing this until you’re left with just one or two features.
These are your must-have, core features. They’re the basis of your product and should be included in your MVP.
Everything else, the should-haves, could-haves, and won’t-haves, should not be a part of your MVP.
However, that doesn’t mean those ideas for features should be discarded completely. As your product evolves after the MVP stage, you can widen the scope of your product and add more and more features to it with every iteration.
Selecting the Right Approach
There’s more than one approach to building an MVP, and yours will depend on the type of service you want to offer and the resources you currently have.
Remember, the purpose of your MVP is to deliver value, not perfect features. How you define and deliver value is entirely up to you. So, don’t be afraid to get creative.
Let’s have a look at the basic approaches to building an MVP to give you an idea of how flexible this process really is.
Did you know you could build an MVP without writing a single line of code?
With a no-code MVP, your aim is to demonstrate how your product will solve a shared pain point and deliver value without actually building the product. Think of it as more of a demo than an actual product.
If that’s a little too abstract, let’s look at a famous example.
In 2008, Drew Houston wanted to present his complex product for storing files online, Dropbox, to potential investors. He had not built the product yet, so what he decided to do was make a simple demo video that would showcase the core features of his software.
Here it is below.
His demo addressed a very common need to easily and safely store and share files online and showed how his solution could solve this need in just a couple of clicks.
The video was a major success, and it helped Houston secure a place at Y Combinator and find his co-founder, Aresh Ferdowsi, who saw the demo video and got in touch with Houston to see how he could contribute.
The story of Dropbox’s simple yet effective MVP only goes to show how far you can get without a single line of code.
Another brilliant approach to building an MVP is to build the front end of your product and make it appear functional but deliver value manually behind the scenes.
That’s what the founders of Airbnb, Joe Gebbia and Brian Chesky, did back in 2007. They wanted to see if people would be willing to pay money to stay at a stranger’s apartment instead of a hotel.
Their MVP was a simple landing page where people could book a night’s stay in their living room.
They were soon proven right. As many as three guests booked stays with them as soon as the page went live.
The lesson to be learned here is that Gebbia and Chesky’s landing page looked professional enough to earn them bookings, but what stood behind it was just two dudes and an air mattress.
The single-feature MVP incorporates the “launch early and launch often” mindset characteristic for agile development.
It means releasing your product at the early stage of development, while it only has a single feature that hasn’t been perfected yet.
A great example of a single-feature MVP is the first version of the popular video game Minecraft. Have a look at how the game looked when it was first released in 2009.
The “pre-classic” version of the game was released after just six days of coding by a single programmer. You couldn’t do much inside the game apart from extracting blocks and moving them to create crude structures.
The next iteration replaced it after just one week. Launch early and launch often, indeed.
As simple as it was, players took to the game right away and it became massively popular, which drove its further development.
What you may take away from these examples is that three immensely successful products took three very different approaches to build their MVPs. But they all got the same answer: “I’m onto something here.”
Mapping Out User Flow
Okay, so you’ve nailed down your core features and figured out how you’re gonna approach building your MVP. Where do you go from here?
Well, you may want to map out user flow to determine how the MVP will be used. In other words, you’ll want to work out the steps each user will take to gain value from your product.
Mapping out user flow can be a little complex as you will need to visualize using a product that hasn’t been built yet.
To make this process easier, try sketching out each individual step so you can get a detailed overview of your entire MVP.
That’s what Jonathan Meharry, a design manager at Hubspot did to map out the user flow of Tally, a simple tool for collecting customer feedback.
He started by sketching out each window users would encounter using the app.
He then shared the sketches with his team, who had an easy time imagining the user flow of the app. This enabled them to work together on iterations of the app, cutting what was superfluous, and adding the steps that were missing.
Once they were satisfied with the flow and every step was locked in, they turned the sketches into high-fidelity mockups.
After that, Meharry turned the mockups over to the development team to turn the mockups into a functioning product.
Commenting on the development process, Meharry notes that the sketches enabled the entire team to participate in building the product because every step was clearly described in the sketches and the mockups.
That way, the design and development teams were on the same page, and the process of mapping out the user flow and building the product was (mostly) frictionless.
The image above is Tally in action. The entire process took only 11 weeks to complete, and everyone involved was absolutely clear on every step of the user flow, which made every member of the team able to participate.
To sum up, mapping out the user flow can seem extremely complex, but it can be made simpler and even fun. If you’re not very adept at sketching by hand, there are numerous tools you can use to map out user flow, like Custellence.
The best practice is to break the flow down into digestible steps and describe each step in as much detail as possible.
Getting Ready to Launch
Launching your MVP is the pinnacle of your hard work and the first time you will be introducing your company to the market.
The purpose of an MVP launch is to attract your first users and see if your product has a place in the market, which makes it one of the most exciting moments of the development process!
Related reading: Best Practices for SaaS User Onboarding
There’s more than one way you can go about launching your MVP, so let’s take a closer look at the three basic types of launch available to you.
A soft launch entails releasing your product to only one part of your target audience, your early adopters. This audience segment usually consists of members of a niche community with a special interest in the kind of product you’re offering.
For example, if you’re releasing an MVP for a fitness app, your early adopters could be fitness enthusiasts who participate in fitness forums and subreddits.
This is a great approach for startups because it mitigates the risk of failure and keeps costs low. It also allows you to collect data that can point to ways you can improve your product ahead of a full release.
A hard launch implies releasing a finished product, followed by a massive marketing and sales campaign.
As you may already suspect, this type of launch doesn’t exactly connect well to the concept of MVPs, because there is no room for improvement after the product is released.
If you do decide to go with a hard launch, make sure you know everything there is to know about your audience and your market so you can predict how your product will fare once it’s released.
Also, check if your infrastructure is strong enough to accommodate a massive number of users at once to avoid crashes that can frustrate your customers.
When Pokémon Go was released in the US and Europe, its developers made the mistake of overestimating their infrastructure. The game was instantly downloaded by millions of players, which put a tremendous strain on the game’s servers.
This resulted in numerous crashes and made the game unplayable.
The takeaway here is that hard launches are more appropriate for more established companies and probably not the best course of action for startups launching MVPs.
The last type we will be discussing relates more closely to launching additional features to your MVP than releasing an entire product.
Dark launching relies on releasing new features to a smaller number of users first, to test the feature out, and then raising that test number of users until you’re certain the update can be rolled out completely.
It’s called a dark launch because the segment of the audience in question doesn’t know they’re testing out a new feature.
This is also sometimes called a canary release because the process resembles the practice of carrying a canary into a mine to test out the air before the miners can enter.
As you keep working on improving your product after the initial MVP launch, you may find this approach useful because it allows you to build on your MVP with new features slowly and safely.
In conclusion, launching an MVP is a sensitive matter. Try to be subtle about it and use it to gather as much knowledge as you can so you can release a perfected version of the product at the full launch.
How to Tell if It Works
To reiterate a previous point, the main purpose of an MVP is to supply you with data and feedback on how users are adopting your product.
You want to see if there is a real market need for what you’re offering and how effective your solution is in solving the problem it tackles.
To answer these questions, you’ll need data gathering systems in place that will paint a detailed picture of how your product is doing out there in the world at large.
Have a look at the diagram above. It depicts a perfect product release plan for SaaS products.
The point is to release your MVP at a low cost and then collect as much data as possible so that you know exactly where to invest resources to perfect the product for the full launch.
As you may already know, there are two types of data you can collect: quantitative and qualitative. Let’s review the methodology for collecting each type.
There’s no better way to see how your customers feel about your MVP than talking to them directly. Qualitative data is all about collecting honest user feedback and there are a few ways to do that efficiently.
An excellent approach would be to conduct customer interviews. As such interviews are less structured than other methods of collecting feedback, users can raise issues or suggest changes that might have never occurred to you.
However, this approach is costly and doesn’t cover a lot of ground.
You can also use customer surveys to cast a wider net and receive more structured responses. Services like SurveyMonkey can be of great assistance in crafting the perfect interactive survey.
Other than surveys and interviews, you can create subreddits and social media groups to interact with your customers in meaningful ways.
One of the best things about offering SaaS products is that you can collect massive amounts of data about how customers are using your MVP by tracking a selection of usage metrics.
However, there is a veritable sea of metrics you can track and zoning in on just a couple of key metrics to track how successful your MVP is can be challenging.
To get the most out of your data, try to select the metrics that answer the right questions and point to concrete actions you can take to improve your product after the MVP stage.
Every startup has its own formula for success, but some of the most commonly used metrics for MVPs include:
- Churn rate (the percentage of users who abandon the product over time)
- CAC (customer acquisition cost)
- MRR (monthly recurring revenue)
- LTV (lifetime value of individual customers)
Whichever combination of metrics you choose to track, remember to make the data available to your entire team. Different experts interpret data in different ways, so you stand to gain the most by having as many perspectives available to you as possible.
A business intelligence platform like Trevor.io, which gives your team access to your company’s real-time data, can help your team learn and suggest iterations and improvements to develop your product beyond the MVP stage.
It allows you to import data from a variety of sources and organize it into neat dashboards, which makes it easy to draw conclusions and suggest actions.
Keep in mind that SaaS products lend themselves to very detailed data analysis. Use that to your advantage and collect as much feedback and data as you can to make the next iteration of your product more efficient and user-friendly.
This article has attempted to map out a clear route for you to take as you prepare to share your excellent SaaS product with the world.
What’s important for you to take away from this article is that you’re not expected to release a perfect product at your first launch. Rather, your aim should be to test the waters and see how your audience and the market will react to the solution you offer.
Therefore, don’t allow perfectionism to stand in your way and stay flexible and open to the knowledge you stand to gain from an early release of your MVP.