Determining the right time to release a minimum viable product (MVP) isn’t easy. You have to be careful not to pack in too many features, and humble enough to be open to being wrong about the viability of your product.
When done correctly, though, the process can lead to hugely successful products. Look at the blockbuster Pokémon Go, which has its roots in Ingress, a game that appealed only to a very small, specific market. “In some ways, Ingress was the MVP in that it enabled the geolocation of landmarks and afforded the user an ability to get updates in real time [showing] where they were, with complex mapping that was enabled on the back end,” said Chris Pegg, a senior business analyst at innovation company GoKart Labs.
Pokémon Go, which capitalized heavily on Pokémon’s brand affinity, boosted interest in technologies that had been around for a while. “Ingress was viable, but until they applied this great Pokémon multiverse on top of it, they really didn’t know what they had,” Pegg added, “so they incrementally started assembling all the experiences that they had in Google Earth and so forth, where now they’re in a really great position to reap some pretty incredible rewards.”
MVPs Should Be Small
A refined MVP matters more in certain technology sectors than others. Aaron Eden, co-founder and COO of Moves the Needle, suggests that a minimum viable product should be so minimal that you’re embarrassed by it, so long as its core functionality solves a customer’s problem. “It should be really really small,” he said. “It should be one piece of functionality that solves one problem for one type of customer.”
Take what you think you’re going to build, Eden recommended, and cut it in half. An MVP typically looks like only part of a feature-set.
Kurt Becker, vice dean for Research, Innovation and Entrepreneurship at NYU Tandon School of Engineering, believes that inventors and entrepreneurs go wrong when they become too solution-driven, inventing a product before drilling deep into the problem it’s supposed to solve. Trying to market-validate a product after its creation is rarely effective.
“Very often, this is not a good approach,” Becker said. “Often the longer you wait, the more refined you make your minimum viable product, the more reluctant you are to actually go back and make changes and rather than listening to the market, you have a tendency to tell the market what it should want.”
Eden points out that developers often continue to add features that don’t solve a problem for customers, even as the product itself grows enormous: “You’re actually overbuilding in those cases. So by being really specific and focused on solving one problem for one customer as your starting point, you can keep from overbuilding.”
Instead of trying to build a really cool platform with features people don’t necessarily need, identify a problem that needs to be solved and keep the problem in mind when inventing a solution. Since you don’t really know at that early point what the customer wants, give your minimum viable product only the absolute minimum of features.
For example, let’s say you build a Web platform that forwards résumés to multiple employers. You could begin the project as a simple site that allows people to upload résumés, which you then manually forward until you determine that there’s a viable audience for the product. “If it turns out that nobody wants to give you their résumé, then what’s the point of building on that?” Eden said.
Customer Feedback Is Crucial
Even before you build a MVP, you should seek customer feedback. “Go to the customer, but rather than try to sell a product—which you don’t have at that point—ask them what their pain point is, or what would make their life easier,” Becker recommended. Only after you have that information can you begin constructing your MVP—unless the feedback from potential customers makes you realize your idea wasn’t that great after all, and you need to pivot.
After your MVP is built, you’ll need to continue collecting customer feedback, and your product may go through several iterations. Users will often ask for additional features. As the founder, you need to figure out what to do with that feedback based on your expertise in the area. “You shouldn’t just add features blindly,” Eden said.
Becker recommends speaking to up to 100 customers during the discovery process. There are different customer segments, some of which have higher market potential. If everyone asking for a specific feature is in that segment, you may want to pay attention.
Eden also suggests looking at behavioral patterns when deciding whether or not to add a feature. If dozens of people say they are interested in a feature, it may be worth looking into. “What you do is you build a small experiment without building the full feature that proves based on behavior (not based on what people say) that they will use that feature,” he said.
For example, if your MVP is a CRM system, and you hear over and over from customers that they’d like to integrate it with a specific marketing system, Eden recommends designing a small button that says it connects to that marketing system. At least initially, clicking on that box will open a window that says: “This feature coming soon.” By counting the number of times people click on the box, you get a better sense of how many people want the feature, which will help you figure out whether to actually build it. Focus not on what customers say, but what they do.
And remember: just because a customer wants a feature doesn’t mean you need to build it. While an MVP is an important way to ensure success, you also have long-term priorities that may not include what a particular customer wants.