-
Carlos López
En el post anterior comentábamos que la mayoría de las empresas que se consideran Agile, son Agile únicamente en la construcción de productos digitales, pero no en el resto de fases del ciclo de vida de un producto digital (ver Por qué las empresas Agile no obtienen grandes beneficios), por ejemplo, en la fase de “idear nuevos productos digitales” o haciendo un Business Case.
Lo cierto es que en la mayoría de las organizaciones, siguen habiendo “grandes visionarios”, es decir, personas que tienen la capacidad de decidir que un nuevo producto es necesario en el mercado y que confían la suerte de ese producto a una simple frase: “confiad en mí que sé lo que hago”.
A partir de ahí toca elaborar un Businees Case para poder justificar la inversión de recursos en esa idea de producto. Personalmente no soy fan de los Business Case en la forma tradicional de su elaboración; basicamente porque la justificación del Business Case, en la mayoría de los casos, está fundamentada en proyecciones de muy alto riesgo que se plasman en un excel como si fueran verdades absolutas. Pero lo cierto es que nada o muy poco está demostrado en ese momento y el Business Case acaba siendo un cómplice de una mala inversión y una pérdida de tiempo. O como decía un amigo mío “¿Qué prefieres que haga? ¿Que me pase 2 días elaborando un Business Case sentado en mi oficina o que me pase 2 días hablando con clientes potenciales sobre la idea de tu producto? ¿Qué método te parece que es más fiable para saber realmente lo que pasará en el mercado?”
¿Dónde está el problema a hacerlo de este modo?
Al fin y al cabo:
- Así lo hemos hecho toda nuestra vida, y así nos hemos hecho grandes
- No hay otra forma de hacerlo
El problema es que los clientes (ya sean particulares o empresas) tienen hoy muchísimas opciones en su mano para resolver un problema y es tremendamente complicado adivinar qué es lo que quiere el cliente, cómo se comportará y cómo trabaja su cabeza para decidir si compra un producto o no. Hace 20 años, por ejemplo, un restaurante de barrio podía elaborar un menú simplemente examinando qué personas vivían en el barrio y echando un vistazo a los restaurantes que había en la misma calle que la suya, para no entrar en competencia directa. Pero hoy en día, ese mismo restaurante pone su comida en una plataforma online de envío de comida y todo cambia. ¿Quién es tu cliente tipo? ¿Qué le gusta? ¿Por qué te elige a tí? ¿Quién compite contigo? Es otro mundo, un mundo con infinitas variables donde cada respuesta a una pregunta levanta otras 5 preguntas más. En definitiva, un mundo mucho más complejo.
Es curioso porque esta clase de ejemplos los entiende todo el mundo, pero cuando hablas con profesionales sobre su sector y cómo responden a estas preguntas, llegas a la conclusión de que sus productos están en “plataformas online de envío de comida”, pero siguen elaborando menús como si fueran restaurantes de barrio de hace 20 años.
Con este panorama, las empresas tienen hoy en día un reto tremendo al que no se habían enfrentado antes: de todos los posibles productos que podemos construir, ¿Cómo decidimos cuál construir? ¿Dónde decidimos invertir y poner recursos para su construcción? Porque si lo hacemos como lo hicimos siempre, el producto nace con mucho riesgo, así que… ¡Algo diferente tendremos que hacer!
Esto nos lleva a que la visión tiene que apoyarse en algo más sólido que simplemente decir “confía en mí que sé lo que hago”. Los visionarios, la forma de idear nuevos productos o servicios tiene que ser actualizada con nuevas técnicas que minimicen el riesgo y aumente las probabilidades de éxito. Necesitamos hacer un “upgrade a los visionarios”.
Y esto Google Venture, la rama de inversión de capital riesgo de Google que financia a startups, lo sabe bien y han publicado mucho sobre este tema, como por ejemplo, en el libro “Sprint” de Jake Knapp, fuente de inspiración de los talleres que realizamos en theUncoding con las organizaciones sobre cómo idear productos hoy en día de una manera fiable.
En resumen, Google Venture (y nosotros lo hemos comprobado) dice que sólo es necesario 5 días de trabajo para ayudarnos a asegurar si una idea que pensamos que es potencialmente interesante, realmente tiene el potencial que habíamos previsto o tenemos que adaptarla. En estos 5 días, reuniremos a la gente adecuada, construiremos un prototipo y lo pondremos en manos de 5 clientes potenciales reales. Con eso es suficiente para minimizar el riesgo asociado a una nueva idea.
No voy a pararme a explicar el método de Google Venture en detalle porque eso daría para mucho. Pero sí voy a explicar cuáles son las claves que hemos detectado en theUncoding que marcan la diferencia entre un producto que nace con bajo riesgo y otro que nace sobre un castillo de naipes.
El equipo adecuado
Es muy común que cuando se idean nuevos productos nazcan con un riesgo añadido porque habitualmente se cae en al menos una de estas dos situaciones:
- Hay personas que son fundamentales para el producto y que no están presentes cuando se idea el producto
- No hay una dinámica que ayude a que las personas presentes saquen lo mejor de sí mismo
O dicho de otro modo, quiero elaborar un nuevo menú, pero los cocineros no están presentes. O los cocineros están presentes, pero el gerente impone su criterio (consciente o inconscientemente) y los cocineros apenas participan.
En el caso de la elaboración de nuevos productos digitales (bien sea de software o de hardware) es muy común que no haya ni ingenieros ni diseñadores UX presentes cuando se idea un nuevo producto digital. Y eso a pesar de que tanto ingenieros como diseñadores UX son los expertos en saber qué posibilidades hay de llevar una idea digital a buen puerto.
Pero tan importante como tener a la gente adecuada presente es asegurarnos de que la gente pueda participar para sacar lo mejor de sí mismo individualmente y a nivel de conjunto, porque no vale de nada que digamos “estar, estábamos todos” si después no favorecemos con una dinámica en la que triunfen las mejores ideas independientemente de quién las emite.
El prototipo
Un prototipo no es un MVP (Mínimo Producto Viable) porque un prototipo no es un producto, sino algo que construyes sabiendo que lo vas a tirar a la basura.
Y es importante el matiz, porque si tu sabes que algo lo vas a tirar a la basura… ¿Te enamoras de él? ¿Vas a invertir mucho tiempo y esfuerzo para que esté bonito? ¿Te va a doler si alguien lo critica? No. Vas a usarlo para tu propósito. Sin más.
Ahora bien, que tu sepas que el prototipo acabará en la basura no significa que el cliente tenga que pensar cuando ve el prototipo “esto es basura”. Para el cliente, el prototipo es una versión bastante realista del producto y a todos los efectos, el pensará que está tocando un producto.
No importa si el prototipo es software, hardware, un servicio…. Se puede hacer prototipo de prácticamente cualquier cosa, y además muy rápido. Desde robots a salas de espera de un centro médico o, por supuesto, aplicaciones en móvil.
Y esa es la clave y donde se equivocan muchas empresas que son Agile (o dicen serlo): se pasan 3 meses elaborando un MVP (que a todos los efectos es un producto construido, aunque tenga defectos “perdonables” por los early adopters) mientras que Google Venture trabaja en 5 días para construir un prototipo de cartón-piedra y llevarlos a 5 clientes potenciales para tener conclusiones en esa misma semana. La diferencia entre Google y el resto.
Las 5 entrevistas
Google Venture valida el prototipo el último día de la semana con 5 clientes potenciales. Clientes potenciales no son amigos, ni familiares, ni compañeros que tenemos al lado ni, por supuesto, el CEO y Directores Generales.
5 clientes potenciales son lo que son: 5 personas que en teoría deberían de estar dispuestos a usar / pagar por tu producto y que seguro que no conoces personalmente.
¿Por qué 5 clientes y no 20?
Porque se basan en un estudio publicado por Jackob Nielsen que dice que con 5 entrevistas se cubre el 85% de los comportamientos y es suficiente para extraer conclusiones. Realizar más de 5 entrevistas nos generará mucho trabajo y no traerá nuevas y reveladoras conclusiones. De esta forma, cuando vemos que un comportamiento es parecido en 3 o 4 personas es muy probable que ese comportamiento sea generalizado.
O dicho de otro modo: si entrevistas a 5 personas y no entienden por qué tu producto es mejor que el de la competencia o esas 5 personas no pueden explicar los puntos clave de tu producto fácilmente, no pienses “es que estas personas no tienen ni idea, ¡¡la culpa es de ellas que no saben ni entender algo tan sencillo!!”. Más bien piensa “menos mal que estas 5 personas me están diciendo claramente por qué mi producto no está funcionando como espero. Tengo mucho trabajo por delante”.
¿Qué es lo más interesante de este método?
Primero, nos confirma que la Agilidad es tremendamente útil no sólo en el desarrollo de software, sino también en la elaboración de productos o servicios de cualquier naturaleza y de cualquier sector.
Y por supuesto, el resultado final del ejercicio. El llevar un prototipo construido con las mejores ideas fruto de la colaboración y teniendo en cuenta varios puntos de vista a 5 clientes potenciales, te da unas conclusiones que dejan a todos con la boca abierta. Entre cafés se comenta “menos mal que hicimos este ejercicio porque nos iba a costar mucho después rehacer el camino” y el CEO piensa “ahora entiendo de verdad el valor de la Agilidad”.
Y esa es la clave. Nos ayuda a tomar mejores decisiones. Es Agilidad en estado puro. Pasamos de estar ciegos a ver el paisaje, de “cree en mí y financia mi idea, que seguro que acierto” a “tenemos que asegurar que esto tiene sentido antes de poner 1€ encima de la mesa”. Y todo en 5 días. El valor de Agile.
