Lean methods are tempting to large organizations. The concept that product owners should shorten iteration cycles to optimize learning and minimize waste is certainly a valuable one. But when Steve Blank and Eric Ries put forth the now world-renowned build-measure-learn model, they did not frame it for the context of enterprise product management. Unfortunately, this has caused unforeseen problems for the otherwise prescient practitioners of this approach.
The primary goal of creating a minimum viable product is not to build something, but instead to learn something. For Ries, who was working at a startup consisting almost entirely of engineers, the easiest way to get their product in front of prospective customers was to build and launch an initial version of it. Hence, the minimum viable product, or MVP.
Champion Advertisement
Continue Reading…
Why MVPs Hold Back Enterprises
According to the 2015 Product Management Insights report that my company Alpha UX recently published, two of product managers’ greatest challenges are internal politics and iterating research and development. While startups are often willing to forego other concerns to quickly launch and iterate a product to learn from users, enterprises can’t afford to throw caution to the wind and focus solely on iterating live products. Our survey shows that, even if a large company wanted to iterate quickly, it would have a great deal of trouble doing so.
Enterprise product teams have multiple layers of communication and decision making—not to mention stakeholders with deep-seated opinions to please. When a large number of constituents from different departments provide conflicting feedback on a product, it puts a product launch further out of reach. So applying a framework that emphasizes frequent launches just exacerbates this problem.
Imagine, for example, that a large financial institution decided to build a minimum viable product for a new peer-to-peer payment application. The product team would have to get approval from legal, quality assurance, customer support, and various other departments before making the application live and getting feedback from users. But for argument’s sake, let’s assume that the product team could ignore all of those stakeholders and launch an early version of the application. If, two days after the launch, user complaints came streaming in, reporting bugs, data breaches, and poor user experiences, unlike a startup, this financial institution could not just close up shop and relaunch under a different name. The company couldn’t even just roll back to an earlier version of the product, because it’s already severely damaged its brand—not to mention possibly having incurred liability for damages.
Why MVEs Work Better for Enterprises
By focusing on the value of learning rather than building, enterprises can reconceive minimum viable products as minimum viable experiments, or MVEs, and apply an experiment-measure-learn approach. When product managers enable their companies to learn through experiments rather than by launching MVPs, they get the equivalent value of MVPs without all of their drawbacks.
Validation of experiments gives product managers the autonomy to push back against the design-by-committee decisions and scope creep that tend to accompany product launches. Plus, unlike products, experiments don’t need to meet the typical quality assurance or scalability standards.
MVEs significantly limit brand exposure to potential customers, which can prove beneficial for more prominent companies. While startups can launch a failed product and keep on moving, longstanding companies can’t do the same without damaging their reputation and compromising consumer trust.
The most important benefit of the MVE is that it moves gathering user feedback from the end of the product development lifecycle to the beginning. If you spend too much time trying to develop an exceptional MVP up front, you’ll have wasted valuable time and resources far too early in the process.
Running an experiment is a simple, liberating process that generates user feedback without taking on the risks of an MVP.
Creating an MVE
Here is a three-step process that you can follow to create your own MVE.
1. Establish Your Minimum.
Because conducting experiments is a waste-reducing approach, you should continuously consider your minimal investment in each experiment. You shouldn’t invest in designing a robust prototype that fully simulates an application’s functionality before first validating the numerous assumptions that go into it.
Reduce value propositions to testable components. You might begin by evaluating how your target users currently solve the problem you’re trying to address—to determine whether there’s an actual need or opportunity. Then, consider testing different value propositions by outlining your solution’s potential features and benefits and gauging users’ reactions. Once you have high-level validation of your proposed solution, a logical next step would be to test basic prototypes that simulate each isolated feature and see how its inclusion or removal affects the perception of value. Because experiments enable you to gain an understanding of what would be a good solution, the minimal requirements for learning increase.
2. Learn How Much Users Are Willing to Sacrifice.
When prospective customers decide to purchase a product, they don’t make that decision in a vacuum. Every product is competing against direct substitutes, as well as other solutions that customers could purchase for approximately the same price.
One of the most obvious ways to validate customers’ willingness to sacrifice value when purchasing your product is to simply charge for it—even if you haven’t yet built the product. But charging customers for a nonexistent product isn’t always feasible. In such cases, you’ll need to substitute an exact dollar figure for the perception of value metric, which can incorporate a number of variables from user feedback that let you evaluate the worth of a product concept. Some good metrics to try are the Net Promoter Score, likelihood to try, ease of use, and rate of selection over competitors’ products.
3. Develop the Right Mindset.
Generating meaningful user insights is the ultimate objective of your MVE. While most products are doomed to fail, experiments don’t suffer the same fate. In fact, experimenting improves your product’s chance of success.
Testing your product concepts lets you better understand your prospective customers’ needs. If your data tells you that your product idea isn’t a winner, don’t look at this as a failure. The purpose of each experiment isn’t to be a game changer; it’s to get you one step closer to the user and, thereby, to success.
For enterprises, lean means running experiments quickly and pursuing the products and features that consistently perform well in testing. Rapid experimentation will help you to either validate or refute your hypotheses quickly and arm you with the data and insights you need to align stakeholders and key departments with a proven vision.
Reframing lean methods in terms of experiments can result in significant breakthroughs for your business. While exchanging the build-measure-learn model for the experiment-measure-learn model may seem like a small change, it allows large enterprises to reap all of the benefits of lean thinking without your getting tangled in red tape or delivering muddled products to customers. Replicating the MVP model that works so well for startups is impractical for large organizations. But you can successfully apply the core principles behind lean methods—experimenting rapidly, aligning your product with users’ needs, and making product decisions that you can back up with data—by conducting minimum viable experiments.
MVE vs MVP—to me it’s a matter of semantics. This is another example of why there’s too much theorizing and discussion and not enough doing in the world of UX. This debate is yet another way to widen the gap between UX and Engineering, and the last thing anyone needs is a bigger divide between those who define the experience and those who build it.
MVP is a loaded term: The bigger the organisation—the writer stated “enterprise environments”—the less experimental an MVP becomes.
It would be nice to think that bigger organisations should understand agile better, but such cultural change is hard to achieve quickly.
The problem is that, when a feature is not being used, it is hard to assess whether it really is not useful. Is the feature not viable, or is it simply badly executed for the sake of speed?
MVP should mean experiment, but often it means deliver and sort it out later. An experimental approach would help to reduce the pressure on an MVP by explicitly stating, this is an experiment.
To me this is a nice idea and a useful discussion point. Thanks for raising it.
Michael has been developing digital products for more than 15 years, serving in roles ranging from developer to product manager. He was previously a Vice President at Greenhaven Partners, a private equity firm, where he managed digital strategy and research business units across the portfolio of companies. He has also worked as an investment banker, focusing on mergers and acquisitions for digital media and technology companies. Michael holds a degree in economics from Dartmouth College and is an active leader and mentor in the Dartmouth Entrepreneurial Network. Read More
