How I Replaced My Entire Growth Team's Output With an AI Workflow12

How I Replaced My Entire Growth Team's Output With an AI Workflow12

How I Replaced My Entire Growth Team’s Output With an AI Workflow

I used to have six people working on growth experiments. SEO, content, email, paid social, A/B testing, analytics. Six people, six Jira boards, six Slack channels. By Q3, I was spending 30% of my week just coordinating the team rather than thinking about strategy.


Then I spent three weeks building a single AI workflow. Not a team of six. One workflow. And it produces more experiments per week than all six of them combined.


This isn’t a "AI will replace your job" piece. It’s a breakdown of how a specific pipeline works, where it beats humans, where it still needs humans, and the actual architecture.

The Problem Wasn’t Output Volume

Most growth teams aren’t slow. They’re bottlenecked on coordination.


Here’s what a typical week looked like:

Week Before:
├── Monday: 3 experiments in review
├── Tuesday: 2 new experiments proposed
├── Wednesday: 1 experiment shipped
├── Thursday: 1 experiment shipped
├── Friday: 0 shipped (meeting week)
└── Total: 4 experiments shipped / ~10 proposed

We proposed 10, shipped 4. The other 6 died in review, got deprioritized, or never got a designer or engineer’s time. The bottleneck wasn’t ideas. It was the handoffs between idea → copy → asset → test → analysis.


The AI workflow doesn’t eliminate the handoffs. It compresses them.

The Pipeline Architecture

The workflow has four stages. Each stage is a prompt chain with structured input/output, not a single "ask the AI to do everything" call.


Stage 1: Idea Generation + Scoring


Input: product changelog, last 30 days of analytics, user feedback clusters, competitor moves.


The model generates 40 experiment hypotheses. Then a second pass scores each one on:

  • Expected lift (estimated)

  • Implementation cost (1-5)

  • Confidence (1-5)

  • Time-to-data (days)

Output: a ranked table. Top 12 proceed to Stage 2.


Stage 2: Asset Production


Each selected hypothesis gets:

  • Copy (email, ad variants, in-app copy)

  • A/B test spec (variant A, variant B, success metric, sample size)

  • A mockup description (not a full design, a spec a designer can execute in 20 min)

This is where most "AI writes your copy" demos stop. I needed the test spec, not just the copy. The sample size calculation alone:


$$n = \frac{2 \times z^2 \times p(1-p)}{(\text{MDE})^2 \times p(1-p)}$$


The workflow generates this per experiment. A growth PM can now hand a fully-specified test to engineering and skip the "let me figure out the stats" step.


Stage 3: Execution Queue


Experiments go into a simple queue. A human (myself) reviews the queue for 15 minutes each morning. I approve, reorder, or kill experiments. The human gate is important — the AI doesn’t know which experiment the CTO will veto for technical debt reasons.


Stage 4: Analysis + Next Iteration


When an experiment hits sample size, the workflow pulls results, writes a 200-word analysis (effect size, confidence, qualitative read of the data), and feeds findings back into Stage 1. Winning patterns become priors for new hypothesis generation.

Where It Beats the Team

Experiments shipped per week:

Team of 6:    ████████████████  4
AI workflow:   ████████████████████████████████████████  12

The 3x difference isn’t magic. It’s that the AI doesn’t need to:

  • Wait for a designer’s calendar

  • Sit in a review meeting

  • Write a Jira ticket

  • Chase a PM for sign-off

It produces complete packages in minutes. A human reviews in minutes. Ship.


Where it still needs humans:

  • Strategic judgment (which metric actually matters this quarter)

  • Stakeholder negotiation (convincing eng to prioritize)

  • Edge cases (a bug that breaks the experiment, a PR crisis)

  • Creative "why" (the AI optimizes; humans decide what to optimize for)

The Prompt Engineering That Matters

The hardest part wasn’t the LLM calls. It was the context windows.


Stage 1 works best when the model sees:

  • The actual analytics (not a summary)

  • 5 recent winning experiments and why they won

  • The product roadmap for next 2 sprints

I build a context document that gets updated weekly. It’s ~4,000 tokens. Feeding the model the raw analytics JSON without structure gives generic output. Feeding it a curated "here’s what worked, here’s the roadmap, here’s the data" document gives specific output.


The scoring rubric in Stage 1 is a 200-word prompt. It’s the most important 200 words in the workflow. If the scoring is wrong, the whole pipeline optimizes for the wrong thing. I iterated on it for a week.

Cost and Time

Three weeks to build. Ongoing cost: ~$120/month in API calls. The team costs: ~$180,000/year. I’m not claiming the AI replaces the team. I’m claiming it replaces the coordination overhead of the team. I still have 4 of the original 6 people. They now focus on the 20% of experiments that need human creativity and stakeholder work.


The 80% that was "write the email, spec the test, calculate the sample size, format the Jira ticket" — that’s the workflow.

What Broke

  • Week 2: The AI generated 40 experiments, 14 were basically the same idea rephrased. Fixed by adding a diversity constraint to the scoring.

  • Week 3: It kept proposing experiments for a feature that was getting deprecated. Context document fix.

  • Ongoing: It overestimates expected lift by ~40%. I apply a 0.6x multiplier in the scoring.

The Mental Model

Think of it as a force multiplier, not a replacement. The team of 6 produces 4 experiments/week. The same team + workflow produces 12. The humans do the 20% that requires judgment, relationships, and creativity. The workflow does the 80% that was eating their time.


If you’re a solo founder: this is your team.

If you have a team: this is your multiplier.

If you’re in enterprise: start with one pipeline, one metric, two weeks. Don’t build the whole thing before you’ve seen one experiment ship end-to-end.


The workflow is 14 prompts, a context document, and a queue. You don’t need a framework. You need to make the handoffs invisible.