What Is An MVP Mobile App?

By Sarah Varki

Normally in tech, MVP is known to stand for “Minimum Viable Product.” In our case, we replace the “Product” with “Platform” (for a crash course on Platforms, check our 101 section). The same basic concepts apply in terms of approach, but the output is a bit different. A minimum viable product tries to prove a concept for a single-sided product. A minimum viable platform, on the other hand, focuses on nailing down the viability of the core transaction of a platform. It’s essentially a way to test a platform business model with the minimum amount of custom coding and complex features.

At Applico, we even provide a service that takes it one step further back: a prototype MVP. Think MVP for the MVP. This is a code-free, manually-operated (and significantly cheaper) prototype that’s purely for determining which platform business model works best, as opposed to determining how to improve and develop a platform with a set business model. This article, however, focuses solely on the minimum viable platform.

Now, if you haven’t read the Lean Startup yet, add it to your list. It’s the foundation for many processes that companies use. To note, there’s a misconception that an MVP is unpolished or unfinished. That’s not the case. It may not have all the features you dreamed of, but it has all the functionality you need. The core methodology is “Build. Measure. Learn.” More famously, Spotify’s version is “Think it. Build it. Ship it. Tweak it.” The point is to learn quickly and iterate.

According to Spotify’s product team, the idea is not to deploy an incomplete product that becomes increasingly complete, but rather to deploy a basic, yet complete, product that becomes increasingly powerful with features that improve efficiency and capabilities.

What Isn’t A Minimum Viable Platform?

Let’s say you want to make a new game where you shoot snowballs. You get some initial feedback on the idea for validation. Then you get the idea to have the player shoot snowballs at elves, something more focused and specific. You deploy a version and test it. Can people see their scores? Do they understand the timer? Do they know when to change their view? You review these questions and evolve and iterate. You add some more features, like sound effects, gather feedback and you adjust. Rinse, repeat.

While this is a great start to an MVP game, it’s not taking into account any platform potential. That is to say that the game isn’t a platform because there is no exchange of value between two sets of users. The game lacks a core transaction.

Early on it’s all about focus. For example, let’s say Uber wanted to start their platform with fare splitting, gamification, countdown timers, and prizes. Could they have done some of these things? Absolutely. But did they start out worrying about that? No; it would have been a lot to deal with. Their focus was just the core transaction: matching drivers and riders based on proximity. And they worked relentlessly to get that core transaction right. Did they eventually add these features and even implement different types of rides (UberT, UberPool, etc)? Yes, but they didn’t start with that. They started with a focus on the main interaction, then grew from there, applying what they learned to other types of rides. Read more about why the no. 1 most common mistake in software development is a lack of business model design.

With that, let’s take a look at a few platforms that are MVPs, and why the MVP Platform model is beneficial.

Examples of Minimum Viable Platforms

1) GLAMSQUAD (read our case study here) 
The concept was simple: an on-demand beauty service. And although there were a ton of complex parts they could have started off with, GLAMSQUAD focused just on their core transaction: booking appointments. They just needed to see if people would actually try to book and if they could get stylists to show up in time. To do this, they experimented in a limited area with their own controlled staff. We worked with them to build a consumer app that was very bare-bones. It only had account info, types of hairstyles, and search for booking appointments. There wasn’t a stylist app, bookings history, in-app cancellations, or a custom backend. Although these were all in their roadmap, it didn’t make sense to spend money on what wasn’t immediately essential. They chose to focus on getting the match correct first, and proving that was viable, before worrying about the rest of what the platform could or needed to become in the future.

2) Amazon
Amazon may be a retail giant now, but in 1995,  “it was nothing more than a few people packing and shipping boxes of books from a two-car garage,” according to this Time Magazine article. They were known to buy and manually package their own items before they had the right supplier. They didn’t allow other sellers onto the platform for years. They first understood what they could sell and how they could sell it, and they expanded from there. They didn’t have all their bells and whistles at launch. That would have been an expensive mistake. They just needed to see if the concept would work and how they could improve it.

3) Taproot+
The Taproot Foundation teamed up with NEO to build a two sided marketplace to match skilled volunteers with nonprofit organizations.  The result is Taproot+. Its early stages were actually quite scrappy. While there were a few pages to browse, they were hand-built. They didn’t have a login, and their “backend” was emails being triggered and matches being manually managed by humans. This wasn’t initially scalable, but it let them learn what pieces would be needed in a later version to set up non profit pages. Things like logins, automated backend, matching algorithms, and templated business pages may have seemed important, but for the MVP they were avoided. They focused simply on learning what was valuable to the community and adjusting their product from there. They made sure the core transaction worked — that people could be matched to non profits — and then used those learnings to build out other aspects of the larger platform.

4) UberEATS
UberEATS is a new food delivery service that builds on Uber’s existing platform, but in a minimalistic way. It’s currently only available in Manhattan. This particular extension of the Uber platforms has no complex system for adjusting to changes in demand. UberEATS delivery workers just get one set of food “inventory” that they carry around for the duration of their shift. There’s no online ordering; it’s all through the Uber app. And they deliver only for a specific number of blocks in a given amount of time frame. They’ve expanded a bit so that users can see what’s on the menu for the whole week, but there’s hardly any advanced functions. Even the email receipts for UberEATS customers leverages the existing Uber ride receipt template. It’s a little weird to get a receipt for “your afternoon ride” when you actually weren’t in a car, but the template serves its purpose. At the end of the day, even with all the money Uber as, they didn’t spend more than what they needed by making everything perfect. They did what they needed to within their existing structure for their proof of concept.

Just like any MVP, you don’t need to build everything to start a platform. At Applico, we’ll work with you to understand and brainstorm all the potential options and to create a phased roadmap that includes the long-term ideas. Phase 1 may not be as robust as you want, but it’ll only be as robust as you need it to be. Your platform has to start somewhere! For more tips on how to solve the Chicken and Egg problem, read here.

 

---

Filed under: Product Engineering | Topics: