I’ve been inventing new products, software and otherwise, for a long, long time — since before minimum viable product was even a thing. And with that in my rearview, I can tell you that no matter how much experience you have, no matter how talented your team is and no matter how well you know what you’re trying to build (and why), you’re going to screw up your MVP.
It’s inevitable. I know this because I still do it.
There are certain unavoidable issues that reintroduce themselves every time we try to get an MVP distilled from the ideal, finished, complex product that exists in our heads. Time is always of the essence. Expectations for the MVP feature set are always sky-high and usually inflated, no matter how diligent we are about tamping them down.
We’re always under-resourced and over-pressurized. We always have some hard choices we need to make. And quickly. This is why you go the MVP route in the first place. You know the problem, you’ve got the solution, but there are a lot of moving parts out there in the real world.
The brass ring is out there for you to grab, you just need to build the carousel and the horse and make the thing spin.
4 Common MVP Mistakes Developers Make
- Letting the scope of the project grow too big too quickly.
- Being overconfident in how consumers will use your MVP’s features.
- Having any complexity in your MVP — at all.
- Letting miscommunication with your teammates get in the way.
The MVP Process in a Nutshell
A minimum viable product has a very specific but often misunderstood purpose. It’s not proof of the viability of the business idea, it’s not proof of concept of the solution, it’s not proof that the market for the product exists.
An MVP is an exercise in getting a billion-dollar idea distilled into a small package that you can deliver to a target market quickly, to start figuring out all the necessary elements to turn the billion-dollar idea into a billion-dollar reality.
You need to offer parts (the minimum) of the product that solve the entire problem (the viable). It’s not experimentation and it’s not an exercise in failing quickly. You throw all your resources at it, and any corners that you cut need to be behind the company curtain, such that the customer gets the full solution for the full price.
This is the MVP game. It’s not easy and it’s not for the faint of heart. And because it’s this way, there are four gotchas that you can’t ignore, because they’re baked into the endeavor. You can’t stop them from happening, you just have to figure out how to control them.
Here they are.
1. Start Smaller Than Small
In terms of scope, start small, then get smaller, then go microscopic, then reduce the scope again.
The problem becomes a problem when you start thinking, “This is so small, we can add it to the MVP feature set,” without taking into account how small things interact with the entire customer process, and branches grow more branches.
Reducing scope is easier to say than to do, because you have to solve the entire problem but do it in the lightest, fastest way possible. No bells, no whistles. You have to focus on the solution and the target market, and eliminate as much of the variability around those things as possible.
Keep the following in mind.
- Only include features that directly contribute to solving the problem. If a feature adds convenience or boosts engagement but doesn’t solve the problem, skip it.
- Scale back the usability, especially design.
- Manumate tasks that don’t have to be 100 percent automated. Hire cheap labor for automatable work. Lose money if you have to in the beginning.
- Limit your target market to the largest group for whom the solution is the most similar with the fewest outliers. If you’re selling t-shirts, start with only the most popular size and sell only them at first.
- When you can’t be 100 percent accurate in your assumptions, especially where money is involved, always favor the customer and solve the accuracy issue later.
2. Prepare for Features Working Differently Than Designed
This mistake often gets tied up with the first mistake, sometimes resulting in an exponential increase in complexity and/or costs overnight.
Just because you have an understanding of how a feature should work and how customers will adopt it doesn’t mean you’re 100 percent right. And if you’re counting on something to be 100 percent right, and it’s 99 percent right, when that 1 percent outlier happens you’re suddenly 100 percent wrong. Then you have to start adding complexity or solve the problem manually for a subset of customers.
By the way, this issue is prevalent with any and all services. So if you’re productizing a service, this is a minefield.
Customers, and even employees, will almost always find or even create loopholes to suit their needs or gain an advantage. This is usually fine with a mature product, but if you give early adopters too many options for doing something, they’ll usually do something unexpected and break user flow in a way you need to work around.
Then you’re suddenly knee deep in issue number one above. You need to account for how features and services might work, and have a plan for all the options, no matter how unlikely or bizarre.
3. Avoid Complexity Leak
If I’m building a process, method or even a feature and it starts to get complicated, I immediately start rethinking the entire process or method or feature from the beginning. In the early days of an MVP, a little complexity is too much complexity.
You should probably be flowcharting all the use cases for the MVP, not just the ideal ones. And if a use case flow starts to get complex, you might think about descoping the entire use case. In a lot of scenarios, you won’t be able to de-scope the use case and still solve the problem, so you’ll need to get creative and limit or simplify the process/method/feature itself until it’s down to just a couple steps or a couple options.
It’s hard to describe when this happens and how to fix it, so I’ll just hammer an ounce of prevention. Initial complexity quickly grows exponentially. And these days, with an overall trend towards product simplicity, especially with software, complexity kills engagement pretty quickly.
4. Limit Miscommunication
Miscommunication will happen. Misunderstandings will happen. When you’re talking about something that doesn’t exist yet, preconceived notions will pop up all over the place.
A sledgehammer solution for this that I still use: During your MVP build, get everyone involved into the same room as often as possible. When you make decisions, repeat that decision out loud and get everyone’s agreement before moving on, every time. This will be painful, but it’s super necessary in the beginning.
The first time you assume a colleague understands an idea the same way you do, they won’t.
Also understand that misunderstandings will happen regardless, and the people who misunderstand the most can be the ones who are trying the hardest. Forgiveness goes a long way during the MVP process. People will ask “dumb” questions and say “dumb” things and get caught up in the air often. Be gracious.
Be a Patient Team Leader
This is where it really pays to be a leader. When I’m doing MVP work on my own, it’s always a joy. It’s fun. I don’t mind spending my free time designing processes and methods and solving problems.
When I’m working with a team, it’s fun in the beginning, but the above four issues always arise and we make these mistakes pretty quickly. I can’t tell you how many times I’ve been scoffed at for wanting to cut important scope out of an MVP, being overcautious about the complexity of a feature or getting an eyeroll when I ask a “dumb” question.
And I’m usually the leader. Make sure you have a good one and, if it’s you, practice your patience early and often.
