Cómo hacer experimentación en Producto y no generar ni un solo euro
Historia sobre cómo experimentar en Producto y sobrevivir en el intento.
La experimentación es uno de esos términos populares en Producto que ha dado lugar a Growth Product Managers y squads multidisciplinares que van por libres en sus organizaciones con los que sueñan muchos PMs. Esto es hacer Producto bien, con mayúsculas: hacer discovery y delivery rápido y en paralelo, usar muchos datos, probar muchas cosas, operar de forma muy autónoma… y además conseguir un impacto claro (o a eso aspiran los Growth PMs).
A pesar de las bondades de la experimentación, es muy fácil caer en un escenario de los horrores: al C-level le suena que eso de experimentar es una excusa para que no haya accountability porque no hay un roadmap como tal (¿dónde están las funcionalidades nuevas? ¿cuántas son? más es siempre más), los desarrolladores se lo toman como luz verde para meter deuda técnica como si no hubiese un mañana, los PMs se ponen su gorro de científicos locos y aquí no se mueve ni una métrica útil ni se genera un solo euro.
¿Qué es la experimentación?
La experimentación es una de las herramientas más útiles para conseguir generar crecimiento (real: del que trae revenue, no DAUs) con el producto y todo lo que lo rodea. Nos permite validar hipótesis de forma rápida y barata, reducir riesgos y optimizar el producto de manera continua. Cuando hablamos de Product-Led Growth (PLG), la experimentación adquiere un papel aún más crucial, ya que aquí el producto se convierte en el principal motor de adquisición, retención y expansión (!).
Siempre que hablo de experimentación hago énfasis en que esto no consiste en unos cuantos tips para que los PMs optimicen pantallas u otros pequeños tweaks del producto, sino que va más allá y nos exige construir un modelo operativo en el que trabajar de forma multidisciplinar para cubrir toda la experiencia del usuario: el producto, el pricing y el go-to-market, la estrategia de distribución, o los canales de comunicación.
La experimentación es una metodología de trabajo multidisciplinar y una mentalidad de empresa para ejecutar una estrategia de crecimiento y conseguir un objetivo de negocio, que utiliza múltiples canales y, principalmente, el propio producto como motor de crecimiento
He visto varios casos de equipos de Producto que tratan de experimentar sin tener en cuenta la experiencia end-to-end y, para sorpresa de nadie, no suele salir bien: estos equipos se centran en frameworks y ejemplos poco aterrizados que no conectan con la realidad de sus usuarios ni del negocio, y al final, el producto está, y tiene que estar, al servicio de los usuarios y del negocio.
Es fácil caer aquí: un par de búsquedas sobre experimentación en product management arrojan decenas de frameworks, guías, casos de growth en los que se cambió un botón y se incrementó la conversión en un 300%, y mucho más. Yo misma he creado, usado y difundido alguno de estos frameworks: al final, los problemas se repiten y, si somos capaces de llegar a una abstracción suficiente, hay fórmulas que casi siempre funcionan en distintos entornos. El problema de la experimentación no son los frameworks, sino que en muchos casos, no sirve para absolutamente nada.
¿Cómo que no sirve para nada?
Al hacer experimentación en producto, los equipos tienden a caer en dos trampas (llamémoslas arquetipos):
Nos volvemos growth hackers (confieso que no puedo aborrecer más la idea del growth hacking: tan desfasada y poco útil como simplista y analíticamente floja) obsesionados con el CRO, A/B testing, un método científico que no entiende de estadística básica y mejoras anecdóticas basadas en mover unos números que no sabemos muy bien para qué sirven o si le solucionan algo a alguien
Nos volvemos Product Managers de libro que viven en el día de la marmota: aburridos, desconectados del negocio, obsesionados con la validación de hipótesis y testearlo todo cuarenta veces y enfrascados en llevar a cabo mejoras incrementales que no aportan ningún valor al negocio ni mucho menos al usuario
Cualquier parecido de estos arquetipos con la realidad es totalmente intencional y basado en mi experiencia en primera persona.
¿Y esto por qué ocurre?
En buena medida, creo que el principal problema a la hora de experimentar es lo que yo denomino la Religión del Producto, en la que el medio -que pueden ser las buenas prácticas de producto, los frameworks de growth, o la idea que nos ocupa: la experimentación- pasa a ser un fin en sí mismo. Nos olvidamos del por qué y el para qué.
La Religión del Producto (con mayúsculas, negrita y acérrima devoción) tiene por libros sagrados aquellos que nos inspiran a todos, devotos PMs incapaces de explicar su P&L 🚩 que afirman con desdén en las entrevistas que “no les dejan hacer discovery” 🚩y, en general, una ojeriza al negocio que roza lo cómico. Vaya locura esto de ganar dinero en una empresa con ánimo de lucro, ¿eh? Con este discurso, es imposible tomarse esto en serio y centrarnos en lo que realmente importa: ganar pasta solucionando problemas.
Prioridades en la experimentación
Para evitar caer en el día de la marmota o el A/B testing compulsivo, necesitamos tener claras 3 prioridades (por orden de importancia):
Generar resultados de negocio
Ejecutar a un buen ritmo
Poner los datos en el centro de las decisiones
Veamos qué implica cada una:
Resultados
Cómo no generar ni un euro:
Cada función mira una métrica distinta, troceando el funnel del usuario y, por supuesto, sin ninguna conexión con los objetivos de negocio. Producto y tecnología miran los DAUs del producto. Marketing se jacta de generar MQLs. Ventas habla de oportunidades. Y así seguimos.
Si la experimentación es una herramienta para generar crecimiento, lo primero que debemos perseguir es ese crecimiento: generar resultados reales y medibles. Esto no quiere decir que miremos solamente el revenue, pero sí debemos perseguir una métrica concreta de negocio que podamos compartir en esos equipos multidisciplinares. No hay mejor forma de no conseguir absolutamente nada experimentando que elegir una métrica inadecuada. Para que esta métrica nos funcione tiene que cumplir algunos requisitos:
Medible a corto y largo plazo, es decir, algo que se mueva. Por ejemplo, net adds: volumen de nuevos suscriptores restando las bajas en un periodo determinado.
Significativa a nivel de negocio: tiene que representar muy bien lo que queremos conseguir y tener un claro impacto en la P&L del negocio. Por ejemplo, adquisición o retención de nuevos usuarios.
Compartida entre distintas funciones: esto no va solo de producto y tecnología, sino que será necesario trabajar con equipos de go-to-market. Estos equipos multidisciplinares tienen que ser owners de esa métrica.
Por supuesto esa métrica ha de responder a un problema de negocio más allá de generar revenue: ¿qué quiero conseguir, dónde me duele más? Cuando nos planteamos cuál es el problema al que queremos dar solución, suelen reducirse a 3 tipos:
Adquisición: no consigo captar nuevos clientes, ya sea porque hay poca gente interesada en el producto (volumen top of funnel) o porque el producto no les termina de convencer (tasa de conversión)
Retención: los usuarios no se quedan en el producto. Esto va más allá de churn directo y es que hay varias etapas intermedias que nos supondrán un problema a futuro: poca frecuencia de uso del producto (dormant users), poco uso en cuanto a funcionalidad (bajo engagement), o downgrades a planes de pricing más baratos o menos funcionalidades
Expansión, o la gran olvidada. Adquirir y retener no es suficiente para crecer: tenemos que ser capaces de seguir monetizando el producto y haciendo crecer el revenue que obtenemos por cliente. Esto incluye upgrades, cross-selling, subidas de pricing…
Al decidir qué problema vamos a atacar con experimentación, siempre insisto en elegir un único problema: es muy fácil intentar hacer todo y acabar no haciendo nada. De esta forma, nos aseguramos un foco único y podemos dar ownership total al equipo sobre la métrica asociada a ese problema.
Ejecución
Cómo no generar ni un euro:
El Growth PM lanza 3 experimentos en un Q. Itera cada uno aproximadamente 12 veces y sigue sin estar seguro: ¿escalo esto o no lo escalo? Seguramente necesite más muestra, o validar con una encuesta. 🥱
Recordemos que uno de los puntos fuertes de la experimentación es aprender de forma rápida y barata, y que una de las palabras clave aquí es multidisciplinar. Al montar equipos de experimentación, o cualquier equipo con el que garantizar que la estrategia de producto y go-to-market (GTM) van de la mano, me gusta hablar de dual track de producto (discovery y delivery) y GTM (estrategia y lanzamiento/post-lanzamiento).
Esto implica que exista un equipo multidisciplinar que trabaja de la mano, asegurándonos aprovechar las fortalezas de cada perfil: no tendría mucho sentido tener a PMs escribiendo copies de marketing o personas de marketing escribiendo historias de usuario.
En la práctica, estos equipos multidisciplinares pueden ser tan grandes como lo sea tu budget y, a medida que escalamos, podemos ir incorporando perfiles específicos. Sin embargo, arrancar es mucho más sencillo: squad de producto con los sospechosos habituales (PM, product designer/UX, Tech Lead, desarrolladores), alguien de Data y alguien de Marketing.
Al principio, es mejor contar con perfiles más generalistas que nos permitan versatilidad y no encasillarnos en un tipo de experimento demasiado concreto: los primeros experimentos siempre fracasan y tardamos en dar con la tecla de lo que realmente mueve la aguja. De hecho, recomiendo encarecidamente tener esto presente al poner objetivos: alguna vez incluso he tenido como KR fracasar N experimentos.
Nadie quiere un equipo de experimentación que vaya lento, ya que esto es prueba y error y cuanto más probemos, mayor probabilidad de éxito tenemos. Pero, ¿cómo encontramos el sweet spot entre la velocidad y no hacer chapuzas que nos salgan caras más adelante? Muchas veces he visto cómo se utiliza la experimentación como excusa para el código de mala calidad y la acumulación de deuda técnica, y por aquí no es.
Habiendo hecho experimentación en empresas de lo más variopinto, desde corporates muy corporate hasta startups y scaleups, siempre digo que un experimento que tarde más de 10 días en validarse es un red flag de manual: seguramente esté mal acotado y definido (en B2C, bajaría a 5 días), y que en ningún caso el análisis debe llevarnos más de un día, esto no es rocket science.
Datos
Cómo no generar ni un euro:
El Growth PM analiza cada punto del funnel y optimiza ad infinitum: busquemos pasar de un 31.5% a un 31.7%. El Data Analyst machaca los mismos datos una y otra vez buscando una mejora incremental más. Marketing solo sabe qué palabra rankea mejor en SEO y le da igual el usuario (o el sentido común).
¡Por fin llegamos a los datos! ¿Cómo hemos tardado tanto si son una parte tan importante? Lo cierto es que, sin resultados y ejecución, los datos no sirven para nada. Si tenemos los dos puntos anteriores cubiertos, pasamos a utilizar los datos para prácticamente todo:
Acotar la experiencia end-to-end del usuario y dar la relevancia justa a cada fase del journey de usuario
Informar al equipo multidisciplinar del estado de su métrica clave y los resultados que se van obteniendo
Fijar prioridades y tomar decisiones en base al comportamiento real y no a los pienso que y creo que. Data trumps opinion, anytime - que le solía decir a mi primer equipo de growth (llegué a hacerme una camiseta).
Ejecutar las acciones que propongamos para experimentar. Esto no es baladí: usamos los datos para definir el cuándo y nos olvidamos del roadmap de producto. Insisto: nos olvidamos del roadmap de producto. No tiene sentido definir qué voy a hacer a priori, sino qué quiero conseguir.
Conclusiones
La experimentación no es solo una serie de pruebas y ajustes, sino una mentalidad y un proceso continuo que coloca al usuario y al producto en el centro de la estrategia de crecimiento, forzándonos a trabajar de forma verdaderamente multidisciplinar para conseguir resultados.
Experimentar a escala y generando impacto no es sencillo, pero tampoco rocket science: muchas veces nos olvidamos del sentido común y que no importa lo inspirados que estemos, la experimentación (como otras tantas prácticas en Producto) no es un fin, sino una herramienta más para 1) generar ingresos y 2) solucionarle problemas al usuario.
Para conseguir un modelo de experimentación que funcione de verdad (hint: que nos dé pasta) la prioridad número uno serán los resultados, seguidos de la ejecución (si no hay movimiento, difícil) y, por último, los datos. Los datos son la base, pero done is better than perfect.
Y, sobre todo, no seamos growth hackers ni PMs de libro. No solo es aburridísimo, sino que no generaremos ni un solo euro.
 | A guest post by
|