Many clients express frustration with minimum viable product, MVP—a notion from Lean Startup that describes a version of a new product a team can use to learn the most while exerting the least effort. But to some teams MVP means mediocre designs launched every few weeks. This doesn’t seem to be in the spirit of what Eric Reese meant when he defined MVP.
And, it is disregarding what we have learned about software engineering. Something transformative was looming in the early 2000’s. Soon, like an edict from above, Lean Startup, Scrum, and Agile enthusiasm focused companies on MVP.
The millions of startups out there needed some guidance, and a startup MVP made a lot of sense. A small team with little money, no customers, and investors who scrutinized their every move meant each build needed to show viability of the idea and the team’s ability to execute on it. In other words, every iteration had to do something.
But many of the organizations that use MVP today don't need to do this, and in fact focusing on MVP is counter-productive. Their goal is to have great software in the end, not to prove something every two weeks. Related, the most extreme, conservative Lean followers consider any form of prototype to be waste and prefer to go straight to code.
In 1991 when I began working in software design a common process was this: designers wrote a long spec, developers coded to meet that spec, QA found bugs in the product build, developers fixed the bugs and we shipped. Then we learned about user issues from customer feedback and lost or gained sales. But, after repeated experiences re-doing design and code, giving customers a terrible first impression, investing much effort and convincing people to change working software, losing money and time, learning about usability issues way too late to do anything about them, and pummeling employee morale -- we learned that we could create different kinds of prototypes and use them to communicate and debate with our colleagues and also as the subject for behavioral usability testing with potential customers.
We learned that we could test early and that it was much easier and cheaper to rip up a paper prototype than it was to rip out hundreds of lines of code. We learned that by treating every design like a hypothesis we could raise the quality of that design and prove its value proposition. True iterative design was born and soon it was done not only at rich and enlightened tech companies -- financial institutions, government agencies, name the industry: iterative design was happening there.
So there are many issues with MVP and a few of the most common problems are these: There is no usability testing at all, or it’s done on the live product. This means that paying customers, and ones who are vocal on social media, are using poor designs. The MVP is not representative of what the design is planned to be.
Getting user feedback on a tent when the ultimate product will be a mansion will usually not be be very helpful. Each MVP is highly focused on a small set of features rather than a whole product. So, when they are all put together, there is great variation and no cohesiveness to the design.
Teams never change the MVP, even if there are severe user issues. It feels to me like in some ways we have fallen back in time and have forgotten what we learned about successfully integrating UX in software development. Today, if you work in an MVP-driven world that happens to be unproductive for your team, try to redefine what "minimum viable" means to you.
Consider suggesting that it be researched and made to be most realistic, useful, usable, and engaging before it goes live and reaches a paying customer.
