Aug 30 2018
Every piece of software is the product of many, many hours of labor—and if you’re not thoughtful about designing with your target user in mind, much of your work may be wasted. Features could be non-intuitive, or simply not useful to your target market. The entire product may not even work properly on your user’s platform of choice.
Problems like these can be alleviated with a product discovery and prototyping process that allows your user base to offer feedback on their needs, and gives them an opportunity to test out a simulated version of your product. But there’s nothing like getting actual real-world feedback on your product to validate your ideas and ensure that the product is meeting the needs of your target market.
That’s why smart software development teams tend to begin with a Minimum Viable Product (MVP), rather than waiting until they’ve completed all of the target features on their product roadmaps.
An MVP is a completed product, not a prototype. It’s been fully coded and debugged, with a well-designed user interface. It’s ready for active use. But it may not have all the bells and whistles you’d expect in a mature product offering.
Eric Reis, author of The Lean Startup, coined the term, defining it as “that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
That means that you can test out your hypotheses about how people will use your product by offering them a limited number of features. You’ll be able to see whether the product is valuable to them, and how people are using it. This allows you to get to market much faster than waiting until all of the proposed features are ready, and enables you to shift gears when needed.
Once you’ve built your MVP, you can analyze usage data to understand whether the product is performing the way you expected, or if you need to make foundational changes to your product offering. You’ll be able to gather insights that help you optimize the current product, and to prioritize the rest of your product release. If you need to shift track, you’ll be able to do that without investing upfront in development for features that don’t offer value to your users.
Throughout the agile development process, software engineers typically focus on some variation of the “feedback loop,” in which your team starts with an idea, builds it, releases it, and optimizes it. The process might be slightly different from company to company, but the principles remain largely the same.
For example, here’s a look at Spotify’s product launch process:
In this process, your MVP serves as an experiment to rapidly collect as much feedback as possible on user response and behavior. This data can be analyzed and informed to help shape the product’s direction from that point forward.
The MVP does not need to be released to all of your users: For instance, Spotify typically releases new products to between 1 and 5 percent of its user base initially. These limited releases enable the company to collect genuine user data that it can then use to further optimize the product before releasing it more broadly. Spotify can continually A/B test variances in features, design, copy and other elements of its product to ensure that the product will gain traction among its target audience.
While some companies seek to launch an MVP that’s purely functional, others believe that, even if your product offers a limited number of features, it’s important to dazzle your audience from Day One.
Brandon Schauer, CEO of Adaptive Path, refers to this as the “cupcake model.” He believes that if you don’t put the right resources into planning out your first release, you’ll be offering your users something akin to a dry cake—you might plan to add the filling and the frosting later, but it’s going to seem unappetizing to them now, and you won’t be able to gain traction.
Instead, he recommends focusing on building a “cupcake.” The features might be limited, but the product should offer a delightful user experience with strong design, and give users a true sense of the product’s capabilities.
Your approach might vary based on the scale of your initial release. If you simply want to test out your product features among a core group of beta users, you may be able to start with a skeleton of your final product and build it out from there before releasing to your entire audience.
But if you want to ensure that you’re able to create brand evangelists as soon as you launch, it will be critical to put in the extra time to show that your product is something special, even if it’s still a fraction of what you hope it will be.
The MVP can serve as the first phase of your product launch, whether limited or widespread. In either case, what’s most important is that you collect the data you’ve gathered, and make good use of it for optimizing the product’s direction from that point. That data could include off-the-cuff comments from users, customer support requests, site analytics data, heatmaps, and more. Collect everything you can, and work together as a team to analyze trends in user behavior to understand whether the product is performing as expected.
From here, you’ll be able to prioritize features and fixes for the next release cycle, and repeat the feedback loop again.
In product development, the learning and iteration process is never-ending—start it out with a strong MVP, but understand that you’ll always have room to grow.
Want more? Head back to the Tivix blog