Learn / Guides / PM glossary (A-Z)
Defining, developing, and building a minimum viable product (MVP)
If you want to implement a lean product development process, working with a minimum viable product (MVP) could be a great approach. But what does that mean, and how can you utilize MVPs within your product team?
This article deep-dives into a minimum viable product (MVP) and how it’s defined, specifically for product management. You'll hear from Pulkit Agrawal, co-founder at Chameleon—a product success and user onboarding SaaS—to help you understand what an MVP is and how you can utilize it with customer feedback to build more informed products.
Here’s what you’ll learn:
Minimum viable product (MVP): its definition and purpose
A minimum viable product (MVP) is the first version of a product fit for market. An MVP has core functionality and, coupled with customer feedback, is a learning tool for product teams to release new features and better iterations of the product.
To get a deeper understanding of the purpose of a minimum viable product, we spoke to Pulkit Agrawal, co-founder at Chameleon—a SaaS onboarding tool for consumer-centered product growth.
Pulkit said defining an MVP depends on what you need to test.
For example, if you're doing problem validation—which is when you test to ensure you understand problems before creating solutions—your MVP might be a feature-lite prototype to assess whether there's a real problem, if people are interested in finding a solution, and if there’s demand for your solution.
Or, if you want to test a new feature for your existing product, you could develop an MVP of that feature and release it to a segment of users to understand if the full version is worth pursuing and rolling out for all users.
But one of the most significant purposes of an MVP is to ensure customer delight by enabling you to make product decisions based on customer feedback as early as possible in the development process.
Why is an MVP important for product teams?
Working with an MVP helps product teams prioritize workflows and deliver solutions, fast. It provides an early opportunity to gather a wealth of qualitative and quantitative data about how customers experience the product—rather than waiting until everything is perceived as perfect.
For example, you might prioritize one feature of your product during development, only to discover later that users make little use of it. But by releasing an MVP, you can see they’re making great use of another feature, which you thought was comparatively minor, and which had been given low priority by the team. Having access to this information before you’ve poured more time and resources into the wrong features means you’re better placed to build a product people want.
This reliance on customer data over guesswork gives you the confidence to release new features and product iterations that are more likely to attract and retain customers—which can be especially important when using methodologies that encourage teams to move quickly and learn from continuous feedback (for instance, agile product teams).
How can product teams use a minimum viable product?
Product teams can use an MVP to:
Move faster: test an initial set of core features earlier than if you waited for everything to be ready
Make customer-centric decisions: build new features based on customer feedback rather than building what you think your customers want
Better prioritize development: validate ideas to understand whether they’re important to users—or not
And product teams can take MVP data even further by having it:
Inform acquisition and retention strategies: mitigate risk by using customer data to inform decision-making and avoid investments that aren’t in line with customers' needs
Adjust product positioning: base positioning on how your customers use your product—which may differ from how you originally intended
Help identify product-market-fit: understand who your users are and what they want by soliciting feedback and understanding user behavior at an earlier stage of the process
But of course, there are other ways to use an MVP beyond those mentioned above. For example, Chameleon originally built a self-serve widget—quickly and in advance of their planned roadmap—to retain a customer, which their scrappy product team quickly evolved into an entirely new product:
“In the early days, we had product tours, but we didn’t have anything that was remotely like a self-serve widget or a checklist. One of our customers wanted this and were considering an alternative provider that offered it at the time. So we said: look, we know we want to build this anyway, but we’ll accelerate our roadmap because we have a customer creating demand for it.”
“We committed to it,” says Pulkit. “We built it quickly, and we built it in collaboration with that customer. It worked. We kept that particular customer, but it also formed the basis of our Launchers product.”
Pulkit's story shows how an MVP helps you respond to customer feedback and adjust priorities to deliver new features quicker than planned. These features will then generate new customer feedback, which continues the process of iteration and refinement in a loop of continuous discovery, rather than building an entirely new feature (or even a new product) only to have customers tell you it’s not what they want.
“Today, time is more important than cost because everything is moving so quickly. Instead of thinking, ‘how can we achieve this for the lowest resource input?’ We should just think about the quickest time.”
How is a minimum viable product (MVP) developed?
An MVP is developed based on data-backed user research: market data suggests customers want a certain product or feature, and you want to develop it, so you create a version with only core functionality to test your product before investing time and effort (and money) into a full version.
Here are a few user research techniques your product team should use to inform the development of your MVP:
Focus groups: gather a small number of people together to discuss your MVP. This is a great method for discovering participants' opinions about what you’re working on and can guide what features you choose to develop (but it can also introduce bias when some participants are more vocal or persuasive than others).
Customer interviews: ask your individual users questions as you develop your MVP and listen to what they say. Mastering customer interviews involves asking open, unbiased questions and embracing silence—listen more than you speak.
Surveys: use virtual questionnaires to solicit feedback about user experience with your product and use that to guide the development of your MVP. (More on how Hotjar can help with surveys later!)
Session recordings: use software to record the actions that real people take with your product, such as mouse clicks, movement, and scrolling. Session recordings are a fantastic way to spot major problems with a site's intended functionality and see where users stumble.
Heatmaps: produce a visual representation of how users move around your product by showing its hottest (most popular) and coolest (least popular) parts. These are a good way to observe and objectively measure behavior on your website.
Collect as much information as you can before and during build to ensure your MVP has a better chance of product-market-fit and is equal parts learnable, feasible, and usable.
Pro tip: with Hotjar, you can start learning from user feedback as soon as your MVP is live; solicit customer feedback with the Incoming Feedback widget, look at Heatmaps, watch Session Recordings, and run Surveys.
An especially great way to use Hotjar for your MVP is to use Heatmaps in conjunction with A/B testing to understand more precisely what the optimum version of your site will look like based on customer data rather than guesswork.
Keep reading to learn more!
How is an MVP used to build stronger products?
Just as you can iterate upon existing features, you can use an MVP to build stronger products: developing new features and demolishing anything standing between your product and customer delight.
As you learn from feedback loops on your initial release, you’ll begin to see opportunities to enhance or grow your product. For example, learnings from your MVP can help to:
Identify pain points: for instance, people having trouble finding a particular feature, encountering bugs or blockers, or confusing navigation
Highlight missed opportunities: if user feedback is telling you a feature is missing, as with the previous example with Chameleon, you can use an MVP to quickly develop a new feature
Stay mission-orientated: for example, if tools like heatmaps are telling you customers aren’t making use of certain parts of your site, you know those areas are low-priority for development or could even be removed entirely
Prioritize improvements to your product: similar to the above, by understanding how users are engaging with your product, you know which features you need to be constantly refining and developing with high priority
Inspire new features: by studying user insights, you’ll be able to identify new features that will make your product more efficient at meeting their demands
How to communicate an MVP with the team once it’s ready for launch
Communication is key: when you launch an MVP, you need to share it across multiple departments within your organization:
Sales and marketing will need to understand what core functionality the MVP is launching with, to go to market.
Customer success will need to know what improvements and new features are coming soon, to help retain customers.
Other product teams will also need to be kept in the loop to ensure no one is duplicating efforts or wasting time on low-priority features that don’t align with the core functionality of the MVP.
To communicate your MVP, draw from popular strategies of cross-functional collaboration culture. Share product updates and new features and the why behind them; empathetically present data and customer feedback so the rest of your team will understand the reasoning behind the change.
When you’re sharing an MVP or MVP learnings with other teams, try to:
Eradicate any product-specific lingo
Showcase how your changes align with company-wide goals
Show how you’re prioritizing the customer
Why is customer feedback so integral for the MVP process?
Customer insight is priceless to product teams who are deciding how to build and iterate on an MVP.
For example, you might build a feature based on common requests from customer feedback surveys. Once your MVP is out in the wild, use tools that enable you to watch how users respond to it and solicit continual feedback to improve your product. (Keep reading to learn how!)
Chameleon is currently building a new product and is embracing an MVP strategy to give it the best possible chance of success. The PM team has mapped out many features they believe the product should have, but they haven't set the priority for building those features, and haven't clarified at what point the product will be viable enough to release.
Pulkit explains the reason for this is the importance of using customer data to inform the direction the MVP takes:
“One of the features we were unsure of how to prioritize was audience segmentation. The MVP could launch without the audience segmentation feature. However, our customer interviews have informed our process; actually, audience segmentation is a really high priority for customers. Therefore, it’s now within scope for the MVP.”
Pro tip: use customer feedback to inform the development of your MVP, but learn how to say ‘no’ diplomatically.
As we’ve made clear in this article: you shouldn’t decide what to include in your MVP in a vacuum and should put the question to your users. But you also shouldn’t do everything your users tell you to—that would be impossible, and maybe even undesirable (after all, your users aren’t developers).
Product managers can feel pressured to accept every request, but the goal is to delight your customers, not to fulfill every request or say ‘yes’ to every idea. Drive results and efficiencies (not to mention profitability) by saying 'no' more frequently.
It’s important not to become an internal blocker and remain open to new requests, but saying ‘no’ helps you prioritize without distraction.
How Hotjar helps product management teams with MVPs
Hotjar's product experience insights tools help product teams validate ideas and hypotheses through user insights and customer feedback.
When you thread Hotjar tools into your minimum viable product workflow, you can use a collection of quantitative and qualitative data to make better product-led decisions. Here’s how:
1. Heatmaps: for visualizing user behavior
Heatmaps are great for seeing what users are attracted to and spotting what they’re missing. If you’re ever unsure of a product iteration, it’s worth releasing two versions and A/B testing using heatmaps.
With heatmaps, you’ll also be able to compare product usage across devices to identify any blockers or pain points for a particular segment.
Collect and analyze your heatmap data and continue to iterate on your product, so users can make the most of all its features and not hit any roadblocks that may lead to churn.
2. Session Recordings: for getting in the user’s shoes
Session recordings are a fantastic way to understand exactly what your users are experiencing and how they’re navigating your MVP. Recordings help your product team understand product interactions by user segments.
For example, if you have a hypothesis about why a particular user segment is dropping off or missing a feature, you can dive into the details with recordings and identify any problems, pain points, or even bugs that entire segments of users may be coming across.
From there, continue to optimize your MVP and provide the best experience possible for all users.
3. Incoming Feedback: for empathizing with users
Heatmaps and session recordings show you what users are doing in your MVP, but it's tough to understand why without hearing from the users themselves.
Hotjar’s Incoming Feedback widget gives your team immediate customer feedback on the user experience in your product, and about each element in your MVP. You can identify pages and features within your MVP that need attention and prioritize backlog management depending on user feedback scores.
4. Surveys: for diving deeper into user feedback
Dive even deeper into data and get some qualitative user feedback with surveys. Online surveys help you understand your users and can be used to discover:
What users like or dislike about your MVP
What users want from your full product
What your users’ goals and challenges are
How you can iterate on your MVP to give users a better experience
This forms a vital part of the continuous feedback loop we mentioned earlier as a key part of building an MVP.
A note: understandably, most product managers tend to focus on uncovering user issues when sending out surveys, but you don’t need to stop at understanding what’s holding users back. Consider implementing surveys on pages that are working really well, too. Here, you can ask users what’s working for them or uncover what they enjoy about their experience so you can bring those aspects of your product into other areas as you build upon your MVP.
Start developing your MVP with customer feedback today
An MVP is a fantastic way to get your product out there as early as possible, giving customers a chance to sample its core functionality and validate hypotheses you made to guide its creation.
The MVP approach can generate faster revenue and save you time and effort, so you don't fully develop products that don’t appeal to your customers. The feedback you generate from your MVP can be used to better prioritize ideas and resources, and help you draw a customer-centric product roadmap.
Enlighten your product team with customer feedback tools that will enable them to build better products in the future.