The difference between 'Minimum' and 'Viable' in MVP
Why it's hard to figure out and commit
People are too willing to scratch the itch of the near thing. Discipline is the difference between what you want and what you want most and what you really, really want. . . . I think people often don’t bring that kind of rigor to whatever it is, if it’s important. Because they’d rather make lots of little tiny decisions than a few big ones.
Sam Hinkie, ex-GM of the Philadelphia 76’ers
I think about this quote all the time. It is hard to balance discipline and creativity. When you’re building a product, you have a lot of ideas. Your team has other ideas. You discuss. You debate. It’s fun, intense, and honestly the best part of product development.
Rather quickly, you have a long list of features. Some are clear must-haves, some are on the fence, and the rest are for some other day (aka not gonna happen).
The next question is, “what’s our Minimum Viable Product (MVP)?” I am willing to bet that 99% of MVPs are actually too broad in scope, and not actually MVPs. Especially at big companies, where you have multiple stakeholders, your MVP is going to become bloated. At startups you have the opposite issue - you build the wrong thing off of your gut or some quick research, and you build it fast, but you build the wrong thing.
Finding and Testing Your Hypothesis
The perfect MVP depends on the hypothesis. You need to be really clear on what you want to answer. This is the structure for creating your hypothesis:
I believe users have problem X
Today they do Y to address the problem
Hypothesis: I believe users would do Z to solve problem X
If you don’t know the problem or how it’s being addressed, then focus on that. Once you know, you’ll have ideas on how to solve the problem. That forms your hypothesis. That’s literally it - I’ve seen so much advice in this category but there’s no need to overcomplicate it.
Once you have your hypothesis, there are a few ways you can validate it:
Describe the idea to somebody
Create wireframes that show a concept, and interview your target users
Create clickable wireframes (use Sketch)
Repeat 1-3 and update your ideas
Write down your conclusions, and then build that
Every PM knows this, and I know the majority of you don’t follow this. There’s always an excuse i.e. “we don’t have time to go through this,” “we’re very confident in the plan,” “there’s similar products in market,” etc. Often times we just skip to step five.
That’s fine too - a lot of times, you just can’t do it the right way. The problem, however, is that even with research/validation/etc., people come to the wrong conclusions and overbuild.
Overbuilding is a waste of time, makes you attached to features you don’t need, and disconnects you from the user and market. If you value speed or efficiency, then overbuilding is one of the worst things you can do.
How to Avoid Overbuilding: Focus on the ‘M’ , not the ‘V’
There’s a really simple way to always build good MVPs. It involves focusing almost entirely on the Minimum part and excluding the Viable i.e. going bottom-up. Don’t fall into the trap of focusing on Viable over Minimum i.e. top-down.
For example, let’s say you want to build a TikTok competitor. What makes TikTok good? Vertical, short-form video, video creation, challenges, ForYouPage, easy sharing, video reactions, algorithm. If you want to compete with TikTok, you might say that you need a vertical video feed + video creation tool. Well how do you decide what videos to show? Ok, so you need some algorithm too. And you can’t just be a TikTok clone, so you need some new killer feature i.e. new way of capturing or editing video. You can cut out challenges, sharing, reacts, add some of the new stuff, and you have your MVP.
Except that’s a waste of time. What’s the hypothesis? That a new way of capturing/editing video will be engaging. “I believe that with this new video creation tool, users will create video more easily.” All the other good stuff like sharing, video discovery, etc. flows from there. So at minimum, you need to test whether people will use your creation tool. And specifically, you don’t need to build the tool. You just need to fake the effect or take some photos and edit the before/after, and test that flow. You could even do it with slides.
In my experience, it’s always harder but more useful to focus on the Minimum over Viable. Focusing on the Minimum forces you to be disciplined on what you need and what you don’t. You can just list the different pages/actions and go through them and decide if the app could work without it or not. Some features are paired i.e. if you have a search, then you need some kind of profile/object in the result, otherwise what are you searching for? A lot of things are needed for a viable product, but there’s less needed to test a hypothesis. Focusing on the Minimum allows you to be disciplined and do as little as possible to test your hypotheses.
Making it Work at Work
This all might seem obvious, but if you’ve done product development, you know it’s way harder to do in real life. In a company with multiple stakeholders, you are going to sound stupid if you have a UX Designer, UX Researcher, Three Engineers, and your proposal is to do very little with a few slides and just iterate for weeks or months. The engineers will want to get a head start on development, the designer will think about user needs and explore mocks, and the researcher will help with research but also want to do foundational work to find user needs. And if you spend three months just making slides and testing ideas, at the end of the quarter your Director will expect to see more output from a six person team.
The way to address this is to get real buy-in from the team. Nobody wants to waste time or build a bad product. If people have different goals or thoughts on how to build the product, you’re going to struggle. So, at the beginning, get everyone in your work group and your bosses committed to testing hypotheses and focusing on the Minimum in MVP. By setting expectations, you can move faster and not feel pressured to over-build or “show impact” too early. The downside of this is that you might get less resources or a smaller team, but that’s a good thing IMO. Headcount is a trap - the more you get, the more you have to deliver. Better to be a small team that is progressing fast and building the right thing.
Would love to hear other people’s thoughts and experiences. Please comment below and subscribe to the newsletter!