One of my early Minimum Viable Products (MVPs) in the founding of CloudHealth Technologies was to test the value proposition of cloud cost optimization. I needed to validate two critical assumptions to my product idea: (1) I could drive a meaningful reduction in cloud costs for customers, and (2) there existed a repeatable process for doing this. By this point in 2012 I had already gained extensive experience doing #1 for my previous employer, a fast growing startup where I was responsible for driving an AWS bill from $350K+ per month to $180K. But what I didn’t know was how generally applicable my experiences were to other customers.
As a technologist, my instincts were to spend a few weeks to write a software MVP that could provide cost recommendations. But the more I defined the software requirements, the more I realized how much I didn’t know about the problem. E.g. What questions did I need to ask customers about their cloud usage? What did I need access to from cloud providers in order to get the data required to drive insights? What format should I use for presenting the recommendations?
It didn’t take long before I finally got around to asking the question I should have started with: what is the real M in my MVP? As much as I like to say that Eric Ries’s Lean Startup is just the marketing version of Steven Blank’s The Four Steps to the Epiphany, his book definitely had an impact on me. While the Four Steps helped reveal the secrets that had eluded me around managing product development risk through continuous customer engagement, Lean Startup gave me the inspiration of real world examples. For example there is the story of Drew Houston, the founder of Dropbox. When Drew was testing his critical assumption - that a superior user experience in file sharing was a game changer - he didn’t bother to invest in the costly and time intensive effort to build a software MVP. Instead Drew mocked up a simple demo and asked customers to join his beta. The result: clear and compelling validation of the demand for an easy to use file sharing service.
Over the next day I pivoted from a software MVP to a much simpler idea: me as a service. My new MVP would engage five companies in a white glove concierge service to optimize their costs. I would work directly with the person who owned the cloud costs - often the VP of engineering or CTO - to understand their challenges and make recommendations. I didn’t even bother to figure out exactly what tools and technologies I would use to derive recommendations, trusting instead that like Bill O’Reilly, I would “do it live.”
The end result was one of my more successful Lean experiments in the formation of my startup. I provided a valuable service to a handful of Boston-based technology companies, validated my two critical assumptions, and learned a tremendous amount about cloud cost optimization - all in less than two weeks. While much of my work was done using spreadsheets, I did find myself writing software scripts to help along the way. These scripts were the beginning of what would eventually become my software product.
Entrepreneurs and product leaders have a natural instinct to over-engineer their MVPs. In their goal to get to the software solution they know needs to be built, they too often forget that gaining validated learning by the fastest and least expensive route should be their singular mission. Sometimes, the M in MVP is not much more than the basics of validated learning: you, a customer and a problem.