Around 2020, Duolingo was flat at roughly 5 million daily active users. Not short on ideas, not short on engineers, not short on things to ship. Flat anyway.

What broke the plateau wasn’t more. It was picking the one number that compounds and aiming everything at it. Four years later they were past 50 million daily users.

Here’s the mechanism, the actual experiments, and how to find your version of that number.

A 30-metric dashboard is a 0-metric dashboard

When growth flattens, broadening feels like the responsible move. More surface area, more chances something lands. Spread the bets, protect the downside.

It fails for a mechanical reason: nothing gets hit twice. Twelve experiments across twelve metrics produce twelve one-off bumps that each decay on their own schedule. Nothing accumulates because nothing is pointed anywhere long enough to accumulate.

Open your dashboard and look at what’s on it. Installs. Signups. Downloads. Virality coefficient. Feature adoption. Push volume. Trial starts. All rendered at the same size, all implicitly labelled important. A dashboard where everything matters equally can’t tell you what to do on Monday — it can only tell you what happened.

Duolingo’s move was subtraction. Find the single metric that drags the rest along, and stop pretending the other twenty-nine deserve equal attention.

CURR is a rate, not a count

The metric they landed on: if a user is active today, what’s the probability they’re back tomorrow? Next-day return probability. Duolingo calls it CURR — current user retention rate.

The distinction that matters isn’t the name. It’s rate versus count.

Counts make headlines. A signup number, an install number, a download record — you bank it once and it’s spent. A rate applies itself to every cohort you will ever acquire, every day, indefinitely. Improve it and you’ve improved the yield on all future acquisition without touching acquisition.

When Duolingo’s team looked at what actually moved DAU, CURR moved it roughly 5x more than any other input — more than installs, more than virality, more than downloads. That’s their read on their own data, not a law of nature. But it’s the finding that justified pointing the entire company at one number.

And the arithmetic behind it is the part that transfers. Improving “do they come back tomorrow” by 1–2% a month is exponential over a few years. A feature launch is linear, and then it decays.

Many small bets, one target

The discipline is the boring part, which is why most teams skip it: every experiment aimed at the same metric. Not distributed across the roadmap. Not one per squad. All of them, at CURR.

Three of the plays:

• They moved the streak counter to the top of the app. DAU up ~3%. A UI change measured in pixels, aimed squarely at return behavior.

• They shipped a “streak wager” — commit to keeping your streak, put something on the line. 14-day retention up ~5%, in-app purchase revenue up ~600%. A commitment mechanic pointed at coming back tomorrow.

• They A/B tested guilt. After about five ignored days, the notification opens with “These reminders don’t seem to be working…” — and then the reminders stop. Even the tone of a push notification became an experiment on return probability.

None of these is a stroke of genius. The streak counter is a position: fixed. The value isn’t in any single test — it’s that they were all cheap, all repeatable, and all nudging the same number by 1–2% a month.

That’s the whole trick. Alignment beats cleverness over a four-year window.

Why it compounded instead of spiking

The results, as reported: DAU from ~5M to 50M+. Churn in core markets from 47% down to 28%. And 55% of users now return the very next day. Over roughly four years.

No hero quarter in there. No single launch you could point at. That’s the tell that the mechanism was real — they optimized a rate that feeds on itself rather than a sequence of one-off launches, so each month’s gain started from the previous month’s baseline.

Worth being honest about the limits: this is one company, self-reported, in a habit-forming consumer product where daily return is the obvious behavior to chase. The transferable part is the method, not Duolingo’s exact definition of CURR.

Find your one compounding metric

Three steps, and you can start on Monday.

1. Pick a rate, not a count. Ask which single behavior, if it happened more reliably, would drag everything else up with it. For a habit app it’s next-day return. For B2B SaaS it’s usually weekly active teams rather than users, or the repeat rate on your core action. If the candidate metric can be banked and spent, it’s a count — keep looking.

2. Kill the dashboard. One north star, a handful of drivers underneath it, a few guardrails so you notice when you’re breaking something. Everything else moves to on-demand, not on-display.

3. Aim the portfolio. Small, repeatable experiments, all pointed at that one number. And change what you judge yourself on: moving it 1–2% a month, not shipping count.

