In the book “Growth Engineering” growth is seen as an integrated system: product, data, code, experiments and operational responsibility. Here we take this vision, but without abstracting: the size of the sample is an economic choice as well as statistical.
Many tests start without a clear idea of the effect they might detect. When the result is uncertain, the team tends to extend the test at random without a precise strategy.
Thesis
Taking a test without defining the MDE is like fishing with a net you don’t know the size of: you don’t know if the fish is missing or if the net is too wide.
It is not about adding another tool to marketing or an extra dashboard to the product. The goal is to build a mechanism that accelerates the transition from signal to decision. A good growth system does not promise certainties, but reduces the cost of uncertainty.
In daily work this also changes the way of writing code. A change is not complete when it passes into production, but when it can be observed, compared with a hypothesis and transformed into a choice: release, iterate, stop or deepen.
Operational schedule
- Baseline 2. Minimum useful effect (MDE) 3. Statistical power 4. acceptable error level 5. Maximum test duration 6. Business decision
This scheme is deliberately simple. The complexity comes with increasing traffic, segments, channels and automations. If the basic flow does not reduce to five or six clear steps, the team is probably automating a process that has not yet understood.
Practical example
If the checkout conversion rate is 4% and you want to see an improvement of 0.1%, it could serve much more traffic than the business can expect.
The point is not the single intervention, but the link between intervention and learning. If the result improves, the team knows what to scale; if it does not improve, it knows what conviction to correct. In both cases the system becomes more intelligent.
Metrometers to monitor
- MDE, Statistical power, Basicline conversion, Opportunities cost of testing
These metrics must not be just decorations. They must be part of a synthetic scorecard, read regularly, with a decision associated with it. If a metric does not influence any choice, it is probably a comfort metric.
Typical error to avoid
Look for significance on too small effects to have real impact on the business.
This error is common because it seems productive: it generates activities, meetings, graphs and often enthusiasm. But growth engineering does not measure the value from the number of things done, but from the quality of the learning cycle that remains.
Checklist for the team
What kind of decision should be made more clearly?, What event or data source makes behavior observable?, What risk do we not want to make worse while optimising?, Who can really change the process after reading the result?
If at least one answer is vague, it is better to stop before implementing. The real speed is not to start immediately, but to avoid to redo the job for hypotheses, data or confused decision criteria.
Practical reading in the ai-driven world weak growth will become even louder. it will be easy to generate ideas, texts, segments and automations, but much rarer to build systems that distinguish signal from noise.
This is why the growth engineer of the future will not only be technical, but also designer of tests, limits, feedback and operational memory. Who knows how to do this does not chase AI, integrates it into a controllable process.
What to do now before calculating statistics, ask: what minimum improvement justifies implementation, maintenance and risk?
Bringing this question to review is already an act of growth engineering: it shifts the conversation from generic opinions to a system that can learn.