Why growth engineering breaks down when product and data systems are not separated

1. Observation

Growth today mixes experimentation + product + data + engineering.

2. Structural problem

There is no clear boundary between system design and execution.

In many modern growth-driven teams, responsibilities like experimentation, product implementation, and data analysis are merged into shared execution layers without a clearly defined system architecture. This leads to a situation where decisions are made at the execution level rather than at the system design level, creating ambiguity in ownership, inconsistent implementation patterns, and reliance on individual availability instead of structured workflows.

Case study (fictional example)

A fast-growing health-tech company (fictional example) assigns growth responsibilities to a small engineering team working directly with product and data.

Instead of having a defined experimentation system, each growth initiative is executed as an isolated effort: one engineer builds tracking logic, another implements UI changes, and a third analyzes results independently.

Over time, experiments become slower to ship, metrics definitions start to diverge between teams, and repeated work appears because there is no unified system governing how growth experiments are designed, executed, and measured.

The issue is not individual performance, but the absence of a structured boundary between system design and execution layers.

3. Visible symptoms

• Engineers doing growth work.
• Growth teams dependent on engineering bandwidth.
• Experiments slowed down or inconsistently executed due to cross-team dependencies.

4. Consequence

Apparent speed, but low real scalability.

Growth decisions depend on technical availability instead of system design.

5. Principle

Growth is not a function → it is a property of the system.