Product, growth, and technology: the convergence your martech stack hasn't absorbed yet

On June 18, 2026 we ran the second edition of Build & Grow together with PostHog: 45 people at Huerta Coworking, Palermo. Three talks back to back, one question underneath all of them: are product, growth, and technology still separate things?

All three answered the same thing from different angles, without having coordinated for it.

Ariana Onega, founder of Empretienda, which was acquired by Ualá, and now building Certenza, opened with how to take a product to market. Her operational point: the gap between "we have a product" and "the market uses it" does not close with a marketing function kept separate from the product, but with a team that treats going to market as part of the product itself.

Valentín Morales, our director, took the central tension of the night head-on: the convergence of product, growth, and technology, and how it rewrites the martech stack. The argument connects with a thesis we already developed on the blog: most growth problems are not acquisition problems, they are product clarity problems. If that is true, separating the team that measures growth from the one that decides the product is separating the symptom from the cause.

Patricio Tarantino, from PostHog, closed by showing PostHog Code, the product the company launches in 2026 and which, as of this writing, is in waitlist. It is not just another code editor: it is a development agent that uses production data as its source of truth, reading in-app activity, errors, session recordings, and support tickets to triage bugs and open pull requests on its own. Its own positioning sums it up: the only AI devtool that understands your product, not just your codebase.

Three talks, one underlying movement. That is what is worth analyzing, beyond the event.

The analysis: convergence, not prediction

The hypothesis is simple to state and uncomfortable to implement: product, growth, and technology are collapsing into a single discipline, and the martech stack is still built for the previous world, the one of silos.

It is worth being precise about what breaks when these three areas are separated, because "everything is connected" is an empty phrase if it does not land. Three concrete things break.

First, feedback. When product and growth are different teams with different tools, the cycle between "we shipped something" and "we understood what happened" stretches out. And feedback that arrives late is not an experiment, it is activity. A team running tests whose results show up two sprints later is not learning, it is documenting the past.

Second, the metric. If product defines success in one tool and growth measures it in another, there is no single version of why users grow or convert. The question that should be answerable in one sentence, why are we growing, turns into a negotiation between dashboards that do not match.

Third, the stack. This is the most tangible cost. Most companies' martech stack was not designed, it accumulated: one tool for product analytics, another for experimentation, another for session replay, another for feature flags, another for the data warehouse. Each solved a specific problem at the time. The aggregate problem is that this fragmentation now weighs more than the lack of data. Information is not missing: what is missing is a single surface where product, growth, and technology look at the same thing.

Convergence, then, is not a prediction about the future. It is a response to a present pain, and it holds even if you delete any particular vendor from the text. The argument is about how teams work, not about what software they buy.

That said, the tooling market reflects the same movement, and PostHog is a legible example because it grew by consolidating categories that used to be separate products. What started as open-source product analytics today brings together, on a single platform, web analytics, session recordings, feature flags, A/B experiments, user surveys, error tracking, a data warehouse, and LLM observability, plus an AI analysis assistant. That list is not a feature catalog: it is exactly the set of separate tools a siloed team would buy, integrate, and reconcile on its own. PostHog Code takes the logic one step further: it takes the signals the platform already captures and uses them as input to write the code that fixes the product. The frontier moves from measuring the product toward building it, and the loop between observing and acting starts to close inside the same tool.

The tensions

Presenting convergence and all-in-one as a cost-free solution would be dishonest, especially in a piece that comes out of an event we ran with PostHog as sponsor. The trade-offs are real and worth facing head-on.

All-in-one has a clear cost: lock-in. Concentrating product analytics, experimentation, and feature flags in a single vendor reduces friction, but increases dependence. If that vendor changes its pricing or its roadmap drifts from yours, the exit is more expensive than when the pieces were interchangeable. Best-of-breed has the inverse cost: each tool is the best at its job, but someone pays the integration tax, which is precisely the fragmentation described above. Either you pay integration, or you pay dependence.

There is also a transition cost that small teams feel more. Consolidating is not free: migrating from an accumulated stack to a unified one consumes team time in the middle of the operating year, exactly the resource a two or three person startup does not have to spare. The sensible decision is rarely "migrate everything now," but "do not add one more tool without asking whether the surface you already have solves it."

The sharpest tension shows up with agentic tools like PostHog Code, and it is where the excitement of a demo collides with the reality of a large company. An agent that ingests session recordings, support tickets, and production data to open pull requests automatically widens the risk surface on three fronts at once: governance (who reviews and approves the code the agent proposes before it reaches production), data sensitivity (session replays and tickets often contain personal information, and feeding them to a system that generates code requires explicit privacy criteria), and compliance (in regulated industries, "self-driving development" is a hard phrase to defend before a security team or a board). None of this invalidates the tool. It does mean the agentic model enters earlier and more easily where the cost of an error is low, and enters last where a bad PR has regulatory consequences.

Finally, a tension about the evidence itself. This analysis rests on operational observation and the logic of the problem, not on benchmarks. There is no number here saying "consolidating improves conversion by X%," because that figure, publicly and verifiably, does not exist. Anyone who needs a case study with numbers before moving their stack is right to ask for it, and it is not available yet.

Who it's for (and who it isn't)

Convergence pays off most in startups and scaleups where speed of learning matters more than optimizing each layer, and where a small team cannot afford the integration tax of five tools. There, reducing the number of surfaces where the truth about the user lives is a direct advantage.

In large operations, with teams dedicated per layer and governance requirements, the calculation changes: they can absorb the integration tax in exchange for avoiding lock-in, and they must carefully weigh the risk surface of agentic tools before adopting them. There is no single answer.

What applies to everyone is the order of operations. The convergence of the stack follows the convergence of the team, not the other way around. If product and growth are still two areas passing tickets to each other, no unified platform is going to unify the operation. That is why the first move, this very week, is not to buy anything: it is to audit how many different tools touch the same user event and how many different definitions of the same metrics coexist in the company. Most teams are surprised by the number, and that map is the decision, not any vendor's feature catalog.