Growth isn’t 40 optimizations. It’s one compounding metric, moved a little, every month.

Not a tweak to the demo. Not a shorter tour. He stopped shipping it as the default.

That violates the reflex every PLG team runs on. Time-to-value is the god metric, so you pre-load something shiny — sample data, a populated dashboard, a demo app — and the user “sees it working” in ten seconds instead of ten minutes. Faster aha, better activation. That’s the theory.

Mirko Novakovic, CEO of Dash0, ran the experiment and got the opposite result. Here’s what he actually measured, the four levers that moved the number, the one deletion that mattered most, and a test you can run on your own onboarding before Friday.

First, the definition most teams get wrong

Activation at Dash0 isn’t “signed up.” It isn’t “completed setup” or “finished the tour.”

It’s one behavior: the user sent us their data.

In Novakovic’s own framing, getting users to send data is the hardest step in the entire funnel. Everything before it is preamble. Everything after it is easier.

That choice of unit is the whole game. Sign-ups flatter you. Tour completions flatter you. “Engaged users” flatters you the most, because you get to define engagement. None of them predict retention, because none of them require the user to do the thing the product exists to do.

Reza Soumeeh’s ladder is the cleanest version of this: registration ≠ activation ≠ retention ≠ monetization. Four different rungs, four different failure modes. Most teams report on rung one and call it rung two.

So before you read the rest of this: if the number on your dashboard doesn’t correspond to a user doing the value action with their own work in it, you’re measuring comfort, not progress.

The curve: 15% → 40%

Early on, Dash0 activated somewhere in the range of 10–15% of new users. Six months later, north of 40%.

The unsatisfying part: there was no single hack.

Four levers, compounded.

• More integrations — fewer users blocked because their stack wasn’t supported

• Better docs — fewer users blocked because they didn’t know the next command

• In-product guidance — fewer users blocked because they lost the thread mid-setup

• Faster cloud setup — fewer users blocked because the first step was too heavy

Look at what those have in common. Each one removes a specific, identifiable reason a user stalls before the value action. None of them make the value action more impressive. They make it more reachable.

That’s the mental model worth stealing: activation gains are a portfolio, not a silver bullet. You don’t find the lever. You find the reasons, and you delete them one at a time until the floor stops leaking.

Worth doing, too — GrowthSpree’s 2026 benchmark set puts activation as the driver of an estimated 60–75% of trial-to-paid conversion variance. Directional and agency-sourced, so hold it loosely. But directionally it says the obvious thing: this is the highest-leverage number you own.

The deletion: why the demo app was hurting

Now the counterintuitive one.

Every new PLG user at Dash0 got a full demo application by default. Sensible design. The product is observability — an empty observability tool shows you nothing, so you populate it. New user logs in, sees traces flowing, dashboards lit up, the product visibly working. Instant comprehension.

Then they stopped making the demo the default and pushed users toward connecting their own environment instead.

The number of users sending their own data went up dramatically.

The mechanism fits in one line: a demo shows value; their own data makes the product theirs.

A demo lets a user stay a tourist. They’re impressed, they understand what the product does, and they have committed nothing. There’s no reason to come back tomorrow, because nothing of theirs is in there. Connecting their own environment is the moment the product stops being a showroom and starts being their tool — the moment it has something in it that they’d lose by leaving.

Generalize past observability, because this isn’t a devtools quirk. Sample data. Templates. Pre-built dashboards. Guided sandboxes. Anything that simulates the value action can quietly substitute for it. Scaffolding built to help users see value can end up delaying the moment they create it — and users will happily accept the delay, because the simulated version is easier and looks just as good.

The honest caveat: this is one company’s self-reported result, and the reverse is true for plenty of products. For some, a demo is the fastest honest path to the aha, and the real activation gap is ICP confusion or a broken setup step, not scaffolding.

So the takeaway isn’t “delete your demo.” It’s this: measure whether your scaffolding is a bridge to the value action or a comfortable detour around it. Most teams have never checked, because the demo was designed to help and helping things don’t get audited.

Bonus mechanism: feedback with no buffer

