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. [caption id="attachment_8722" align="aligncenter" width="650"] The right way to build an MVP (Source)[/caption] 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.