I think the meaning MVP has been kind of bastardized. A lot of people now use it as justification for including lots of features that have no business being in the first iteration of the product design process.
Products That Count: How so?
At Redshift, sometimes we’re approached by clients who say “We’ve come up with a set of requirements for our MVP!” In reality, it’s an enormous list of features. The implication is: we’ve thought about this and we can’t possibly eliminate any of these features from the list. When the conversation we should be having is exactly the opposite of that.
I think it comes from a misunderstanding of the term MVP. This is exacerbated by the tendency that many product managers have when they’re passionate about their product. And that would be biting off more than they can chew.
To me, the MVP is the minimum thing we can tape together that allows us to get meaningful feedback from users. So, it’s not your finished product design. It’s not your 1.0. It might not even be something that actually works. It’s whatever you can create that lets you start learning.
Why is it difficult for product design teams to stick with the “minimum” in MVP?
It’s not easy. When you create a new product, you spend hundreds of hours thinking about it, and you think about all the features it will eventually have. You have to have the grand vision otherwise you wouldn’t have started your business and raised money for it. The difficulty is that the big picture can get in your way when it’s time to find the first step. You have to cut corners and create something that represents a watered-down version of where you want to go.
We ran into the same problem at Redshift with a mobile app we created for ourselves. Despite preaching all of these practices to our clients, when it was our product, it was very difficult for us to put something in front of customers that we thought was incomplete. At every turn we thought, let’s add a little more, let’s make it a little better before we put it in front of people. The problem is: we allowed many months to go by, and that delayed key learnings we should have captured early on.
I wonder if we should propose a new and better name for MVP. When it has the word “product” in it, it suggests, “What is the 1.0 or minimum feature set I’m going to be proud of?” Instead, we really ought to be thinking, “What is the minimum testable unit, or minimum learnable entity?” The goal should be to create something that allows you to test the viability of your main hypothesis. In other words, the essence of your product.
Is there a process or framework product design teams can use to help us define a good MVP?
I think a useful thought experiment is to go through the list of features you think are essential and ask yourself, “Is there a way for me to not build this? Is there a way for me to test this product design without building this feature?” And I think in almost every case, something you think is essential is not quite essential.
I love the example of CardMunch, which was the business card scanning app acquired by LinkedIn. You’d think their MVP would have included optical character recognition, right? But the interesting question to ask is, “How would I test the viability of this business without OCR?” Well, we’d be forced to get some people to manually read and transcribe each business card, online bitcoin vanity addresses which is exactly what they did at first. So they used a little smoke and mirrors to create the illusion of a more fully featured product, and that allowed them to get customer feedback must faster than if they had tried to build the OCR technology from the beginning.
That’s a great example of brute-forcing a problem that would normally take a lot of time to solve.
Saving time is a huge part of the MVP process. Jake Knapp talks about this in his book “Sprint” where the process is to create a testable prototype in a week. I think a week is a little arbitrary, but I agree that setting a time constraint is important. Instead of asking, “What do I think is the minimum set of features,” ask yourself first, “What is the minimum amount of time that is acceptable to go without receiving some customer feedback?” Maybe that’s 4 weeks, or 8 weeks, but you should impose a time limit and make that non-negotiable. That’s a good way to force yourself to keep the MVP small because you can’t build too much in that time frame.
If you’re going to get negative feedback from users, isn’t it better to get it earlier rather than later?
Exactly! It’s normal to be afraid of embarrassing yourself in front of customers. We’re taught to fear failure so that creates a disincentive to put things in front of people. We ran into this with our own product. But good entrepreneurs don’t fear negative feedback. They want to get that feedback as early as possible. That’s why it’s important not to get distracted by trying to include too many features in your MVP. It should really be a badge of honor to say, “Look how little I was able to launch with.”
Conclusion
- Ask yourself “What is the minimum testable unit, or minimum learnable entity?” when assessing the product and its features.
- Evaluate your feature list—how would you test the product without a given feature?
- Keep your development time lean—aim to create a testable prototype in the minimum amount of time to test as early as possible to better understand your product and user behavior.