One more Dash0 choice that belongs in an activation story, even though it doesn’t look like one.

700+ customers, and no customer success department. Deliberately. A Slack channel per customer, issues routed straight to product and engineering.

Novakovic’s reasoning: if they shipped something painful, the team needed to feel it directly — without a customer success buffer.

Here’s why that shows up in the activation number. Onboarding friction is invisible to the people who can remove it, because they never experience it. A CS layer is very good at absorbing that pain: tickets get resolved, users get unstuck, satisfaction stays fine, and the underlying friction never reaches the person who could delete it in an afternoon.

Short line between the pain and the people who can fix it. That’s an architecture decision as much as an org one.

Run this test this week

Four steps. Maybe ninety minutes, most of it in your analytics tool.

1. Write down your activation event as a behavior the user performs with their own data or their own work. Not “signed up.” Not “completed setup.” Not “viewed the demo.” If you can’t phrase it with the word their in it, you haven’t found it yet.

2. Measure what % of new users hit it. That’s your real activation rate. It will be lower than the number you’ve been reporting. That’s the point.

3. List every piece of scaffolding between sign-up and that event. Sample data, demo environment, templates, tours, checklists, pre-filled projects. For each one, ask the question: bridge or substitute? Does it move the user toward doing the thing, or does it let them feel like they already did?

4. Pick the one you most suspect is a substitute, and A/B removing it as the default. Not deleting it — demoting it. Available on request, not served automatically. Then watch the value-action rate. Not sign-ups, not session length, not tour completion. The rate at which users put their own data in.

If the number goes up, you just found out your onboarding was competing with your product.

It’s a good argument. It’s also, mostly, beside the point.

A team that ran 514 experiments in a single year found that the format was never the lever. What moved their number was a screen most growth teams would have argued themselves out of shipping — and the argument against it would have sounded like good judgment.

If you’re staring at an 8% free-to-paid rate wondering whether that’s fine, here’s the mechanic, the numbers, and the part worth copying.

The number that stops you

Fyxer added an optional credit-card screen to their trial.

Sign-ups went down. Conversion went from 5% to 35%. Paying customers doubled on the same traffic. The experiment resolved in eight days.

Read that again slowly, because the shape of it is the whole lesson: fewer people entered the funnel, and more people paid. That only reads as a paradox if you’re counting the wrong thing.

Worth noting where this came from. This wasn’t a marketing brainstorm or a “what if we tried” in a Monday standup. It came out of a growth-engineering team — Kameron Tanseli’s — that treats the funnel as a system with instrumentation, not a set of opinions to be defended.

Why it works — the mechanism, not the trick

A credit-card field is not friction. It’s a qualification gate.

What it does is trade raw sign-up volume for intent. Someone who types in a card — even when they’re told they don’t have to — has made a small, private decision about whether they expect to pay. Everyone downstream of that field is a different population than the one you had before. Your conversion rate didn’t improve because your product got better in eight days. It improved because you stopped measuring against tire-kickers.

This isn’t a one-company anecdote, which is the part that should make you take it seriously. The 2026 Free-to-Paid Report — Kyle Poyar with ChartMogul and ProductLed, across roughly 200 products — found card-required trials convert around 5x higher than card-free ones. Fyxer’s 5%→35% sits neatly inside that benchmark rather than out on some lucky tail.

And here’s the finding from that report that should reframe how you read your own dashboard: median free-to-paid conversion is about 8%, but the top 20% of products convert around 10x the bottom 20%.

That spread is enormous. It means “are we good?” is a question with no useful answer — the median tells you almost nothing about where the ceiling is. The better question is which side of the mechanics are we on? Because a 10x gap isn’t a talent gap. It’s a gap in what’s been tested.

It was a system, not a screen

The card gate is the headline, but it’s the least interesting thing here in isolation. What matters is that it sits in a log alongside a dozen other moves, each one a small piece of evidence that this was engineering rather than luck:

Annual plan as the default, with the price shown as an effective per-month figure and a 25% discount. Result: 2.3x more annual trials. Roughly half of paying customers now take annual — which is a cash-flow and retention change disguised as a pricing-page tweak.

