Can you afford to gamble on an idea for an app or on an assumption about how consumers will respond to it? I bet your clients aren’t too comfortable doing that either, especially when it’s their money and reputation on the line.

An app can be a risky investment for a business if it’s not approached with care. Even then, the most well-researched of app concepts can lead to disappointing user download and retention rates.

Whether you’re in the business of building mobile apps or SaaS products, have you thought about using minimum viable products (MVPs) to safeguard your clients’ investments?

Not only do MVPs allow you to get projects through your pipeline more quickly, but they enable developers to create stronger products overall for their clients.

Here’s what you need to know.

The Value Of MVPs In App Development

Frank Robinson was the first to define what an MVP was back in 2001. At its root, an MVP is a scaled-back version of a product that’s released to the public for the purposes of testing and validating the product’s concept and viability on the market.

Eric Ries, the author of The Lean Startup, was one of the early advocates of MVPs and he had some interesting things to say about why and how we should use them back in 2013:

The point isn’t to create leaner products. It’s to get the most basic version or concept of an app into the hands of adopters and evangelists. That way, the developer collects user feedback early on that, in turn, is used to properly shape the product into its final version.

Take Dropbox, for example. This is what the product’s landing page looked like back in 2009:

It’s a simple page that includes the company name, an explanation of the software and a link to download the desktop or mobile app. For users that want to know more about what they’re getting, the “tour” took them to a mini-site with more information:

That’s a far cry from the powerhouse storage, content creation and collaboration service that both consumers and businesses use today:

But that’s the beauty of the MVP. Essentially, it forces developers to build products with only the minimum — but absolutely essential — set of features.

Dropbox didn’t need to foresee the power of cloud storage services or to create something that wasn’t right for the market at the time. All it needed to do was launch a simple solution that users needed then and there. Users could then validate the product and provide the company with the direction it needed to take its product.

There are other benefits to creating an MVP:

• You can get the product on the market much more quickly than if you were to wait for the full app to be developed.
• You get a chance to test the viability of the concept before you commit too many man-hours to the job.
• You give yourself more room (and maybe even a little forgiveness, too) to work out the kinks in your final product.
• You save money with an MVP. First, because you only spend time building features that are absolutely needed. Second, because you might find that users are content with the scaled-back version and you won’t need to do much more work to finalize the product.
• With a tested idea that’s been embraced by users, you have something to bring to investors which could make the rest of the development process go much more smoothly.

As Eric says in the video, an MVP is the best way to maximize your chances of success and to do so in a much shorter timeframe than complete product development allows for.

How To Build A Valuable MVP That Users Want to Test

Your MVP’s success rides on its ability to leverage insights and feedback provided by early adopters — the ones who are 100% on your side, believe in the product and want to help you fill in the gaps. So, don’t lose sight of that.

An MVP is not some half-assed app thrown together. It still needs to be valuable.

Here are some things you must do before you build and launch your MVP:

1. Decide the Product’s Purpose

If you want your app to succeed, it needs to uniquely solve a problem for a large segment of the consumer base. That means your MVP needs to clearly break down what the product does and why users need it.

For example, this is how Uber (then UberCab) sold itself during its beta in 2010:

Like the Dropbox example earlier, it’s extremely simple in concept and no-frills in terms of explaining what it is or why it’s so valuable. But you still get the idea. It’s an app that lets people order and pay for a car from their phone. Essentially, it’s a convenient substitution for cabs.

Jump ahead a year, you’ll see that Uber started to firm up its identity and value proposition with its official product launch:

This was back in 2011 when Uber dropped the “Cab” and labeled itself an on-call private driving service. It was a way to let consumers experience certain luxurious privileges they might not otherwise have been able to afford.

Although that’s not the final form Uber ended up taking, you can see how early user feedback helped the product developers decide which parts of the platform were really worth highlighting and building upon.

This is exactly the kind of thing that will happen when you build an MVP and start to gather valuable insights from users about what they want and which features they need. But, first, you have to start by getting clear on its general purpose and value. You can refine it later on.

2. Locate Your Ideal Users

You have your concept. Now, it’s time to figure out if consumers are going to want it. Even though an MVP is cheaper and faster to build doesn’t mean it won’t end up a complete waste of your time and resources. You have to at least confirm that the interest is there and then define, in clear terms, who your target user is.

Specifically, you need to think about location.

In the Uber example above, you can see that the beta product was only tested in San Francisco.

The initial version of Airbnb did something similar. Joe Gebbia, the co-founder of Airbnb, tells the story of his MVP on a 2017 episode of How I Built This.

Basically, he was low on cash and decided to rent out air mattresses in his San Francisco apartment for an upcoming conference. Knowing that hotels would be short on rooms, he figured he could make money off of it. But it wasn’t just rent money he made. He got an idea for a new business after a lot of people showed interest in renting space in his apartment.

So, he and his partner created a website called “AirBed & Breakfast”. Once it went live, though, it spread far beyond the original San Francisco test area.

In 2009, there were AirBnB rentals in 72 countries. Today, you practically have your pick of the litter in any town around the world. But it all started with San Francisco.

So, as you set about building your product, think about where the best places will be to test and get feedback on your app before you do a full release of it. You want the area to be a good representation of the population and demographics you aim to target. You also have to make sure there’s a demand for the product and that your target users can afford to use it (once you start monetizing).

3. Choose an MVP Format

The format of your MVP is another important thing to think about before you do any building.

In some cases, you’re going to have to build a workable product. For example, let’s say your goal is to build a new dating app. There are tons of dating apps on the market; with two apps, in particular, that continually dominate the pack. You know that building any sort of mobile dating app would be a huge and costly gamble, no matter how much you cut back on features. So, what do you do?

