Producto, growth y tecnología: la convergencia que el stack de martech todavía no asimiló

El 18 de junio de 2026 hicimos, junto con PostHog, la segunda edición de Build & Grow: 45 personas en Huerta Coworking, Palermo. Tres charlas seguidas, una sola pregunta de fondo: producto, growth y tecnología, ¿siguen siendo cosas distintas?

Las tres respondieron lo mismo desde ángulos diferentes, sin haberse coordinado para eso.

Ariana Onega, fundadora de Empretienda, que terminó siendo adquirida por Ualá, y hoy al frente de Certenza, abrió con cómo llevar un producto al mercado. Su punto operativo: la distancia entre "tenemos un producto" y "el mercado lo usa" no se cierra con una función de marketing separada del producto, sino con un equipo que trata el ir al mercado como parte del producto mismo.

Valentín Morales, nuestro director, tomó la tensión central de la noche de manera directa: la convergencia de producto, growth y tecnología, y cómo eso reescribe el stack de martech. El argumento conecta con una tesis que ya desarrollamos en el blog: la mayoría de los problemas de growth no son problemas de adquisición, son problemas de claridad de producto. Si eso es cierto, separar al equipo que mide el growth del que decide el producto es separar el síntoma de la causa.

Patricio Tarantino, de PostHog, cerró mostrando PostHog Code, el producto que la empresa lanza en 2026 y que al cierre de esta nota está en lista de espera. No es un editor de código más: es un agente de desarrollo que usa los datos de producción como fuente de verdad, leyendo actividad in-app, errores, grabaciones de sesión y tickets de soporte para triar bugs y abrir pull requests por su cuenta. Su propio posicionamiento lo resume: la única devtool de AI que entiende tu producto, no solo tu código.

Tres charlas, un mismo movimiento de fondo. Eso es lo que vale la pena analizar, más allá del evento.

El análisis: convergencia, no predicción

La hipótesis es simple de enunciar e incómoda de implementar: producto, growth y tecnología están colapsando en una sola disciplina, y el stack de martech todavía está armado para el mundo anterior, el de los silos.

Conviene ser preciso sobre qué se rompe cuando estas tres áreas se separan, porque "todo está conectado" es una frase vacía si no se aterriza. Se rompen tres cosas concretas.

Primero, el feedback. Cuando producto y growth son equipos distintos con herramientas distintas, el ciclo entre "lanzamos algo" y "entendimos qué pasó" se alarga. Y el feedback que llega tarde no es un experimento, es actividad. Un equipo que corre tests cuyos resultados aparecen dos sprints después no está aprendiendo, está documentando el pasado.

Segundo, la métrica. Si producto define el éxito en una herramienta y growth lo mide en otra, no existe una sola versión de por qué los usuarios crecen o convierten. La pregunta que debería poder contestarse en una oración, por qué crecemos, se vuelve una negociación entre dashboards que no coinciden.

Tercero, el stack. Acá está el costo más tangible. El stack de martech de la mayoría de las empresas no se diseñó, se acumuló: un tool para product analytics, otro para experimentación, otro para session replay, otro para feature flags, otro para el data warehouse. Cada uno resolvió un problema puntual en su momento. El problema agregado es que esa fragmentación hoy pesa más que la falta de data. No falta información: falta una sola superficie donde producto, growth y tecnología miren lo mismo.

La convergencia, entonces, no es una predicción sobre el futuro. Es una respuesta a un dolor presente, y se sostiene aunque uno borre del texto a cualquier proveedor en particular. El argumento es sobre cómo trabajan los equipos, no sobre qué software compran.

Dicho eso, el mercado de herramientas refleja el mismo movimiento, y PostHog es un ejemplo legible porque creció consolidando categorías que antes eran productos separados. Lo que empezó como product analytics open-source hoy reúne en una sola plataforma web analytics, grabaciones de sesión, feature flags, experimentos A/B, encuestas a usuarios, seguimiento de errores, un data warehouse y observabilidad de LLMs, además de un asistente de análisis con AI. Esa lista no es un catálogo de features: es exactamente el conjunto de herramientas separadas que un equipo en silos compraría, integraría y reconciliaría por su cuenta. PostHog Code lleva la lógica un paso más allá: toma las señales que la plataforma ya captura y las usa como input para escribir el código que corrige el producto. La frontera se corre desde medir el producto hacia construirlo, y el círculo entre observar y actuar empieza a cerrarse dentro de la misma herramienta.

Las tensiones

