AgentStack
SKILL verified MIT Self-run

Product Psychology Retention

skill-jmadriano2-claude-skills-product-psychology-retention · by jmadriano2

Use when designing or diagnosing long-term retention architecture — progression systems, streaks, leaderboards, compound rewards, community mechanics, diagnosing week-2 or month-6 churn, or building systems that make quitting feel painful. Triggers "fix our retention", "users churn after X weeks", "design our streak system", "should we add a leaderboard", "agent-proof the app", "users finish our…

No reviews yet
0 installs
4 views
0.0% view→install

Install

$ agentstack add skill-jmadriano2-claude-skills-product-psychology-retention

✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

Are you the author of Product Psychology Retention? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

Product Psychology Retention

When to use

Open this skill when the question is how do we make users unable to walk away over weeks and months rather than what do users feel and remember in this moment. A week-2 churn diagnosis. A progression system scoping doc. A streak or leaderboard design. An app that feels fine moment-to-moment but drifts off in week 5.

Retention architecture is the discipline of designing systems that make quitting feel painful — through craving loops users cannot privately satisfy, loss aversion on accumulated progress, social visibility that turns achievements into status, and identity metrics that let users edit who they are. Individual features (points, badges, streaks) are not retention architecture. The stack is.

Do not use this skill for first-impression or onboarding warmth — that is product-psychology-craft. Do not use it for visual fundamentals — that is frontend-visual-foundations. Do not use it for interaction patterns — that is frontend-interaction-craft.

The five principles

Every retention problem decomposes into these five. Diagnose by naming which one is in play — or missing.

1. Craving machine

Variable-ratio reinforcement — the same mechanism behind slot machines — creates craving, not pleasure. Users keep pressing the lever not because they are happy but because their brain is locked in a constant chase for the next hit.

