No entres ahí: Outcomes vs Outputs - Parte 2
Hola! Tiempo que no nos leemos por acá y de esta forma. Cómo estás? Qué tal estuvieron estos meses?
En esta segunda entrega quiero sumergirnos nuevamente en los Outcomes y los Outputs pero desde dos enfoques bien particulares: Iniciativias individuales e Iniciativas cross-equipo.
---
Una aclaración importante mientras te vas acomodando, cuando me refiero a "cross-equipo" estoy pensando en aquellas empresas, compañias y organizaciones que tienen más de un equipo que ejerce cierto grado de ownership sobre los productos y servicios que ofrece. Tienen la capacidad de tomar decisiones y posteriormente ejecutar sobre los mismos. Esto que también se conoce cómo "equipo multidisciplinario" es muy cómun actualmente para las startups, ya que les permite trabajar con equipos dedicados a ciertos momentos del Customer Journey Map o diferentes features que conforman un producto.
Cómo vimos en la entrega anterior, los Outcomes son los resultados que provienen de una serie de acciones planificadas y ejecutadas para lograr un objetivo tal cómo mover un KPI ó una métrica de negocio. Mientras que los Outputs son resultados que provienen de una acción concreta y especifica, que puede estar o no asociada a un objetivo de negocio.
Que pasaría entonces, si tuvieramos Outcomes especificos para diferentes equipos dentro de un mismo producto? Cómo se diferenciaría esto de un único equipo con múltiples Outcomes?
Ejemplo práctico
Tenemos dos empresas, Luffy S.A. y Yuji S.R.L. (estoy muy orgulloso de estas referencias) ambas son startups que se dedican a la misma industria y construyeron productos similares. La diferencia es que Luffy logró levantar un poco más de capital que sus competidores y utilizó esa inversión para crecer más, ampliando sus equipos de tecnología y producto. Mientras que Yuji se mantuvo estable con un solo gran equipo de tecnología.
Ambas organizaciones quieren diferenciarse y "sacudir el mercado" de alguna forma, por tal motivo decidieron trabajar con Outcomes. Cómo se vería esto?
Outcomes para un único equipo (Yuji S.R.L.)
En organizaciones con un único equipo de tecnología o producto, cómo Yuji, los Outcomes suelen estar más enfocados y unificados bajo un mismo paraguas. Esto significa que todo el equipo está alineado hacia un conjunto común de resultados, esto nos permite:
• Alineación (Aligment) clara: Todo el equipo comparte una misma visión y trabaja hacia los mismos objetivos. No le decimos al equipo lo que tiene que hacer, dejamos que lleven adelante su propio proceso de Product Discovery. Aquí es importante que el liderazgo se esfuerce por brindar siempre una visión clara, que entusiasme pero que también desafie. Te dejo un video al respecto en este link.
• Priorización concentrada: La estrategia de priorización, junto con cualquiera de sus metodos para lograrla, está en control de un solo grupo de personas. El equipo puede tomar decisiones rápidas, ya que no hay dependencia directa de otros equipos. El peligro de esto es que esa priorización no esté desconectada de lo que el negocio espera y necesita.
• Menor fragmentación de esfuerzos: Con un solo equipo trabajando en múltiples Outcomes, hay una integración más directa de las acciones. El equipo puede pivotear más fácilmente cuando ve que uno de los Outcomes no está logrando el impacto deseado. Esto también trae riesgos, cómo la selección del problema debajo de este posible Outcome.
Por ejemplo, para Yuji, si su objetivo es aumentar la conversión en un funnel de ventas, todo el equipo estará enfocado en ese outcome, desarrollando las funcionalidades necesarias, optimizando el diseño y ejecutando las pruebas que correspondan. En un escenario ideal tomado de este ejemplo, la retroalimentación sería inmediata y el progreso hacia el Outcome se vuelve visible para todas las personas involucradas.
Ahora, veamos cómo este enfoque cambia cuando involucramos múltiples equipos, como es el caso de Luffy.
Outcomes para múltiples equipos (Luffy S.A.)
En el caso de Luffy S.A., con múltiples equipos trabajando en diferentes áreas del producto, los Outcomes pueden dividirse cross-equipo, cada uno con su propio enfoque y las particularidades de cada caso, pero todos contribuyendo hacia lo mismo. Este escenario trae lo siguiente:
• Alineación global, pero ejecución independiente: Los equipos tienen sus propios Outcomes, pero estos deben alinearse con un Outcome global mucho más amplio (pero no lo suficiente porqué el que mucho abarca poco aprieta) relacionado con los objetivos de la empresa. Esto requiere una mayor coordinación y comunicación entre equipos. Este es uno de los lugares donde cómo persona de Producto podes aportar mucho valor, no solo que podes, yo diría que debes hacerlo. Te dejo un articulo al respecto en este link.
• Esfuerzo colaborativo: Aunque cada equipo puede tener su propio Outcome, es necesario asegurarse de que los esfuerzos no se superpongan o, peor aún, qué compitan entre sí. Acá también es donde vos cómo persona de Producto te tenes que destacar, para evitar que las iniciativas no compitan entre ellas. Pensalo de esta forma, lo que otro equipo esté construyendo tiene que beneficiar o ser de utilidad para mi equipo, no se pueden desentender de lo que están haciendo los demás.
• Dependencias cross-equipo: En muchas ocasiones, los Outcomes de un equipo pueden depender de los outputs de otro. Por ejemplo, el equipo de UX puede necesitar que el equipo de backend desarrolle una nueva API antes de que puedan implementar una mejora en la experiencia de usuario. La identificación de esta dependencias, su posterior documentación y finalmente su comunicación es escencial para evitar dolores de cabeza.
Si Luffy S.A. decidiera, por ejemplo, mejorar tanto la adquisición de usuarios como la retención, podrían dividir estos Outcomes entre distintos equipos. El equipo de adquisición trabajaría en mejorar las estrategias de marketing, las landing pages y las integraciones externas, mientras que el equipo de retención se enfocaría en optimizar las funcionalidades in-app que incrementan el engagement. Ambos Outcomes son importantes, pero se ejecutan de manera independiente y se conectan en el valor a las personas usuarias.
Desafíos y beneficios de ambos enfoques
Para ir cerrando, en ambos ejemplos pudimos ver las ventajas de cada enfoque pero también los desafíos. En el caso de Yuji, un solo equipo con varios Outcomes puede correr un riesgo grande de sobrecarga en la cantidad de cosas para hacer y también en errarle con la priorización de las iniciativas de un Outcome (por ende errarle a lo que el negocio quiere). En el caso de Luffy, el desafío y al mismo tiempo un riesgo bastante grande es mantener la alineación de cada equipo a esas metas globales, es bastante común que un equipo avance más rápido que otros y esto podría derivar en un lo que se conoce como el Problema del Silo, te dejo un video al respecto en este link.
¿Podemos evitar que esto suceda? ¿Podemos mitigar estos riesgos? Podemos intentarlo...
En el caso de Yuji con una priorización bien pulida, muy cercana a las métricas principales del negocio. Mientras que en el caso de Luffy con algunas ceremonias cross-equipo que nos mantengan informados y conectados de forma sincronica.
De todas formas, nada nos asegura el éxito. No hay fórmulas mágicas. Proba lo que a vos y tu equipo mejor le sirva, primero para trabajar tranquilos y además para hacer mejores productos, mejores en el sentido que le resuelvan cada vez más y de forma consistente las necesidades a las personas usuarias.
---
Estuve unos días de descanso en San Pedro qué me ayudaron a tener tiempo y sobre todo inspiración, para escribir estas ideas con las que venía dando vueltas hace tiempo, no te puedo prometer que voy a reducir el tiempo entre cada entrega de estos articulos, pero al menos lo intentaré.
Mientras estuve en SP, fui a comer a la Campiña de Mónica y Cesar. De postre me pedí un "Flan de Naranja" que te dejo para que disfrutes visualmente.
https://x.com/nicoproducto/status/1836469499480195239
En la próxima entrega, exploraremos juntos algunos consejos prácticos para qué puedas aplicar y de esa forma sacarle el mayor provecho a los Outcomes. Especialmente útil si estás ocupando un rol de Producto 😌
Un abrazo
---
Bonus Content
En relación al ejemplo de múltiples equipos de tecnología y producto, una herramienta útil al momento de organizar estos equipos de desarrollo o planificar el trabajo por delante es ponernos en el lugar del usuario (persona usuaria) e imaginarnos todo el camino que tienen que recorrer, desde que entra en contacto con el producto hasta el momento de cumplir la acción principal por la que llegó. A esto se le conoce como "Customer Journey Map" y podes leer más información acá. Con este mapa definido, podemos rápidamente asignar equipos a momentos especificos del viaje del usuario o redefinir prioridades para contextos muy cambiantes.