While attending Project Product ‘19 in Indianapolis, Product Manager Courtney Rowe and CPO Eric Prugh asserted the idea of replacing minimum viable product (MVP) with Simple, Lovable, Complete (SLC) as a standard for product release. Because of the large number of questions and interest that arose from our discussion and PactSafe's use of the methodology, we’ve dedicated a blog post that hopefully gives our product-minded peers a better grasp on the concept.
The term minimum viable product (or “MVP”) is the lazy product manager’s best friend. For years, the term has referred to a first release of a new product with few resources, low effort, and just enough features to be usable. A common alternate phrase for MVP can be, “bare bones.” Coined by Frank Robinson in 2001, and popularized by Steven Blank and Eric Ries, MVP is the reigning methodology in software shops. Having grown from a product origin, MVP has taken over development strategies and has become a toxic concept for growing organizations.
But what is all the hype about?
A quick Google search for “MVP” returns hundreds of thousands of articles that highlight its definition, origins, and uses in business today. However, upon closer examination, it’s become clear that MVP might not be the best tool for growing businesses and efficient development or product teams.
So, let’s break it down. What does MVP really mean?
Synonyms: least possible, smallest
The word “minimum” connotes laziness and promotes the idea that you are completing the least amount of work needed to cross the finish line.
Synonyms: workable, usable
When I think about the word “viable,” an image of Tim Gunn shouting “MAKE IT WORK” to a group of developers comes immediately to mind. The fact that “workable” is the standard we strive for when building a new product is shameful.
Synonyms: device, output
There isn’t much of a definition here. The “P” in the acronym is more of a placeholder than an measurable value. In this sense, “product” could be replaced with “thing,” and it could still work. I’m convinced the creator of MVP included this piece to make the connection to the Most Valuable Player concept.
When broken down like this, one can see the theme of laziness that runs rampant throughout the narrative of MVP. Breaking down the components in this way exposes holes in both design and functional thinking that is critical to getting your customer’s buy-in on the value of your new product.
Using MVP as a measurement of readiness for launch takes the product manager’s concept of a functional product into account instead of the customers. At PactSafe, we keep our customers at the forefront of our builds to ensure present and continued success.
Digging into recent MVP content from product resources, an anti-MVP trend begins to emerge. Though most of this content starts by stating why MVP was needed and mentioning Eric Ries, they eventually veer into discussion of why the MVP model isn’t (and hasn’t) been scalable with the evolution of technology and product processes. As products and technologies evolved, so did the concept of MVP transition to an SLC model.
SLC, which stands for simple, lovable, and complete, has gained significant adoption in product teams over the past few years alone. At PactSafe, SLC is how we evaluate the quality and usability of our product before launch. The words that make up the term are commonly used, easily understood, and to the point.
Building software and architecting the user experience requires you to put yourself in the shoes of the user to consistently make choices that benefit your customer, not just your product.
In order to identify use cases and gotchas that would otherwise remain hidden until user testing, product and development teams must think and behave like the user in your product. Being forward-thinking in this way helps your teams develop a customer-focused product from the first launch, have a shorter beta time, and a better recognition of value from your users.
Here is how the pieces of SLC affects the PactSafe product process:
When evaluating the functionality, workflows, and UI of an early product, the concept we strive towards is “simple.” Releasing a new product is essentially unleashing a new technology concept on your platform, so it is important to ensure that even novice users of your app understand the goal. This is critical to adoption.
Users hate complexity: frustrating events and confusing workflows, more often than not, drives them to just quit the experience all together.
To keep it simple, create streamlined workflows, use common, easily-understood language, and address the customers needs.
While the word “lovable” makes you think of a visual experience, it is most powerful when referring also to functionality. Product Managers know more than anyone the struggle of putting functionality before design, but the key to a good product is to have great functionality that goes hand-in-hand with a beautiful visual UI; this is the basic equation for a successful product.
“Lovable” focuses on the goal of the feature, its functions, and the value the function provides to the user. All (good) product managers are used to thinking about use cases in terms of the global capabilities of the product. However, most tend to overlook that extra step needed to understand the business value that the function provides to customers.
Making sure that your function is “lovable” emphasizes the customer’s future with the feature. Hopefully, it will be love at first sight and together they will sail blissfully on the sea of a good product. Yet, to reach this level of love, the product manager has to understand how the customer’s use case can and will evolve.
While the mind moves towards functionality upon hearing the word “complete,” this aspect of SLC refers to all components of the product equally. The key to fulfilling the “complete” aspect is ensuring that all the UI components, workflows, functionalities, and gotchas have all been fully vetted and confirmed with the customer requirements.
Missing functions, confusing UI, and workflows that are missing vital steps to complete an action will frustrate users and cause them to stand against your product, or worse, to stop using it.
By using “complete,” your team can effectively compare the product build to all your customers’ must haves. This will help you to successfully complete the function and ensure that there are mechanisms and tools in place for your customer to fall head over heels for your build.
Using SLC instead of MVP can provide a more complete vision of the value to your customers. Product managers are hired to direct the product towards both business and customer goals. Using MVP with business goals for your product direction implies a lack of customer input, which is integral to the successful launch of a product. SLC, on the other hand, puts the customer back into the product ideation process.
Learn more about PactSafe's API-first high-velocity contract acceptance platform.