Build, measure, learn. Ship small, fast and often. Don’t spend months building an intricate, feature-packed product that hasn’t been tested. These are the obvious principles to follow when building Minimum Viable Products.
This article explores the less obvious mistakes that happen when building MVPs. They can happen when we only think about the obvious do’s and don’ts of Lean. The goal of Lean is to maximize learnings relative to time and resource investment. However, we may misinterpret the word “lean” literally, as in, the goal of ‘lean’ is to hack features together with little to no resources. Unless the hackiness of features improves the pace of learning, we might think we are following lean when we are, in reality, straying from the path.
Here are three unintuitive mistakes that you can make when you’re following the Lean process but are losing sight of learning objectives.
Building Too Small
When we think of Lean, we think of tiny, low-cost, hacky features. While building simple, low-tech MVPs is usually a fast way to achieve learnings, it’s also possible to de-scope MVPs to a point where an experiment fails to validate the product.
If you’re finding yourself scoping out the product from the product, you might not get the right level of feedback needed to evaluate its core value hypothesis. For example, if you build a landing page with a fake sign up process, this is a useful way to gauge demand. But it’s not the same as a fully-functioning, working product, and it might not validate whether users will actually use the product. Users might like the idea of the product, but fail to use it in practice.
In the above example, the landing page tests demand, when the question we need to validate is whether users adopt the product. If the learning goals aren’t precise, building smaller won’t be more efficient than building bigger or building nothing. Moreover, running too many small tests over and over can incur unnecessary resource costs, especially when they fail to produce impactful learnings.
Cutting Too Many Corners Because “It’s an MVP”
We’ve all heard someone say “we don’t need to think about this right now, it’s an MVP.” In other words: “Let’s not get mired in the details, let’s just build something quick and ship.”
When the goal is shipping fast is to learn, it makes sense to ignore the fluff and accept some less-than-ideal user experiences. However, if the learning goals are lost in the process of cutting corners, there are instances where ignoring the details can hurt the success of the experiment.
If you’re launching a novel product, but the onboarding to the product is poorly executed, users might not end up getting to the point where they can experience the value of that product. You might conclude, erroneously, that users did not want to use the product, when in reality they weren’t able to access value. Or, you might have to adapt the MVP and run it again with a better UX. In either case, cutting corners to ship fast isn’t efficient: Shipping a hacky feature at the expense of learning is slower than shipping a slightly more detailed product that generates better learnings.
Building an MVP Without Validating the Need for an MVP
The MVP is better than spending months waterfall-building an untested, feature-packed product, but it isn’t always the cheapest or fastest way to validate a new product idea. Minimum Viable Products are still full products, and they’re not going to be free.
It’s easy to come up with an awesome vision, and declare that your next step is to build an MVP to test it out in the real world. But, there are other things that you should validate first, like: “Is my product solving a problem that users actually have?” or “Is there demand for this type of solution?”
There are many types of low-cost, pre-MVP prototypes that can be built in order to produce early feedback. One of my favorites is simply showing low-fidelity mockups to potential users. It’s super cheap and fast, and can inform how to shape an MVP. You might find that the problem your product intends to solve is actually not top-of-mind for users. Avoiding an unnecessary MVP saves time and resources, and increases the rate of learning relative to investment.
Wrapping Up
If there is one sentence to remember about Minimum Viable Products, it’s that the goal is to maximize learnings relative to time and resource investment. Without keeping this ratio favorable to learnings, these kinds of mistakes can happen:
- If an MVP is too minimal, product validation can be inconclusive, or even fail. You might not be testing the product, but the demand for the product, or the idea of the product.
- If an MVP is built sloppy for the sake of speed, then it might not be usable enough to achieve product validation. In this case, you are shipping, not learning.
- Some learnings are best collected without building a full MVP. Minimum Viable Products are not free, and may not be necessary if you still need to validate core assumptions about customers, markets, and whether your MVP addresses real customer needs.
Bottom line: If you focus on reducing time investment without keeping in mind the learning implications, you might find that you ship faster, but learn at a slower pace!