Understanding innovation · Part I · The fundamentals
02 · The problem before the idea
11 min de lectura
In brief
- Innovation processes can start from a technology in search of a use (technology push) or from a need in search of a solution (market pull). Real processes are iterative, but the starting point determines the dominant risk: whoever starts from the technology risks building what nobody wants.
- The jobs-to-be-done literature moves the unit of analysis from the product to the task: people do not buy products, they hire solutions to get a job done. Understanding the job comes before designing the solution.
- A problem has to be validated the way a technology is validated. The criteria are measurable: frequency, cost to whoever suffers it, willingness to pay in order not to have it, reliability of the source that reports it.
- The cheapest point at which to stop an initiative destined to fail is before development begins: every subsequent phase multiplies the cost of the error. Problem analysis is therefore the phase with the best ratio between cost and risk reduction in the whole process.
Section 1
Two directions of travel: push and pull
The historical models of the innovation process describe two opposite directions of travel. The technology push model, associated with Vannevar Bush's report Science, the Endless Frontier (1945), describes a linear flow that starts from basic research, passes through applied research and development, and ends in the market: science produces knowledge, knowledge produces technology, technology finds uses. The market pull model, formulated in reaction to the first (Schmookler, 1966), reverses the arrow: it is demand, the need expressed by the market, that directs technological development; invention follows the economic opportunity.
Later research has shown that both linear models describe real processes badly. The chain-linked model of Kline and Rosenberg (1986) documents that innovation proceeds by iterations with continuous feedback: from the market to the design, from the design to research, from production back to the design. Scientific knowledge is not a source upstream but a reserve on which the process draws at every point when it meets an obstacle.
If the linear models are descriptively false, they nevertheless remain diagnostically useful, because the starting point of a project determines which risk dominates. A project that starts from the technology (a laboratory has developed a material, an algorithm, a process, and is looking for somewhere to apply it) typically has reduced technological risk and market risk still intact: the question "does it work?" already has a partial answer, the question "does anybody need it, enough to pay for it?" has not yet been asked. A project that starts from the problem has the opposite structure. Startup mortality leans clearly towards the first side: the recurring analyses of causes of failure (among them the series published by CB Insights on the post-mortems declared by founders) put the absence of a market need stably in first place, well above technical failures. Building what nobody wants is the most frequent and most costly error in the sector, and it is an error you commit in full before you notice it, because technology that works produces signals of progress (prototypes, demos, patents) even when it is advancing towards a market that does not exist.
Hence the methodological rule that gives the chapter its title: the problem comes before the idea. Not because ideas do not count, but because an idea is an answer, and the quality of an answer cannot be assessed until the question has been formulated precisely.
Section 2
The job to be done: the correct unit of analysis
Formulating the question precisely requires choosing the right unit of analysis, and the jobs-to-be-done literature (Christensen, Hall, Dillon and Duncan, Competing Against Luck, 2016, on an insight that goes back to Levitt) proposes the most useful one: not the product, not the customer as a demographic profile, but the job the customer is trying to get done. People do not buy a drill because they want a drill: they hire the drill to obtain a hole, and they hire the hole to hang a shelf. The competitor of a product is not only the similar product: it is any other way of getting the same job done, including the option of not doing it at all.
The most cited empirical example in this literature is the study of milkshakes at a United States fast food chain, carried out by Christensen's group. The company had tried to improve the product by asking customers about attributes (thicker? sweeter? more fruit?) with no effect on sales. Direct observation revealed that almost half the milkshakes were sold early in the morning to commuters alone in their cars: the job for which the milkshake was hired was not nourishment but filling a long and boring journey with something clean, manageable with one hand and able to last twenty minutes. The real competitors were bananas, cereal bars and doughnuts, all of them worse on those dimensions. The effective improvement (thicker, with pieces of fruit that extend its duration, faster dispensing) followed from the job, not from the attributes.
For the analysis of a problem, the job-to-be-done perspective produces three operational questions. In which process does the problem live, that is, what is the complete job within which the point of pain sits? How is the job done today, with which solutions, and where exactly do these fail or cost? And which dimensions of the solution really count for the person doing the job, which are often not the technically most interesting ones? Breaking the current process down into its stages, with the identification of the exact point of pain, is the method by which a stated problem ("we lose too much time on X") becomes an analysed problem (at which stage, how many times, at what unit cost, for whom).
Section 3
Validating a problem: the criteria
A problem, like a technological hypothesis, can be validated or refuted. There are four criteria, and each is measurable or at least estimable with evidence gathered in the field.
Frequency. How many times the problem occurs, for how many subjects. A serious but rare problem and a slight but daily problem have completely different economics; frequency multiplied by severity is a first approximation of the size of the pain, and therefore of the potential market.
Cost. How much the problem costs those who suffer it, in money, time, risk or quality. The cost must be measured on the real process, not stated in the abstract: the breakdown into stages in the previous section serves exactly to locate and quantify the cost.
Willingness to pay. The decisive question, and the most difficult, because the stated answer is systematically unreliable: almost everyone declares an interest in a hypothetical solution, far fewer buy it when it exists. The strong evidence is behavioural: is somebody already paying today for partial or improvised solutions? Do they devote their own time and resources to working around the problem? Do they sign a letter of intent, a pre-order, a paid pilot? The hierarchy of evidence runs from the stated (weak) to the contractual (strong), and chapter 07 will take up the theme within the general frame of hypothesis validation.
Reliability of the source. Who brings the problem, and from what position? A problem reported by someone who has suffered it daily for years, inside the production process in which it lives, has a different status from a problem hypothesised while reading sector reports. The best source is the direct bearer with long experience and a concrete interest in the solution; the worst is the intuition of someone who has never seen the process. Between the two there is a gradation that has to be declared and weighted.
A fifth, cross-cutting criterion concerns any solution that already exists: if the problem is real and nobody has yet solved it, the question "why?" deserves an explicit answer. Acceptable answers are of three kinds: the enabling technology is recent, the problem is recent, or the existing solutions are demonstrably ineffective or inefficient at an identifiable point. If none of the three holds, the most probable hypothesis is that the problem does not pass the first three criteria, and that the silence of the market is information, not opportunity.
Section 4
The economics of stopping early
The last reason why the problem comes before the idea is economic, and it is worth making explicit because it governs the whole architecture of the phased processes that chapter 07 will treat in detail.
The cost of stopping an initiative grows by orders of magnitude along the path. Stopping during problem analysis costs days or weeks of investigative work. Stopping after the development of a prototype costs months of technical work and the capital that financed them. Stopping after launch costs all this plus industrialisation, marketing, and the opportunity cost of the alternatives not pursued in the meantime. The product development literature formalises the principle with the empirical rule of cost amplification between phases; the exact number varies by sector, the direction does not.
A counter-intuitive consequence follows: the problem analysis phase, which is the least costly of the whole process, is the one with the highest return per euro spent, because it is the point at which the information capable of killing a wrong project costs least. A well designed innovation process therefore does not treat problem analysis as a formality to be dispatched in order to reach the interesting part: it treats it as the main filter, and considers every project stopped in this phase a success of the method, not a failure. The discipline of killing early and cheaply the initiatives that do not deserve to continue is what makes a portfolio of projects with uncertain outcomes sustainable, as we shall see in chapters 08 and 10.
In the Volcano method
This chapter grounds the most characteristic choice of the Volcano path: the route does not begin with the idea but with the problem, and the first two phases (F1, capture of the problem; F2, analysis of the problem) are travelled by Volcano before the startup exists. Phase F1 implements the criterion of the reliability of the source: the problem enters the network brought by whoever suffers it, through identified channels (customers, consultancy, allies, the direct channel "cuéntanos tu problema"). Phase F2 implements the other criteria of section 3: the current process broken down into its stages, the exact point of pain, frequency, cost and willingness to pay, the piece-by-piece examination of any existing solution to verify that it really is ineffective or inefficient. The question that closes F2 ("is it frequent, is it costly, and would anyone pay not to have it?") is the first of the seven decisions, and the method explicitly declares it the cheapest point at which to let an idea die, consistently with section 4. The first of the six risk-reduction levers (problems already validated, not ideas) is the synthesis of the whole chapter, and the problem-solution matrix is its operational instrument.
Readings
Further reading
- S.J. Kline and N. Rosenberg, "An Overview of Innovation" (1986): the chain-linked model that closed the era of linear models; a dense but short read.
- C.M. Christensen, T. Hall, K. Dillon and D.S. Duncan, Competing Against Luck (2016): the complete treatment of jobs-to-be-done, with the milkshake case and the method of investigation.
- A. Osterwalder, Y. Pigneur, G. Bernarda and A. Smith, Value Proposition Design (2014): the operational translation of the analysis of the customer's job into design instruments.
- R. Fitzpatrick, The Mom Test (2013): a short practical manual on how to question the bearers of a problem without obtaining polite answers; a useful antidote to the unreliability of the stated.
Frequently asked questions
Frequently asked questions
Is it not enough to ask customers what they want?
No, for two documented reasons. Stated answers about hypothetical solutions are systematically optimistic: almost everyone says they are interested, far fewer buy. And customers formulate their needs in the terms of the solutions they know, asking for better versions of what exists. Effective investigation observes behaviour (what they already pay for, how they work around the problem, what they sign) and reconstructs the job to be done, not the stated preferences.
Is a problem that nobody has yet solved always an opportunity?
No: the silence of the market is information. The absence of solutions is compatible with an opportunity only if one of three explanations holds: the enabling technology is recent, the problem is recent, or existing solutions fail at an identifiable and demonstrable point. If none holds, the most probable hypothesis is that the problem does not pass the criteria of frequency, cost or willingness to pay.
Is starting from the technology therefore always a mistake?
No: many important innovations were born technology push, and a venture builder legitimately receives technologies in search of an application. The error is not the starting point but the failure to manage the risk that this starting point entails: whoever starts from the technology has market risk intact, and must in any case go through the analysis of the problem (for which job, whose, at what current cost) before investing in development. The starting point determines the order of the validations, not their necessity.
Is stopping a project at the analysis phase not an admission of failure?
It is the opposite: it is the method working. Every subsequent phase multiplies the cost of the error, so an initiative destined not to hold up that is stopped when it has consumed only weeks of investigation is capital saved and reallocated to better alternatives. In a portfolio of projects with uncertain outcomes, the discipline of killing early is what finances the projects that deserve to continue.
John F. Kennedy, 1962