A new Pro tier at $50/user, up from a $30 list price. Revenue per trial went up 67%. Checkout completion fell by 6%. That trade is not close, and you only know the shape of it because someone shipped it and watched.

Trial length segmented by time-to-aha. Three days produced instant cancellations. Seven days worked best overall. But users signing up with personal email addresses needed 14 — they were slower to reach the moment where the product proves itself. Trial-start rate moved from 13.4% to 22.1%. Note what happened there: the answer wasn’t “shorter” or “longer,” it was “depends who,” and you can’t find that without segmenting.

And then the honest one. Social proof added to the “connect your email” step: 57.1% → 59.8%.

That’s a 2.7-point lift. Real, worth keeping, thoroughly unglamorous. I’m including it on purpose, because a set of results where everything is a doubling isn’t a log — it’s a highlight reel. Most experiments land here. The card gate is memorable precisely because most weeks don’t produce one.

The actual moat

514 experiments in twelve months. A team of four. That’s roughly 90 per engineer per year — call it two a week, every week, with no dead months.

Here’s the part I’d underline: no single test in that log is the strategy. The rate of testing is.

Nobody sat in a room and reasoned their way to “an optional credit-card field will 7x our conversion.” The idea is counterintuitive on its face — a reasonable person would predict it kills the funnel, and a reasonable person would be right about sign-ups. You don’t guess your way to that screen. You build an engine that surfaces it, then you have the discipline to count the right metric when it does.

Which means the constraint in your funnel probably isn’t ideas. You almost certainly have a backlog of them. If you run two experiments a quarter, you will never find your version of that screen — not because your hypotheses are worse, but because eight shots a year is not enough shots. Throughput is the moat. Everything else is downstream of it.

Count payers, not sign-ups. Then build the experiment engine that finds the one screen you’d never have guessed.

I build these experiment systems for a living — if your free-to-paid number has been stuck, that’s usually the work. Reply to this email and tell me where it’s stuck.

That reader now has company. The other one doesn’t execute JavaScript, doesn’t scroll, and doesn’t give you the benefit of the doubt when a number fails to appear.

Here’s the part that should get your attention: when a buying agent can’t get your price from you, it doesn’t come back empty-handed. It gets the price from G2, from Vendr, from a competitor’s comparison post. Someone answers the question either way. The only variable is whether it’s you.

Below: the numbers, the three distinct ways this fails, and a ten-minute test you can run on your own site before you finish this email.

Pricing is the only page that breaks

The setup, from Kevin Indig’s study with Siteline: an agent was given three buying tasks — pricing and features, integrations, security — across 100 B2B products, five runs each. 1,500 runs total. No links were handed over. The agent had to find each vendor the way a real buyer’s agent would.

Integrations got answered from the vendor’s own site 93% of the time. Security, 92%. Pricing: 79%.

And pricing generated 77% of every third-party citation in the entire study.

Say that plainly. On security and integrations, you are the source. On price, one time in five, somebody else is.

Of the 580 third-party pricing citations, 52% came from editorial content and 46% from directories — G2, Capterra, Vendr, Tekpon. Which means the number a buyer sees is a number someone else published, at a date you don’t control, with a discount assumption you never made.

Nobody has “we lost authorship of our own price” on a dashboard.

Three ways a pricing page disappears

These are three different failures with three different fixes, and only one of them is a decision anyone actually made.

1. Opacity — there’s no price. 14% of tested products publish no pricing anywhere; in Marketing/Sales and Customer Support categories it’s closer to a third. When the agent hit a no-price vendor, 45% of runs cited at least one third party. Gating price is a legitimate strategy. It now has a line item attached: G2 fills the gap, and G2’s number is your number as far as the buyer is concerned.

2. Machine-readability — there’s a price, but it can’t be parsed. Zendesk’s pricing table renders client-side in JavaScript. The agent doesn’t execute JS. A person sees a full price list; the agent saw a blank page. This is the one that stings, because nobody chose it, nobody owns it, and it sits in no one’s KPIs. Your pricing page can be perfect and invisible at the same time.

3. Access friction — the agent never reaches you at all. Braze couldn’t be reached in the study; the agent pulled its numbers from G2 and Vendr instead. Access errors showed up in only 7% of runs — small enough to look like noise.

