Do things that don’t scale: Building an MVP without Software Development

The term Minimum Viable Product (short: MVP) has become mainstream and is widely used particularly in the context of digital product development. The strategic varieties of an MVP are often narrowed down to the first version of a software product, at least in the field of software development. In this blogpost I will introduce a different approach to building an MVP without using software development and explain why it should be a foundational part in the toolbox of any modern product manager.

Rise of the MVP

Besides transforming existing business models, processes or structures, innovating – searching for new (digital) business models – is often an important part of digitization. Amazon, Airbnb or Tesla, to name only a few well-known examples, threaten to or have already disrupted various old and established markets.

To win this race for digital innovation, a lot of companies started to adopt the lean, customer-centric and data-driven methods pioneered by those companies and other massively successful companies and startups. The best known of these methods is probably “The Lean Startup”, which was et al. adopted by General Electric in their famous and renowned “FastWorks” approach.
But why do established companies adopt methods that have the word “startup” in their title and thus seem to be designed for companies with a different maturity level? To better understand this, let’s have a look at the original definition by the author of “The Lean Startup”, Eric Ries:

A startup is a human institution designed to deliver a new product or service under conditions of extreme uncertainty.

This definition does not refer to any “demographic” attributes like e.g. the number of years a company already exists. Instead it just focuses on the context a venture or institution operates in. This explicitly includes established companies that are operating in new markets with a high uncertainty – which is something Eric Ries likes to point out as well.
So what is it that makes everyone excited about this method?

Lean startup is inspired by a variety of proven ideas and methods like design thinking, agile engineering, lean manufacturing or management and customer development by Steve Blank. But at its core it uses something that is crucial for the understanding of a lean startup: “the scientific method”:

1. Observation and description of a phenomenon or group of phenomena.
2. Formulation of a hypothesis to explain the phenomena
3. Use of the hypothesis to predict the existence of other phenomena, or to predict quantitatively the results of new observations.
4. Performance of experimental tests of the predictions by several independent experimenters and properly performed experiments.

In lean startup, the adoption of the scientific method is called the “build-measure-learn cycle”.

Hypotheses (ideas) about a business model or product are formulated. Then an experiment is conducted to validate those hypotheses. The results of this experiment are used as input for the new ideas to kick off the next build-measure-learn cycle.

This approach is used due to the fact that – under conditions of extreme uncertainty – assumptions about the market are an inherent part of the development of products and services, and knowledge has yet to be built. Being aware of this fact and rigorously testing those assumptions in the market increases the chance to build a product that can really achieve product-market fit. Otherwise one will at least learn if a product or business model is not working very early in the lifecycle and thus will avoid further costly invests (fail fast and smart).

There is a good reason to use this iterative approach to find product-market fit. In a study conducted by CB Insights 101 startups were asked about the reasons why they failed. The top reason was “no market need”.

A fundamental tool in the lean startup methodology, used to build the main experiment for the leap-of-faith assumptions in a business model, is the Minimum Viable Product. This is the reason why the MVP became very popular in the startup world.

The corporate interpretation of MVP

The term Minimum Viable Product seems to be coined by Frank Robinson (CEO, SyncDev). But, as mentioned, it was made popular by Eric Ries in his bestselling book “The Lean Startup”. One of Ries’ earliest definitions of a MVP can be found in his blog “Startup Lessons Learned” , which was the main source for the book that he published later:

The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

The average shiny slides for the new “digital strategy” of an average corporate seem to have to contain the word MVP as inevitably as it seemingly has to be linked to software development. In small variations it often comes down to “the first version of a software with a minimal feature set” which has to be “iteratively improved” later. What a wonderful and handy definition. But admittedly for people familiar with agile software development and methods this is just old hat. Arguably the reason for this could be that Eric Ries, having a background in software development, was heavily influenced by those methods. This is actually partly true as he especially was and is a strong supporter of eXtreme Programming by Kent Beck .

But this is not the real reason why “MVP” in these presentations just seems to be a cool new buzzword for something old. Let’s have a look at the definition again to find a different explanation. The first thing to notice is: Mapping “product” to “software” is a very narrow interpretation of the original idea. It’s also questionable that software will always lead to the “least effort” to “collect the maximum amount of validated learning”. So the real question is: Does MVP really have to equal software?

