Solo el 5 % de las buenas ideas llega a funcionar de verdad: qué las mata en el camino
Parte de la serie sobre tiempo de respuesta a los contactos
Itamar Gilad estima que solo un 5 % de las ideas de alto valor llega a producción cumpliendo su potencial. Dónde se caen y qué cambia en el último tramo.
Hay una estimación incómoda circulando sobre el desarrollo de producto. Es de Itamar Gilad, en Why Good Product Ideas Don't Survive.
Si se encadenan las tasas de supervivencia que él estima para cada fase del embudo clásico —un 20 % de las buenas ideas sobrevive a la priorización, un 40 % de ésas llega intacta a la especificación, un 50 % de ésas se construye como se pensó, y algo se recupera iterando después del lanzamiento— resulta que alrededor del 5 % de las ideas genuinamente valiosas llega a producción cumpliendo lo que prometía.
El número exacto es discutible, y el propio Gilad lo dice: los porcentajes de cada fase son suyos, no medidos, y si se le da a cada fase cuatro veces más margen le sale una de cada cinco. El mecanismo que describe no lo es tanto, y se reconoce en cualquier empresa que haya intentado automatizar algo: la idea era buena, la prueba salió bien, y hoy nadie la usa.
Lo interesante es dónde se cae, porque no es donde la gente supone.
Las ideas no se rechazan, se quedan
Un rechazo es información. Alguien mira una propuesta, decide que no, y explica por qué: no hay presupuesto, no es el momento, no es prioritario. Se puede volver con ella más adelante.
Lo que mata las ideas es lo otro: quedarse en un punto donde nadie decide nada. Está sobre la mesa, no está descartada, y va bajando de posición cada vez que entra algo más urgente.
El problema no es la decisión, es la ausencia de decisión. Y tiene un coste que no aparece en ningún sitio: la persona que la empujaba deja de empujar. No por enfado, por agotamiento. La próxima vez que tenga una idea parecida, ya sabe lo que pasa con ellas.
El tramo donde se cae de verdad
Cuando se pregunta dónde fallan estos proyectos, la respuesta habitual es «al principio, eligiendo mal». A veces. Pero el tramo que más se lleva es el último: el que va de funciona en una demo a funciona un martes cualquiera.
Una demo se prepara. Se elige el caso que sale bien, los datos están limpios, alguien está mirando la pantalla. En producción entra lo que entra: el formulario a medio rellenar, el nombre en mayúsculas, el caso que nadie previó, el día que el proveedor cambió el formato sin avisar.
Ese tramo no es «más código». Es:
- qué pasa cuando llega algo que no encaja
- quién se entera de que ha fallado
- qué se hace mientras está caído
- quién lo mantiene en tres meses
- qué permisos hacen falta y quién los da
Nada de eso sale en la demo, y todo eso decide si el proyecto sirve. Sobre esto exactamente hemos escrito aparte: por qué hacer el prototipo ya no es el problema.
Un piloto no es una demo
Las dos palabras se usan igual y significan cosas opuestas.
Una demo responde a: ¿esto es posible? Se prepara para convencer, y está bien que lo haga.
Un piloto responde a: ¿merece la pena? Y para eso necesita, escrito antes de empezar, dos cosas:
- Qué número tiene que moverse. No «que vaya mejor». Un número con su valor de partida medido: cuántas horas, cuántos minutos de respuesta, cuántos casos sin atender.
- Quién decide mirándolo. Una persona con nombre, y qué resultado la haría seguir adelante o parar.
Si esas dos cosas no están escritas, lo que se ha encargado es una demo. Puede gustar mucho y no cambiar nada, que es exactamente el resultado más frecuente.
El orden que sobrevive
Lo que hemos visto funcionar no tiene nada de sofisticado:
Medir antes. El número de partida, con el método escrito. Si no hay número antes, no hay forma de defender el después. Para el caso de los tiempos de respuesta, el método completo está en cómo medir tu tiempo de primera respuesta.
Elegir el proceso más repetido, no el más aparatoso. Un proceso diario da datos en dos semanas. Uno mensual, en medio año.
Probar con los datos sucios. Los peores que tengas, no los mejores. Ahí se ve si aguanta.
Poner fecha de decisión desde el día uno. Un piloto sin fecha de cierre se convierte en un proyecto permanente en fase de pruebas, que es la forma más elegante de no decidir nunca.
Dejarlo funcionando sin quien lo construyó. Si depende de que esa persona esté disponible, no está en producción: está en demo prolongada.
Lo que el 5 % tiene en común
No es que fueran mejores ideas. Es que alguien se ocupó del último tramo cuando ya no era emocionante: cuando quedaban los casos raros, los permisos, el documento de qué hacer si falla un domingo.
Ese tramo no luce en ninguna presentación. Es donde se decide si la idea existe o solo existió en una reunión.
Preguntas frecuentes
¿Por qué una prueba de concepto que funcionaba no llega a usarse?
Casi siempre porque la prueba se hizo en condiciones que no existen el resto del año: datos limpios, un caso bien elegido, alguien pendiente de que saliera bien. En producción entran datos incompletos, casos raros y gente que tiene otras cosas que hacer. El salto no es técnico, es de condiciones.
La forma de adelantarse es hacer la prueba con los datos más sucios que tengas, no con los mejores. Si aguanta ahí, aguantará después.
¿Qué distingue un piloto útil de una demo bonita?
Que el piloto tiene escrito, antes de empezar, qué número tiene que moverse y quién va a decidir mirándolo. Una demo demuestra que algo es posible; un piloto responde a si merece la pena. Son dos preguntas distintas y se preparan distinto.
Si nadie sabe decir qué resultado haría que se siguiera adelante, lo que se ha encargado es una demo, aunque se llame piloto.
¿Cuánto debe durar la prueba antes de decidir?
El tiempo suficiente para que el proceso se repita bastantes veces, que en un proceso diario son unas dos semanas. Ni tres días —los datos no dan— ni tres meses, porque a partir de cierto punto la decisión ya está tomada y solo se está retrasando por escrito.
¿Quién debería llevar el último tramo, del prototipo al uso real?
Alguien con el mandato de tocar lo que haga falta y la obligación de dejarlo funcionando sin él. Ese tramo no es más código: es permisos, casos raros, qué pasa cuando falla, quién lo mira el mes que viene. Si no tiene dueño, es donde el proyecto se queda.
Si tienes algo parado en ese último tramo —una prueba que funcionó y no se usa, un proceso que se automatizó a medias— el diagnóstico gratuito es media hora mirando qué falta exactamente para que funcione sin nadie encima. Ese último tramo es el que cubre del prototipo a producción.
Cuando lo que hay que arreglar es la entrada de contactos, lo que hacemos está en la página del sistema de respuesta a los contactos: primera respuesta con contenido en menos de 60 segundos a cualquier hora, la pregunta que falta hecha, y el aviso al comercial que le toca con el contexto preparado. Sin tarifa publicada: el alcance y el importe se cierran por escrito después del diagnóstico.