Minimal Viable Demo (MVD)
I came across the term Minimal Viable Demo (MVD) when I read a blog written by my former Purdue graduate school classmate and CTO of Juniper Networks Raj Yavatkar. In his post, Raj offers great insights about being an effective CTO. One of his insights focused on the “fail fast” philosophy of many agile organizations. He suggests that many organizations interpret “fail fast” to focus on a Minimal Viable Product (MVP). He defined an MVP to be “a product launched with basic features to test its viability with customers, with the final product released only if feedback is sufficiently positive.” Raj argued that a better “fail fast” strategy would be to focus on a Minimum Viable Demo (MVD): “rather than introducing a product into the market, MVD provides a faster and more agile way to prove or disprove a hypothesis with sales, marketing, and other internal stakeholders, even with select customers.”
I work with many early-stage SaaS companies that are on a journey to achieve product-market-fit (PMF). Most, if not all of them, focus on an MVP as the basis for achieving PMF. The problem is building functional MVPs can cost significant time and money. Given the capital efficiency requirements of the current times, for some companies, an MVD that precedes an MVP would be much more capital efficient, timely, and productive.
In the context of an MVD, the definition of “minimal” should be informed by focusing on only the most important buyer desired outcomes and limited to just the proposed capabilities that deliver the outcomes in different and better ways than competitors. “Viable” in this context is about ensuring that the proposed capabilities could eventually be developed with the given assets and resources of the company in a timeframe consistent with the market window. Finally, “demo” in this context can mean anything from a scaled-down functional prototype to a mock-up. Conventional wisdom suggests great demos last between 5 and 15 minutes. The “demo” must be finished only to the extent that it is suitable to obtain the desired feedback on your hypothesis.
I recently had an experience with the MVD for a start-up looking to validate its product concept and pricing. Our product hypothesis was “We believe global buyers of certain commodities will achieve better commodity pricing, delivery, and quality because of crowd-sourced analysis and prediction of commodity vendor pricing, delivery, and quality and aggregated purchasing power through a community-based software platform.”
Rather than invest in a full-featured MVP, we used Balsamiq, a tool for rapidly producing interactive web and mobile software prototypes. Within one day, we had a reasonable interactive functional prototype of the main workflows and key features that would deliver on the desired buyer outcomes. The features we prototyped in Balsamiq were consistent with delivering on the core hypothesis outcome: “better commodity pricing, delivery, and quality”. We were able to do interactive user feedback sessions with several early adopter prospects and a channel partner to gain valuable feedback. These sessions focused on the key jobs of the commodity buyer related to the desired buyer outcomes. Each session resulted in valuable feedback and allowed us to revise the prototype based on the learnings from the session. Over the span of one week, we converged on an MVD that became the basis for the MVP. I became a believer in the MVD concept.
For more complex applications, proving out the technical feasibility of a new product may be less about the user interface and more about the underlying technology and algorithms. In such cases where the innovation may involve ML or other advanced algorithms or processing, the nature of the MVD will vary. In short, the content, scope, and nature of an MVD will vary depending on the nature of the validation you are seeking, the market opportunity, and the desired outcome.
Food for thought.
