When “The Lean Startup” author, Eric Ries, realized the value of validated learning, the easiest way for him to get in front of prospective customers was by building an initial version of his product, launching it, and evaluating the feedback. After all, his startup consisted primarily of engineers so building products was what they were good at, what they did quickly, and perhaps one of the only things they could do efficiently. Hence the minimum viable product.
But the primary goal of utilizing MVPs is not and never was to actually build something. Our CEO, Thor Ernstsson, wrote definitively that “The goal of an MVP is not to launch the first version of a product. It’s simply to start gathering feedback and observing users actually interacting with something. This distinction is critical.”
And it’s a distinction that has often been lost in translation when applied to enterprise. We’ve written an ebook to help product managers refocus on the inherent value of developing an MVP so that they can apply comparable practices to the enterprise’s unique product lifecycles.
In the ebook, we provide a guide to what Validately founder Steven Cohn calls the “minimum viable experiment.” In an article announcing the ‘MVE,’ he claims:
“I basically hijacked the definition of the MVP but am using a word that (hopefully) won’t be misinterpreted. My hope is that by replacing the word “product” with the word “experiment,” that the expectations are now better aligned with the results (i.e. learning) that you are likely to get.”
This distinction has practical implications. Product teams in large companies are not as nimble as startups due to increased layers of communication and decision making, and increased brand and legal risk, among other factors. For enterprise product managers, validated learning comes far more rapidly utilizing other strategies. Instead of a “Build-Measure-Learn” approach, enterprise product managers need to take an “Experiment-Measure-Learn” purview.
Reframing the methodology in terms of ‘experiments’ is the breakthrough that enterprise product managers have been waiting for. Just some of the numerous benefits we touch upon in the ebook are:
Efficient use of resources
Building and launching a comprehensive product takes a lot of time and money. Given the substantial risk that any new product has of not being something customers want, this is an extremely risky proposition. Designing an MVE requires far less time and money. If done correctly, they can provide just as much validated learning as a product launch while greatly improving the chances of success further in the product development lifecycle.
Simplify coordination with engineers
Coordinating with any other department, particularly engineering, requires another level of communication, management, diplomacy, and resources. Experimentation enables you to answer some key questions and defend critical arguments early on without the use of engineers or code. Once you have the data and findings from experiments in hand, you’ll have a much stronger case for your vision when you visit the engineers. You’ll also be able to build trust and rapport a lot quicker.
Limit brand exposure and legal risk
One major difference between a large company and a startup is that a large company has significantly more brand risk and sensitivity to legal risk. A startup has no reputation, and less concern for “bending the rules” because of their lack of reputation and exposure.
Running an experiment instead of launching a product is a great way to limit the risk a large company faces. There are many common tactics to limit exposure of half-baked products, such as geo-fencing, invite-only beta lists, and non-branded products. Of course those tactics wouldn’t be ideal for startup MVPs that can be “viable” products, but are ideal for testing a particular value proposition or a new user segment without all the typical overhead.