The Screen That Leaked a Third of Your Signups — While Growth A/B-Tested a Button

Why this matters

Your funnel dashboard will happily tell you conversion dropped 4% on step 3. It will never tell you step 3 shouldn't exist. That distinction is the whole game — and if you're an engineer who ships features without asking which funnel step you just touched, you'll burn months polishing a screen nobody should be looking at.

The month we optimized the wrong transition

Here's a real one. A growth team I worked with burned a month running A/B tests on the 'pick a model' step of an agent-building product — step 3 to step 4 in the onboarding funnel. Copy, layout, button color, the works. Conversion crept up a couple points. Meanwhile step 2, 'connect your API key,' was quietly losing over a third of every signup cohort, and nobody had touched it in a year. Why? Because step 2 predated the analytics dashboard entirely. It got built during the migration from a single-provider integration to multi-provider support, back when 'connect API key' meant pasting a string into a form that gave you zero feedback if you got it wrong. By the time growth had a dashboard to look at, that step was just... there. A fixture. Something to measure, not something to question.

Name the mechanism

Funnels get built after the product ships, never before. Someone bolts analytics onto whatever flow already exists, and from that moment on, the shipped flow quietly becomes the assumed-optimal flow. The dashboard can only ever answer 'how many people made it from step N to step N+1' — it has no way to ask 'what if step N weren't there at all.' Every box in a funnel chart earned a permanent seat at the table the day someone wired up tracking for it, whether or not it deserved one.

• ▹A funnel measures the transitions. It has no opinion on whether the nodes in between should exist.
• ▹The moment a step has a conversion number attached, teams start treating 'improve that number' as the job. Deleting the step starts to feel like breaking the data instead of fixing the product.
• ▹AI products make this worse, because flows get bolted together fast. An onboarding funnel today might be carrying three provider migrations, two auth rewrites, and a 'temporary' rate-limit gate inside its steps — and the dashboard shows you none of that history.

Why engineers see it and growth doesn't

Growth and PM read the funnel from the outside. They see 'verify email: 62% conversion' and go hunting for UX friction to sand down. You read it from the inside. You know email verification exists because the transactional email provider you bolted on in year one required verified addresses to avoid getting spam-flagged — not because any user asked for it. You know the 'select a foundation model' picker exists because the product briefly supported exactly one provider, then someone added a picker when multi-model support shipped, and nobody ever checked whether 90% of users just want the default. You know which screen is a genuine trust-building moment and which one is scar tissue from a payment provider's KYC requirement. None of that lives in an analytics event. It lives in git history, in old Slack threads, in your own memory of the migration. That's the asymmetry — and it's exactly why you're the one positioned to catch a dead-weight step before growth even knows to go looking for it.

The diagnostic: would this step exist if we built it today?

Before you ask how to improve a step's conversion, ask one question first: if we were building this product from scratch today, with the constraints we actually have now, would this screen exist? Run it against a few of the usual suspects:

• ▹Email verification: it existed to fight spam and satisfy an ESP's sending requirements. In an AI product where the real gate is API-key issuance or a rate-limited free tier, verified email is often doing zero extra fraud-prevention work — the rate limiter already covers it. If you'd build the rate limiter today regardless, the verification screen is dead weight riding along for old reasons.
• ▹Profile completion: usually exists because an old data model needed certain fields populated to render the dashboard, not because users need to fill them in before getting any value. If your platform can infer a display name from the OAuth provider and push 'org size' or 'use case' to a later, optional moment, that mandatory profile screen is a leftover schema constraint wearing an onboarding costume.
• ▹Confirmation / 'review before you submit' pages: sometimes genuinely earn their keep — irreversible actions, billing. Sometimes they're a fossil from when the underlying API call was slow or flaky and you needed a beat for it to settle. If the API is fast and idempotent now, that confirmation page is compensating for a problem you already fixed.
• ▹AI-specific example: a manual 'connect your first agent' setup wizard that exists because early versions required hand-configuring a webhook. If your platform now auto-provisions that webhook on signup, the wizard is a UI for a problem you already solved server-side. Worse — if agents themselves are now hitting your onboarding API programmatically, a human-shaped wizard step actively blocks them.

The fix is a habit, not a redesign

You don't need to pitch a funnel redesign project to act on any of this — that's a roadmap fight you will lose. The habit is smaller, and it fits inside work you're already doing. Next time you touch a funnel step for any reason — a bug fix, a copy tweak, a perf pass — ask the deletion question before the optimization question. 'Should this step exist at all?' comes first. 'How do we make it convert better?' comes second, and half the time it turns out to be moot. This costs you nothing extra in ticket time. You're just reordering two questions you were going to think about anyway.

What's next

Spotting a dead-weight step is the easy part. Day 16 is about what happens when you actually try to delete one — and it's rarely the code that fights you. It's the growth team's historical baseline, the exec who remembers 'that screen was added for a reason,' and the fact that killing a step means someone has to admit the funnel's been wrong for a year.

Extend your knowledge

• ▹Pull up your own product's onboarding or activation funnel and run the deletion question against every step, one at a time. Write down the ones you genuinely can't justify from scratch.
• ▹Check git blame — or whatever migration history you've got — on the step with the worst conversion in your funnel. Did it come from a real user need, or an old technical constraint?
• ▹If your product has agents or other programmatic clients as users now, not just humans, audit which onboarding steps quietly assume a human's on the other end. Those are prime dead-weight candidates.
• ▹Read what growth practitioners write about activation and funnel metrics generally — Reforge and Lenny's Newsletter both cover this — it's a good gut check for whether even growth-native teams have internalized this blind spot.