There’s a reason so many companies started by founders from a corporate background fail. Traditional enterprises operate on models that work for the problems they face, but the problems faced by startups are often completely different.
Large enterprises deal with problems that are well defined, and where the solutions are clear. These problems are best solved by utilising existing institutional knowledge about how to solve such problems and implementing a plan to do so.
Startups, on the other hand, operate in a domain where typically the problems are less well defined and the solutions completely unknown. In such situations what works for large enterprises - planning - is the worst approach. Instead, startups should be running small experiments and validating their problem/solution fit ASAP.
A framework for determining how to solve problems
We’ll explore these quadrants further but first, to illustrate this, there is a famous experiment run with MBAs, engineers, and kindergarten children where each group is given a set time to construct as tall as tower they can, using sticks and marshmallows. In this experiment invariably the MBAs perform the worst, while kindergarten children only moderately underperform the engineers.
The reason for this failure is because for both the MBAs and Kindergarteners, both the problem and solution are unknown. Neither has a firm grasp of the problem of engineering against gravity, or the solution in building a tower with sticks and marshmallows. However, the MBAs have been taught a planning mindset (where both the problem and solution are known) and spend most of the of their allotted time planning the perfect solution, only to complete construction just before the deadline and have the tower collapse. Meanwhile, the Kindergarten children begin construction immediately and after repeated failure eventually learn what kind of structures are resistant against collapsing - something the MBAs never get to do.
As a side, for the Engineers, this experiment represents a known problem and unknown solution. All they have to do is brainstorm the solution based on their existing knowledge.
Problem is known | Solution is known
This is a typical scenario in established industries and large enterprises. The problem that is being looked at is very clearly defined, and similar problems have been solved before. As a result, the solution is very clear - just adapt what has been done before.
In this case, all that needs to be done to solve the problem is plan accordingly. Utilise the existing knowledge, assemble resources, and execute. Experimentation here is unnecessary as all that legwork has already been done.
In most of the enterprise world, this model is what is taught to work, based on the experience of solving problems for the enterprise. As a result, this is also what is taught at most business schools and is accepted as best practice.
Need to launch a version of an old product? Just repeat what the company did last time with minor tweaks.
Problem is known | Solution is unknown / Problem is unknown | Solution is known
In these scenarios, there exist two possibilities. Either the knowledge to identify the problem or solution already exists institutionally, or it does not.
If the knowledge exists internally, then it is a matter of correctly brainstorming to extract this information and identify either the problem or the solution.
If this knowledge does not exist internally, then it is a matter of going to to the market and conducting research to fill this gap.
Typically for most organisations, the problems they face are somewhere within this spectrum. Good use of market research and brainstorming eventually leads to identifying the problem and the solution to be implemented.
Problem is unknown, Solution in unknown - Experiment
When both the problem and solution aren’t really known, taking the above approach of researching and brainstorming can be incredibly costly and time-consuming. When there are so many unknowns the risk of failure rises dramatically, and this combination of high uncertainty and high costs mean that failure can be fatal - a $250,000 6-month long development cycle can kill a project’s entire budget. Even if the research was conducted well by the time the research is complete and the solution architected and implemented, the market may have changed.
In such situations, the better approach is to run many small experiments with limited risk to get market feedback as soon as possible. This requires minimal research and if conducted in a way to contain risk can be much cheaper and quicker.
Startups, more often than not are often operating in this fourth quadrant. This is one of the myriad reasons entrepreneurs from a corporate background often fail. Like the MBAs, they spend all the time (as measured by runway) planning and creating the perfect solution for their ill-defined problem. They only get one chance at validating their approach and thus failure is catastrophic. Had they contained the risk of failure by conducting short experiments they would have had plenty of opportunities to learn and iterate without killing their runway.
Startups should be acting much more like Kindergarteners and embrace experiments by assuming they know nothing.