Entender la innovación · Parte I · Los fundamentos
02 · El problema antes que la idea
11 min de lectura
En síntesis
- Los procesos de innovación pueden partir de la tecnología en busca de un uso (technology push) o de una necesidad en busca de una solución (market pull). Los procesos reales son iterativos, pero el punto de partida determina el riesgo dominante: quien parte de la tecnología corre el riesgo de construir lo que nadie quiere.
- La literatura sobre los jobs-to-be-done (trabajos por hacer) desplaza la unidad de análisis del producto a la tarea: las personas no compran productos, contratan soluciones para realizar un trabajo. Entender el trabajo viene antes que diseñar la solución.
- Un problema se valida como se valida una tecnología. Los criterios son medibles: frecuencia, coste para quien lo padece, disposición a pagar por no tenerlo, fiabilidad de la fuente que lo comunica.
- El punto más barato para parar una iniciativa destinada a fracasar es antes de que el desarrollo empiece: cada fase posterior multiplica el coste del error. El análisis del problema es, por tanto, la fase con la mejor relación entre coste y reducción del riesgo de todo el proceso.
Sección 1
Dos direcciones de marcha: push y pull
Los modelos históricos del proceso innovador describen dos direcciones de marcha opuestas. El modelo technology push, asociado al informe de Vannevar Bush Science, the Endless Frontier (1945), describe un flujo lineal que parte de la investigación básica, pasa por la investigación aplicada y el desarrollo, y termina en el mercado: la ciencia produce conocimiento, el conocimiento produce tecnología, la tecnología encuentra usos. El modelo market pull, formulado en reacción al primero (Schmookler, 1966), invierte la flecha: es la demanda, la necesidad expresada por el mercado, la que orienta el desarrollo tecnológico; la invención sigue a la oportunidad económica.
La investigación posterior ha mostrado que ambos modelos lineales describen mal los procesos reales. El modelo de enlaces en cadena de Kline y Rosenberg (1986) documenta que la innovación procede por iteraciones con retroalimentaciones continuas: del mercado al diseño, del diseño a la investigación, de la producción de nuevo al diseño. El conocimiento científico no es una fuente aguas arriba, sino una reserva a la que el proceso recurre en cualquier punto cuando encuentra un obstáculo.
Si los modelos lineales son descriptivamente falsos, siguen siendo, sin embargo, diagnósticamente útiles, porque el punto de partida de un proyecto determina qué riesgo domina. Un proyecto que parte de la tecnología (un laboratorio ha desarrollado un material, un algoritmo, un proceso, y busca dónde aplicarlo) tiene típicamente un riesgo tecnológico reducido y un riesgo de mercado intacto: la pregunta "¿funciona?" ya tiene una respuesta parcial, la pregunta "¿le sirve a alguien, lo bastante como para pagarlo?" todavía no se ha planteado. Un proyecto que parte del problema tiene la estructura opuesta. La mortalidad de las startups se inclina claramente hacia el primer lado: los análisis recurrentes sobre las causas de fracaso (entre ellos las series publicadas por CB Insights sobre las autopsias declaradas por los fundadores) sitúan de forma estable en el primer puesto la ausencia de necesidad de mercado, muy por encima de los fracasos técnicos. Construir lo que nadie quiere es el error más frecuente y más costoso del sector, y es un error que se comete por completo antes de darse cuenta, porque la tecnología que funciona produce señales de progreso (prototipos, demostraciones, patentes) incluso cuando avanza hacia un mercado que no existe.
De ahí la regla metodológica que da título al capítulo: el problema viene antes que la idea. No porque las ideas no cuenten, sino porque una idea es una respuesta, y la calidad de una respuesta no puede evaluarse hasta que la pregunta se ha formulado con precisión.
Sección 2
El trabajo por hacer: la unidad de análisis correcta
Formular la pregunta con precisión requiere elegir la unidad de análisis adecuada, y la literatura sobre los jobs-to-be-done (Christensen, Hall, Dillon y Duncan, Competing Against Luck, 2016, sobre una intuición que se remonta a Levitt) propone la más útil: no el producto, no el cliente como perfil demográfico, sino el trabajo que el cliente está intentando realizar. Las personas no compran un taladro porque quieran un taladro: contratan el taladro para obtener un agujero, y contratan el agujero para colgar una estantería. El competidor de un producto no es solo el producto similar: es cualquier otra forma de realizar el mismo trabajo, incluida la opción de no realizarlo en absoluto.
El ejemplo empírico más citado de esta literatura es el estudio sobre los batidos de una cadena estadounidense de comida rápida, realizado por el grupo de Christensen. La empresa había intentado mejorar el producto preguntando a los clientes por los atributos (¿más espeso? ¿más dulce? ¿más fruta?) sin efecto sobre las ventas. La observación directa reveló que casi la mitad de los batidos se vendía a primera hora de la mañana a personas que viajaban solas en coche al trabajo: el trabajo para el que se contrataba el batido no era alimentarse, sino ocupar un trayecto largo y aburrido con algo limpio, manejable con una mano y capaz de durar veinte minutos. Los competidores reales eran plátanos, barritas y rosquillas, todos peores en esas dimensiones. La mejora eficaz (más espeso, con trozos de fruta que alargan la duración, dispensación más rápida) se derivaba del trabajo, no de los atributos.
Para el análisis de un problema, la perspectiva del trabajo por hacer produce tres preguntas operativas. ¿En qué proceso vive el problema, es decir, cuál es el trabajo completo dentro del cual se sitúa el punto de dolor? ¿Cómo se realiza hoy el trabajo, con qué soluciones, y dónde exactamente fallan o cuestan? ¿Y qué dimensiones de la solución cuentan de verdad para quien realiza el trabajo, que a menudo no son las técnicamente más interesantes? La descomposición del proceso actual en sus etapas, con la identificación del punto exacto del dolor, es el método por el que un problema declarado ("perdemos demasiado tiempo con X") se convierte en un problema analizado (en qué etapa, cuántas veces, con qué coste unitario, para quién).
Sección 3
Validar un problema: los criterios
Un problema, como una hipótesis tecnológica, puede validarse o refutarse. Los criterios son cuatro, y cada uno es medible o al menos estimable con evidencia recogida sobre el terreno.
Frecuencia. Cuántas veces se presenta el problema, para cuántos sujetos. Un problema grave pero raro y un problema leve pero cotidiano tienen economías completamente distintas; el producto de la frecuencia por la gravedad es una primera aproximación a la dimensión del dolor, y por tanto del mercado potencial.
Coste. Cuánto cuesta el problema a quien lo padece, en dinero, tiempo, riesgo o calidad. El coste debe medirse sobre el proceso real, no declararse en abstracto: la descomposición en etapas de la sección anterior sirve exactamente para localizar y cuantificar el coste.
Disposición a pagar. La pregunta decisiva, y la más difícil, porque la respuesta declarada es sistemáticamente poco fiable: casi todos declaran interés por una solución hipotética, muchos menos la compran cuando existe. Las evidencias fuertes son conductuales: ¿alguien paga ya hoy soluciones parciales o artesanales? ¿dedica tiempo y recursos propios a sortear el problema? ¿firma una carta de intenciones, un pedido anticipado, un piloto de pago? La jerarquía de la evidencia va de lo declarado (débil) a lo contractual (fuerte), y el capítulo 07 retomará el tema en el marco general de la validación de hipótesis.
Fiabilidad de la fuente. ¿Quién trae el problema, y desde qué posición? Un problema comunicado por quien lo padece a diario desde hace años, dentro del proceso productivo en el que vive, tiene un estatuto distinto de un problema hipotetizado leyendo informes sectoriales. La mejor fuente es el portador directo con experiencia larga e interés concreto en la solución; la peor es la intuición de quien nunca ha visto el proceso. Entre las dos hay una gradación que debe declararse y ponderarse.
Un quinto criterio, transversal, se refiere a la solución que eventualmente ya exista: si el problema es real y nadie lo ha resuelto todavía, la pregunta "¿por qué?" merece una respuesta explícita. Las respuestas aceptables son de tres tipos: la tecnología habilitante es reciente, el problema es reciente, o bien las soluciones existentes son demostrablemente ineficaces o ineficientes en un punto identificable. Si ninguna de las tres se sostiene, la hipótesis más probable es que el problema no supere los tres primeros criterios, y que el silencio del mercado sea información, no oportunidad.
Sección 4
La economía de parar pronto
La última razón por la que el problema viene antes que la idea es económica, y vale la pena hacerla explícita porque gobierna toda la arquitectura de los procesos por fases que el capítulo 07 tratará en detalle.
El coste de parar una iniciativa crece en órdenes de magnitud a lo largo del recorrido. Parar durante el análisis del problema cuesta días o semanas de trabajo de investigación. Parar después del desarrollo de un prototipo cuesta meses de trabajo técnico y el capital que los ha financiado. Parar después del lanzamiento cuesta todo esto más la industrialización, el marketing y el coste de oportunidad de las alternativas no perseguidas entretanto. La literatura sobre desarrollo de producto formaliza el principio con la regla empírica de la amplificación de los costes entre fases; el número exacto varía según el sector, la dirección no.
De ello se sigue una consecuencia contraintuitiva: la fase de análisis del problema, que es la menos costosa de todo el proceso, es la de máximo rendimiento por euro gastado, porque es el punto en el que la información capaz de matar un proyecto equivocado cuesta menos. Un proceso de innovación bien diseñado no trata, por tanto, el análisis del problema como una formalidad que despachar para llegar a la parte interesante: lo trata como el filtro principal, y considera cada proyecto parado en esta fase un éxito del método, no un fracaso. La disciplina de matar pronto y a bajo coste las iniciativas que no merecen continuar es lo que hace sostenible una cartera de proyectos de resultado incierto, como se verá en los capítulos 08 y 10.
En el método Volcano
El capítulo funda la elección más característica del camino Volcano: el recorrido no empieza por la idea, sino por el problema, y las dos primeras fases (F1, captura del problema; F2, análisis del problema) las recorre Volcano antes de que la startup exista. La fase F1 implementa el criterio de la fiabilidad de la fuente: el problema entra en la red traído por quien lo padece, a través de canales identificados (clientes, consultoría, aliados, el canal directo "cuéntanos tu problema"). La fase F2 implementa los demás criterios de la sección 3: el proceso actual descompuesto en sus etapas, el punto exacto del dolor, frecuencia, coste y disposición a pagar, el examen pieza por pieza de la eventual solución existente para verificar que es de verdad ineficaz o ineficiente. La pregunta que cierra F2 ("¿es frecuente, costoso, y alguien pagaría por no tenerlo?") es la primera de las siete decisiones, y el método la declara explícitamente el punto más barato para dejar morir una idea, en coherencia con la sección 4. La primera de las seis palancas de reducción del riesgo (problemas ya validados, no ideas) es la síntesis de todo el capítulo, y la matriz problema-solución es su instrumento operativo.
Lecturas
Para profundizar
- S.J. Kline y N. Rosenberg, "An Overview of Innovation" (1986): el modelo de enlaces en cadena que cerró la época de los modelos lineales; lectura densa pero breve.
- C.M. Christensen, T. Hall, K. Dillon y D.S. Duncan, Competing Against Luck (2016): el tratamiento completo de los jobs-to-be-done, con el caso de los batidos y el método de investigación.
- A. Osterwalder, Y. Pigneur, G. Bernarda y A. Smith, Value Proposition Design (2014): la traducción operativa del análisis del trabajo del cliente en herramientas de diseño.
- R. Fitzpatrick, The Mom Test (2013): breve manual práctico sobre cómo preguntar a los portadores de un problema sin obtener respuestas de cortesía; antídoto útil contra la poca fiabilidad de lo declarado.
Preguntas frecuentes
Preguntas frecuentes
¿No basta con preguntar a los clientes qué quieren?
No, por dos razones documentadas. Las respuestas declaradas sobre soluciones hipotéticas son sistemáticamente optimistas: casi todos se dicen interesados, muchos menos compran. Y los clientes formulan las necesidades en los términos de las soluciones que conocen, pidiendo versiones mejores de lo existente. La investigación eficaz observa el comportamiento (qué pagan ya, cómo sortean el problema, qué firman) y reconstruye el trabajo por hacer, no las preferencias declaradas.
¿Un problema que nadie ha resuelto todavía es siempre una oportunidad?
No: el silencio del mercado es información. La ausencia de soluciones es compatible con una oportunidad solo si se sostiene una de tres explicaciones: la tecnología habilitante es reciente, el problema es reciente, o bien las soluciones existentes fallan en un punto identificable y demostrable. Si ninguna se sostiene, la hipótesis más probable es que el problema no supere los criterios de frecuencia, coste o disposición a pagar.
¿Partir de la tecnología es, entonces, siempre un error?
No: muchas innovaciones importantes han nacido technology push, y un venture builder recibe legítimamente tecnologías en busca de aplicación. El error no es el punto de partida, sino la falta de gestión del riesgo que ese punto de partida conlleva: quien parte de la tecnología tiene el riesgo de mercado intacto, y debe recorrer de todos modos el análisis del problema (para qué trabajo, de quién, con qué coste actual) antes de invertir en el desarrollo. El punto de partida determina el orden de las validaciones, no su necesidad.
¿Parar un proyecto en fase de análisis no es admitir un fracaso?
Es lo contrario: es el método que funciona. Cada fase posterior multiplica el coste del error, de modo que una iniciativa destinada a no sostenerse que se para cuando solo ha consumido semanas de investigación es capital salvado y reasignado a alternativas mejores. En una cartera de proyectos de resultado incierto, la disciplina de matar pronto es lo que financia los proyectos que merecen continuar.
John F. Kennedy, 1962