Como validar la innovación para obtener agilidad de negocio

Validar innovación de negocio en agilidad de negocio

Acabamos la serie de artículos sobre este modelo de agilidad de negocio con una visión sobre cómo validar las iniciativas de innovación que realizamos. Por si no leísteis los tres artículos anteriores, aquí os los dejo:

Quizás la validación debería ser lo primero que se impulse en una organización sin una filosofía de agilidad de negocio. Tanto en cursos como en consultorías he oído muchas veces ejemplos de empresas que requieren la realización de un caso de negocio detallado, estimando los beneficios de la iniciativa, pero que luego no revisan los resultados reales obtenidos.

Algunas medidas que pueden ayudar a validar con más efectividad las iniciativas son:

🤔 Entender qué es la validación

Para entender en qué consiste la validación y para qué debemos hacerla, es necesario primero entender el proceso de creación de valor. Aumentar la madurez de los equipos introduciendo capacidades de experiencia de usuario puede comenzar por reflexionar sobre este proceso.

El modelo lógico de métricas de los proyectos nos ayuda a tener una vista amplia de los tipos de métricas y a medir las cosas que importan para crear valor real. Los tipos de métricas son:

  • Qué recursos se utilizan para realizar el trabajo, que planifican la inversión en el desarrollo de nuevos productos o en su mantenimiento. P.e. el coste de cada Sprint.
  • Qué métricas de las actividades nos ayudarán a gestionar y mejorar los procesos de trabajo. P.e. medimos los defectos del software, la velocity, el ritmo de despliegues, etc.
  • Qué sabemos sobre los productos creados, p.e. la cantidad de funcionalidades, la cantidad de accesos a cada funcionalidad, la duración del uso de los usuarios, etc.
  • Qué resultados obtienen los usuarios y clientes, p.e. hacer más eficiente su trabajo, evitar riesgos, adquirir los productos que necesitan, etc.

Los impactos, qué beneficios aporta la iniciativa a la empresa, p.e. disminuir gastos, aumentar ventas, o gestionar mejor el conocimiento.

Project Metrics Logic Model

A pesar que podemos evitar el esfuerzo del desarrollo si el descubrimiento de producto detecta iniciativas que no aportarán resultados a los usuarios, la validación del valor sólo vendrá cuando los usuarios accedan al producto real. Por ello las entregas frecuentes suponen un ahorro de esfuerzo.

Entendiendo el proceso de creación de valor, podemos lanzar preguntas como estas puede crear la necesidad de repensar cómo se conciben, priorizan, estructuran y validan las iniciativas estratégicas:

  • ¿Tenemos métricas del uso de las aplicaciones? 
  • ¿Cómo sabemos que hemos resuelto los problemas de los usuarios?
  • ¿Qué retorno de inversión (ROI) ha obtenido la organización con la iniciativa?

   

📊 Usar telemetría, feedback y analítica

Uno de los principios que es fundamental instaurar en las organizaciones que quieran centrarse en los usuarios y generar productos de valor añadido con eficiencia es tomar las decisiones basadas en evidencias. Se debe evitar que el ego, sesgos o posición organizativa de las personas sean los factores de peso para tomar decisiones de inversión en los productos.

Para poder obtener todas estas métricas, es necesario disponer de herramientas que den soporte a la captura y análisis de estos tipos de información.

  • Las herramientas de gestión del trabajo, como p.e. Jira, permiten medir el esfuerzo dedicado y muchas métricas de gestión del trabajo, como defectos, integraciones, velocity, versiones, despliegues, etc.
  • Las herramientas de telemetría como Google Analytics, Hubspot, Hotjar o Mixpanel, permiten entender el uso de las funcionalidades, la navegación de los usuarios, los embudos de conversión, entre otros. Sin estas, ¿cómo tenemos evidencias del uso del producto que hacen los usuarios?
  • Para medir los resultados para los usuarios
    • En productos para el uso interno en organizaciones se pueden monitorizar parámetros operativos reales como p.e. la reducción en el tiempo medio de ejecución de una tarea.
    • En productos para clientes externos, aunque también se pueden obtener parámetros operativos reales, puede ser difícil por los temores a pérdida de privacidad de los usuarios o directamente por aspectos legales como la RGPD. Como alternativa podemos usar encuestas o herramientas de feedback automatizado como Typeform, Hotjar o UserVoice.
  • Finalmente, las métricas de beneficio organizativo se pueden obtener de los sistemas de márketing (CRM) o financieros (ERP).

Una vez que disponemos de esta información, es muy útil integrar los diferentes tipos de métricas en un panel como este ejemplo que mostramos a continuación. También es útil añadir otra información al panel, como el feedback cualitativo de los usuarios o de los stakeholders.

Mixpanel Metrics Dashboard

🕵️‍♂️ Validar con usuarios y stakeholders durante todo el proceso

El desarrollo de producto efectivo es, en el fondo, una conversación constante con el usuario. Como dice Jeff Gothelf, validar una hipótesis con los usuarios con el producto ya terminado es la forma más cara que existe

La validación sobre que estamos trabajando en la línea correcta para entregar un producto que satisfaga a la vez las necesidades de los usuarios y de la empresa, tiene dos grandes fases.

duoble-diamond-design-min
El modelo de “doble diamante” del diseño orientado al usuario

La primera fase consiste en entender si podemos encontrar un problema real del usuario que le motive a usar el producto o funcionalidad (y a pagar). Puede ser que el usuario no tenga un problema suficientemente intenso para cambiar su manera de actuar, o para pagar. 

Para poder validar la necesidad del usuario y las soluciones que podemos ofrecerles de manera económica podemos utilizar técnicas baratas como las entrevistas o los prototipos.

Las actividades de investigación sobre el usuario o user research de esta fase suelen realizarse previamente a crear un equipo Scrum que realice el resto de la iniciativa.

La segunda fase consiste en encontrar y escalar una solución viable a los problemas, por motivos económicos, técnicos o de ser mejor que la competencia. En este momento ya se suele organizar el equipo Scrum, que va creciendo según la validación que el usuario acepta y utiliza el producto porque soluciona sus necesidades. El modelo dual track Agile continúa realizando las actividades de descubrimiento y entrega del producto. Este modelo valida constantemente las necesidades identificadas y las funcionalidades entregadas.

   

Transparencia en los resultados

Una característica que da efectividad a la validación de las ideas e hipótesis identificadas, y de las funcionalidades desarrolladas, es tener transparencia en los resultados.

Qué toda la información esté disponible en un muro o panel para el equipo y los actores interesados es una manera efectiva de crear entendimiento compartido, tomar mejores decisiones y generar involucración de las partes relevantes.

P.e. si una funcionalidad se usa poco y eso lo ve mucha gente, puede generar más interés y presión para mejorar las asunciones que impulsaron esta funcionalidad.

En el curso Professional Scrum Product Owner Advanced desarrollamos un muro de producto completo con caso de estudio realista.

Product Wall - Product Management

La validación realimenta el descubrimiento y la priorización

Cualquier esfuerzo de validación (transparencia e inspección) que hagamos será inútil si no conseguimos utilizar esta información para tomar decisiones que mejoren el futuro del producto.

Los Sprint Review son el lugar donde aprender sobre nuestras asunciones y lo que descubrimos durante el Sprint. Aquí intervienen:

  • El Product Owner con la información que ha recogido sobre las necesidades de los usuarios, las métricas obtenidas a todos los niveles del producto y las conversaciones con stakeholders.
  • Los developers con cualquier información sobre cómo cumplir mejor la meta del Sprint.
  • Y todos, incluyendo a los stakeholders, con las ideas de como mejorar los siguientes Sprints, o sobre las siguientes metas de producto.

El backlog de producto debe dar transparencia sobre el trabajo y opciones para conseguir las metas de producto.

Scrum y UX - Backlog Management

Dadme feedback en 20 segundos

¿Qué te ha parecido este artículo? ¿Te gustaría que profundice en algún aspecto?

🙏 Si os ha gustado este artículo, os pido dos cosas a cambio:

  • Añadid comentarios de vuestra experiencia y punto de vista , haced “like” y compartirlo con vuestros conocidos.
  • Completad esta encuesta que ¡os tomará solo 20 segundos!

Referencias

¿Quieres recibir más información y recursos de calidad?

¡Sigue a Alex en las redes sociales!

Alex Ballarin, Professional Scrum Trainer

Alex Ballarin es Professional Scrum Master y Business Agility Coach. Además de este blog, publica contenido frecuentemente en las redes sociales

¡Suscríbete a nuestra newsletter mensual!

Cada mes enviamos una newsletter a más de 1.200 personas con contenidos, recursos y ofertas especiales de nuestros cursos. Queremos ofrecer contenido de calidad y sin spam.

¡Sácale más partido a este artículo!

Comenta en Linkedin

Continúa la conversación en Linkedin citándome (@alexballarin).

Comparte con tus conocidos

¡O comparte este artículo con otras personas a las que les pueda interesar!

Continua aprendiendo

En nuestro blog encontrarás otros artículos clasificados por rol y por nivel,
y además podrás irlos guardando tal y como los leas. 👇

Scroll al inicio