Engineering
Experimentation
Growth Engineering
Product

Growth Experiments @ Apollo Workflows: Small Bets, Real Data, Hard Lessons

Harshit Pandey
June 22, 2026
11 min read
Growth Experiments @ Apollo Workflows

This is the second in a series of engineering articles from Apollo's Workflows team. If you missed the first one on solving the cold-start problem with AI, start there.

About Workflows: Apollo Workflows is Apollo's automation engine — built to handle the heavy lifting in your sales process: scheduling tasks, updating contact records, and driving outreach at scale. Think of it as the layer that turns your GTM playbook into something that runs itself.

We shipped five growth experiments for Apollo Workflows over a few quarters. Two of them blew past our expectations. Two of them quietly flopped. And honestly, the ones that didn't work taught us more than the ones that did.

This isn't a highlights reel. It's a case study in what happens when a product engineering team starts thinking like growth engineers — with real numbers, real missteps, and the mental models that changed how we approach experimentation.

🧠 The Way We Think About Experiments

Before we get into the results, it helps to know the philosophy behind them.

At Apollo, growth engineering isn't a separate team that runs experiments on your product. It's a mindset shift. Engineers are expected to own their metrics — not just ship features, but understand whether those features are actually moving the needle. That means reading your Amplitude dashboards before proposing a change, writing a hypothesis before touching a line of code, and being honest when the results say you were wrong.

The frameworks we use are simple by design. One that stuck with me from the Growth Engineering Bootcamp is ELMR — a user psychology lens from Reforge that asks four questions about every user-facing change:

  • Emotion: What feeling do you want to trigger? Curiosity? Social proof? FOMO?
  • Logic: What's the rational reason a user should act? The stat, the benefit, the "save 70% of your time."
  • Motivation: How do you reduce friction enough that the user actually takes the step?
  • Reward: What do they get immediately after acting? Not eventually — right now.

I'll show you exactly how I used this framework on one of the experiments below. What surprised me was how much sharper my thinking got once I started filtering decisions through it. Once I started running decisions through it, I caught myself tweaking copy that looked fine on the surface but had no clear emotional hook. It's a useful sanity check before you ship something you're already attached to.

image.webp

The other thing we rely on heavily: hypothesis-first thinking. Every experiment starts with a clear, falsifiable statement: "We believe that [change] will cause [impact] because [reason]." If you can't write that sentence, you're not ready to ship an experiment.

🧪 The Experiments

🌟 The Hidden Gem Nobody Was Finding

Hypothesis: Surfacing the "Auto-Enrich Before Sequence" workflow in the People Finder — where users already have high intent — will drive meaningful workflow activation.

What we built: A nudge in the People Finder that promoted the auto-enrich workflow to users who were adding contacts to sequences but hadn't activated this specific workflow type.

image.webp

What happened: This was the most surprising result of the batch. Weekly workflow firings on the enrich node jumped from roughly 100 to over 2,300 (23x increase). Of the users who saw the nudge, 31% activated a workflow.
But here's what made it really land: 73% of those users had never touched enrichment before, and 68% were net new to non-auto-enrich workflows altogether. This wasn't re-engaging existing users, it was unlocking a feature for people who didn't know it existed.

The real learning: The feature wasn't broken. The placement was. And what made this sting more than a typical discovery problem: the feature was genuinely good. One click to set up. Real value: enriched contacts, cleaner sequences, visible almost immediately. This is the most underrated growth lever in any mature product: hidden gems. Before you build something new, ask whether something you've already shipped is just sitting in the wrong room.

🤖 The Cold-Start Killer

Hypothesis: Replacing generic workflow templates with AI-personalized recommendations will reduce the cold-start friction for new users and increase workflow activation.

What we built: An AI-powered recommendation engine that analyzes a team's existing sequences and suggests workflows tailored to their specific use case. New users see recommendations that feel relevant immediately, not a blank canvas.

undefined

What happened: When we rolled AI Recommendations out, the numbers were hard to ignore. New users who saw recommendations activated workflows at a +115.8% higher rate. Existing users engaged more — +83.1% lift. Week 3 retention jumped +86.3%.

We rolled it out in stages: 10% → 50% → 100% of teams. Each ramp held. No regressions. The AI generator we built was later reused for homepage recommendations, which wasn't something we planned — but it's the kind of extensible architecture payoff that makes incremental design worth it.

(This one has a deeper writeup — see the first article in this series if you want the full breakdown.)

What surprised us: 1 in 3 users (33.6%) who try a recommendation actually activate a workflow. Compare that to the blank canvas they started from, where most users bounced without ever launching anything. The blank canvas was the enemy. The recommendation was the shortcut past it.

🔌 The Bold First Step That Stalled at the Door

Hypothesis: Introducing Workflows inside the Chrome Extension — triggered after 3 "add to list" actions — will drive new users to discover and activate automation they didn't know existed.

What we built: The first-ever appearance of Apollo Workflows inside the Chrome Extension. A split-test nudge triggered at the third "add to list" action, surfacing the Lookalike workflow template with a direct CTA to view it in the Apollo dashboard.

image.webp

What happened: The nudge did exactly one thing well: it got people to open the workflow builder. Play Builder opens jumped +140% in the treatment group — a clear signal that the nudge itself was working. But the funnel stalled right there. Rule activation — the metric that actually mattered — sat at a 5.56% baseline in control, and the treatment never moved it enough to reach statistical significance. After 8 days and 34,500+ users exposed, the experiment closed as statistically insignificant. People opened the door. They just didn't walk through it.

