- How do I balance minimum and viable?
- Won’t our customers be disappointed with a product that doesn’t work?
- Isn’t an MVP about building the most basic thing we possibly can?
In a nutshell the way to address these questions and move forward with your MVP is to remember that the primary goal, the main objective, is to validate a hypothesis — or to get learning. In this post, we’ll answer each of these questions and explain how it’s done.
How do I balance minimum and viable?
Let’s say you want to learn whether X is true. For your MVP, viable means your product will help you learn if X true. If it does that job well — if you can trust the data, then it’s viable. An MVP is minimum if it lets you learn whether X is true for the least cost.
Try to forget about striking the right balance. Make sure your product is both minimum and viable according to those two criteria. Define what you want to learn, determine the least expensive way to learn that, then double check that the MVP you came up with will let you collect valid data.
Give careful consideration to the trade off between minimal investment and the need for quality data (the stuff where learning comes from). If you get skewed data because your product was minimal in a way that affected your target market’s ability to relate to your product vision correctly, then your MVP wasn’t really viable — it was waste.
Won’t our customers be disappointed with a product that doesn’t work?
What customers? Seriously, even if you’re fortunate enough to have lots of customers, it should be extremely rare that the only way to get validated learning is by building out a functional product that has the potential to disappoint all of your customers.
If you’re working on your very first product starting from the ground up, then you don’t have any customers. And your goal should be to prove that your product vision is marketable. Come up with a value proposition, then learn if your target market sees value they think is worth paying for. Developing a functional product at this stage of learning isn’t wise. And you’ll probably iterate several times on the marketability of your idea, pivoting a time or two before you’re ready to build something truly interactive.
If you’ve got customers and you’re working on a new product or feature for them, your MVP might be as simple as sending them an email with a mockup of your idea and survey to get their feedback. Or try the deploy first, code later approach. Add a button or link to your feature, then track clicks to gauge customer interest. Your customers might even feel special that they get an inside peek at product development. And they’ll be reassured you’re working on new and exciting ideas. If you don’t want your customers to see it, try running a remote online usability study with people in your target market. Put your mockups in front of them, give them your value proposition, and see what they say.
Isn’t an MVP about building the most basic thing we possibly can?
In one sense it is about building the most basic thing you can learn from — because an MVP is all about learning what to build. But that approach is far too simplistic, and frankly a very bad way to build an MVP.
You need to build something that lets you collect validated learning. The functional pieces of your product are probably the most expensive things to build. So it makes sense to skip a lot, if not all of that development in your first MVP. You can get valided learning as long as the users are able to relate to your product vision — for better or worse. That means a non-functional or semi-functional MVP should embody a very advanced representation of the value your product has to offer — even if what it has to offer doesn’t work yet. If the users can understand the promised value, you’ll be able to get a very good idea of what they think of it.
Things to avoid:
- Don’t be unprofessional – If your product is so ugly people hate it before they know what it does, you don’t have a viable product.
- Don’t forget to sell your vision – If your vision is so poorly represented that people can’t perceive the value, you don’t have a viable product.
- Don’t make it hard for users to tell you what they think – If a bad user experience prevents a person from contributing to the data you want to collect, you don’t have a viable product.
Things to consider:
- Do a smoke test – Develop a landing page for your non-functional product. Make it seem seem like a legit product — it’s often far less expensive than a semi-functional version with an unprofessional image (and it’s usually a better way to assess marketability). You’ll be amazed at what gems of learning you can get for very little investment. Your first semi-functional version will be much better off for it.
- Describe your product vision beyond it’s functionality – Describe what your product is supposed to do eventually. Use very concise, conversational English. Put your value proposition in a prominent place, list key features, and explain in simple terms how it works. Words are cheap compared to developing a functional product. Do this right, and people will relate to your vision — and be able to give you valuable feedback.
- Measure with surveys – Link your MVP to a survey designed to measure user sentiment about your product vision. You’ll get a good sense for what people expect from your product before you invest in more expensive functionality.
Summary Tips for Your First MVP
- Establish a value proposition that communicates your product vision well.
- Formulate a hypothesis like this: “My target market is willing to pay for a product that provides my value proposition”
- Build an MVP that proves or disproves your hypothesis for the least cost.
Bonus tip: Consider testing marketability by running a smoke test. That is, build a product web page instead of the product itself. Then drive traffic to it using search advertising to collect data. It’s often far less expensive than building a functional product, yet provides copious amounts of learning in the early stages.Beginner's Guide to Minimum Viable Products by Brian Lehmer