It isn’t noise. On normal runs, third-party fallback ran at 17%. On runs with an access error, it hit 77%.

That’s not a linear relationship, it’s a threshold. A 7% failure rate produces a 4.5x swing in who answers for you. Which is exactly why an audit is cheap relative to the exposure — you’re not optimizing a curve, you’re checking whether a switch is flipped the wrong way.

The fix is boring, which is the point

Adding schema.org Product and Offer markup with price and priceCurrency moved one tested page from 73 to 93 on a readiness score. One lever.

And here’s the detail that should end the internal argument about whether this is a positioning problem: a well-known B2B pricing page scored 73 on one run and 92.5 on another. Same page. Same hour. The 20-point spread came entirely from how the page happened to get fetched.

Nothing about the copy, the tiers, or the value metric changed. This is infrastructure, not strategy.

Fixing the page still isn’t winning

Now the honest part, because I don’t want you to fix your markup and declare victory.

Even when a vendor showed a real, public, numeric price, agents still cited at least one third-party source in 18% of runs. Publishing doesn’t buy exclusivity. It buys you a seat.

And single-shot visibility measures almost nothing about who wins the deal. Arnav Narang ran high-intent buying conversations out to five turns and watched one brand’s share of voice fall from roughly 100% to roughly 10% — not because of anything the brand did, but because ordinary buyer constraints entered the conversation. Team size. Budget. Compliance. The stuff that shows up in every real deal by turn three.

So the frame I’d leave you with is three moments, not one:

findable → parseable → chosen.

A team that fixes only the first will lose at the third, and will never see it in a report.

Run the test yourself — ten minutes

Not a hypothesis. A finding, about your site, today.

1. Ask an agent: “Find all pricing and features for [your product].”

2. Run it three to five times, not once. The study found the same page scoring 20 points apart across runs — one clean result tells you nothing.

3. Read exactly three things: Did it get a number? Was the number right? What did it cite?

4. If G2, Vendr, or a comparison blog appears in the citations, stop looking for a cause. That’s the finding.

5. Then push it to five turns with real constraints — “we’re 40 people, budget is $2k/mo, need SOC 2” — and watch whether you’re still in the answer at the end.

If you want ongoing numbers rather than a spot check: Microsoft Clarity’s new Bot Activity report separates AI crawlers from AI assistants fetching a live answer for a user in the moment. Worth having. One catch — it needs a CDN connection to see this traffic. The JS snippet alone won’t catch it, for the same reason the agent couldn’t read Zendesk’s table.

Your pricing page has three ways to disappear, and you only chose one of them.

Making growth surfaces machine-readable is most of what I do these days — if you run the test above and don’t like what you see, reply and tell me what it cited.

The same person who filed this under “snake oil” a year ago now calls it his fastest-growing channel.

That’s worth taking apart. Because if your fastest-growing visitor isn’t human, the funnel you’ve spent three quarters optimizing has a blind spot sitting right at the top of it.

The shift

Automated traffic is growing roughly 8x faster than human traffic. (Secondary source — take the number directionally. Nobody’s arguing about the direction.)

Here’s what that does to the buyer: the shortlist gets built before anyone lands on your site. By the time you see a visit, the evaluation is half over. And you cannot A/B test your way onto a list you were never on.

The reframe that does the work here:

Ranking is a position. Being cited is a recommendation.

SEO earns you a slot to be evaluated in. Citation earns you the endorsement — the machine speaks on your behalf, and the buyer treats it as an answer rather than a result.

One note before I go further: Kyle’s post is a paid #profoundpartner placement. I’m not selling you the tool. I’m showing you the loop, which is vendor-agnostic — and, as it happens, buildable in a weekend.

The teardown

Four nodes, and the arrows matter more than the boxes.

1. Monitor. Which prompts cite you. Which cite a competitor. Who’s overtaking you, and how fast.

2. Find the gap. Exactly one prompt per week you should own and don’t. One. Discipline beats coverage here — a coverage strategy turns into a content sprint, and content sprints die the way content sprints always die.