The practical implication: most of your reward system should be predictable and transparent, but somewhere inside it, sprinkle controlled surprise. A bonus on an unpredictable schedule. A milestone that arrives early. A discovery that varies daily (Finch's virtual bird returns with 15–20 possible finds per adventure). The system is mostly trackable — with moments of unpredictability inside.

Track one visible progress metric users obsess over — Finch's six-trait personality, League's league points, Whoop's Recovery score. A single tracked metric creates more engagement than 20 scattered badges. Scattered badges read as decoration; one tracked system reads as progress.

A counter that only goes up is not a craving machine. It is an odometer. If the next tap always yields the same reward, there is no craving — only completion.

Deep dive: see references/craving-machine-playbook.md for variable-reward scheduling, controlled-surprise placement, and the track-one-system rule.

2. Infinite game

Humans feel the pain of losing something roughly twice as intensely as the pleasure of gaining the equivalent — Kahneman's loss aversion. Retention architecture weaponizes this: build systems where users have accumulated something they do not want to give up, and never let them finish.

Four moves:

  • Audit for terminal achievement states. If a user can "complete" your app — hit the top level, finish the course, beat the content — you have a ceiling on retention. Level 10 in a language app is a gun pointed at your own retention rate.
  • Design compound streaks, not counting streaks. A counting streak is a number that resets. A compound streak unlocks tangible value — diamonds, cosmetics, tier flair — that users have earned and would lose if the streak breaks. The freeze has to be earned, not given.
  • Ceremonial milestones. Big accumulated wins — hit ₱100k savings, paid off debt, 500 classes — deserve a full ritual arc: anticipation (the approach — "three more entries to your yearly review"), ceremony (the reveal — a designed moment, not a toast), afterglow (the share, the badge, the reflection that converts outcome into identity). Counting milestones without ceremony converts wins into receipts.
  • Periodic resets that preserve earned status. League of Legends resets rank every season — but honor levels and cosmetics carry forward. Users face a fresh climb without losing what they are.

3. Invisible scoreboard

This is the load-bearing principle. Without social visibility, the craving machine and the infinite game can be abandoned privately. A user can quit a variable-reward loop in their bedroom. They can break a 47-day streak and no one knows. The loss is painful but private.

The moment progression becomes visible — on a leaderboard, in a segment PR, as a tier badge others can see — quitting stops being about losing progress. It becomes publicly admitting you stopped. Social visibility converts engagement into identity, and identity is the one thing people do not voluntarily walk away from.

The moves:

  • Make achievements visible to others. Strava segments. Peloton's live in-class leaderboard. Not buried in a "Stats" tab — primary navigation.
  • Design metrics as mirrors, not reports. When a user sees their number, they should immediately think how do I compare. A report says "you ran 12km this week." A mirror says "you ran more than 67% of people your age this week."
  • Build community dynamics, not just features. Parasocial relationships — instructors calling out names, creator-led cohorts, named presence — create AI-proof moats. AI can generate a leaderboard; AI cannot replicate Cody yelling "you're doing great" at position 42.
  • Location in navigation matters. If the social layer is buried in a tab, you are exposed. In Strava, the home feed is the community; the tracking is what makes it function.

This principle is how a product survives the agent era. When an AI can complete the task, the community is the only reason left to open the app.

Deep dive: see references/identity-stack.md for scoreboard patterns, parasocial moat design, and the social vs personal identity split.

4. Identity mirror

A single metric that represents who the user is, not what they did. Whoop Age aggregates nine biometric streams into one number — your biological age — updated weekly. Users do not check it for information. They check it to see who they are becoming.

The pattern:

  • Aggregate many inputs into ONE identity number. Not 3 narrative scores. Not a dashboard. One number. The aggregation is what turns data into identity — if users can drill into components, they can dismiss individual numbers; one composite feels like a verdict on them.
  • Update on a slow, consistent cadence — weekly, or every few days. A daily number is a measurement. A weekly number is a self-image check-in.
  • Make the number trend-worthy. "Is it moving the right direction?" is the question users silently ask every time they open the app. Trend beats instantaneous value.
  • The outcome is behavior change, not information. Users are not optimizing a stat. They are editing their self-image — which is why identity metrics outperform activity metrics for long-horizon retention.

The alternative — "surface the hidden stats via contextual insights" — deepens the tool layer. It does not create identity. A user who treats the app as a dashboard they compare is using the product. A user who has a pace-of-aging number is becoming something via the product.

5. Identity-first intent

Before designing any retention feature, name what the user says about themselves when using the product. Not the action — the identity.

  • "I'm a Strava runner." (not "I use Strava")
  • "I'm a Peloton member with 500 classes." (not "I take Peloton classes")
  • "I'm someone who pays off debt." (not "I use a budgeting app")

This is the planning principle that makes the other four work. Without a named identity, retention features are disconnected: a craving loop with nothing to crave toward, a streak of nothing, a scoreboard no one wants to be on. With a named identity, every retention feature stacks — each one reinforces the same self-concept.

The agent-era test: if an AI agent could do everything my app does through a text message, what identity keeps users coming back? A tool has no answer. A product built around an identity has an obvious one.

The test question: can you state in one sentence what the user becomes by using this product regularly? If not, the retention architecture is decoration on top of a utility.

Quick checklist

Run this on any retention question in under a minute:

  1. Craving — is there controlled surprise inside the reward system, or is every reward predictable? Is there ONE metric users obsess over, or scattered badges?
  2. Infinite game — can a user finish? Do streaks compound into tangible value, or just reset? Are big milestones ceremonial, or silent?
  3. Scoreboard — is progression visible to others? Is the social layer primary navigation, or buried? Are metrics mirrors or reports?
  4. Identity mirror — is there ONE number that represents who the user is, not what they did? Does it update on a self-image cadence?
  5. Identity — can I state in one sentence what the user becomes by using this product?

Final question: would quitting this product feel like a private inconvenience or a public admission? If "private," principle 3 is missing and principles 1 and 2 are unlocked.

If any answer is "no" or "I'm not sure," that is the issue to fix.

Before / after patterns

The odometer problem

  • Before: A points counter increments with every action. Users plateau at week 2. The instinct is to add more predictable progression — levels, tiers, more point-earning activities.
  • After: Keep the transparent backbone, but sprinkle controlled surprise inside it — a bonus on an unpredictable schedule, a milestone that arrives early, a discovery that varies. Consolidate scattered badges into ONE obsessed-over progress metric. The predictable layer gives narrative; the variable layer creates craving.

The ceiling problem

  • Before: Ten mastery levels; 45% churn within two weeks of hitting level 10. The instinct is to scope levels 11–25.
  • After: Make level 10 a real ceremonial graduation — ritual, shareable, identity-conferring. Then design the post-graduation experience as a different mode: maintenance streaks with decay, output challenges, community layer. No more numbered levels — streaks, stats, cosmetics, and collectibles that are horizontal and infinite. The ceiling becomes a passage.

The private-streak problem

  • Before: Strong 30-day streaks but weak 6-month retention. The instinct is to add haptics and bigger confetti so streak events feel more rewarding.
  • After: Solo celebrations amplify the pain of breaking a streak without creating a reason to stay. Add a social scoreboard — visible tier, leaderboard, or community-level challenges where streaks are public. Pair with an identity mirror (a single trend-worthy composite). The celebration becomes an identity marker others can see, and breaking the streak becomes a public story, not a private shame.

When to read the references

  • references/craving-machine-playbook.md — when designing a reward system: variable-ratio scheduling, controlled-surprise placement, the track-one-system rule, and when predictability versus unpredictability earns its place.
  • references/identity-stack.md — when designing social or identity layers: scoreboard patterns, parasocial moat design, the social vs personal identity split, and how the two stack into a single architecture.

If the checklist above answers the question, you do not need the references.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet — be the first.

Versions

  • v0.1.0 Imported from the upstream source.