La Brecha Producto-Proceso: Cómo Detener Esta Fuga en el Presupuesto de tu Organización

Lee la Transcripción:

Estamos probando la transcripción de nuestros pódcast usando un programa de software. Por favor, disculpa cualquier error tipográfico, ya que el bot no es correcto el 100% del tiempo.

Hannah Clark: Una de las cosas maravillosas de las organizaciones ágiles es que estamos constantemente experimentando y aprendiendo para mejorar nuestras organizaciones y los productos que ofrecemos. Cada avance en tecnología es el resultado de algún tipo de experimentación, pero aquí está el lado negativo: los experimentos no siempre conducen a resultados positivos. De hecho, muchos experimentos están muy mal planteados—y cuando hay cientos de miles de dólares en juego dependiendo del resultado de un experimento, lo último que queremos es tomar decisiones con datos defectuosos. Y lo más preocupante: la mayoría de las veces, ni siquiera nos damos cuenta de que los datos son erróneos hasta que es demasiado tarde.

Mi invitado de hoy es Manuel Da Costa, fundador de Effective Experiments. Como probablemente puedas deducir del nombre de su organización, a Manuel le preocupa principalmente ayudar a las organizaciones a realizar mejores experimentos, lo que conduce a una mejor toma de decisiones de producto. Si bien las herramientas adecuadas pueden ayudarnos a mejorar la experimentación y el análisis de datos, él también ha identificado un fenómeno que se origina en los márgenes del organigrama, llamado la brecha producto-proceso—y que está costando silenciosamente millones a las empresas tecnológicas. Empecemos.

Bienvenidos de nuevo al pódcast del CPO Club. Estoy hoy aquí con Manuel Da Costa.

Manuel, muchas gracias por acompañarnos hoy.

Manuel Da Costa: ¡Hola a todos! Hannah, gracias por invitarme.

Hannah Clark: ¿Podrías contarnos un poco sobre tu trayectoria y cómo llegaste a donde estás hoy?

Manuel Da Costa: Claro. Soy el fundador de Effective Experiments. Somos una empresa que provee software para ayudar a las compañías a colaborar mejor y tomar mejores decisiones de producto. Mi trayectoria, bueno, comenzó hace mucho, en el ámbito de las startups Lean, donde aprendí este enfoque de prueba y aprendizaje para validar. Después fui adentrándome en el mundo de la optimización de conversiones y gradualmente desarrollé mi propio producto, donde realmente ayudamos a equipos de producto y experiencia de cliente a trabajar mejor juntos.

Y eso me lleva al punto en mi carrera en el que necesito contar esta historia, que es para lo que estamos aquí en este pódcast.

Hannah Clark: Tengo muchas ganas de profundizar en esto.

Hoy nos vamos a centrar en un fenómeno al que has llamado la brecha producto-proceso. ¿Puedes empezar dándonos una visión general de a qué se refiere esto y las circunstancias que lo rodean?

Manuel Da Costa: Sí, claro. McKinsey ha hecho algunas investigaciones recientes donde analizaron la distancia entre buenas y malas prácticas de gestión de producto, y realmente se reduce a esta expectativa de los líderes sobre cómo debería ejecutarse el producto. Y luego está lo que realmente está ocurriendo en el terreno, con los product managers ejecutando, y hemos detectado esa desconexión. Le di el nombre de brecha producto-proceso, pero en realidad es la distancia entre las expectativas y la realidad.

Hay muchas razones por las que esto sucede y entraremos en ello, pero en última instancia la dirección quiere un mejor producto y los responsables y managers de producto no cumplen con ello. Hay una serie de razones para que eso ocurra.

Hannah Clark: Hablemos un poco más de eso. Dijiste que hay muchos factores que pueden desencadenar esta situación. ¿Cuál es el origen o el recorrido de cómo ocurre esta brecha y cómo llegamos ahí?

Manuel Da Costa: Claro. Veamos lo que se pide hoy en día a los equipos de producto, que es validar todas las decisiones que toman. La experimentación se ha vuelto el vehículo para que los equipos de producto validen sus hipótesis, para comprobar si están sacando el producto correcto.

