On the human MVP
A couple of weeks ago, I became a second time dad. The baby girl is healthy as one can be, and - like all babies - happiest when well fed. My son is almost three years old, and he asked me if he could give the baby part of his banana. He figured that if he liked it, she might like it, too. But I had to tell him his sister doesn’t really do well on bananas. Turns out newborn babies don’t do well on anything other than milk. Oh, and also they can’t walk. Or talk. Or communicate other than by crying, apparently. They’re basically only good for turning milk into poop and fat. But they’ve got potential.
A Minimum Viable Product
According to Wikipedia, a Minimum Viable Product is a product with just enough features to satisfy early customers, and to provide feedback for future product development. An MVP doesn’t do much yet, and it’s definitely not developed enough to be considered mature.
The human MVP really isn’t that great. I mean, the basics are there: the arms, legs, a digestive system and so forth - but most parts are not even functioning properly yet, or at least not to their full potential. Not to mention a human MVP is tiny: human babies are about one third the size of a full-grown human! It’s portable, sure. But it won’t really help in reaching the top shelf now will it?
All this baby talk got me thinking on how MVP’s are thought of in software development land. An MVP should be exactly that: a Minimum Viable Product. Not a full-blown product in which a couple of nice-to-haves are left out. That’s not an MVP or even an Agile way of working - that’s building a product via Waterfall methodologies with a couple of beta-releases to satisfy stakeholders.
Not that there’s anything wrong with that. Especially when rebuilding existing applications for technical reasons, a waterfall approach might be the way to go. Although you might be missing out on some benefits of building an MVP first:
1. By building an MVP you get to improve the User Experience for your users.
You might’ve done user research before you started building. You might even have shown UI prototypes to potential users and gathered feedback. There’s even a probable chance that feedback was positive.
However, nothing compares to having users actually trying to accomplish something in your product, because nothing is ever as good as its design looks. This is equally dangerous and insightful, because users might get frustrated. They might not be able to find what they’re looking for, or not be able to accomplish the task they’ve set out to do. You might even lose a couple of users that give up or don’t agree with your choices. Making them feel heard, and focusing on turnaround time might help you keep those users on-board even if their experience with your product wasn’t that positive.
Most importantly, when users try your product, you can measure what they’re trying to achieve. See what menu options they’re using. See what sections they visit, and what features they use - and watch how they get there! Follow the path your users take, and how long it takes them to get where they want to be. This allows you to tune the navigation and interface of your product to the paths they follow, ultimately resulting in a better experience for your users.
2. Building an MVP prevents building unnecessary features.
A lot of preparation goes into building a product. Focused, knowledgeable people in your company will have great ideas on how to improve a product, or what features are essential. The CEO probably has a great idea, too, and Sales might have a couple of prospects they can haul in if one or two features are added.
Your products are not built for your Sales Consultants nor your CEO. Your products are not even built for the vocal minority of your customers, nor for a couple of high-potential prospects. You’re building a product that makes end users happy. And most of them aren’t yelling their requests at you or your team - they show their intents by (not) using features in your application. By ruthlessly focusing on your end users' needs, your product will be the most effective - and thus add the most value for the company.
Pro Tip: The dummy button method
A great way to find out if a product feature is in high demand for all your users is the dummy button method.
- Place a button in the location where this potential feature would end up.
- When clicked, the button only shows a form asking users why then want this feature..
- Add telemetry to monitor how often (if at all) the button is clicked. This shows user intent, even if users don’t feel like submitting the feedback form.
- After an X amount of time, decide on whether or not to actually build the feature, based on input from the form and telemetry.
3. By building an MVP you get to try a new Development technique without going all-in
This one is close to my heart, as I’ve experienced this first-hand. The team and I were building a product, and we had a set of features mapped out to develop. After some research, the team decided upon a certain framework to build the application with. A couple of months later, the team found that the framework didn’t fit as well as initially believed. Unfortunately, the project was setup in a way that prevented the team from pivoting to a different framework - ergo extra development time and costs.
Building an MVP first forces you to focus on building the bare essentials of your product or feature. Chances are the development team will find out pretty fast whether the chosen development direction is a good fit. If it’s not there’s still time to change direction without losing too much valuable time.
In conclusion
Building a product MVP-style is developing a product based on actual data instead of gut feel. Like a baby that tries a little bit of unknown food first and only engorges themselves if they like it. The main benefit is the same for both situations: there’s less poop to clean up after.