The term “Minimum Viable Product” has been around for so long that it is now a cliche. If you aren’t writing a post on how the startup framework stinks, you’re writing about how you’ve improved upon it.
Take, for example, this post by the very talented Robleh Jama of Tiny Hearts. The app studio founder desires to pass along some great advice to aspiring creators what he has learned along the way to four stellar launches. The part that stood out to me, however, was this statement about how to define the scope of your release:
“Make sure your app has maximum desirability, viability and feasibility, especially for version 1. That’s MDVFP.” He ends the paragraph with the statement, “MDVFP is the new MVP!”
So the problem, it would seem, Jama has with MVP is the Viable part. I noticed at least once or twice a month in 2013, as writers were keen on attacking the theory Eric Ries made popular in his book Lean Startup. Most of the posts, as is the case with Jama’s, agree that you shouldn’t try to bite off more than you can chew at once. You take an idea, spit-polish it to perfection, and let the world tell you how you did.
The interesting part of Jama’s MDVFP is the extra letters. Instead of a product simply being considered “viable”, he also includes desirability and feasibility to the equation. The acronym is taken from this document on human-centered design, a concept that being investigated and tested by the mobile development community today. For a product to follow HCD axioms, it must be extremely desirable, technically feasible, and financially viable to be put into production.
What I am confused by is why aren’t these concepts already part of an MVP design? How in the world could someone follow The Lean Startup get their company off the ground if they didn’t take desirability into consideration? Wouldn’t they have done research into the technical capability of creating their viable idea before pitching it?
Viable is being ripped to shreds because people want to play the semantics game with the word. If I had a dollar for every time a developer told me they disagreed with the concept of MVP, I would at least be able to treat my wife to dinner. Instead of focusing on the intent of the term and using it as a framework instead of instructions, I think more would understand that “viable” pretty much covers everything else you think it doesn’t.
The definition many often forget is the original. Minimum Viable Product is nothing more than, “…a version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
Do the smallest amount of work needed to get the most learning done. If you work in client services like me, that may include a bit more work than you would if you were building for yourself. Either way, you have a conversation around what is needed and go build it. If you can combine that with the agile principle of making decisions as late in the release cycle as possible, you have something going.
If the term itself bothers you, there’s nothing wrong with coming up with your own twist. Ryan Hoover called his Minimum Viable Experiment. Roman Pichler likes Minimal Marketable Product. Startup Blender prefers Minimum Delightful Product. It does on and on. The problem occurs when you try to point how your term is different than the original. The reason why Ries and that term has stuck around for so long is because it is generic enough to cover most of the others.
If it’s viable, it’s marketable, delightful, and so much more.
I prefer blogs like David Aycan’s post on HBR about the most important letter in MVP. In it, he doesn’t concern himself with the consternation over the term “viable”. Instead, he focuses his energy on not getting to minimalistic with your work and instead worrying about whether it’s viable or not.
Part of me thinks that advice is more relevant than ever. Stop trying to coin your own term. Instead, focus on making viable happen.
One thought on “Blog Post: Can We Stop Being So Literal With ‘Viable’ Please?”
It’s been an interesting experience here at my company as re develop our “MVP” Windows Reader app. The focus, from our snart and experienced CEO and CTO, has always been on creating a viable Beta product that can be shared with users and potential customers as a way of gathering feedback on the key aspects of the app that we get right or wrong. It’s been pretty fascinating to see how far that takes us – our MVP is, by necessity, very full-featured (else we would be overwhelmed with negative feedback).
The focus needs to be on “Viable” rather than “Least”, at least in our case.
MVP is one of those terms, like Agile, that has been different at each company I’ve worked at and which is sometimes different from project to project.