Muchos de estos equipos han sido encargados de ejecutar experimentos, pero no tienen la experiencia o el conocimiento suficiente; o si lo tienen, es muy superficial sobre cómo experimentar. Por lo tanto, las decisiones se están tomando a partir de experimentación, pero la propia experimentación puede ser defectuosa. Puede que no sea lo suficientemente rigurosa. Y hay factores adicionales también.

Hablamos de colaboración entre equipos, de la conciencia de qué hacer y también de cómo priorizar eficientemente. Hay tantas prioridades en conflicto en producto, sobre todo qué deberían estar haciendo y, sumado la experimentación ahora, cómo priorizar eficazmente esa acumulación de tareas para el máximo resultado.

Estos son algunos síntomas que hemos visto en el terreno, donde, como decía, a los equipos de producto se les pide ejecutar, pero también incorporar la experimentación en sus prácticas, pero no se les da el apoyo suficiente para ayudarles en ello.

Hannah Clark: ¿Qué falta en esta ecuación? Parece que casi hay un conjunto de habilidades de investigación de usuario (UXR) poco desarrolladas en los product managers que ocupan esta posición. Y eso, al menos, causa un efecto dominó de resultados defectuosos, ¿cuáles son para ti los principales contribuyentes a la falta de preparación en la que se encuentran los responsables de producto?

Manuel Da Costa: Veamos a dónde se está llevando la experimentación. En muchas organizaciones, la experimentación la realizaba principalmente el equipo de marketing o el equipo de optimización de conversión (CRO).

Quizás era un pequeño grupo o un pequeño centro de excelencia. Con el tiempo, se les ha pedido transferir sus habilidades a los equipos de producto para que puedan ser autosuficientes en ejecutar sus propios experimentos. El primer reto es esa falta de conocimiento. Puede que en las organizaciones se realicen talleres de capacitación, sesiones guiadas sobre cómo hacerlo.

Pero ahí se detiene. Les dan acceso a herramientas, formación superficial. Pero no hay recursos para ayudarles a entender si realmente están mejorando o no. Por tanto, se guían solo por la cantidad. Dicen: hemos realizado X experimentos, ese es el resultado, pero nadie monitoriza ni revisa si esos experimentos se han ejecutado correctamente, si se planificaron bien y si han sido bien analizados.

Desarrollar esa habilidad lleva bastante tiempo. Piénsalo como un músculo; no es algo que perfeccionas tras hacerlo una vez. Hay responsables que ejecutan buenos experimentos pero pueden ser demasiado simples; otros prueban experimentos complejos pero están mal instrumentados. De esta manera, al transferir la información a la dirección diciendo "creemos que los próximos pasos son estos", puede basarse en información incorrecta—y ni siquiera lo saben, porque no hay supervisión.

Esto me lleva al siguiente punto: falta supervisión. Muy a menudo se da un nivel de confianza a estos equipos para que ejecuten experimentos y los resultados que devuelvan se creen a rajatabla. Pero debido a la falta de recursos, nadie invierte tiempo en verificar si esos resultados son precisos.

Si esos resultados se obtienen con buenas o malas prácticas, ese es un factor. El otro en todo esto es la ausencia del nivel de liderazgo. Al hablar de liderazgo, me refiero no solo al product owner, sino al VP de producto, al CPO. Son quienes deben responsabilizar a los equipos.

Y no solo responsabilizarlos, sino también darles margen para que puedan dedicar tiempo a ejercitar ese músculo, aprender a experimentar mejor, a tomar mejores decisiones y priorizar mejor. Por estas dos razones surge esa diferencia entre expectativas y realidad. Los responsables de producto y especialistas intentan salir adelante sin tiempo ni recursos para implantar estos procesos.

Así que parte de la responsabilidad recae en el liderazgo, que debe dar margen y espacio para conseguirlo.

Hannah Clark: En términos prácticos, ¿cómo se materializa eso desde la perspectiva del liderazgo? ¿Cuáles son algunos de los pasos que los líderes pueden tomar para evitar esta brecha producto-proceso?

