“If your product is a swiss army knife,” the workshop leader told us, “then your MVP is this simple pocket knife.” No, I thought, it should be a neolithic hand axe. How do you even know anyone wants to cut things?
MVP, or minimum viable product, is a tool presented in Eric Reis’s The Lean Startup. Lean is a product philosophy designed to continuously ensure that a software team is building the right thing, something people want and will pay for. It’s a key part of the philosophy we at Pivotal try to instill in our clients.
Many of our client companies are somewhere in the middle of their lean/agile transformation. Most of them still have a long way to go, but all of them have begun to adopt much of the lean terminology. The problem with that is that it often inoculates them from some of the key principles. The MVP may be the best example of this.
LinkedIn founder Reid Hoffman famously said, “If you are not embarrassed by the first version of your product, you’ve launched too late.” This, to me, perfectly sums up the ethos of the MVP. The point is to launch your product ludicrously early so as to begin testing/de-risking it long before you expect it to be making real money. The problem is, that is often not at all how big corporations see it; they want their first release to be fully functional.
Like so many other lean product or agile development tools, that of MVP tends to get warped somewhere between a company’s first lean/agile workshop and the actual on-the-ground practice of that company’s software teams.
More than a couple times I seen enterprise releases labeled “MVP” that are large, fully-functional versions of the product (crammed full of invalidated assumptions). After marinating for months in corporate culture, MVP becomes MVBP, minimum viable beautiful product, or MVPTICSMB, minimum viable product that I’m comfortable showing my boss. Really, it becomes a euphemism for “Release 1.0.”
In my most recent engagement at Pivotal Labs—building an app to sell insurance online—we saw this as a risk. We decided not to wrestle over the meaning of MVP (“Hey I know you all think that means this but it actually means this…”). Instead, we coined a new term: SVP, the “shoddiest viable product.”
Language is powerful; the client didn’t know what SVP meant, and it allowed us to control its meaning. We freed ourselves from any prior baggage or expectations for MVP.
Our implicit attitude became, ‘worry about the MVP later, first let’s focus on getting an SVP out the door as soon as humanly possible.’ We designed an SVP that (like any good real MVP) was not designed to solve all of our users’ problems, but rather to test our key product assumptions. Users were taken through just a couple screens where they entered personal information, then were handed off to a call center rep to get a price and bind their policy.
We launched after only 28 days of active development (shattering records at the client company) and began learning from real user data immediately. The product had no required form fields, no real error messaging, no “go back” function, no ability to “save for later,” used month-old data, only worked during business hours, and didn’t even quote a price. It was like that scene in THE MARTIAN where he rips everything out of his spaceship not absolutely crucial for flying.
But launching allowed us to quickly validate one of our riskiest assumptions: would users start a purchase online and then segue to working with a human? With a fully automated system close to a year away, we needed to know fast whether a hybrid system would work. We learned that it would (but if users had hated our flow we would have wasted minimal time). This gigantic corporation was now releasing daily and iterating on a live product six weeks in for the first time ever.
The client was thrilled. I don’t think any of the team members we worked with will ever again start a project without a firm focus on the SVP. And neither will I.
But let’s be very clear: SVP is the result of a public-relations makeover. I love SVP not because it is a novel idea (it isn’t), but because it is a terrific rebranding suited for enterprise clients. On our team, it brought the freshness back to the original concept, freed us from the corporate powerpoint definition, and reminded us that our job was to publish the shoddiest possible piece of software that allowed any subset of users to show us their real preferences and behaviors. Our job was to learn lightning fast, not to publish a polished product.
Reinventing our language allowed us to return to the original, daring ethos of lean product development. Next time I face terminological whitewashing I will waste no time in making up a brand new phrase.
MVP needed a new publicist. We superglued the “shoddiness” element of the SVP (Hoffman’s embarrassment factor) inextricably to the term so that (hopefully) it can never bloat to the same extent as its older and more prestigious cousin. But if it does, we’ll be ready to make up yet another new term. And if you’re wondering if we use a different s-word when we’re alone as a team — yes we do.
See Part 2 of this post:
Part 2: The SVP in Flight. Does “Shoddy” Mean Poor Quality?
Note: Since coining the term “SVP,” I have become aware of a similar concept invented by Rik Higham. Read about it here.
SVP: The Shoddiest Viable Product was originally published in Built to Adapt on Medium, where people are continuing the conversation by highlighting and responding to this story.