The real learning: Traffic ≠ activation. Getting someone through the door is not the same as getting them to stay. If your downstream experience isn't ready for a cold audience, a nudge will surface the problem faster than it creates value. We needed Inline Workflows to be further along before this experiment could convert at the rate we wanted.

👥 Right Message, Wrong Surface (when a whisper won't wake anyone up)

Hypothesis: Dormant non-admin users will engage with Workflows if nudged via an in-product tip (SideTip) showing personalized social proof from their team.

What we built: A SideTip for non-admins who had activated a sequence but hadn't visited Workflows in 60+ days. The nudge showed their team's top-performing workflow with a personalized message — e.g., "Jeremy from your team just automated 1,200 contacts. Want to try it too?"

undefined

Designing this, I ran it through the ELMR framework:

  • Emotion: Social proof — a teammate already did it, so it feels achievable.
  • Logic: A concrete stat ("Save 70% of your time") backs the pitch.
  • Motivation: We showed a live, working workflow — not a blank builder.
  • Reward: Clicking through lets users explore a real automation immediately.

The copy and intent felt solid. The ELMR check helped sharpen both.

What happened: We ran the nudge copy through the ELMR framework before shipping — and it showed. The SideTip reached 4,100 non-admin users, and the dismissal rate was 65% — meaningfully lower than the 71% we see on generic nudges. ELMR did its job: the copy was sharper, the emotional hook landed, and fewer people batted it away without reading it.

But the funnel fell apart right after the click. Clicking the SideTip dropped users onto the Workflows page — not into a ready-to-run workflow. They still had to figure things out on their own. No single-click activation. No immediate reward. The activation rate was 3.45%, and it never moved enough to reach significance. Here's the other thing we underestimated: SideTips, by nature, carry more ignorance risk than modals. They sit at the edge of the screen.

ELMR + a modal? That would have been a different story entirely.

The real learning: The framework isn't the problem when the experiment fails — ask what the framework was working against. ELMR gave us the sharpest copy we'd written. The SideTip gave it the smallest possible stage. For a dormant user who hasn't thought about Workflows in 60 days, a tooltip at the edge of the screen isn't a nudge — it's wallpaper. You need a format that demands attention before the message can earn it.

🗂️ The Quiet Enabler

Hypothesis: Adding template category tabs inside the Workflows Finder will help users navigate to relevant templates faster, reducing time-to-first-workflow.

What we built: Categorized tabs in the workflow template library — filtering by use case so users don't have to scroll through everything to find what's relevant.

image.webp

What happened: Shipped. Low drama. Improved template discoverability. We didn't do a dramatic split test on this one — it was a clear UX improvement that removed a real friction point, and we monitored the downstream metrics to confirm no regressions.

The data told a quiet story. Roughly 1 in 4 users who visited the Templates tab applied a template — a ~27.2% average conversion rate, sustained consistently for 2 quarters across hundreds of users every week. No launch spike. No drop-off. Just a steady signal that when templates are easy to find, people actually use them.

The real learning: Not every improvement needs a big experiment. Sometimes you identify a clear friction point, fix it, and watch the downstream metrics (templates used in our case) move in the right direction. The discipline is in knowing the difference between a change that needs validation and one that just needs to be done.

📊 What the Data Told Us (That We Didn't Expect)

Looking across all five experiments, three patterns emerged that changed how we think:

1. Contextual beats promotional, every time.
The Auto-Enrich nudge worked because it lived where users were already doing the thing it was helping with. The nudge for dormant non-admin users failed because they pulled users away from their current context to think about something else entirely. The closer your nudge is to the moment of maximum intent, the better it converts.

2. Nudges drive spikes. The product drives habits.
The Chrome Extension nudge drove traffic. The activation didn't follow. A nudge can create a moment of awareness, but it can't substitute for a downstream experience that converts that awareness into a habit. If the post-click flow is broken or confusing, a better nudge just exposes the problem faster.

image.webp

3. Dormant users need doors, not breadcrumbs.
For users who are already engaged (like the People Finder users in the Auto-Enrich experiment), a quiet nudge works great. For users who haven't formed any intent (non-admins, dormant users), the format matters as much as the message. For that segment, a SideTip was just noise. If we'd run a modal with a stronger CTA first, we'd have a better read on whether the problem is the format or the feature itself.

💡 What We Learned About Ourselves

Running experiments changed how the team operates in ways I didn't fully anticipate.

image.webp

We got better at saying what we believe upfront. Writing a hypothesis before building — and committing to what success looks like — is surprisingly hard the first few times. It forces you to separate "I think users will do X" from "I hope users will do X."

We got more comfortable with failure. Two of these experiments didn't work. That's not a bad hit rate — it's the cost of learning. The ones that flopped gave us sharper instincts for what to try next.

And we started treating Amplitude dashboards the way most engineers treat PRs — as part of the job, not a bonus step after the "real" work is done.

🚀 Want to Build Like This?

We're still learning how to do this well. If you've run experiments like these and have opinions on what we got wrong, I'd genuinely like to hear it — reach out. And if you want to work on problems like this at Apollo, we're hiring.

Share

Related articles

Evolve your team's engagement & intelligence today