Business Plan Hypothesis. Sometimes we are too stubborn execute our business model without having spent some time before to check the validity of the assumptions on which it is built, which is a huge risk to the project. If we are able to validate these leaps of faith through concrete experiments we can adjust the model and adopt the necessary corrections
Some time ago we talked about the importance of making a critical interpretation of the business plan, a useful tool for some purposes, but rife with hypotheses about what will happen in the future or about the behavior and needs of the client. I think a much more interesting to the business plan is the use of alternative business models, as it provides an integrated and coherent vision on the key elements of the business (and no vacuum is famous as the business plan).
Still, the business model, like any tool that attempts to model high-level startup or a company suffers from the same problem as the business plan: is littered with leaps of faith, or what is the same, ideas and approaches that give as good and on which rests the business model. It is absolutely normal as designing a business model we are doing an exercise of inception of what we expect to happen on the needs of a client etc.
Why are so important leaps of faith?
The dangerous, and unfortunately often happens, try these hypotheses or assumptions as if they were true so you can get us to blindly run a business model that does not correspond to reality, something sadly commonplace. Some of the most common scenarios that we use for our business plans, but which in practice are actually elements on which there is significant uncertainty are:
- Who will buy? (Who is the client, and where is it?)
- Why do they buy? (What real problem we solve for which they are willing to pay?)
- What, how, and how to buy? (Aspects such as recurrence, sales channels, customer experience)
- How do I'll hold? (Are mechanisms that allow us to retain? May be viral?)
- Is it a profitable model? (Will we be able to provide the service / build the product with expected margins?)
That is absolutely critical to identify the circumstances in which our business model before running it is based, which tends to draw leaps of faith. A leap of faith is any high-level course unvalidated (uncertainty) we have included in our business model, and that really includes one or more hypotheses itself
Validation business model hypothesis
For example, if we are designing the business model of a stall selling lemonade (tricky in Spain) in an area where many people spend, we are really assuming a considerable number of leaps of faith:
- People stop to buy a drink
- Customers are willing to pay 2 € per glass
- Customers will return periodically
Each one of those leaps of faith is capable of being decomposed into specific scenarios for which experiments can be designed adhoc and check its validity (or not). For example, to validate that people will stop buying lemonade hypothesis can be defined as:
At least we get 10 customers a day. It is enough to be at peak hours (from 8-9, from 13:45 to 16:15 and 17:30 to 19:30). Will they let us put a stall at the entrance to the subway. As we can see, there is a not insignificant number of assumptions which we have based our model. The key is to design experiments for testing, measuring and especially learn as the ultimate goal of validating the hypothesis is to learn from the conclusions to implement course corrections or pivoting the business model.
HOW TO IDENTIFY?
The key to identifying the leaps of faith is to make an absolutely critical reading of the business model, business plan or any planning we have done on our business, with particular attention to those elements that are surrounded by uncertainty:
- Who are the customers and what motivates them
- How can we reach them
- That level of engagement we will get, and how they want to be sold
- What conditions, prices and other of our allies are true and constant in time
- The benefit formula and income strategy is consistent and appropriate to the client
- (Other risks of product differentiation, barriers, etc.)
Once identified breaks faith should order them according to the risk they pose to the project, ie, first they should be placed those who, to show incorrect, would pose a great threat to the viability of the initiative. Having done this, we should consider designing small-scale experiments and very specific that allow us to validate if the assumptions on which the leap of faith is based are correct or not.
One of the first temptations we must avoid is to group and designing experiments to test hypotheses 6 or 7 at a time, because we may not be able to identify the end what assumptions if they have been validated and which not. The key is to define very specific experiments that help us to establish beyond reasonable doubt the validation (or not) of the hypothesis, so the key is to establish metrics that help us to objectify the process because otherwise we tend always to make a extremely positive interpretation of results or worse, become complacent and decide that all is well by not facing reality (which just indicates that the business model does not work).
VALIDATION OF CUSTOMER
The first hypothesis we should validate are those related to the customer, because on one side often involve much risk (the customer is the basis of the business model), and on the other hand in many cases can be made without having built the product ( as they seek motivations, preferences, options etc). To do nothing better than adopt the philosophy "Customer Development" Steve. S. Blank, which bases its strategy of abandoning the "strategy board" and leave the office to talk with customers, to understand their real problems, needs, interests, what they are willing etc.
VALIDATION OF PRODUCT
Once validated customer scenarios and assumed the necessary course corrections, it's time to start building the product iteratively, real substrate of the business model and architect with which we will make money. Again, and instead of taking a traditional approach, we should first build a very limited release of produce to validate a leap of faith, and usually will be the first major utility related to the client will find in the product. In this case, Eric Ries comes to our aid with Lean Startup philosophy and concept of MVP (Minimum Viable Product), which has been brilliantly extended by people like Ash Maurya.
What tool can I use to capture the hypothesis?
One of the best ways to translate the assumptions and have designed experiments to validate them is through the Development Space Dashboard, a tool that we propose John Mullins & Randy Komisar in the interesting book Getting to Plan B: Breaking Through to a Better Business Model. In fact we will use the example they usually use to talk about their use, but adapted to the case that we have set.
Like it? Please share!