3. Ship a citable asset. A structured, scoped, authoritative page built for that one prompt. Kyle’s was a pricing-resources hub. He is now the #2 most-cited source for “best newsletters on pricing,” with HubSpot closing in behind him.

4. Measure. Citation share moves → signups move. Then you go again.

The part most people miss isn’t in any of the four nodes. It’s in the loop itself: this is a system, not a campaign. Campaigns decay. Loops compound.

What actually makes a page citable

• A real “last updated” date. Roughly +15% citation uplift (Kevin Indig’s number). The cheapest growth lever on this list is a date field. Go add it.

• Answer-first structure. The answer in the first two lines, not in paragraph six. Machines quote the top of the page.

• Hyper-specific intent over keyword volume. Incumbents win the broad terms on brand priors. You win the specific ones — the ones your buyer actually types when they’re three days from a decision.

• Structure a parser can read. Clean headings. Real data. No FAQ buried in an accordion.

And the caveat that will save you a wasted month: none of this rescues a page with nothing original in it. Machines cite sources, and a source needs something of its own to say — a number, a dataset, a teardown. Formatting is the delivery mechanism. It is not the payload.

Buy vs build

Buy (Profound-class agents): live this week, 10+ engines monitored, vendor owns the data, recurring seat cost. The right call if you have budget and nobody who builds.

Build (n8n + Claude + your warehouse): a weekend of work, monitors the 20 prompts your buyer actually types, costs tokens instead of seats, and the data stays yours. The right call for a lean team with one person who ships.

The honest trade-off: buying gives you breadth, fast. Building gives you depth, cheap, and owned. The mistake isn’t picking the wrong one — it’s picking neither and calling it “we’ll do SEO.”

One more layer worth naming, because nobody has cracked it: AI-influenced revenue attribution. Visibility tools are everywhere. Revenue mapping isn’t. When your CMO asks what AEO made you this quarter, the honest answer today is a heuristic, not a number. Whoever fixes that is going to do very well.

The one thing to keep

AEO is the first acquisition channel where the entire loop — detect, brief, draft, measure — can run as a background agent. Detection is an API call. The brief is a prompt. The draft is a prompt. The measurement is a cron job.

A channel that used to require an SEO team is now a one-person channel.

That isn’t a metaphor for the thesis of this newsletter. It is the thesis, finally showing up in a real place.

I build these loops for growth teams. If you want to know whether you’re the cited answer in your category, reply with your category and I’ll tell you what I see.

Inside that one title are two different people who build two different companies. And if you’re a Series A or B founder about to make this hire, picking the wrong one is a six-figure mistake. Here’s how to tell them apart before you sign the offer.

The middle is disappearing

Adam Schoenfeld has a read on where the GTM org is going: it’s barbelling. On one end, Builders and their agents. On the other, brand and narrative Creatives. And the vendor-managers in the middle — the people whose job was to own the stack and keep the tools talking — are thinning out.

This isn’t a hot take. It’s a hiring pattern you can watch in real time. Line up the active JDs at Airwallex, Legora, Algolia, Applecart, and Notion next to the Ashby band, and the shape is the same everywhere: companies are paying up for the ends and quietly hollowing out the middle.

Which matters for one blunt reason. If you staff the middle, you’re hiring into a function that’s shrinking. The safe-looking hire is the one aging out.

The two people fighting for that title

The Optimizer (Type A) comes from RevOps or MOps. Their instinct is to take the workflows you already have and modernize them with AI-native software. Hand them a mess of tools and they’ll pick a clean stack, wire it together, and make it hum. High floor, fast time-to-value — and a low ceiling, plus whatever lock-in comes with the tools they chose.

The Builder (Type B) comes from engineering or technical growth. Their instinct is to build the system itself — Claude Code, MCP, a CDP, a warehouse. When the capability you need doesn’t exist as a product yet, they make it exist. Higher ceiling, more variance, and a bigger compliance and maintenance surface to own.