Presentar la convergencia y el all-in-one como una solución sin costos sería deshonesto, sobre todo en una nota que sale de un evento que hicimos con PostHog como sponsor. Los trade-offs son reales y conviene mirarlos de frente.

El all-in-one tiene un costo claro: lock-in. Concentrar product analytics, experimentación y feature flags en un solo proveedor reduce fricción, pero aumenta la dependencia. Si ese proveedor cambia su modelo de precios o su roadmap se desvía del propio, la salida es más cara que cuando las piezas eran intercambiables. El best-of-breed tiene el costo inverso: cada herramienta es la mejor en lo suyo, pero alguien paga el impuesto de integración, que es precisamente la fragmentación descrita arriba. O se paga integración, o se paga dependencia.

Hay además un costo de transición que los equipos chicos sienten más. Consolidar no es gratis: migrar de un stack acumulado a uno unificado consume tiempo de equipo en el medio del año operativo, justo el recurso que una startup de dos o tres personas no tiene de sobra. La decisión sensata rara vez es "migrá todo ya", sino "no agregues una herramienta más sin preguntarte si la superficie que ya tenés lo resuelve".

La tensión más filosa aparece con las herramientas agénticas como PostHog Code, y es donde el entusiasmo de un demo choca con la realidad de una empresa grande. Un agente que ingiere grabaciones de sesión, tickets de soporte y datos de producción para abrir pull requests automáticamente amplía la superficie de riesgo en tres frentes a la vez: gobernanza (quién revisa y aprueba el código que el agente propone antes de que llegue a producción), sensibilidad de datos (session replays y tickets suelen contener información personal, y alimentarlos a un sistema que genera código exige criterios de privacidad explícitos) y compliance (en industrias reguladas, "self-driving development" es una frase difícil de defender ante un área de seguridad o ante un board). Nada de esto invalida la herramienta. Sí define que el modelo agéntico entra antes y más fácil donde el costo de un error es bajo, y entra último donde un PR mal puesto tiene consecuencias regulatorias.

Por último, una tensión sobre la evidencia misma. Este análisis se sostiene en la observación operativa y en la lógica del problema, no en benchmarks. No hay acá un número que diga "consolidar mejora la conversión un X%", porque ese dato, de forma pública y verificable, no existe. Quien necesite un case study con cifras antes de mover su stack tiene razón en pedirlo, y todavía no está disponible.

Para quién (y para quién no)

La convergencia rinde más en startups y scaleups donde la velocidad de aprendizaje importa más que optimizar cada capa, y donde un equipo chico no puede pagar el impuesto de integración de cinco herramientas. Ahí, reducir la cantidad de superficies donde vive la verdad sobre el usuario es una ventaja directa.

En operaciones grandes, con equipos dedicados por capa y requisitos de gobernanza, el cálculo cambia: pueden absorber el impuesto de integración a cambio de evitar el lock-in, y deben sopesar con cuidado la superficie de riesgo de las herramientas agénticas antes de adoptarlas. No es una respuesta única.

Lo que aplica a todos es el orden de los factores. La convergencia del stack sigue a la convergencia del equipo, no al revés. Si producto y growth siguen siendo dos áreas que se pasan tickets, ninguna plataforma unificada va a unificar la operación. Por eso el primer movimiento, el de esta misma semana, no es comprar nada: es auditar cuántas herramientas distintas tocan el mismo evento de usuario y cuántas definiciones distintas de las mismas métricas conviven en la empresa. La mayoría de los equipos se sorprende con el número, y ese mapa es la decisión, no el catálogo de features de ningún proveedor.

Lo que no sabemos

No existe una cifra pública y verificable que cuantifique el costo de la fragmentación de tooling en empresas de LATAM. Esta nota lo trata como patrón observado en la operación diaria y en lo que se discutió en el evento, no como dato de mercado.

Tampoco está claro a qué velocidad avanza la convergencia por industria. Es plausible que en sectores con equipos de data maduros el movimiento sea más lento, porque el costo de salida de los stacks existentes es mayor.

Sobre PostHog Code en particular: se lanza en 2026 y al cierre de esta nota está en lista de espera, así que lo que se afirma es sobre la dirección que marca el producto, no sobre resultados a escala en producción.

Y, por transparencia: esta nota sale de un evento que hicimos con PostHog como sponsor. La tesis de convergencia no depende de PostHog, pero los ejemplos de tooling que usamos lo favorecen. El lector debería tenerlo a la vista.

Contenido asistido por IA y criticado por tres personas que no se ponen de acuerdo en nada. El resultado es esto.