Seguimiento del ciclo de vida de innovación
Tailwind Traders se plantea preguntas sobre la innovación que afectan también a muchas otras organizaciones:
- ¿Cómo aumentamos el ritmo de cambio sin afectar a la marcha del negocio?
- ¿Cómo se decide dónde innovar y qué cambios implementar para maximizar la rentabilidad empresarial de esas innovaciones?
La respuesta a ambas preguntas es que Tailwind Traders debe adoptar el cambio como parte de su cultura de organización. Una razón por la que las organizaciones con aversión al cambio a menudo tienen interrupciones relacionadas con los cambios es que estos son demasiado grandes e impactantes. Los cambios son difíciles de probar en entornos controlados y realistas.
Si se establecen procesos para introducir cambios con frecuencia, esos cambios son más pequeños en cuanto a tamaño y riesgo. Pero este proceso no solo implica la adopción de ciertas herramientas o tecnologías. También requiere una cultura que fomenta el cambio y acepta los errores.
El concepto de aceptación de errores puede parecer contraproducente, pero es fundamental para el ciclo de innovación. Si las personas temen cometer errores porque les sitúan en el centro del juego de búsqueda de culpables, es probable que no persigan nuevos enfoques para resolver problemas ante el miedo a cometer errores. Entonces, toda la organización se convierte en presa de sus prácticas establecidas.
Es posible establecer una cultura de "fracasar y responder rápido a los errores" en la que se anima a las personas a probar nuevos métodos. Se les capacita para cambiar rápidamente la dirección en caso de no obtener el resultado esperado, lo que permite crear una cultura de innovación más rica.
Innovación basada en hipótesis
Podría describir la innovación como un ciclo iterativo basado en hipótesis. Cuando se identifica la existencia de un problema, se pueden formular una o varias hipótesis que puedan explicar la causa principal y llevar a la solución. La definición del propio problema puede suponer un desafío, ya que debe ser medible.
Por ejemplo, la definición del problema "Los clientes no están satisfechos con nuestra opción de plataforma de pago" no es medible, por lo que es difícil de resolver. Si puede definir el problema como "El 23 % de los clientes abandonan su sesión de compra en el paso en el que tienen que elegir la plataforma de pago", estará en una posición mejor para medir el éxito de cualquier posible solución.
Después de definir un problema de forma medible, puede formular hipótesis que puedan explicar y resolver el problema. Por ejemplo, una hipótesis para Tailwind Traders podría describirse como: "Agregar ContosoPay a nuestras plataformas de pago admitidas reduciría el abandono de clientes en la página de pago del 23 % al 10 %". Ahora hay una idea sobre la mesa y actuar sobre ella es cuestión de comprobar su validez.
Las hipótesis deben centrarse en agregar valor a los clientes y mejorar su experiencia en las interacciones con la organización. Esta idea se conoce como empatía con el cliente: coloca al cliente en el centro de la innovación y se centra en aumentar el valor para ellos y para usted.
Hay muchas maneras de validar una hipótesis sin tocar el código de la aplicación. Las encuestas de clientes y la investigación de mercado son dos ejemplos de valiosas fuentes de información que pueden ayudar a decidir la validez de una hipótesis. La comprobación de estas fuentes permite calificar su hipótesis y seguir adelante con aquellas con mayor probabilidad de precisión y valor empresarial agregado.
Compilar
Una vez que una hipótesis tiene un potencial de valor suficiente para compilarse en la aplicación, se inicia el proceso de compilación. Aquí la velocidad es, de nuevo, fundamental.
Los sprints de desarrollo deben ser lo más cortos posible. Mantener sprints permite confirmar o rechazar rápidamente la hipótesis. También permite perfeccionar la forma en que se integra la función necesaria en la aplicación. El resultado son ciclos de innovación más rápidos.
Measure
Se quiere comprobar la precisión de la hipótesis lo antes posible. Un producto mínimo viable (MVP) es una versión preliminar de la función nueva que recopila información y permite confirmar si se está avanzando en la dirección correcta.
El objetivo del MVP no solo es comprobar su hipótesis, sino también cualquier supuesto que pueda haber hecho. Por ejemplo, si el 23 % de los clientes de Tailwind Traders abandonan el proceso de compra en la página de pago, la hipótesis sostendrá que el motivo es que la empresa no ofrece suficientes plataformas de pago. Sin embargo, el motivo podría ser distinto. El MVP debe diseñarse para confirmar o rechazar estos supuestos y la hipótesis.
Learn
La fase de aprendizaje es similar al inicio del proceso. Después de obtener más información sobre los supuestos y la hipótesis, podría averiguar que eran correctos, parcialmente correctos o incorrectos. Tener una mentalidad de crecimiento y humildad suficiente como para admitir errores le permite lo siguiente:
- Amoldarse rápidamente si necesita seguir trabajando en el MVP.
- Volver a centrar sus esfuerzos en otras áreas y formular una hipótesis alternativa.
Es importante destacar que, aunque la hipótesis y los supuestos fueran incorrectos, el proceso le ha permitido aprender algo nuevo sobre los clientes y la empresa. No lo considere tiempo desperdiciado. La clave es obtener ese conocimiento lo antes posible y aplicarlo a una hipótesis futura. Esta idea es la base de la cultura con respuesta rápida a errores.
Qué hacer después
La Introducción a la innovación de Cloud Adoption Framework es el mejor lugar para comenzar la exploración sobre cómo innovar.