Software of course, due to its scalability and reach, is a valuable and valid option to test the core assumptions of a business model and thus a good choice for an MVP. But it’s crucial to understand that it is just one in a wide range of different options to build an MVP. Especially for very complex business models – e.g. models with a complex value chain including a great variety of stakeholders – there are way more elegant, fast, and lean types of MVP. Although they might not be as scalable as software, they still provide everything that is needed to understand how to reach product-market fit.

Joe Gebbia, one of the founders of airbnb , often emphasizes that one of the most important lessons they learned from Paul Graham at Y-Combinator was this: “Do things that don’t scale” . This advice was the reason why Airbnb got in touch with early adopters in the first place and learned that high-quality photos of rentable apartments could be a key factor for the platform’s success. In fact it is still considered one of Airbnb’s key steps to product-market fit.

Allegedly the advice “do things that don’t scale” is given to any new founder at the Y-Combinator program which underlines the importance of this wisdom. And it is also a great counsel for an MVP strategy.

In the last couple of years, numerous examples of young, digital ventures that validated their idea before having a scalable software product have been given. Eric Ries and others extracted the underlying patterns from these examples that we can now use as blueprints for designing a good MVP.

Types of MVP

A pretty common misconception about MVP is that it’s just a shiny new marketing description for a crappy and unfinished product.

The term might not be ideal and it often causes discussions. One is the ongoing competition of finding the best modification of the term for a certain context, like MSP (Minimum Sellable Product), MMP (Minimum Marketable Product) or MLP (Minimum Learnable Product).

In the end, MVP is a widely used term and – to me – it doesn’t make any difference which term is used if the core aspects of a good MVP are clear.

Figure 3: Aspects of an MVP ¹

As figure 3 shows, a good MVP should cover each of the four aspects: feasible, valuable, usable, delightful. Additionally it is supposed to test the riskiest assumptions about a product or business model as well as ideally charge the customer from day one. ²

But the most important factor of an MVP is time. “The only way to win is to learn faster than anyone else. – Eric Ries”³ Because there is nothing more frustrating than having a competitor validating and executing your idea faster than you.

This is why the aspect of the “least effort” is so important to the design of an MVP. It shifts the focus to minimizing the time that is needed to generate learning respectively to validate or invalidate the underlying hypotheses. The types of MVP that I will subscribe subsequently are examples of reducing the effort by deliberately excluding software development.

Concierge MVP

The idea behind a “Concierge MVP” is to offer the core features of a product without any automation through software to validate the viability of the business model. From the customer’s view it is already a product worth paying for because he is getting a significant value out of it. It covers all the important aspects a fully automated product would provide later so the only difference is a lack of scalability – and thus sustainability – which is not necessary because it does not support learning at this point.

Example

The Duesseldorf-based startup Pillbox originated from the 2016 “Startup Sprint Duesseldorf”. The founders’ vision was to significantly improve simplicity and security for medication consumption by offering a better packaging (box with blister packs, fig. 4) and checking for potentially harmful interaction between drugs. They also wanted to provide additional digital services like a digital medication management dashboard, automated follow-up prescription application and frequent delivery (figure 5) to make obtaining long-term medication more convenient.

Figure 4: The Pillbox

A first viable software product potentially had to include a great variety of different stakeholders along the value chain with a very heterogenous IT landscape. The customer and his smartphone, doctors with various practice systems, pharmacists, blister centers and logistics providers had to be part of a solution that would likely have taken months to be developed. An enormous amount of money and effort for an idea that had yet to be proven. But the founders took a different approach.

Figure 5: pillbox service

From their point of view there were two core assumptions that had to be proven for their idea to have a chance of surviving:

• Would customers trust a startup when it comes to dosage and delivery of their medication ?
• Would customers – considering the german healthcare system – be willing to pay for the product and services they wanted to offer ?

Those assumptions could be tested in a more lightweight and cost-effective way by building a Concierge MVP.

The founders established a cooperation with a medical center to acquire their first twenty early adopters that were willing to pay a monthly fee for their offering. Those customers were provided with the full service offering from prescription pickup over ordering and packaging with the help of a partner pharmacy and blistering center up to a personal delivery of the pillbox. Every step in the process was done manually by the founding team.