Manuel Da Costa: Primero, establecer los KPIs correctos. El principal problema son los incentivos perversos. Lo que quiero decir es que puede fijarse como objetivo lanzar X funcionalidades en un trimestre o año. Hay que alcanzar ese número.

Se convierte en una carrera por cantidad, no calidad. Da igual si lanzas una característica compleja o varias simples mientras consigas el objetivo. Se trata de poner KPIs adecuados que incentiven correctamente, no solo llegar a la meta de cualquier manera.

En segundo lugar, dar suficiente margen de tiempo y recursos a los equipos y a quienes los supervisan para acompañar y mejorar a estos equipos producto y así tomar mejores decisiones a lo largo del tiempo. Nadie empieza sabiendo experimentar bien; aprender requiere tiempo y no es suficiente con un solo taller.

Estos equipos necesitan coaching continuo y mentoría. La falta de margen es porque hay que lograr los KPIs y, por tanto, no hay tiempo para mejorar. Es un ciclo vicioso. Todo comienza con liderazgo, queriendo mejorar la toma de decisiones de producto.

¿Cómo se mejora esa toma de decisiones? Experimentando y validando hipótesis. Ese es el primer paso. Y para hacerlo, hay que equipar a los equipos: darles tiempo, recursos, margen y nivel de seguridad para equivocarse. Lo fundamental en la experimentación es que puedes equivocarte. Si las métricas se fijan solo por cantidad, o exigiendo una tasa de éxito determinada, la gente acaba manipulando el sistema para lograrlo.

Experimentar es creer que algo puede funcionar, pero sin saberlo hasta probarlo. Al lanzarlo, recibimos feedback de clientes y del mercado, que determina si funciona.

Entonces decidimos si seguimos esa vía o no. Ese espacio de seguridad es fundamental; si no se brinda, los responsables irán a lo seguro solo para alcanzar KPIs, pero nunca tomarán decisiones innovadoras.

Hannah Clark: Me imagino un mundo en el que esta brecha producto-proceso pasa desapercibida, donde se alcanzan los KPIs, la gente está contenta, el negocio sigue en pie, pero falta algo. ¿Cuáles son algunos síntomas de que una organización sufre silenciosamente esta brecha y que podría haber mejoras importantes o que se están tomando decisiones dudosas por experimentación defectuosa?

Manuel Da Costa: Si hay experimentación defectuosa, lo hemos visto: los CPOs y VPs comentan que no confían en los resultados de los experimentos. Así que se vuelve a tomar decisiones por intuición, aunque haya datos, pero al no confiar en ellos, se descartan.

Ese es un síntoma. Otro ejemplo es empresas que presumen de ser data-driven, orientadas a producto o cliente, pero son solo palabras, lo importante son las prácticas. Ves que las características lanzadas no coinciden con lo que el cliente quiere.

Al final, se convierten en una "fábrica de funcionalidades", sacando cosas sin aportar verdadero valor al cliente o al negocio.

Hannah Clark: ¿Tienes marcos de trabajo que recomendarías para ejecutar mejores experimentos o alguna acción práctica a tomar?

Parece que hay muchos factores y algunos escapan al control. ¿Por dónde empezar si detectamos esta brecha en la organización?

Manuel Da Costa: Absolutamente. El primer paso es estandarizar. Cuando se facilitan herramientas para experimentar, hemos notado que distintos equipos, incluso en una misma empresa, hacen experimentos o clasifican datos de forma diferente. Así que lo primero es definir cómo debe ser el proceso.

Cuando sabes cómo debe ser ese proceso, lo estandarizas. Estandarizar no significa rigidez absoluta, aunque mucha gente lo ve así. El problema de un enfoque demasiado flexible es que acaba en caos, y los datos se vuelven inútiles para el futuro.

Estandarizar requiere fijar el proceso, la forma de clasificar datos y la nomenclatura, las prácticas de análisis, quién aprueba, etc. Implementar modelos RACI (responsables, aprobadores, comunicados e informados).

