Un 25% más de conversión en el paywall, celebrado en la revisión del viernes. Tres meses después, esa cohorte usa menos el producto, renueva peor y deja el mismo ingreso que el control. Nadie hizo nada mal según sus propios objetivos, y ahí está el problema.
Rara vez falta talento en estos casos. Falla la interfaz entre dos funciones que tocan las mismas pantallas con relojes distintos: Growth mide en ciclos de dos semanas y Product en trimestres de trece semanas.
Cuando esa interfaz no está diseñada aparecen esfuerzos duplicados y discusiones sobre quién es dueño de qué. Peor aún, salen experimentos que mejoran un tramo del embudo mientras debilitan el producto entero, como pasó con el paywall.
La tensión tiene raíces legítimas. Growth viene de la tradición del performance: embudo, medición incremental, velocidad. Product viene de la estrategia, la propuesta de valor y la coherencia del sistema con ingeniería.
Además, el growth ya no vive en marketing. Está dentro del producto: en el onboarding, en la primera percepción de valor, en los hábitos, en el precio y en la reactivación, y cada vez más en bucles apoyados en datos y personalización. Por eso discutir de quién depende Growth no lleva muy lejos.
¿Qué reglas permiten entonces a las dos funciones trabajar sobre la misma superficie sin pelearse por ella? No hay una estructura única para todas las empresas. Sí hay cuatro mecanismos que se repiten donde la relación funciona: una jerarquía de métricas, un sistema común de experimentación, derechos de decisión escritos y rituales con fecha. Casi todos parten de aceptar que lo del paywall no fue un choque de personas.
Lo que parece un choque de personas es un fallo de diseño
Cuando Growth y Product chocan, el diagnóstico habitual es humano: faltó comunicación, sobran egos, el PM es lento, Growth es agresivo. A veces influye. Casi nunca es la causa.
Hay que dejar escrito quién decide sobre la activación, quién manda en el onboarding, quién puede tocar el precio y quién revisa los riesgos de diseño y técnicos. Si no, esas decisiones quedan al azar. Y en una empresa el azar tiene nombre: política interna, poder informal y las prisas del trimestre.
El producto acaba pareciéndose a la forma en que se hablan los equipos que lo construyen. Si entre Growth y Product no hay una interfaz definida, el producto tampoco la tendrá, y el usuario lo nota como un onboarding que promete una cosa y un paywall que vende otra.
La ambigüedad de propiedad es la fuente de fricción más frecuente. El onboarding es a la vez núcleo de la experiencia y palanca de activación, y lo mismo pasa con los paywalls, los avisos de upgrade, los programas de referidos y los recordatorios de reactivación.
Sin un modelo explícito aparecen dos riesgos opuestos. Uno es la superposición: tres equipos tocando la misma pantalla con criterios distintos. El otro es el vacío: todos asumen que «eso lo lleva el otro equipo» y el problema se queda sin dueño.
A esa ambigüedad se suma la diferencia de horizontes. Product trabaja con valor acumulativo y arquitectura de largo plazo; Growth necesita señales rápidas y mejoras medibles. Ninguna de las dos miradas está equivocada. Falta un mecanismo que las haga convivir, y sin él cada equipo optimiza dentro de su lógica: Growth mejora una conversión y enturbia el producto, Product protege la coherencia y deja pasar ventanas de aprendizaje.
Un buen diseño organizacional aprovecha esa tensión. Define interfaces, ritmos y una jerarquía de decisión para que ambos operen con autonomía sin desconectarse de la estrategia.
Product crea el valor; Growth lo amplifica. Product Management define, construye y sostiene el valor central: qué problema del usuario se resuelve, cómo encajan las funciones entre sí, hacia dónde va el roadmap. Growth trabaja para que la gente descubra ese valor, lo pruebe antes, lo convierta en hábito y acabe pagando por él.
Parece simple, y rebaja muchos conflictos. Product no puede ignorar el embudo, porque un valor que nadie percibe no retiene a nadie. Growth tampoco puede tratar el producto como una colección de palancas de conversión.
Las organizaciones que pierden esta diferencia caen en uno de dos extremos: Growth se vuelve decorativo, sin capacidad de tocar los recorridos críticos, o se convierte en una fuerza paralela que optimiza métricas inmediatas a costa de la coherencia.
Lo que mejor funciona es un acoplamiento estrecho con responsabilidades distintas, y se entiende mejor etapa por etapa.
En activación, Growth lidera el backlog experimental y Product protege la lógica de la experiencia y la promesa del producto. En monetización, Product define la arquitectura de la oferta y Growth valida la disposición a pagar, las fricciones de conversión y la mejora del ARPU. En retención, Product diseña los motivos para volver y Growth afina los disparadores, las secuencias y el momento de cada contacto.
La zona gris no desaparece, pero queda acotada por tres preguntas: quién lidera, quién protege y qué métrica arbitra cuando ambos discrepan. La tercera es la que falló en el paywall.
El paywall con números: por qué el test de dos semanas engañó
Pongamos cifras redondas, inventadas pero verosímiles. Llegan al paywall 10.000 usuarios al mes. El control convierte al 4%, es decir, 400 suscriptores a 10 euros al mes. La variante de Growth (plan anual destacado, prueba gratuita más corta, más urgencia en el texto) convierte al 5%: 500 suscriptores, un 25% más. A las dos semanas, la variante gana sin discusión.
Un 25% más en dos semanas sobre un paywall maduro merece sospecha antes que celebración. En una pantalla que ya se ha optimizado muchas veces, los saltos grandes suelen salir de un error de medición o de una ventana mal elegida. Aquí la medición era correcta; el fallo estaba en la ventana.
El coste aparece en las renovaciones. Supón que al tercer mes sigue pagando el 70% de la cohorte de control y solo el 56% de la cohorte de la variante, porque la urgencia atrajo a usuarios menos convencidos. Quedan 400 × 0,70 = 280 suscriptores en un caso y 500 × 0,56 = 280 en el otro. El 25% de mejora se ha evaporado en noventa días. Si la cohorte de la variante sigue perdiendo usuarios más deprisa, a partir del cuarto mes la variante ya resta ingresos, y eso sin contar las devoluciones ni los tickets de soporte que genera una venta forzada.
El golpe llega también al cálculo de adquisición. Supón que la empresa se ha puesto como suelo un LTV de tres veces el CAC. Con un CAC de 120 euros y un LTV de 360, el negocio está justo en esa línea. Si la cohorte nueva retiene un 20% peor, el LTV cae hacia 288 euros y la relación baja a 2,4. Growth habría cumplido su objetivo de conversión y, a la vez, habría vuelto menos rentable cada euro de adquisición.
El mecanismo de fondo es que los usuarios aprenden. Un test corto mide la primera reacción a la urgencia; el efecto a largo plazo depende de cómo se comporta esa gente cuando la urgencia ya no está, y los dos números pueden ir en direcciones opuestas.
Para un paywall de suscripción mensual, la regla es concreta. El test, o un grupo de control que se deja aparte, dura al menos hasta la primera renovación. Y la métrica de salvaguarda (la que no puede empeorar) es la renovación o el uso activo a ocho semanas, además de la conversión.
Mantener ese control también cuesta, y conviene poner el precio sobre la mesa. Si el 10% del tráfico del paywall, 1.000 usuarios al mes, sigue viendo la versión antigua durante 90 días y la variante convierte de verdad un punto más, el control renuncia a unas 10 suscripciones al mes, 30 en todo el periodo. Frente a una decisión que afectará a 10.000 usuarios al mes durante años, es un seguro barato.
Una jerarquía de métricas decide quién gana cuando discrepan
Compartir paneles no basta. Growth mira el coste de captar clientes, la activación, la mejora de cada test y la retención. Product mira qué funciones se usan, si la gente completa sus tareas y si está satisfecha. Si nadie dice cómo se relacionan esas cifras, cada equipo acaba defendiendo su propia idea de avanzar.
Una jerarquía bien diseñada tiene cuatro pisos. Arriba, una North Star Metric que capture el valor recurrente que el producto crea en la vida o el trabajo del usuario, lejos de las métricas de vanidad. Debajo, las palancas de crecimiento: adquisición, activación, retención y monetización.
Después, las métricas de producto: adopción, éxito en tareas críticas, fricción y profundidad de uso. En la base, las métricas experimentales: mejora incremental, conversión local, CTR, tasas de finalización.
El valor de la jerarquía está en su regla de lectura. Una victoria en la base solo cuenta si no empeora ningún piso superior dentro de la ventana acordada. Con esa regla, un aumento de activación que no mejora la retención deja de celebrarse a destiempo, y un paywall que sube ingresos a corto plazo pero reduce el uso activo se evalúa con el contexto completo.
Por eso la jerarquía funciona como mecanismo de alineación entre equipos más que como asunto del equipo de datos: decide de antemano qué métrica arbitra un conflicto, en lugar de dejarlo en manos de quien levante más la voz en la revisión.
Escrita, la regla cabe en tres líneas. Supón una herramienta de gestión de proyectos cuya North Star son las cuentas que cierran al menos tres tareas compartidas por semana; la palanca que trabaja Growth es la activación a siete días y la salvaguarda es la retención a ocho semanas.
Un test que sube la activación del 30% al 33% pero baja la retención a ocho semanas más de un punto no se escala, por bonito que sea el primer número. El umbral exacto lo fija cada equipo. Lo que no se negocia es acordarlo antes de ver el resultado.
Growth tiene aquí una queja razonable. Si cada test de paywall tiene que esperar ocho semanas a la salvaguarda de retención, el equipo pasa de lanzar dos pruebas al mes a lanzar una cada dos meses, y la velocidad de aprendizaje se desploma. Dos tests al mes son 24 al año; uno cada dos meses son 6.
La salida conserva la salvaguarda y añade un indicador adelantado validado con cohortes anteriores. Si el uso activo en la segunda semana ha seguido de cerca a la retención a ocho semanas en las últimas seis cohortes, sirve para decidir rápido, y un control pequeño confirma después el efecto largo. Cuando el indicador adelantado y la retención real se separan, se deja de usar y se vuelve a esperar.
La experimentación necesita un sistema compartido. Saber qué mirar no dice cómo aprender de ello. Muchas empresas dicen que deciden con experimentos, tienen feature flags y un tablero de tests A/B, y les falta lo principal: una disciplina común. Cómo se redactan las hipótesis, cómo se priorizan, qué estándar estadístico se exige, cómo se documenta la decisión, cómo se evalúan los riesgos de UX y arquitectura y dónde se guarda lo aprendido para no repetir errores.
Growth suele marcar el ritmo, pero Product no puede quedarse fuera. Si Growth experimenta sin un marco compartido, los tests se desconectan de la estrategia. Si Product controla cada prueba, la velocidad de aprendizaje cae.
El equilibrio aparece cuando ambos usan el mismo sistema: Growth aporta la energía de prueba, Product el contexto y la evaluación de los compromisos estructurales. Ese sistema incluye plantillas de hipótesis, un método de priorización, criterios de QA, revisiones periódicas, decisiones registradas y una biblioteca de aprendizajes, y gana peso a medida que la empresa crece.
El mínimo estadístico cabe en media página. Calcula antes de lanzar cuántos usuarios necesitas para ver el efecto más pequeño que te importa. Deja correr el test semanas completas, para no comparar lunes con sábados. Usa una sola métrica principal. Y no pares el test en cuanto aparezca un resultado bonito. Una herramienta de análisis experimental bien configurada reduce la arbitrariedad al leer los resultados. La velocidad experimental sale de ahí, y muy poco del esfuerzo heroico de dos o tres personas.
Donde mejor se ve esa disciplina es en el ciclo de vida de un experimento. La secuencia parece obvia; su valor está en el orden. Las salvaguardas se fijan antes de construir y los criterios de lectura antes de lanzar, que son justo los dos pasos que se saltan con prisa y los que habrían detectado a tiempo el problema del paywall.
Flujo de un experimento Growth/Product (secuencia operativa)
- Product detecta una fricción concreta (una caída en onboarding o una pérdida de valor temprano) y la documenta como problema, no como solución ya decidida.
- Growth la convierte en hipótesis con una métrica primaria y métricas de salvaguarda explícitas (qué no debe empeorar).
- Diseño e ingeniería construyen las variantes dentro de esos límites de UX y arquitectura.
- Data instrumenta el experimento y fija los criterios de lectura antes de lanzarlo, no después de ver los resultados.
- Product revisa los riesgos de experiencia, técnicos y de cumplimiento antes del lanzamiento. Durante el test, el equipo supervisa los límites acordados y detiene la exposición si se incumplen.
- La decisión de escalar, iterar o descartar se toma con evidencia compartida, y el aprendizaje se archiva para no repetir el mismo ciclo.
Cada superficie crítica necesita un dueño escrito
Antes de cada test tiene que estar claro quién tiene la última palabra. Muchas fricciones nacen menos de diferencias legítimas de criterio que de no haber dejado escrito quién decide, quién consulta y quién ejecuta. Una matriz de derechos de decisión resuelve la mayoría, se llame así o no. Para un SaaS self-serve, un reparto razonable de partida sería este:
- Onboarding principal: Product decide la arquitectura de la experiencia, Growth propone y valida variantes, Diseño protege la consistencia y Data garantiza la medición.
- Precio y empaquetado: la lógica estratégica pertenece al PM junto con negocio; Growth prueba elasticidad, paquetes y respuesta por segmentos.
- Paywall y avisos de upgrade: Growth decide las variantes dentro de un rango de precios fijado por Product, con la renovación como salvaguarda obligatoria.
- Disparadores de ciclo de vida y reactivación: decide Growth, y Product puede vetar un mensaje que prometa algo que el producto no cumple.
- Programa de referidos: decisión conjunta, porque toca a la vez la adquisición, la experiencia del invitado y el coste por usuario.
La lista exacta cambia en cada empresa. Lo que importa es que exista y que el resto de dominios críticos (la experiencia central, la recuperación de clientes que se van, los mensajes de monetización dentro del producto) tengan su fila. Eso reduce política interna, acelera decisiones y evita que cada conflicto se resuelva como si fuera el primero.
Para lo que no tiene fila hace falta una regla de desempate: si Product y Growth no se ponen de acuerdo en 48 horas, decide el dueño de la métrica más alta de la jerarquía afectada, y la decisión queda registrada con su motivo. El plazo es orientativo; lo que evita la parálisis es que exista uno.
La matriz también aclara los roles. El Product Manager responde de la estrategia, del problema del usuario y de la consistencia de la experiencia, y una parte central de su trabajo es impedir los máximos locales: mejoras en una métrica que deterioran el sistema.
El Growth PM responde del rendimiento del embudo y del roadmap experimental que lo mejora, en contacto diario con diseño, ingeniería, analítica y marketing. Tratarlo como un PM de segunda o un marketer disfrazado es un error, porque es un operador de crecimiento dentro del producto: traduce oportunidades de negocio en experimentos medibles.
Alrededor trabajan varios perfiles. Los growth engineers hacen posible la velocidad. Data scientists y analistas comprueban con rigor si un cambio causó de verdad el efecto. Diseño evita que tanta optimización rompa la experiencia. Y marketing y el equipo de comunicaciones con clientes llevan el sistema a la captación y a los mensajes.
La estructura depende del tamaño, y cada opción tiene su coste
No existe un diseño universalmente correcto, y copiar el organigrama de una empresa admirada sin su contexto suele salir caro. Hay cuatro patrones habituales, y cada uno compra algo a cambio de otra cosa.
Growth incrustado en los squads de producto acerca la lógica experimental al detalle de la experiencia. El precio es la duplicación: cuatro squads acaban con cuatro plantillas de test y cuatro maneras de leer un resultado, así que exige una coordinación central fuerte.
Un equipo central de Growth aporta disciplina, herramientas y estándares analíticos, pero Product puede vivirlo como una fuerza externa que interviene sin cargar con la complejidad del producto, y solo funciona con derechos de decisión muy bien definidos.
El modelo híbrido de Product-Led Growth combina especialistas incrustados con una función central que estandariza prácticas, y suele funcionar bien en SaaS self-serve. En ese reparto, cada squad responde de un flujo de valor completo, y la función central ayuda a los demás a adquirir una capacidad sin ejecutar por ellos: enseña a montar el test y deja que el squad lo lance.
Por último, los equipos por misión (activación, retención, monetización) con propiedad conjunta de PM y Growth alinean resultados como ninguna otra opción, pero exigen mucha madurez analítica y de liderazgo, porque la superposición de responsabilidades es máxima.
Hay quien sostiene que un equipo de Growth separado sobra: si cada PM responde de las métricas de crecimiento de su área, desaparece la frontera que genera el conflicto. En empresas con dos o tres squads suelen tener razón, porque coordinar una función más cuesta más de lo que aporta.
Dejan de tenerla cuando varias superficies comparten el mismo embudo (registro, onboarding, paywall) y nadie las ve completas, o cuando cada squad mide el mismo test de forma distinta. Como orientación, a partir de cuatro o cinco squads que tocan el mismo embudo una función central de estándares empieza a pagarse.
Los rituales sostienen lo que el organigrama promete. Muchas empresas rediseñan el organigrama y esperan que la colaboración mejore sola. Casi nunca funciona.
Lo que hace funcionar la relación son las reuniones compartidas, con fecha en el calendario. Media hora a la semana para revisar el embudo. Cada dos semanas, planificar juntos los tests. Una reunión de estrategia al mes y una revisión de métricas al trimestre. Y un repaso tras cada experimento que haya cambiado una decisión.
Esos rituales cumplen dos funciones. La obvia es coordinar trabajo. La importante es crear una lectura común de la realidad: Product y Growth dejan de encontrarse solo cuando hay conflicto y construyen juntos el marco para interpretar el comportamiento del producto.
Hay un síntoma sencillo para saber si funcionan. Si en la revisión semanal alguien presenta un resultado que el otro equipo desconocía, el ritual existe en el calendario pero no en la práctica.
La retrospectiva de experimento no necesita más de veinte minutos y cuatro preguntas: qué esperábamos, qué pasó, qué decisión cambia y dónde queda escrito. Si la cuarta respuesta está vacía, lo aprendido se perderá con la siguiente rotación del equipo.
En un growth loop, cada optimización local cambia las demás etapas. Los growth loops son la prueba más dura de todo lo anterior, porque en un bucle la salida de una etapa es la entrada de la siguiente. Un usuario que se activa bien retiene más; uno que retiene invita a otros; los invitados llegan con una expectativa que el onboarding tiene que cumplir. Una optimización en un punto cambia las condiciones de todos los demás, y el reparto que parecía limpio sobre el papel se pone a prueba.
El reparto por etapas de más arriba sigue valiendo, con una etapa más al principio del bucle: en adquisición, Product define la propuesta de valor que hace que el producto merezca descubrirse, y Growth trabaja la distribución y el coste de acceso.
El paywall del principio es un bucle roto en miniatura: la conversión subió en monetización y el coste apareció en retención, donde ninguna salvaguarda del test estaba mirando. En el ejemplo, la variante perdió 220 suscriptores entre el primer y el tercer mes, 100 más que el control, y si el programa de referidos depende de usuarios satisfechos, esos 100 tampoco invitaron a nadie.
De ahí sale una regla práctica: cada experimento lleva una salvaguarda sobre la etapa siguiente del bucle, no solo sobre la propia. En un test de monetización eso significa vigilar al menos dos números más: la retención a ocho semanas y las invitaciones enviadas por usuario activo.
Dos equipos sobre el mismo embudo: la señal de que toca formalizar
En etapas tempranas bastan roles híbridos y métricas simples: onboarding, activación y bucles básicos, sin burocracia.
Al crecer conviene crear un equipo de Growth propio, poner reglas más firmes a los tests y separar mejor la fase de investigar qué construir de la de ejecutar. Una señal de que toca dar ese paso: dos o más equipos lanzan tests sobre el mismo embudo en el mismo mes. A partir de ahí la coordinación informal ya no alcanza y hace falta un calendario común de experimentos. En esa fase, las herramientas de evaluación de capacidades ayudan a mapear la estructura real de capacidades del equipo y a detectar huecos antes de que se conviertan en cuellos de botella.
En la etapa enterprise la formalización crece: comités de Growth entre squads, aprendizajes integrados en la estrategia de portafolio y planificación a varios trimestres, donde el modelado de escenarios ayuda a sostener conversaciones más rigurosas sobre la dirección.
En cualquiera de esas etapas, los fallos se parecen mucho de una empresa a otra, y cada uno deja un síntoma reconocible. Con KPIs en conflicto (Product medido por salud del producto, Growth por mejora local, sin jerarquía común), dos equipos presentan el mismo trimestre uno como éxito y otro como fracaso.
Cuando Growth va por libre, las ganancias de conversión no aparecen en la retención a 90 días. Cuando Product actúa como freno porque no hay salvaguardas claras, cada prueba se discute como una amenaza sistémica y el tiempo entre hipótesis y lanzamiento pasa de semanas a meses. El solapamiento se ve en dos tests corriendo a la vez sobre la misma pantalla. Y la falta de gobernanza experimental tiene el síntoma más fácil de comprobar: nadie sabe decir qué se aprendió del último test fallido.
¿Estructura o reglas? Un diagnóstico de una hora
Antes de tocar el organigrama, haz una prueba. Toma los últimos cinco experimentos que afectaron a onboarding, activación o paywall y responde para cada uno tres preguntas: quién decidió lanzarlo, qué métrica de la jerarquía debía moverse y qué pasó con la North Star unas semanas después.
Si las respuestas cambian según a quién preguntes, el problema está en los derechos de decisión o en la jerarquía de métricas, y ningún cambio de estructura lo arreglará. Una matriz de una página, revisada con ambos equipos en la misma sala, es el arreglo más barato.
Si las respuestas coinciden pero los experimentos se repiten o nadie recuerda lo aprendido, falta el sistema de experimentación: plantillas de hipótesis, criterios de lectura fijados antes del lanzamiento y una biblioteca de aprendizajes que alguien mantenga viva. Y si algún test de precio o de paywall se cerró antes de la primera renovación, conviene reabrirlo con un grupo de control a 90 días.
Cuanta más IA y personalización entren en el producto, más a menudo coincidirán ambos equipos sobre la misma pantalla. Con la matriz escrita, ese choque se resuelve consultando una fila.