After three months, the founders did not have a scalable product, but they were able to validate their riskiest assumptions and prove that they had found a market where people were willing to pay for the product and – even better – they had a zero churn rate in that first period. Through constant contact and conversations with their first customers, the founding team was also able to generate a great amount of qualitative learnings about their product. Besides valuable insights about the importance of a convenient onboarding process and the confirmation that an app was the preferred channel to their customers, even for the older people in their segment, they learned one major thing: Their main value proposition was not security and simplicity with the box as the core concept, but the convenience that was provided by their service offerings. The value people saw in Pillbox and what they were actually willing to pay for was saving one of their most sacred goods – time. The box itself was just a neat and handy goody that made the whole thing even more convenient and time-saving.

Based on their new findings about the real value of their product and processes, the Pillbox team was also able to better identify the crucial parts of their business that had to be automated first in order to serve the market need better and scale the product efficiently. Because now their decisions were driven by learnings and knowledge about their market instead of assumptions.

This example shows how a Concierge MVP can be used to validate the core assumptions of a business model in an otherwise rather complex market. And also how this approach can help discover the unknown unkowns of your idea through the qualitative nature of the experiment.

Conclusion

Speed is a key factor of successfully bringing a product to market. So in product development we often focus on reducing the time-to-market. Within the context we looked at it in this article, there is a shift of focus. Under conditions of high uncertainty, where the actual existence of a market is in question, we rather want to focus on learning as fast as possible. So for this breed of more innovative products and ventures, the thing we should talk about is reducing the Time to Learning.
Every step of this iterative process is driven by two main questions:

• What is the (next) riskiest assumption about my product or business model?
• What is the leanest experiment I can build to test this assumption?

The MVP is a powerful tool for product managers to build complex experiments for answering those questions and should therefore be an integral part of their toolbox. We have also seen that building software is not necessarily the leanest way of building an MVP or experiment. The critical decision to make here is choosing the right tool for the job. To do this, it’s inevitable to have an overview over the solution space, in this case the different types of MVPs to choose from. Especially the variants described in this article – Concierge MVP, Wizard of Oz MVP, and Piecemeal MVP (please have a look at the original article here for the latter) – are great ways of brining a first product to market using a minimum amount of time and effort. So for certain cases those are valuable alternatives to building an MVP by investing in building software.

The lean startup principles we touched upon in this article in general as well as the MVP in particular are not just a good fit for the pre-product-market-fit stage of a product. Even in later stages core principles like the build-measure-learn loop or the MVP pattern(s) introduced in this article can be a great way to foster more knowledge-based than gut-based product development decisions. Those patterns can be very easily adapted to validate ideas and assumptions for larger or smaller product features.

Let me walk you through one last example from the great book “Sprint”⁴ by Google Ventures. The book covers the concept of one-week “Design Sprints” that was originally developed by members of the Google Ventures Team.

The Silicon-Valley-based Startup Slack built a very successful instant messenger for teams and companies. During a Design Sprint conducted by Google Ventures, the team from Slack wanted to find a new kind of onboarding process for their messenger because they recognized that users had trouble understanding how to navigate their tool. The idea the team developed during the Sprint was to build a chat bot that would help users understand the messenger in a conversational way as well as being a constant contact for further questions that might come up later. An important part of a Design Sprint is conducting an experiment to test the idea within the one week of Sprint, so the experiment had to be really small. What the team came up with basically was a Wizard of Oz test for their chat bot idea. To test the acceptance on the users’ side as well as the effectiveness of a bot as an onboarding process, the team invited a couple of new potential users and had them execute the onboarding with one of their team members acting as a “bot” behind the scenes. This way the team was also able to get a first indication about the level of intelligence such a bot needs to have for users to be willing to interact with it and get the help they need.

This example shows that the concept and patterns of MVPs can be a valuable strategy to constantly avoid the risk of doing the wrong thing in product development by making more sound, considerate, and information-based decisions about the next steps to take.

This blog post was first published in the Softwerker special edition “Digitalisierung”. 
Subscribe to the softwerker for free.
For more information about our service offerings, go to www.theblackframe.com .

<sub>1. Humble, Molesky, O’Reilly: Lean Enterprise S. 77
2. Maurya, Ash: Running Lean”, Part II – Chapter 3
3. Ries, Eric: The Lean Startup, S. 111
4. Knapp, Zeratsky, Kowitz: Sprint, S. 175</sub>