Puede sonar rígido, pero en realidad da límites claros. Da igual si el equipo cambia; el método queda, se incorpora en cada experimento y decisión posterior.

El otro paso es vincular las decisiones con los objetivos del negocio, no solo lanzar y esperar. Deben alinearse con las métricas del negocio. Con esas dos cosas tienes una base sólida, aunque al principio vaya lento, ya que cuesta acostumbrarse a priorizar y evaluar bien cada experimento.

Después, asegurar una supervisión clara, de modo que cualquiera pueda revisar retrospectivamente cómo va un equipo, no para buscar errores, sino para detectar brechas y mejorar con coaching.

Por ejemplo: "Has lanzado cinco experimentos, pero algunos no tienen una hipótesis sólida o no tienes las métricas adecuadas; aquí puedes mejorar". Solo así se avanza, con feedback que genere progreso.

Juntas, estas acciones ayudarán a cerrar esa brecha en la organización.

Hannah Clark: Es interesante que para esto haga falta inteligencia emocional a nivel de liderazgo. Porque mucho depende de la relación y la seguridad psicológica entre líderes y equipos de producto para poder cometer errores y experimentar sin miedo.

¿Qué consejos recomendarías para fortalecer la confianza y las relaciones entre equipos, especialmente cruzando el organigrama? ¿Cómo podemos mejorar la confianza mutua, en especial ante un proceso nuevo como este?

Manuel Da Costa: Sin duda, es más fácil decirlo que hacerlo, porque hablamos de personas y de egos, y hay que saber mostrarse vulnerable, que es lo más difícil. Pero creo que el liderazgo debe ofrecer esa seguridad psicológica y también cambiar un poco el lenguaje.

Por ejemplo, no decir que una prueba "fracasó" o "tuvo éxito". Centrarse en el aprendizaje. Pasar la conversación de ganancias y fracasos a: "Gracias al experimento, validamos la necesidad de esta funcionalidad o de este cliente" o bien "gracias a esto, vimos que no hacía falta desarrollar cierta función y ahorramos recursos". Es cambiar el chip del simple experimento por experimentar para ganar; de ahí la importancia de los KPIs y de cómo diseñarlos.

Puede que managers y responsables escuchen esto y piensen: "Nos gustaría hacer eso, pero nuestros KPIs son diferentes". Por eso hay que implicar al liderazgo, porque si no, el efecto secundario es que la organización se convierte en una fábrica de funcionalidades y parece que avanzan, pero ¿realmente aportan valor?

Hannah Clark: Una buena reflexión.

Además tengo curiosidad. Hablando de temas prácticos en el liderazgo, los KPIs y los tamaños de equipos varían. ¿Cómo supervisar efectivamente un equipo de producto a medida que escala, cuando entran nuevos miembros con diferentes niveles de conocimiento?

¿Cómo estandarizar y asegurar el nivel adecuado de supervisión, sobre todo si somos pocos líderes en comparación con los miembros del equipo?

Manuel Da Costa: Nosotros hemos creado la figura del "orquestador". Según el tamaño y número de equipos, el orquestador supervisa varios equipos o personas. Puede encargarse de la integración, formación y mentoría, asegurando que todo funcione y reportando al siguiente nivel jerárquico.

En vez de un solo líder para todo, tienes responsables de pequeños grupos que se concentran precisamente en la formación, coaching y asegurar que las decisiones de producto y experimentos se desarrollen dentro de los límites del proceso. Esa figura puede supervisar varios equipos, según el tamaño.

Hannah Clark: Y comparto la idea de los límites claros o "guardrails". A veces parece que limitan, pero en la práctica reducen la fatiga por decisión y clarifican el trabajo del equipo, porque no están siempre redefiniendo procesos al mismo tiempo que construyen el producto. Hay base para ello.

También me pregunto cómo estandarizar la supervisión, que es más abstracta. ¿Qué recomendaciones tienes para ello, sobre todo si como líder no tienes un profundo background en experimentación?

