I spent four months blaming my users for a bug in my onboarding
For four months I had a clean explanation for why half my users vanished after install: people don’t remember their dreams. It was a great explanation. It let me off the hook, it sounded like wisdom, and it was completely wrong.
Here’s the story of how I turned a technical failure into a user behavior insight, held onto that story for a season, and only found out I was wrong when I stopped theorizing and watched what actually happened.
The comforting story
Dreambook is an AI dream interpreter. The premise is: you log a dream, you get an interpretation. The obvious drop-off risk is obvious — if users don’t remember dreams, they can’t use the product. Retention looks bad. Activation looks bad. Early signal was soft. I had a ready explanation sitting right there.
It’s a seductive frame because it’s true enough to feel like insight. People do forget dreams. The research is real. I had a statistically plausible story for every weak number.
The number that wouldn’t move
About 50% of new installs were dropping off before logging a single dream. Not “within a week” — within the first session. That’s not forgetting a dream overnight. That’s something happening in the first three minutes.
I let that sit for a while. Built other things. The number didn’t move. Added a “remind me in the morning” push notification. The number didn’t move. Made the empty state friendlier. The number didn’t move.
At some point the explanation and the number stopped fitting together, and I ran out of ways to make them fit.
The day I actually watched
Session recordings. I had them. I hadn’t looked at them systematically — I’d glanced, seen nothing obviously broken, moved on. This time I sat down and watched fifty sessions start to finish.
Twenty minutes in, I had the answer.
The onboarding flow had a step where users were asked to set a morning reminder before they’d done anything else. The framing was: “We’ll remind you to log your dream.” Completely reasonable from a product design perspective. In practice, it was a wall. Users hit a permission dialog — system-level, full screen, “Allow Notifications?” — with no context for why they should say yes. Most said no. Then they hit the next screen, which assumed they’d said yes and referenced the reminder they hadn’t set. The screen felt broken. A meaningful fraction of users stopped there.
It wasn’t a memory problem. It was a sequencing problem. The ask came before the value. The permission came before the trust.
The fix
I moved the reminder prompt to after the first dream log. By then the user had done the thing, seen an interpretation, understood what the product was for. The ask made sense because the value was already demonstrated.
Drop-off didn’t go to zero. But it moved. Measurably, quickly, without changing anything else.
What the EM in me should have known
I’ve spent ten years in engineering management watching teams misdiagnose problems. The pattern is always the same: someone has a story that fits the data well enough, and the story is more comfortable than the alternative (which is: something in the product is broken and we have to fix it).
I ran the same play as a solo founder. I had a user behavior explanation for a product problem. I held it for four months.
The thing that broke the loop wasn’t cleverness. It was watching fifty session recordings and not looking away from the ones where users stopped. The data was there from week two. I wasn’t looking at it right.
The correct diagnostic sequence for a high early drop-off is: watch sessions first, theorize second. I did it in the wrong order, and it cost me four months.
That’s the lesson. Not “check your onboarding notifications” — that’s too specific to generalize. The lesson is: when a number doesn’t move in response to anything you do, the explanation is wrong, not the users.