MVPs are there to get the information you need to build out a full product, as well as to start building an audience and developing some marketplace traction. In the words of startup pioneer Eric Ries:
‘What separates MVPs from traditional market research is that it is a deliberate experimentation approach based in customer behavior, not opinion. MVPs are designed so that the customer takes some action and exchanges something of importance that need not be monetary — such as time, space, or other resources.’
MVPs are also a chance for businesses to iterate and improve their processes for building and launching products.
MVP build and launch come in three stages: Preparation, build, and launch. Then you iterate.
In this post, we’ll look at those three stages and cover what you need to be successful at each, starting at the beginning with preparation.
Stage 1: Preparation
Identify how the product meets a specific need
It’s vital to start by making sure you know that your product will meet a known, specific need.
In some cases, you’ll have knowledge that there’s a market actively calling for your product. You might operate in a space where the deficiency of the current toolkit is evident to all, and managers and executives regularly ask for recommendations for a product that does X. Or you might be a startup working with an established corporate entity that already has tons of data on the market for the product.
If you’re not in either of these positions, get solid answers to these questions:
- What’s the problem or opportunity?
- Whose problem or opportunity is it?
- How much do they care about it?
- How much say do they have in it?
- How much money do they have to spend on it?
- How many of them are there?
- Is it legal?
- Who’s already doing it?
Obviously, some of these answers will be slightly vague. You’re not going to know there are 32,546 people out there who care about the problem and they have $2.68 each to spend on it. But you can ballpark the information to a level where it’s useful to make decisions with. Answer all these and you’ll have a better understanding of your market than most companies that launch a new product.
That matters. Here’s why most new products, and the businesses that create them, fail:
Answering the questions outlined above won’t raise you any more money. But it will give you clarity on market, regulatory and legal issues, competition, and pricing. Together those factors kill 88% of new products. Lay a solid foundation of understanding and yours won’t be one of them. Your MVP is part of that foundation-laying process, but you need to do some minimum viable product research too.
Create a product strategy
A product strategy is a high-level plan for what your product aims to achieve and how it plans to do it. Product strategy should take the insights and understanding you gained from answering the questions in the section above, and turn them into a strategy that you can orient the whole organization around.
This should include:
- End goals for the user. What do they want out of your MVP?
- User flows. How will users move through your MVP?
- Marketing strategy. How will you reach your intended users?
- Data strategy. How will you acquire user data, how will you analyze it, and how will you feed the resultant insights upstream?
Create a product roadmap
A product roadmap lays out the route to launch and beyond. Just like the roadmap you’d want if you were driving through unfamiliar territory, it attempts to tell you where to go, sets out expected times of arrival at landmarks, and seeks to warn of hidden dangers.
This is where you address issues like features and prioritization, establishing urgency and importance. MVPs should test just what’s urgent and important.
Read more about how to create a comprehensive product roadmap here.
Throw as much as possible away
For MVPs, this really can’t be overemphasized. The tendency to build a product that has everything everyone thinks might be a good idea always has to be resisted. An MVP should be fast and cheap to build — as fast and cheap as is compatible with its goals. From the list of features your users might want, or your team might believe in, you have to ruthlessly discard everything you can possibly do without.
Stage 2: Build
Check the roadmap and strategy — these should be living documents that respond as you plan and build
MVP roadmaps and strategies aren’t made once and then used as guides forever. Instead, they constantly interact with the process of creating the MVP and launching it. For example, suppose your roadmap calls for a feature that turns out to be prohibitively expensive. Should you build it anyway? Or should you reorient your efforts, reducing expenditure and improving outcomes? The answer is obvious, but legacy product development processes don’t make sufficient allowances for these events. You should start responding to data from the development process, even before your first MVP iteration is complete, and seek to create documents you can continue to use as guides after the first iteration. To learn more about MVP iterations and the importance of launching early, read this blog post.
Use judgment to cut the right corners
Building an MVP doesn’t have to mean writing every line of clean, shippable code from scratch. In fact, it never does. The best developers rely on code libraries when they build from the ground up, and MVPs can be made from products and tools that already exist. It’s about matching speed with function and budget.
However, this requires judgment. Some great MVPs are built from a hodge-podge of already-existing tools. If the main purpose is to test the product’s functionality on its intended audience, they don’t care how it works. Some MVPs are built with no-code tools or on staging platforms. That’s fine. But it can also sometimes cause more problems than it solves. Assessing the requirements of the MVP and matching them to the fastest, lowest-commitment toolkit that doesn’t also come with undesirable side effects is a task for experienced development professionals.
Stage 3: Launch
Marketing your MVP launch
You should already know who your intended users are, and research at the strategy stage should prepare your team to market your MVP. You should have identified the correct channels to reach your target audience, and have developed messaging that communicates your product’s value to them.
For many new products, a website that collects email addresses, then offers free access in return for feedback, is an excellent approach. But just because it’s what everyone else does, doesn’t mean it’s the right approach for your MVP. It has some data problems too. (The problem with surveys is, they’re only ever answered by the kinds of people who answer surveys. Same with website signups.)
Consider other ways of successfully approaching your users, from partnering with companies that already serve them to innovative approaches like LinkedIn’s conversational ads. Make your criterion: which approach would be best for the full version of our product?
Collecting user feedback
The whole point of an MVP is to gather feedback. You should be doing this internally, identifying ticking points, difficulties and stages of production where you encountered unexpected problems (or successes). But the main goal is to get usable data from customers. Some of that will be in the form of feedback. Some will be as usage data or observational data from test users. Every approach to gathering user data is a compromise that comes with its own drawbacks.
The best solution is to use the gold standard in each category of data. For quantitative user data (quantitative data is data you can put numbers to, essentially), you can’t beat usage data collected from inside the product itself. That will tell you how many times people logged on, used a feature, gave up halfway through because your user flow was confusing… all vital knowledge to iterate on.
For qualitative data (how good was it?) user interviews are excellent. Get some from departing users if you can, ask open-ended questions, and let real conversations develop. A talk with a customer is worth more than a survey. They might make a passing comment that changes the whole way you view your product, or tell you what everyone they work with is saying about it.
Where practical, you should also consider user recordings. What people do and what they say they do are usually different; user recordings let you see real behavior in real time. For improving user interfaces and experiences, they’re irreplaceable. Read more about how to gather user insight on your MVP in this post.
Your first-draft MVP should show you where some of the problems in your product are. You might find only minor issues. You might find that your market is interested in your product for different reasons than you thought — that you’re primarily seen as a file-sharing tool although you envisaged a future as a chat app. Or you might find that you have new, crucial information about how to structure your backend and codebase to best support your functionality; every important decision isn’t about product-market fit.
Whatever the case, MVPs shouldn’t be one-and-done. You should iterate the main product. The second draft of an MVP is often when startups get some code written for the first time, especially if the founders don’t have a development background. You should ‘MVP-ise’ the process of introducing new features too, going back to the drawing board of market need and user targeting and building minimum versions of new features before dialing them into user requirements.
The MVP Checklist
- Identify the market need. Be as clear and specific as possible about who, what, where, when and why
- Check for legal and regulatory issues
- Survey the space and identify current or future competitors
- Create a product strategy, including:
- End goals for users
- Data strategy
- User flows
- Marketing strategy
- Create a product roadmap including features, urgency, and estimated timing for the development and release process
- Refine and condense. What can you leave out?
- Identify the right tools to build your MVP
- Assemble an appropriate team, including outside expertise where necessary
- Identify the right channels to reach your audience
- Market your launch in advance
- Collect quantitative (how much?) and qualitative (how good?) user feedback
- Feed data back upstream
- Reorient strategy and roadmap to reflect
- Plan features for new iteration
Consider using this checklist for new features as you build out your product or iterate your MVP.
How AndPlus can help
At AndPlus, we’ve helped startups and established enterprises build MVPs for a range of industries. We offer standalone services for specific sections of the MVP process, such as our roadmapping service. But we can also act as partners throughout, supplying expertise, staff to fulfill specific roles, or as your tech department handling building and testing.
Here are some of our success stories:
- Medica blood gas analysis application
- Allerton/Honeywell BACnet mobile app
- Cognex sales enablement tool for iPad
- Research before you plan, plan before you build.
- Launch then iterate.
- Constantly feed data back upstream, react to changes quickly to reduce wasted effort.
- The right match with readymade tools and/or custom code matters.
- MVPs should deliver data you can derive insights from. That can be user data or internal data on the process of building and launch.
- Iterate frequently. Shorter iteration cycles mean more opportunities to correct mistakes and include insights.