Manuel Da Costa: Todo empieza con un marco de gobernanza (governance framework). Eso implica crear las reglas de cómo debe idearse un experimento.

Eso incluye qué hay que registrar: una buena hipótesis (no solo una hipótesis, sino una sólida). También otros detalles relevantes: información técnica, el público objetivo, y datos clave para el negocio. Crear ese marco implica definir que toda experimentación debe recopilar ciertos datos mínimos imprescindibles y luego otros opcionales.

No me gusta la palabra "imponer", pero estos límites protegen a la organización de acumular datos inútiles, que también ocurre.

Si das mucha flexibilidad, cada equipo define el experimento a su manera. El marco dicta recoger información relevante para negocio y técnica siempre.

Después está el proceso: ningún experimento debe diseñarse, ejecutarse y analizarse sin pasar por ciertas fases. Igual que no lanzarías una funcionalidad sin QA, tampoco un experimento. El marco debe decir que no se puede pasar de fase sin ese QA. Eso es no negociable; todo experimento sigue ese camino y si no lo hace, se monitoriza para investigar por qué.

Es aquí donde implementamos un "scorecard de salud". Es un listado de puntos a evaluar: ¿hubo hipótesis sí/no? ¿Cuándo se creó? ¿Al inicio del experimento o tras obtener resultados para justificarlo?

A esto se le llama "harking", que es crear hipótesis después de conocer resultados. Forzar los datos para que digan lo deseado. Sucede cuando los experimentos no resultan "ganadores" y se reajustan métricas o hipótesis. Los marcos de gobernanza y límites lo evitan. No digo que sea intencionado, pero si el KPI es hacer X experimentos o alcanzar X tasa de éxito, la gente adaptará todo para lograrlo.

Así se monitoriza: ¿se siguió el proceso? ¿Se cambiaron datos críticos? El scorecard permite saber si el experimento se ejecutó correctamente. Y finalmente decidir si se confía en el experimento y en las decisiones derivadas, o no, y por qué; siempre sirve para guiar y mejorar.

La organización mejora las decisiones de producto y la calidad de los experimentos.

Hannah Clark: Me ayudan mucho los marcos que has dado. Es muy útil.

¿Tienes ejemplos de éxito de organizaciones que lograsen cerrar la brecha producto-proceso?

Manuel Da Costa: No puedo dar el nombre de la empresa, pero hicimos esto mismo con una compañía que pasaba de equipos centro de excelencia a equipos de producto y de mercado. Era una empresa global de ecommerce, con muchos equipos de mercado y de producto poco experimentados al inicio.

Fue importante no introducir la experimentación a todos los equipos a la vez. Realizamos un análisis FODA de cada equipo, puntuando su conocimiento y su motivación. Después integramos primero a los mejor puntuados y usamos su éxito como prueba social.

Llamábamos "sprints" de tres meses a cada ciclo, tras los cuales los equipos quedaban autosuficientes. Así, sumamos equipos, incrementando la colaboración y el soporte comunitario. El proceso duró dos años y fue necesario, ya que el cambio cultural es lento.

Al terminar, los equipos dominaban la experimentación y la integración de nuevos empleados duraba menos de un mes gracias a los marcos y sistemas implantados. Así, seguían el método sin inventar variaciones.

Hannah Clark: Agradezco mucho los ejemplos y esto ha sido muy esclarecedor.

Gracias, Manuel, por acompañarnos. ¿Dónde puede la gente seguirte en línea si quiere saber más de tu trabajo y Effective Experiments?

Manuel Da Costa: Puedes encontrarme en LinkedIn. Estoy bastante activo allí. También puedes visitar EffectiveExperiments.com para conocer más sobre nuestro trabajo. Publico mucho contenido en nuestro blog. Os invito a seguirme en ambos recursos.

Hannah Clark: Fantástico. Muchas gracias.

Gracias por escucharnos. Para más ideas, guías y reseñas de herramientas, suscríbete a nuestro boletín en theproductmanager.com/subscribe. Puedes escuchar más conversaciones como esta suscribiéndote a The CPO Club, donde sea que escuches pódcast.