How to Maximize Your Minimum Viable Product.
Create the product that most simply delivers on the core user need.
Do the words “Minimum Viable Product” bring to mind a watered-down version of the killer product you really want to develop? Many people confuse launching a MVP with compromise in order to meet the expectations or deadlines from stakeholders. But if you understand the core value of an MVP, then it’s the smartest first step in product development.
There are many misunderstandings and misapplications of a concept that has led so many startups to launch successful products. The best way to avoid the common pitfalls of an MVP is to embrace the concept and apply it correctly. If planned properly, MVPs don’t just avoid these pitfalls, they reverse them.
Why start with an MVP?
The most important thing to understand about an MVP is that it’s based on learning rather than presuming to know everything. A successful MVP is thoughtful and laser-focused on satisfying a core user need as quickly and effectively as possible. A good product development team understands that:
You may love your idea, but you don't initially know if your users will.
Building a digital product is not the same thing as building a skyscraper; it’s shaped by interactions with users whose behaviors and preferences you can initially only make educated guesses about through user research and analytics. The simpler and more focused you make your MVP, the more effectively you can measure user reactions to it. Think of it this way — you don’t try to develop a new cancer drug that you think will be effective against all cancers, you start with a refined initial experiment on one cancer, measure your results, and do more of what’s working.
A great MVP works the same way. The time and resources you have to spend on your product are valuable, so don’t squander them by testing too many hypotheses at once. In the enterprise setting, it can be tempting to plan your MVP by addressing every stakeholder desire for the product. After all, you’re not a startup, you’ve got the resources, so why not? The issue is that users don’t know anything about what the marketing department or the HR department wants from the new product, they just know whether it’s useful to them. Focus your MVP on validating your assumptions about users, and listen to their reactions closely. Any large organization can build a new product; it takes courage and fortitude to build one your users will actually love.
Product teams build better new products with lower uncertainty.
When building an MVP, you generally have two inputs to the number of permutations the product can take. On one side, you’ve got the different potential features that could solve your business problem if users love them. On the other, you’ve got the possible ways you could implement each feature. This formula gives way to a dizzying number of possibilities that need to be tested, so keep the number of possible variations small to make sure you deliver the best possible MVP with the resources you have.
Let’s say that you’re launching a new company website and one goal is to feature new products on the homepage. You can do this with stunning imagery and video, or maybe testimonials from early customers, or maybe even press coverage about how awesome the company is. One of these ideas will be the best option to test in an MVP, and a great product team will narrow down lots of ideas to the best one.
Added complexities should be addressed scrupulously.
Now, imagine that the company wants to call out great career opportunities on the homepage. And maybe recent press releases. And let’s not forget quotes from the executive team. Pretty soon, the task of delivering an MVP that validates your assumptions gets tougher, since you’re testing several things at once. What could easily happen is that your new product gets messy and frustrates both users and stakeholders, because everyone had to get their pet feature into the mix. Plus, you’ve created an environment where it’s not as clear to isolate what’s working and how to optimize results.
The shortest path is rarely the road less traveled.
A common mistake is to try to delight and innovate at every turn, spending precious development time perfecting a particular design element. But actually, there’s no reason to reinvent the wheel when it comes to basic interactions and non-core functionality. For example, if you’re designing a website that needs a registration form, make sure you’re leveraging known best practices for maximizing the usability of registration forms. Don’t try to be the company that reinvents how we all think about registration forms.
All team members need to stay aligned on the core goals.
When it comes to execution, a successful product team needs to be in sync with all other teams and partners. Therefore, in the planning stages, align on one or two things that your team wants to accomplish and stay focused on accomplishing those together. Do you want to make browsing for products a much better experience? Are you trying to build effortless content search? Is surfacing all of your great video content the most important goal? Establishing these common goals with all disciplines from design to development will help everyone stay on track and not going off on tangents. Work across the various stakeholders invested in your hot new product to focus these first steps, so they can be intentional and unobstructed by clutter.
Room should be left to learn and react.
When you aren’t sure what users really want or how they are going to interact with a feature, sometimes it’s best to scale back and use the MVP as a chance to gather insights. The risk in building out complex functionality in response to assumptions you have about a user’s pain points is that you might waste resources building the wrong feature, then lock yourself into an experience that doesn’t deliver.
When these insights are applied through every stage of planning and execution, you can be much more confident of your product’s direction. Sharing these insights and the actual data behind them can be an essential step in earning stakeholders’ trust. It’s not an outcome of limiting the possibilities, but the way to truly understand the best features and possibilities for the product.
So take this approach to MVPs to your next boardroom discussion. Rather than thinking of MVPs as a series of cutbacks and lowered expectations, remember that every aspect of the successful MVP is intended to achieve the product your users really want — now that you know what it is.