What I check when a model is confident but wrong.
02
✦ ML Personalization · Trust · 0→1 · Personal Anecdote
What I check
what we chose not to personalize became the product feature →
What I check
when a model is confident but wrong.
what we chose not to personalize became the product feature →
The personalization engine was strong on paper for returning users. For brand-new users, cold-start math guaranteed it would be confidently wrong, and confidence, not accuracy, is what broke their trust. I didn't expect the fix to be admitting the product didn't know them yet.
Didn't see the trust angle at firstHonest UI, not a smarter modelNow watch this on every cold-start surface
Personal Anecdote
This is a Personal Anecdote, not a verified employer engagement. Written to show how I diagnose and structure a 0→1 personalization problem, the numbers below are original.
0
People on the team
0
Weeks to ship
0
% lift, new-user retention
0
Surfaces it now protects
What I Check
A model's honesty about its own uncertainty is a trust feature, not a weakness to hide
My first instinct was to make the model better, not more honest. It took a stack of exit-survey quotes calling us "random" and "broken" for me to realize the model wasn't the problem, its confidence was.
An ML system that presents cold-start uncertainty with the same visual confidence as a well-calibrated prediction isn't lying exactly, but it reads that way to the user the first time it's wrong. So now, on any 0→1 personalization surface, I check how the UI presents confidence before I check the model's accuracy. That one check is the whole fix. The rest of this case is the one time I skipped it and what it cost us.
Here's the surface that taught me to check, and the four things I built so I'd never skip it again. 👀
The Case
Role & scope
PM owner for new-user personalization experience. Accountable for the trust/UX decision, working across applied science, design, and the search personalization team the pattern later extended to.
Stakeholders aligned
Applied science (co-designed the confidence threshold), design (the "still learning" state and copy), and the search personalization team (adopted the pattern on a second surface).
Business problem
New users saw 32% negative feedback on recommendations versus 9% for returning users, and retained at only 54% by week two versus 81% for the cohort that browsed organically instead, during the exact window that decides whether someone comes back.
Goals
Confirm the churn was caused by confident-but-wrong recommendations, ship a fix that closed the trust gap without adding onboarding friction, and do it without regressing the model's actual time-to-accuracy.
The Tension
The model was strong on paper for returning users, and confidently, disproportionately wrong for brand-new ones.
How do you fix a trust problem that's caused by a model doing exactly what it was trained to do?
The personalization model was, by every offline metric, strong, precision and recall on held-out returning-user data looked great. But new users, who by definition had almost no interaction history, got recommendations built on thin signal that the UI presented with the same visual confidence as a five-year returning customer's, sometimes a 97% match badge on a guess built from zero prior sessions.
When the model guessed wrong for a new user, which cold-start math guarantees it will do disproportionately often, I decided it didn't read to that user as "the system is still learning me." It read as "this product doesn't get me at all," during the exact window where first impressions decide whether someone comes back. Doing nothing meant the model's own early-stage inaccuracy was quietly taxing the metric that mattered most: whether a brand-new user trusted the product enough to return. That distinction, between an accuracy problem and a trust-presentation problem, is what determined everything I did next.
What the badge showed vs. what was actually happening
The badge said 97%. Underneath it, three separate things were quietly wrong at once.
From Wobbling Read to Locked Calibration · how the problem statement first looked
Uncalibrated read · week 1
?new users leaving faster than browsers
?but their rec confidence score is HIGH
Calibrated read · week 3
Blind spot: Cold-start new users
Root cause: Confidence presented as fact
Confirmed, not a data artifact
A hunch isn't a case yet. Time to go find out if it holds up. 🔎
Research
What the data actually showed
A confidence paradox isn't a decision either. Before proposing anything, I confirmed the pattern held across four independent data sources, so I wasn't fixing a one-dashboard anomaly.
[1] FEEDBACK DATA
"New-user 'not relevant to me' feedback rate hit 32%, versus 9% for returning users, a 3.6x gap."
[2] RETENTION DATA
"Week-two retention for new users who engaged with recommendations was 54%, versus 81% for the cohort that browsed organically instead."
[3] MODEL INTERNALS
"Confidence scores for cold-start recommendations were, ironically, often higher than for established users, a side effect of how the ranking objective was regularized."
[4] USER INTERVIEWS
"New users didn't expect perfect personalization on day one, they expected the product to behave like it knew it was still learning."
The feedback and retention gaps told me something was wrong; I still had to rule out the boring explanations before proposing a fix.
Uncalibrated read · week 2
?eval methodology bug
?prior-seeding bug
?regularization side effect
Calibrated read · the analysis I actually ran
✕ Ruled out: Evaluation methodology bug
✕ Ruled out: Prior-seeding bug
Confirmed: Regularization over-indexes thin signal
Confidence-vs-interaction-count regression analysis
Illustrative, indexed for shape not scale
The shaded band is the whole problem 👀
Model confidence score
Actual accuracy
The shaded gap on the left is the whole problem, new users got the least reliable recs with the most confident presentation.
New vs. returning cohorts
Same product, two very different first weeks
New users gave more negative feedback and retained worse, in the same product, same week.
Problem statement
The product presents cold-start uncertainty as confidence, which breaks trust during the highest-leverage window for retention, an estimated 27-point retention gap between new and returning cohorts.
North-star metric
New-user week-two retention (baseline 54%, target 66%+).
Guardrail metrics
Time-to-personalization-accuracy (must not regress); engagement with the "still learning" state itself (must not become an ignored excuse).
Non-goals
Improving the model's cold-start accuracy via new algorithms, this was a trust and expectation-setting problem layered on top of an already-reasonable model.
This is the exact scorecard I brought into the review with design and ML leads, so the trade-off would be a joint call, not a private judgment.
- North star: new-user week-two retention
- Guardrail: time-to-accurate-personalization (must hold)
- Guardrail: feedback-state engagement rate (must not be ignored)
KPIs I actually tracked week to week
New-user week-2 retention
54%→66%, +22%
"Not relevant" feedback rate
32%→14%
Time-to-accurate personalization
flat (guardrail)
Feedback-state engagement
41% tap rate
Onboarding activation friction
unchanged (0 added)
New-user negative feedback
-38% relative, all categories
Four ways to fix it. Only one of them didn't ask new users to work for their own trust.
Ideation & Decision
Weighing the alternatives
Four ways to close a 27-point retention gap, each trading off trust against friction differently. I scored them on both axes so design and ML could see the trade-off, not just my conclusion.
1
Do nothing; let the model catch up over time. $0 cost, but the evidence showed 46% of new users were leaving before week two, well before the model ever caught up.
2
Force new users through an onboarding preference quiz first. ~4 weeks to build, improves early accuracy, but research pegged the added friction at a projected 8-12% activation drop.
3
Ship a visible "still learning" state with lightweight feedback.Chosen ~3 weeks, 0 added onboarding steps. No added friction, and it turns an accuracy weakness into an honesty strength.
4
Fall back to generic best-sellers, no personalization claim at all. ~1 week, safest, but wastes the imperfect-but-real early signal the model does have.
Accepted riskTelling users the system is "still learning" could read as a less premium experience than competitors projecting total confidence. Accepted because the evidence showed confident-but-wrong was costing 27 points of retention, an honest uncertain state was the cheaper risk.
Deliberately not builtA rapid-onboarding preference survey, it would have improved model input quality, but at a projected 8-12% activation-friction cost higher than I was willing to pay in the first session.
I brought this matrix into the room instead of a recommendation memo, so ML could see me rule out the quiz on the friction data, not on a hunch.
Uncalibrated read · week 5
?trust vs. friction, which option wins
Calibrated read · the matrix I brought to the room, week 6
"Still learning" state (chosen): High trust, zero friction
✕ Onboarding quiz (rejected): High trust, high friction
Same four options, now impossible to misjudge
My Mental Model
Trust vs. Friction
Four options, one question: which earns trust fastest without asking a brand-new user to do work before we've delivered them any value? The onboarding quiz feels like the rigorous choice, but asking for effort before proving worth is exactly backwards this early.
Laid out as diverging bars, the "still learning" state matches the quiz's trust gain almost exactly, for a fraction of the friction cost.
Chosen
Considered
Rejected
Deciding was the easy part. Getting design and ML to agree on when to show it was the real work. 🛠
Solution
What if the product just admitted what it didn't know yet?
Actors & Inputs
- New users
- Personalization model
- Confidence-estimation layer
- Recommendation UI
→
System Change
- Confidence-to-UI-state mapping added
- Low-confidence recs get "still learning" treatment
- One-tap feedback feeds next scoring pass
→
Outcome
- Cold-start trust preserved
- Model gets better signal, faster
- Pattern reused on search personalization
From Wobbling Read to Locked Calibration · how I thought through the confidence-threshold logic
Uncalibrated read · week 7
?if confidence < X, show "still learning"
?where's X? who sets it?
Calibrated read · the rule that actually shipped
Above threshold: Standard confident treatment
Below threshold: "Still learning" + 1-tap feedback
Feedback loop: Feeds next scoring pass directly
Threshold co-designed with applied science, not imposed
Watch the needle drop. Then toggle to see what the user was actually shown.
97%
38%
Confidence shown to the user
Model's actual confidence, day 1
👤 New user · first session, zero interaction history
97% match for you
94% match for you
👤 New user · first session, zero interaction history
Still learning · rate this 👍👎
Still learning · rate this 👍👎
I underestimated one thing going in: after years spent making the product feel confident and premium, just the idea of visibly admitting uncertainty during a brand-new user's very first session felt risky to nearly everyone in the room, not the mechanism itself, the admission.
Design wanted
Rare appearance, worried the "still learning" state looked unpolished
ML wanted
Frequent appearance, worried about overclaiming accuracy
Resolved by: a feedback metric both teams already trusted
I didn't bring a mandate to add the "still learning" state; I brought the confidence-versus-accuracy data and asked design and ML to co-design the threshold themselves, so it was theirs to defend, not mine to enforce.How I led
How the quarter actually went
WEEK 1
Confidence paradox noticed
Cold-start confidence scores looked higher than established-user scores, flagged as odd during a routine model review.
NoticedWEEK 3
Root cause traced to regularization, not a bug
Confidence-vs-interaction-count analysis confirmed the model over-indexed on thin early signal.
DiagnosedWEEK 6
"Still learning" state proposed, threshold co-designed
Design and ML helped set the confidence threshold instead of having one imposed on them.
ProposedWEEK 9
First copy was too apologetic, retested
"Sorry, we don't know you yet" tested worse than a neutral, confident-about-being-honest tone.
AdjustedWEEK 12
Shipped, then extended to a second surface
"Still learning" state live in recommendations; extended to search-result personalization, same cold-start dynamic.
Shipped 🎉Proof
| Hypothesis | New users shown an honest "still learning" state with lightweight feedback will retain better than new users shown confidently-framed but statistically weaker recommendations. |
|---|---|
| Design | New users randomized into the existing confident-framing UI versus the new "still learning" state; both saw the same underlying model scores. |
| Primary metric | Week-two retention. |
| Result (illustrative) | Week-two retention rose from 54% to 66% in the treatment group (+22% relative); "not relevant to me" feedback dropped from 32% to 14%; time-to-accurate-personalization held flat, unaffected. |
| Follow-up | Confidence-aware UI pattern extended to a second surface (search-result personalization) the following quarter, same cold-start dynamic, no new headcount. |
Honest confidence framing for new users
→
Reduced trust damage from early wrong recommendations
→
Higher new-user week-two retention
→
Larger pool survives long enough for personalization to become accurate
Shipped isn't the same as done. Here's what I'd actually keep, and what I'd do differently. 🕑
Learnings
Key takeaways
What worked
Treating model uncertainty as a UI/trust problem, not only an ML accuracy problem, closed a 27-point retention gap in 12 weeks with zero new headcount.
What didn't
My first "still learning" copy was too apologetic ("sorry, we don't know you yet") and tested worse than a neutral, confident-about-being-honest tone.
Next time
I'd test copy tone in parallel with the confidence-threshold experiment instead of sequentially, I lost a whole cycle (roughly 3 weeks) re-testing copy after the mechanism was already validated.
The pattern outlived the project: the search personalization team adopted the same confidence-aware UI approach the following quarter for a structurally identical cold-start problem, which is the part of this I'm proudest of, not the fix itself, the fact that it became the default other teams reached for.
"Trust is a product capability, not a compliance afterthought."
Principle carried forward"Build systems that make the next decision easier."
Principle in practiceFrameworks & skills applied
Cold-start strategy
Confidence calibration & UX
North-star & guardrail design
Cross-functional alignment
A/B experimentation
Trust & retention design
Cold-start strategy
Confidence calibration & UX
North-star & guardrail design
Cross-functional alignment
A/B experimentation
Trust & retention design
Quick Answers
FAQ
Is this a real project from a specific employer?
I wrote this as a Personal Anecdote to show how I think through a 0→1 personalization problem, not to claim a specific past engagement.
Why an honest UI state instead of a smarter model?
The model was already reasonable given its data constraints, I decided the real gap was how we presented its uncertainty, so that's what I fixed.
What would you do differently?
I'd test copy tone alongside the confidence-threshold experiment instead of after it, I'd have saved a full cycle of re-testing.
Isn't telling users "we're still learning" a risky admission? 👀
Only if you assume confidence is what earns trust. The evidence said otherwise, users forgave uncertainty a lot faster than they forgave being confidently wrong.