You could build a PWA dating app instead. The costs would be lower, the time-to-market significantly faster and it would be much easier to get your MVP in front of users than if you were to put something on the app store. You might even find that the PWA suffices in terms of product format in the end.

In other cases, the MVP won’t even need to be an actual product. It can just be a website announcing the product or providing a wireframe/prototype of the concept.

In 2018, Rand Fishkin announced that he was leaving Moz, the company he co-founded in 2004. Simultaneously, he announced a new product called SparkToro.

Now, Rand is someone who can launch a concept as an MVP and for it to still be successful. He has a long-standing history and solid reputation in this space, so, of course, users are going to gravitate to this new product despite it being unavailable for consumption.

For those of you building an MVP for a new brand, you probably won’t get so lucky. However, it’s really going to depend on what type of product you’re planning to build.

If there’s absolutely no way to create the product in a scaled-back version, then this could be an option worth exploring. It would also be a good idea if you or your client have absolutely no funds and need validated feedback to prove the viability of your concept to investors. That’s really the only way I see Joe Schmoes getting away with this.

If you do go this route, you’re going to need a really good explainer section, too. This is what SparkToro has on its What We’re Building page:

I think for the kinds of users that would gravitate to a product like this — namely, advanced marketers that actually need this kind of solution — this way of testing the concept and viability of the features is good. It’s written in their language and with visuals they understand.

However, for users that aren’t familiar with your brand or aren’t as well-trained as Rand’s audience, a wireframe or prototype of the product’s dashboard would be a better idea. Even an explainer video from the founder would work well. It just needs to be something that convinces users to sign up and start providing feedback as early as possible.

4. Find Your Actual Minimum

If you watch the video of Eric Ries, you’ll see that he provides a formula for defining the minimum features of your MVP. It goes like this:

# of minimum features you think you need / 8 = The True Minimum

It makes sense if that formula makes you feel apprehensive. But think about it like this:

You build an MVP that is as simple as it can possibly be without it becoming useless. You ship it out to users and give them a chance to provide feedback.

A few things might happen as a result:

They absolutely hate it.

They complain to you about how Feature A sucks and how they wish it did something else or how Feature B was almost there, but then fell short of expectations. That’s perfect! Your test users will tell you exactly what they want from your product. Get enough consistent feedback and you’ll have a list of must-have features that need to appear in the next version of the app.

They’re okay with it, but don’t love it… yet.

Again, it’s okay if users aren’t 100% happy with it. You’ve given them an opportunity to try out a product that’s going to be awesome and they see the promise in it. Give them a chance to speak their mind and let you know what they loved and what they didn’t. Then, focus on strengthening those weak points and including the features that will make it a real game-changer.

They’ll love it as is.

Let’s be honest, this isn’t likely to happen. But wouldn’t it be great if feedback was so scarce that you could roll with the MVP as is? Plus, think of all that time you saved yourself and money you saved your client by cutting the product back so much. Sometimes simpler is better.

Don’t forget to thank these users for their feedback and support of the product. There’s no way you could create the solution they need without their insights and so it would be in your best interest to recognize the role they play in this. In return, they’ll continue to be your product’s evangelists long after launch.

5. Design Your Landing Page Early

Although I’m not too keen on a landing page or mini-website serving solely as the MVP (for the aforementioned reason), I do think it’s a good idea to get a mobile-first landing page up while the MVP is in the works.

Gaming apps and SaaS would be especially good choices to launch a beta signup page early. Here’s an example from Hytale:

If you want your MVP to succeed, you should put some of that extra time you now have towards building out a strong landing page. Start by researching the early websites from the companies featured in this post. They all successfully explained their concepts, soft-marketed their products and convinced early users to sign up for testing.

While you’re at it, you should set up your blog, social media accounts and community features (with an active newsletter), too. You never know. Someone might find the announcement of your MVP somewhere other than Google search and decide they want to bookmark the site or sign up early to be a beta tester.

It’s never too soon to start getting buy-in from your user set!

6. Define Your Success Criteria

Last but not least, you have to decide how you’re going to measure the success of your MVP. Because it’s not just about the quality of feedback.

Consider the following:

• How many visitors visited your landing page?
• How many of those people signed up for the beta?
• How many users did you retain over a set period (1 month, 3 months, etc.)?
• How many people provided feedback and was it a substantial enough set to make solid decisions about the product design and features going forward?
• Did the demographics of your user set match the audience you designed the app for? Why do you think that was?
• How much time, on average, did users spend inside the app?
• Which features did they spend the most time with? The least?
• Which features received the most favorable feedback? The least?
• Were there certain users who had a positive experience with the product? What made them different?

Take all of the information you gathered — from the original landing page, the beta testers, the usage data and so on — and really look over it all. What is it telling you about the MVP you’ve designed? And, now, what are you going to do with it?

Will you leave it as is or build it out to the full product it’s meant to be and that users want?

Will it be easy to attract and acquire customers based on the usage data you’ve collected? What’s more, will you be able to retain those users or is it more cost-effective to keep your app browser-side instead of in native app form?

And, finally, how much can and should you charge for access to the product? Will it ultimately make the company profitable or is there just not enough interest (at least in the monetization side of things) to make this a worthwhile venture?

I know I’m leaving you with a lot of questions, but there’s a lot you’re going to need to sort out once the tests begin. Plus, it’s the whole reason you created an MVP in the first place. This user feedback is invaluable to the process and is the only way you’re going to know if it’s a product worth pushing out to the market or taking back to the drawing board.

(ra, yk, il)