A B2B SaaS client came to a session with a conversion problem and a list of suspects. The pricing might be wrong. The upgrade prompt might be badly placed. The positioning on the premium tier might not be landing. All reasonable, all testable, and we had a plan for working through them.
Then somebody checked whether the premium features were actually reachable.
They weren’t. A flag had never been enabled in production, so free-tier users were never granted the premium credits their tier entitled them to. Anyone who reached for a premium feature was quietly redirected to the pricing page instead — not an error, not a message, just a redirect.
Ninety users reached for premium features during that window. Eight converted.
The other eighty-two didn’t decline the offer. They never got it.
The bug you can’t see because it looks like a funnel
What makes this class of failure so expensive is that it doesn’t announce itself. Nothing threw an exception. No support ticket said “the button is broken,” because from the user’s side nothing looked broken — they clicked something and landed on a pricing page, which is precisely what hitting a paywall is supposed to feel like.
The analytics agreed. The event stream recorded users viewing the pricing page and not purchasing, which reads as a perfectly ordinary, slightly disappointing conversion rate — the kind that sends a team straight into arguing about which number to fix first. Every dashboard in the company was green in the sense that it was working correctly. It was faithfully reporting a number that meant nothing.
And every hypothesis formed in that window inherited the problem. Was the pricing too high? Unanswerable — nobody was being shown the thing the price was for. Was the upgrade prompt badly placed? Unanswerable. Was the premium tier’s positioning weak? Unanswerable. An entire quarter of funnel reasoning, built on a measurement of a mechanism that wasn’t running.
Like this? I send one idea like it most weeks. One PLG idea a week → subscribe
Entitlement drift is the specific villain
This isn’t a freak occurrence. It’s a predictable consequence of where tier definitions live.
In most PLG products, what a given tier is allowed to do is encoded in at least three separate places: the billing provider’s plan configuration, the application’s own config or database, and a feature-flag system layered on top. Sometimes a fourth, if there’s a legacy grandfathering table nobody wants to touch.
Those four things are supposed to agree. Nothing enforces that they do. They drift — at launch, when a tier gets renamed, when a flag gets toggled for a staging test and never toggled back, when someone adds a plan in the billing provider and forgets the app doesn’t know about it yet.
When they disagree, the failure is almost always silent, and it almost always fails closed: the user gets less than they paid for, or less than they were promised, and the system reports it as a conversion event that didn’t happen. It very rarely fails open, which is the version somebody would notice within a day.
So buy your own product
The fix is embarrassingly low-tech, and almost nobody does it on a schedule.
Get a clean account — new email, no internal domain, no admin flags, nothing that marks you as staff — and walk the entire commercial path on real production. Not staging. Production, with a real card.
- Sign up the way a stranger does, and stop where they’d stop.
- Reach the gate. Use the product until you hit the paywall organically. Confirm you actually get to it, and that what’s behind it is described accurately.
- Pay. With a real card, on the real processor.
- Verify the entitlement landed. This is the step everybody skips. Did the thing you just bought actually turn on? Immediately, or after a delay, or not at all?
- Cancel, and confirm the downgrade does what it’s supposed to — including what happens to work you created under the higher tier.
Do this once a quarter, and after any release that touches billing, plans, entitlements, or flags. It takes under an hour and it is the single highest-yield hour available to most PLG teams, because it’s the only test that exercises the path a customer actually walks end to end.
A staging environment won’t catch this. The flag in question was enabled in staging. That’s why nobody found it.
What this means for every number you’re about to act on
There’s a discipline underneath this that goes past one bug.
Before you optimize a conversion step, confirm the step works. Before you read a rate against a benchmark, confirm the mechanism that produced the rate was running. Before you measure a lift against a documented baseline — the honest way to prove anything worked — confirm the baseline itself was measuring a functioning system. A Delta-Only Attribution Model comparison against a broken baseline gives you a beautiful, rigorous, meaningless number.
The general form: a conversion rate is a measurement of a mechanism, and a broken mechanism shows up as a bad rate, not as an error. It belongs next to the other question worth asking before any redesign — whether the people who left ever reached value at all. Both are cheap, both are skipped, and both routinely kill a quarter of planned work. “Our conversion is worse than we expected” is not evidence that the funnel design is wrong. It’s evidence that something upstream deserves ten minutes of verification before anyone books a month of work.
Eighty-two users in that account were never given the chance to say no. Finding out cost one session. The redesign nobody needed would have cost a quarter.
Most engagements start by looking at what’s actually happening in the product rather than what the dashboard says. That’s the Diagnose phase.
Running a trial you’re not happy with? Book a call and I’ll walk your funnel live.