The Optimizer (Type A)The Builder (Type B)BackgroundRevOps / MOpsEngineering / technical growthDefault moveChooses a stack and makes it run cleanBuilds the system that doesn’t exist yetWorks inAI-native software you can buyClaude Code, MCP, CDP, warehouseStrengthHigh floor — reliable, fast to valueHigh ceiling — creates net-new capabilityCostLow ceiling, vendor lock-inMore variance, compliance + maintenance surfaceFails whenThe tool they need doesn’t exist yetAsked to babysit vendors — gets bored, leaves

Neither is better. That’s the part most job posts get wrong. They fail in opposite directions — and the whole game is knowing which failure you can’t afford.

The one question that sorts them

Here it is:

Is the growth system I need already possible with tools I can buy — or does it not exist yet?

Already possible, just needs to run clean → hire the Optimizer. Doesn’t exist yet → hire the Builder.

That’s the whole decision.

The mismatch is where the money burns. Pay a Builder $260K to babysit vendors and they’ll leave inside a year — the work is beneath the thing they came to do. Ask an Optimizer to architect a system from zero and they’ll stall, because their strength was choosing, not creating.

You can catch this in a single interview move. Ask the candidate to walk you through the last system they built — then the last stack they chose. Listen to the verbs. “Built,” “wrote,” “designed from scratch” is one person. “Evaluated,” “selected,” “rolled out” is the other. The verb reveals the type faster than any resume.

The one idea to keep

The title is converging while the job is diverging. Every company will post some version of “GTM Engineer,” and the comp bands will keep climbing faster than anyone’s clarity about what the role actually does.

So don’t match the salary band to the most impressive resume. Match the type to the problem you can’t yet solve. That’s the only version of this hire that pays for itself.

If you run growth right now, your calendar probably looks like this: two A/B test reviews, an onboarding tweak standup, a CRO sync. Real budget, smart people, full sprints — and the growth curve is still flat. Here’s the uncomfortable explanation: in 2026, the fastest-growing companies treat funnel optimization as a small lever and put their weight on shipping value and activating users on it fast. This week: two real teardowns. One company that quantified the funnel as a 5% lever at $200M ARR, and one that rebuilt onboarding around a single quick win. This will feel wrong if you were trained on AARRR. Read it anyway.

The hero teardown: Lovable’s 95/5 engine

Start with the number, because it earns the thesis: Lovable hit $200M ARR in under a year with roughly 100 people — and by their own growth lead’s account, the team spends about 5% of its effort on funnel optimization and 95% on shipping new product and new growth loops. That’s not neglect. It’s a deliberate allocation at the fastest-scaling software company we’ve seen.

The mental model shift is funnel → engine. A funnel is linear and leaky: pour traffic in the top, lose most of it, optimize the leaks. An engine is a loop: every ship creates something to talk about, the talk brings builders, the builders create output that markets the product, and the cycle funds the next ship. When your product changes weekly, squeezing 3% out of a signup page is a rounding error against launching the thing that re-activates your entire dormant base.

Two structural moves make it work, and both are things buyers consistently miss. First, activation was moved out of growth and into product. Lovable’s growth team barely touches onboarding — because activation is the moment the product delivers a stunning result, and that’s a core-product problem, not a tooltip problem. Second, the core product is given away free as the distribution channel. Free credits aren’t a cost center; they’re the marketing budget. Someone wants credits to run a hackathon? That’s a campaign you didn’t have to build.

The operator translation, if you run growth at a scaling company: cap your funnel spend, fund shipping, and re-test PMF every quarter — Lovable operates as if product-market fit has a three-month half-life, because in AI markets it does.

The honest caveat: this doesn’t mean fire your CRO team. It means stop calling a 5% lever your growth strategy.

The mechanism: Apollo’s Velocity → Value onboarding

If shipping value is the engine, activation is where the user first feels it. Here’s what “activate on value” looks like operationally.

Apollo renamed its onboarding from High-Velocity to High-Value [VERIFY against Pill 2 source before send] — and the rename was the decision. Velocity onboarding optimizes for motion: steps completed, tooltips clicked, checklists cleared. Value onboarding optimizes for one thing: did the user get an outcome?

The flip has three parts. Every first session must deliver at least one quick win — a real outcome, not a configured setting. Success is redefined as the outcome, not “tour completed.” And instead of front-loading everything into day one, there’s a deliberate 14-day path [VERIFY] that sequences the next wins so momentum compounds instead of stalling after signup.

