Una investigación de Standish Group muestra que un 80% de las funcionalidades desarrolladas aportan un valor bajo o nulo al usuario.

Más allá de lo creíble que sea o no esta estadística, si que creo que merece la pena reflexionar sobre algo que observo muy comunmente en los equipos que desarrollan productos digitales: La importancia que se le da a un entregable y el poco estudio que se hace posteriormente sobre si realmente mereció la pena el esfuerzo, a veces, cuando incluso los recursos son muy limitados.

¿Cuanto dinero hemos invertido para que nadie utilice nuestra funcionalidad? Todos nos podemos equivocar, pero por lo menos… ¿Nos hemos dado cuenta de que nadie la utiliza? ¿Hemos aprendido del error? ¿Cual ha sido el coste de oportunidad de no enfocar nuestros esfuerzos en algo que genere más impacto?

Muchas veces el día a día nos empuja a centrarnos simplemente en entregar lo que tenemos entre manos. Muchas veces entregar por entregar, sin saber muy bien cuales son los objetivos que estamos persiguiendo y si realmente lo que estamos entregando es la mejor vía para cumplir con el objetivo que tenemos. En muchas ocasiones porque alguien nos ha dicho que esto es lo que hay que hacer ahora.

Dar un paso atrás y reflexionar, pensar si lo que estamos haciendo realmente nos llevará a conseguir nuestro objetivo es de vital importancia cuando los recursos no son infinitos. Sin embargo, rara vez las culturas organizativas lo incentivan o crean el espacio suficiente y seguro para que esto ocurra de forma natural.

Uno de los grandes errores que cometemos en el día a día es relacionar el completar una tarea con el éxito dentro de la organización. La tarea es un output, y está bien haberla terminado, pero no implica un éxito para la organización…

[Imagen] -

¿Por qué estamos haciendo esa tarea? ¿Realmente esa tarea genera el impacto esperado? ¿Existe otra tarea que consiga el mismo impacto con menor esfuerzo?

De nada sirve acabar una tarea si esa tarea no desencadena un cambio de comportamiento en nuestro cliente final. No obstante, a todos se nos felicita al entregar una nueva pieza de software, entregar una ppt o elaborar un informe.

En muchas ocasiones, se nos fomenta el entregar por entregar, aunque no sepamos si esa entrega realmente ha servido para cumplir los objetivos perseguidos, a veces, por que no sabemos ni que objetivos perseguimos, pero eso es madera para otro informe.

Son cosas diferentes

Para muchas personas la diferencia entre outputs y outcomes pueda ser meramente semántica, para mi conlleva una reflexión mucho más profunda al respecto de lo que hacemos en nuestro día a día que marca grandes diferencias en las organizaciones.

Para que el lenguaje no nos lleve a errores, es fundamental comenzar con una definición de ambos términos:

  • Output: Lo que producimos en nuestro día a día. En un mundo digital pueden ser piezas de software, ppts u hojas de excel. En un mundo físico podemos hablar de piezas de un producto, talleres de formación o un servicio de consultoría ofrecido entre otras muchas cosas.
  • Outcome: Cambios de comportamiento observados a partir de lo que hemos producido en nuestro día a día. Cambios en las encuestas de satisfacción, cambios en el número de ventas, cambios en la financiación recibida…

Depende de nuestro sector los outputs y los outcomes pueden ser muy diferentes, sin embargo es importante desacoplar el uno del otro y entender la relación de causalidad que existe entre el primero y el segundo.

Los outputs pueden generar outcomes, sin embargo en el día a día nos fijamos más en si los outputs se finalizan (tareas acabadas, funcionalidades en producción, talleres impartidos…) que en si los outcomes generados son los que nosotros esperamos.

Medir, medir y medir

Una misma funcionalidad puede llevarnos a múltiples cambios de comportamientos… O a ninguno. Un mismo output que producimos en nuestro día a día puede generar un resultado que nos acerque a nuestro objetivo, que sea totalmente irrelevante o que incluso nos aleje de nuestra meta.

Por esta razón, es de suma importancia utilizar el método científico en cada tarea en la que vamos a utilizar un esfuerzo relevante. Utilicemos el método científico para entender si nuestro output ha producido un resultado estadísticamente significativo como para ser una tarea en la que merezca la pena seguir poniendo esfuerzo.

El método científico simplemente nos dice que midamos como se comporta el objeto a estudio en un entorno de control y como se comporta una vez introducimos nuestro output en el escenario. Si realmente se ha observado un cambio de comportamiento en la dirección que buscabamos… ¡Bingo! Si no, ya podemos dedicar nuestros esfuerzos a otras cosas.

En un mundo afectado hoy en día por el covid en el que la escasez de recursos va a ir en aumento debemos enfocarnos en cambios de comportamientos y no en los outputs, celebrar aquellas acciones que nos acerquen de manera estadísticamente significante a nuestro objetivo y cambiar aquellas que no nos muevan en la dirección correcta.

Dejemos de pensar en términos de tareas en el día a día, en términos de funcionalidades de un producto, en términos de talleres impartidos o software entregado. De nada sirve un equipo que entrega un montón de funcionalidad bonita a final de mes si no consigue acercarnos a nuestros objetivos.

Centrémonos en medir si dichos outputs realmente nos acercan en términos medibles a nuestro objetivo. No celebremos una entrega de una pieza de software, entendámosla únicamente como una apuesta hacia nuestro fin, nuestro objetivo, nuestro outcome.

Diferenciemos entre output y outcome o caeremos en la espiral de construcción y desarrollo sin tener siquiera certeza de si nuestra funcionalidad será algún día utilizada.