The durable line to keep: a user who clicked through 12 tooltips and felt nothing hasn’t activated — they’ve just been busy.

The through-line + this week’s one action

Same thesis, two altitudes. Lovable is the strategy: move activation into product and make shipped value the engine. Apollo is the mechanism: what activating-on-value actually requires, session by session.

Your one action this week: name the single quick win your product delivers in session one. If you can’t name it, that’s your highest-leverage work this quarter — not another funnel test.

Reply or comment “ENGINE” and I’ll send the one-page template I use to map any company’s growth engine (funnel vs loop), plus the 3-question quick-win onboarding audit.

I build these systems for a living — activation, growth loops, and the plumbing behind them. If that’s the problem sitting on your desk right now, just reply to this email.

— Dawid

The teardown: how monday.com made activation an agent

monday.com didn’t bolt a chatbot onto their funnel. They rebuilt first-touch around three agents, each owning one stage: Amanda works top-of-funnel qualification, Jax owns activation, and Oscar handles expansion signals. Each one has a number attached to it — not “engagement,” but pipeline.

Jax is the one worth zooming in on. It’s live in the product, and it doesn’t just answer questions — it takes UI actions. A new user says “I want to track my agency’s client projects” and Jax builds the board, sets the columns, invites the flow. The result monday.com reports: 2.5x activation versus the self-serve baseline. That’s not a chatbot metric. That’s the single most expensive problem in PLG — time-to-first-value — collapsed into a conversation.

Here’s the contrarian part, and the reason this isn’t a “big model budget” story: the moat isn’t the model. By monday.com’s own account, roughly 80% of the work is orchestration — routing, context-loading, CRM writes, handoff rules, guardrails. The model is a commodity you rent. The plumbing is the asset you own.

“Reps only ever receive qualified, context-loaded meetings.”

That sentence is the whole design philosophy. The agents don’t replace the sales team — they make sure humans only spend time where humans win.

The one-person version: I shipped the same play solo

Why speed-to-lead specifically? Because it’s the cheapest pipeline you’ll ever generate — it’s revenue you already paid to acquire and then left on the table. The canonical story is PayPal’s: an internal audit found 8,000 inbound leads nobody had ever called. Working just that backlog — leads they already owned — drove pipeline up ~50%. No new spend. Just speed applied to existing intent.

So I built the one-person version of the monday.com play. The stack:

Twilio → Vapi → ChiliPiper → n8n/Slack.

Twilio catches the inbound call or form-fill (that’s your SDR’s phone). Vapi is the voice agent that responds in seconds, qualifies with three or four questions, and — this is the Jax move — takes the action: it books the meeting through ChiliPiper directly on a live calendar. n8n is the 80%: it writes the lead to the CRM, posts the full transcript and qualification summary to Slack, and fires the 24h follow-up if the lead goes quiet. Every piece replaces a human task that used to take hours and now takes seconds.

The honest build-in-public note: the model was the easy 20%, exactly as the monday.com teardown predicted. What actually ate the weekend was latency (a voice agent that pauses 3 seconds feels broken), the human hand-off (when does the agent stop and escalate?), and consent (call recording disclosure isn’t optional, and it changes the opening script). Nobody sells you the plumbing. The plumbing is the product.

So what — the buyer’s 3 moves

1. Find your slowest first-touch. Measure two numbers this week: inbound response time and trial time-to-first-run. One of them is embarrassing.

2. Put an agent on the speed layer first, not the whole funnel. Don’t buy “AI transformation.” Buy seconds where you currently spend hours.

3. Measure conversion and pipeline per agent — not “AI adoption.” monday.com attaches a revenue number to each agent. Copy that, at any scale.

Enterprise or solo, the lever is the same: speed at the moment of intent.

I tear down a real growth system like this every week — subscribe if that’s useful.

I also build these speed-to-lead systems for inbound-heavy teams. If slow follow-up is quietly costing you pipeline, just reply to this email.

P.S. — Reply “stack” and I’ll send you the exact Vapi + ChiliPiper + n8n wiring as a one-page diagram.