Toby — Personas

⚠️ About the product context. The agent soul describes Toby as an "AI customer-support tool" tied to Freshdesk/Dapper. The production database tells a different story: this is the consumer-grade tab/bookmark organizer Toby (teams_all, groups_all, lists_all, cards, labels, shareable_links). Personas below are derived from the schema that exists, not the schema described in orders. Flagged in pending_review for operator confirmation.

TL;DR

70,095 users were active in the last 30 days. Seven personas account for 100% of them, dominated by one giant: the Tenured Free Organizer (62.4%) — long-tenured free users who maintain ~22 lists each but barely create new ones. The revenue anchor is the Solo Pro Power Saver (9.5%, 6,656 users) — the most engaged segment (94% of them log in weekly) and the one still actively building (avg 2.5 new lists per month). True team usage is real but small (Multi-User Collaborator, 7.0%) and predominantly free, suggesting team-plan monetization is leaking. Acquisition is muted (only 7.1% are new in last 60 days). Retention curve flattens cleanly at ~31% W12 across cohorts — solid for a free productivity tool.

Headline numbers

Active users: 7d 59,625 · 30d 70,095 · 90d 87,492 · all-time 1,046,685
Plan mix (active 30d): free 88.5% · paid_pro/team 9.5% · trialing 2.0%
Tenure mix (active 30d): ≤14d 2.1% · 15–60d 5.1% · 61–180d 6.8% · 181d–2y 25.0% · >2y 60.9%
Cohort retention (Oct 2025–Feb 2026, n=17,068): W1 46.3% · W4 39.2% · W12 30.5%
Subscriptions: 7,058 active yearly Pro · 685 active monthly Pro · 8,833 trialing · 79 active yearly Team (only 96 paid teams have >1 member)
Cancellations last 180d: 235 (not_using 39%, too_expensive 37%, other 22%, missing_features 2%)
Public sharing reach: only 31,770 users (~3%) have ever made a public list; 14,306 active card-share links
Sign-in: 239,255 users via Google OAuth — the dominant identity provider
Top corp domains in active-30d (org-adoption signal): netflix.com (165), servicenow.com (100), amazon.com (80), umich.edu (58), bytedance.com (55)

Personas at a glance

Slug	Name	n	Share	Weekly stickiness¹	One-liner
`tenured-free-organizer`	Tenured Free Organizer	43,722	62.4%	86.6%	Long-tenured free user who maintains a stable library and rarely creates new lists
`solo-pro-power-saver`	Solo Pro Power Saver	6,656	9.5%	93.9%	Paid solo Pro, the revenue anchor, still actively building (~2.5 new lists/mo)
`casual-tab-saver`	Casual Tab Saver	6,595	9.4%	83.3%	Tenured but lightly invested — ≤3 lists lifetime, ~0 new content
`multi-user-collaborator`	Multi-User Collaborator	4,908	7.0%	87.1%	In a team with ≥2 members, mostly on free; the highest public-list-share rate after archivists
`new-adopter`	New Adopter	4,946	7.1%	58.4%	Created in last 60 days, exploring; lowest stickiness, highest churn risk
`free-tier-archivist`	Free-Tier Archivist	1,848	2.6%	86.4%	100+ lifetime lists on free; the heaviest organizers, biggest "should be paying" pool
`trial-explorer`	Trial Explorer	1,420	2.0%	89.7%	Currently in Pro trial, but median tenure is 4.6 years — long-time free users finally upgrading

¹ "Weekly stickiness" = % of segment members with last_active in last 7d (proxy: how reliably the segment shows up week to week, given they're already 30d-active).

How segments compare

The 80/20 of revenue is solid. Solo Pro Power Savers + Trial Explorers are 11.5% of active users but generate ~100% of recurring revenue (only 79 yearly Team subs vs 7,058 yearly Pro subs). Solo, not team, is the business.
The biggest unmonetized pool is sitting in plain sight. Free-Tier Archivists (1,848 users) have avg 224 lists, 28.4% use labels, and 18.6% make public lists — they out-organize every other segment, including Pro. They're either committed free-riders or on Pro and we miscount due to a Pro-team-membership tracking gap (worth investigating).
Trials are not first-time signups. Trial Explorers have an average tenure of 1,695 days (4.6 years). Trial activations are coming from inside the existing free base, not from acquisition. This means trial conversion is a re-engagement lever, not a top-of-funnel one.
Team plan is dramatically under-monetized. 4,908 active users sit in multi-member teams; only 1,206 of them are on any paid team. The other 3,702 are getting the collaboration value of team_basic for free. Either move them to a paid Team plan or restrict free-tier collaboration limits.
Onboarding is the weakest link. New Adopters convert to weekly stickiness at 58.4% — every other segment is at 83–94%. The 30d–7d gap (41.6%) is where the funnel leaks. With cohort W4 retention at 39.2%, ~6 of every 10 new signups are gone by week 4.

Persona — Tenured Free Organizer {#tenured-free-organizer}

The mass of Toby. Long-tenured free users who already finished organizing and now maintain a stable library.

Snapshot

n = 43,722 · share = 62.4% of active users
Tenure: avg 1,267 days (~3.5 years) · ~98% are >180d on platform
Plan: 100% free (team_basic); explicitly no active paid sub
Weekly stickiness: 86.6% (37,850 of 43,722 also active in last 7d)

Behavioral signature

Average 22 lists, accumulated over years
Creates only 0.13 new lists per month — the library is "done"
Only 8.7% use labels; 4.0% ever made a public list
Solo (not in a multi-member team), not in a trial
Returns weekly to consume and add the occasional bookmark, not to reorganize

What they do (and don't)

Heavy: opening Toby (last_active is recent), reading from existing lists
Light: list creation, labels, public sharing, team features
Avoids: paying — they've evaluated Pro for years and chose free

Retention shape

The reason this segment is so large is precisely because retention is so good. Once a user crosses ~6 months on Toby with a non-trivial library, they almost never leave. The implicit "switching cost" is the library itself — moving 22 lists × ~30 cards each to another tool is nobody's idea of fun.

Inferred jobs-to-be-done

(inference, not fact)

"Give me a place to dump tabs I might want later, that I trust will still be there in 2 years"
"Be my personal bookmarks-as-bookshelf — passive, calm, not a productivity system"

Pain-point hypotheses

Ageing libraries with broken/dead links — never surfaced or pruned (signal: 3.5y avg tenure, only 0.13 new lists/mo means library is increasingly historical)
No reason to upgrade — Pro doesn't offer the one thing they'd care about: link-rot rescue or periodic resurfacing (signal: 0% paid, 88.5% of all active users are free, cancellation not_using is the #1 reason at 39%)
Cross-device sync gaps push some users to alternatives — though we can't see this in DB without device events

Evidence

Defining query:

WITH active_30d AS (
  SELECT id, created_at FROM users
  WHERE deleted_at IS NULL AND last_active >= NOW() - INTERVAL '30 days'
), uls AS (
  SELECT user_id, COUNT(*) AS lists FROM lists_all WHERE deleted_date IS NULL GROUP BY user_id
), paid AS (
  SELECT DISTINCT ut.user_id FROM user_teams ut JOIN subscriptions s ON s.team_id = ut.team_id
  WHERE s.status IN ('active','past_due','trialing')
), team_size AS (
  SELECT team_id, COUNT(DISTINCT user_id) AS members FROM user_teams GROUP BY team_id
), in_multi AS (
  SELECT DISTINCT ut.user_id FROM user_teams ut JOIN team_size ts ON ts.team_id = ut.team_id WHERE ts.members > 1
)
SELECT COUNT(*) AS n
FROM active_30d a LEFT JOIN uls ON uls.user_id = a.id
WHERE a.id NOT IN (SELECT user_id FROM paid)
  AND a.id NOT IN (SELECT user_id FROM in_multi)
  AND EXTRACT(DAY FROM NOW() - a.created_at) > 60
  AND COALESCE(uls.lists,0) BETWEEN 4 AND 99;

Validation query (behavioral fingerprint):

-- Re-runs the full segmentation cascade and reports avg lists, labels, public-list adoption per segment.
-- See "Methodology" — this is the same query for every persona row in the at-a-glance table.

Persona — Solo Pro Power Saver {#solo-pro-power-saver}

The revenue anchor. Solo paid Pro users who are still actively building their library years in.

Snapshot

n = 6,656 · share = 9.5% of active users
Tenure: avg 1,740 days (~4.8 years) — among the most tenured cohorts on the platform
Plan: active or past_due on Pro (team_productivity); ~91% of all active Pro subs are yearly
Weekly stickiness: 93.9% — the highest of any segment

Behavioral signature

Avg 131 lifetime lists and still creating 2.5 new lists/month — the only segment with healthy ongoing creation
18.7% use labels (vs 8.7% in tenured-free)
16.1% make public lists — actively share work product
Solo team (no co-members) — Pro is being used as a personal premium upgrade, not for collaboration

What they do (and don't)

Heavy: list creation, labels, sharing individual cards/lists publicly
Heavy: weekly logins (94% of segment is active in last 7d)
Avoids: inviting other team members — they want Pro features, not collaboration

Retention shape

Effectively flat. Yearly billing + 4.8y tenure + 94% weekly stickiness = the "smile curve" that growth-strategy literature treats as the gold standard of PMF. This segment IS Toby's product-market fit, in the segment-specific sense that Karri Saarinen and Sean Ellis describe.

Inferred jobs-to-be-done

(inference, not fact)

"Make my browser/tab discipline a first-class part of how I work, not an afterthought"
"Let me publish curated lists I'm proud of (resources, link-roundups, learning paths)"
"Unblock me from Free-tier limits (whatever they currently are — likely list count or label count)"

Pain-point hypotheses

Pro feature set may be plateauing — the 685 active monthly subs vs 7,058 yearly ratio means new monthly conversions are slow (signal: 101k canceled monthly Pro subs historically vs only 1.1k canceled yearly; monthly is the leakier funnel)
Solo-only design means no obvious upgrade path into Team plan (signal: only 49 active solo Team subs)
AI/auto-organize features (per surveys "Something Smarter Is Coming", "Let Toby Name Your Collection") are landing here first — adoption will tell us if Pro evolves correctly

Evidence

Defining query:

WITH active_30d AS (
  SELECT id FROM users WHERE deleted_at IS NULL AND last_active >= NOW() - INTERVAL '30 days'
), paid AS (
  SELECT DISTINCT ut.user_id FROM user_teams ut JOIN subscriptions s ON s.team_id = ut.team_id
  WHERE s.status IN ('active','past_due')
), team_size AS (
  SELECT team_id, COUNT(DISTINCT user_id) AS members FROM user_teams GROUP BY team_id
), in_multi AS (
  SELECT DISTINCT ut.user_id FROM user_teams ut JOIN team_size ts ON ts.team_id = ut.team_id WHERE ts.members > 1
)
SELECT COUNT(*) AS n
FROM active_30d a
WHERE a.id IN (SELECT user_id FROM paid)
  AND a.id NOT IN (SELECT user_id FROM in_multi);

Validation query (subscription health):

SELECT s.status, p.access_role, p.interval, COUNT(*) AS subs
FROM subscriptions s JOIN prices p ON p.id = s.price_id
WHERE s.status IN ('active','trialing','past_due','canceled')
GROUP BY s.status, p.access_role, p.interval
ORDER BY subs DESC;

Persona — Multi-User Collaborator {#multi-user-collaborator}

The team-shaped user. Lives in a team with ≥2 members. Mostly on free, sharing more publicly than peers.

Snapshot

n = 4,908 · share = 7.0% of active users
Tenure: avg 1,586 days (~4.3 years)
Plan: 80% free (team_basic), 20% paid (team_productivity shared or team_team)
Weekly stickiness: 87.1%

Behavioral signature

In a team with ≥2 distinct members; team tracks 18,173 teams have at least one open team-invitation, but only ~96 teams have actually grown to multi-member paid status
Avg 36 lifetime lists (between casual and pro)
15.6% make public lists — second-highest after archivists
13.5% use labels — slightly above tenured-free average
Created public/private groups (workspaces) far more than other segments

What they do (and don't)

Heavy: shared lists, group invitations, public link generation
Heavy: shared workspaces (teams_all + groups_all of type=public/private)
Avoids: paying for team plans — only 79 active yearly Team subs cover the entire population

Retention shape

Healthy — 87% weekly stickiness with multi-year tenure suggests these are durable working relationships. Risk is asymmetric: when one team member churns, others may follow.

Inferred jobs-to-be-done

(inference, not fact)

"Coordinate a shared library with a co-founder/teammate/spouse without paying enterprise prices"
"Send a public link of my list to a few non-Toby people without asking them to sign up"
"Maintain a shared resources hub for a club, class, or small project team"

Pain-point hypotheses

The Team plan is too expensive or under-valued for this segment — the gap between 4,908 active multi-team users and 130 active Team-plan users is the core monetization question (signal: only ~2.6% of multi-team active users pay for Team)
Free-tier collaboration is too good — there are 26,881 pending team invitations across 18,173 teams, but only 96 paid teams in total; viral attempts are happening but never converting to paid
The 250-user Team plan ceiling vs 7K Pro plans suggests Toby hasn't cracked B2B sales motion

Evidence

Defining query:

WITH active_30d AS (
  SELECT id FROM users WHERE deleted_at IS NULL AND last_active >= NOW() - INTERVAL '30 days'
), team_size AS (
  SELECT team_id, COUNT(DISTINCT user_id) AS members FROM user_teams GROUP BY team_id
), in_multi AS (
  SELECT DISTINCT ut.user_id FROM user_teams ut JOIN team_size ts ON ts.team_id = ut.team_id WHERE ts.members > 1
), paid AS (
  SELECT DISTINCT ut.user_id FROM user_teams ut JOIN subscriptions s ON s.team_id = ut.team_id
  WHERE s.status IN ('active','past_due','trialing')
)
SELECT COUNT(*) AS n
FROM active_30d a
WHERE a.id IN (SELECT user_id FROM in_multi)
  AND a.id NOT IN (SELECT user_id FROM paid);  -- the under-monetized free portion (4,908 minus 1,206 paid)

Validation query (collaboration scale):

SELECT
  CASE WHEN ut_count = 1 THEN 'solo' WHEN ut_count = 2 THEN '2 members'
       WHEN ut_count BETWEEN 3 AND 5 THEN '3-5 members'
       WHEN ut_count BETWEEN 6 AND 10 THEN '6-10 members'
       ELSE '11+ members' END AS team_size_band,
  COUNT(*) AS team_count
FROM (
  SELECT t.id, COUNT(DISTINCT ut.user_id) AS ut_count
  FROM teams_all t JOIN user_teams ut ON ut.team_id = t.id
  WHERE t.deleted_date IS NULL AND t.access_role <> 'team_basic'
  GROUP BY t.id
) sub
GROUP BY team_size_band;

Persona — Casual Tab Saver {#casual-tab-saver}

The user who signed up years ago, made 1–3 lists, and never went deeper.

Snapshot

n = 6,595 · share = 9.4% of active users
Tenure: avg 1,300 days (~3.6 years)
Plan: free
Weekly stickiness: 83.3%

Behavioral signature

Avg 2 lifetime lists — sometimes just one
0.06 lists/month — essentially zero new creation
Sub-segment: ~2,306 of these have 0 lists lifetime (the "Sleeping Lurker" pattern — they log in but never create)
4.7% labels, 1.2% public lists — minimal organizing behavior

What they do (and don't)

Heavy: passive returns to look at the same one or two lists they made years ago
Avoids: every advanced feature

Retention shape

Surprisingly sticky given how light usage is — 83.3% weekly. But this is selection bias: we're already filtering on 30d-active, so we're seeing the "still hanging around" tail of a much larger long-tail of dormant accounts (recall 1.05M total users vs 70K active — 93% of registered users have lapsed).

Inferred jobs-to-be-done

(inference, not fact)

"Bookmark this one tab I want to come back to" — but doesn't trust browser bookmarks
Toby is functioning as a single-page bookmark, not as a system

Pain-point hypotheses

They're not feeling enough product value to deepen usage — onboarding never landed (signal: avg 2 lists, decade-class tenure)
Browser bookmarks + Chrome Groups (which Toby integrates with — see "New: Toby with Chrome groups! 🎉" survey, 29k responders) may have absorbed the use case for this segment
Could be a churn risk if Chrome continues investing in native tab/group features

Evidence

Defining query:

WITH active_30d AS (
  SELECT id, created_at FROM users WHERE deleted_at IS NULL AND last_active >= NOW() - INTERVAL '30 days'
), uls AS (
  SELECT user_id, COUNT(*) AS lists FROM lists_all WHERE deleted_date IS NULL GROUP BY user_id
), paid AS (
  SELECT DISTINCT ut.user_id FROM user_teams ut JOIN subscriptions s ON s.team_id = ut.team_id
  WHERE s.status IN ('active','past_due','trialing')
), team_size AS (
  SELECT team_id, COUNT(DISTINCT user_id) AS members FROM user_teams GROUP BY team_id
), in_multi AS (
  SELECT DISTINCT ut.user_id FROM user_teams ut JOIN team_size ts ON ts.team_id = ut.team_id WHERE ts.members > 1
)
SELECT COUNT(*) AS n
FROM active_30d a LEFT JOIN uls ON uls.user_id = a.id
WHERE a.id NOT IN (SELECT user_id FROM paid)
  AND a.id NOT IN (SELECT user_id FROM in_multi)
  AND EXTRACT(DAY FROM NOW() - a.created_at) > 60
  AND COALESCE(uls.lists,0) <= 3;

Validation query (the Sleeping Lurker sub-segment — zero lists):

WITH active_30d AS (
  SELECT id FROM users WHERE deleted_at IS NULL AND last_active >= NOW() - INTERVAL '30 days'
), uls AS (
  SELECT user_id, COUNT(*) AS lists FROM lists_all WHERE deleted_date IS NULL GROUP BY user_id
)
SELECT COUNT(*) AS sleeping_lurkers
FROM active_30d a LEFT JOIN uls ON uls.user_id = a.id
WHERE COALESCE(uls.lists,0) = 0;  -- 2,306

Persona — New Adopter {#new-adopter}

Created in the last 60 days. Still figuring it out. The leakiest funnel stage.

Snapshot

n = 4,946 · share = 7.1% of active users
Tenure: avg 25 days
Plan: free (most are pre-trial)
Weekly stickiness: 58.4% — by far the lowest

Behavioral signature

Avg 5.9 lifetime lists — front-loaded creation
Avg 1.64 new lists per month — actively experimenting
Only 1.2% use labels and 0.6% make public lists — haven't discovered advanced features
Heavy correlation with Google OAuth signup (the dominant identity path)

What they do (and don't)

Heavy: list creation, exploration, "what does this app do" behavior
Avoids: anything past the homepage / first list

Retention shape

The cohort retention curve we computed across 18 weekly cohorts gives the ground truth here:

W1 retention: 46.3%
W4 retention: 39.2%
W12 retention: 30.5%

Interpretation under the PMF lens: the curve flattens between W4 and W12 (39%→31% is a much smaller drop than W1→W4 of 46%→39%), so users who cross week 4 generally stay. The acquisition problem is the first 4 weeks.

Inferred jobs-to-be-done

(inference, not fact)

"Try this thing my friend / Reddit post / YouTuber recommended"
"See if this can replace browser bookmarks for me"
"Set up a tab-overload coping strategy"

Pain-point hypotheses

Onboarding doesn't reach the aha moment fast enough — 41% don't return weekly (signal: stickiness gap of 25–35pp vs every other segment)
We have a "videoOnboarding" experiment running on 303,182 users (the only A/B test in user_experiments) — clearly an active investment area, but no segment-level result is visible in the schema
55% of cohort never reaches W4 — the same magnitude as Top Shot's 55% Rookie Debut churn cited in the user-lens skill, suggesting first-experience problems are a category trait, not a Toby-specific one

Evidence

Defining query:

WITH active_30d AS (
  SELECT id, created_at FROM users WHERE deleted_at IS NULL AND last_active >= NOW() - INTERVAL '30 days'
), paid AS (
  SELECT DISTINCT ut.user_id FROM user_teams ut JOIN subscriptions s ON s.team_id = ut.team_id
  WHERE s.status IN ('active','past_due','trialing')
), team_size AS (
  SELECT team_id, COUNT(DISTINCT user_id) AS members FROM user_teams GROUP BY team_id
), in_multi AS (
  SELECT DISTINCT ut.user_id FROM user_teams ut JOIN team_size ts ON ts.team_id = ut.team_id WHERE ts.members > 1
)
SELECT COUNT(*) AS n
FROM active_30d a
WHERE a.id NOT IN (SELECT user_id FROM paid)
  AND a.id NOT IN (SELECT user_id FROM in_multi)
  AND EXTRACT(DAY FROM NOW() - a.created_at) <= 60;

Validation query (cohort retention):

SELECT
  date_trunc('week', u.created_at) AS cohort_week,
  COUNT(*) AS cohort_size,
  COUNT(*) FILTER (WHERE u.last_active >= u.created_at + INTERVAL '7 days')  AS active_w1,
  COUNT(*) FILTER (WHERE u.last_active >= u.created_at + INTERVAL '28 days') AS active_w4,
  COUNT(*) FILTER (WHERE u.last_active >= u.created_at + INTERVAL '84 days') AS active_w12
FROM users u
WHERE u.created_at >= NOW() - INTERVAL '210 days'
  AND u.created_at <  NOW() - INTERVAL '90 days'
  AND u.deleted_at IS NULL
GROUP BY cohort_week
ORDER BY cohort_week;

Persona — Free-Tier Archivist {#free-tier-archivist}

The heaviest organizers on the platform — and they're not paying.

Snapshot

n = 1,848 · share = 2.6% of active users
Tenure: avg 2,073 days (~5.7 years) — the most-tenured segment
Plan: free (team_basic)
Weekly stickiness: 86.4%

Behavioral signature

Avg 224 lifetime lists — top of the platform
28.4% use labels — by far the highest adoption
18.6% make public lists — the most prolific public sharers
Still creating ~0.5 new lists/month — slowing but not stopped

What they do (and don't)

Heavy: every advanced organizing feature (labels, groups, public lists)
Heavy: cross-list curation, naming conventions, discoverable libraries
Avoids: paying — despite using more advanced features than the Pro segment in pure adoption-rate terms

Retention shape

Almost certainly the highest LTV-shape user on free. They're not going anywhere — the switching cost (224 lists) is enormous.

Inferred jobs-to-be-done

(inference, not fact)

"Maintain my personal knowledge base / link-museum"
"Be a public curator (educator, hobbyist, researcher) shipping link collections"
"Have an external memory I can outsource browser history to"

Pain-point hypotheses

They've never been upsold correctly — Pro pitches probably emphasize storage limits or seats, not whatever this segment cares about (probably: better search, link-rot detection, exports, advanced labels) (signal: 224 lists × free, 28.4% label adoption — they're using everything Toby offers and not paying)
Sample size is small (1,848) but qualitatively this is the "Curator persona" the user-lens skill describes — high-engagement, low-monetization, high-influence (public lists)
They likely include the Toby creator/influencer subset who promote Toby publicly without compensation

Evidence

Defining query:

WITH active_30d AS (
  SELECT id, created_at FROM users WHERE deleted_at IS NULL AND last_active >= NOW() - INTERVAL '30 days'
), uls AS (
  SELECT user_id, COUNT(*) AS lists FROM lists_all WHERE deleted_date IS NULL GROUP BY user_id
), paid AS (
  SELECT DISTINCT ut.user_id FROM user_teams ut JOIN subscriptions s ON s.team_id = ut.team_id
  WHERE s.status IN ('active','past_due','trialing')
), team_size AS (
  SELECT team_id, COUNT(DISTINCT user_id) AS members FROM user_teams GROUP BY team_id
), in_multi AS (
  SELECT DISTINCT ut.user_id FROM user_teams ut JOIN team_size ts ON ts.team_id = ut.team_id WHERE ts.members > 1
)
SELECT COUNT(*) AS n
FROM active_30d a LEFT JOIN uls ON uls.user_id = a.id
WHERE a.id NOT IN (SELECT user_id FROM paid)
  AND a.id NOT IN (SELECT user_id FROM in_multi)
  AND EXTRACT(DAY FROM NOW() - a.created_at) > 60
  AND COALESCE(uls.lists,0) >= 100;

Validation query (label + public-list power-user profile):

WITH archivists AS (
  -- the defining query above
  SELECT a.id FROM users a WHERE a.deleted_at IS NULL AND a.last_active >= NOW() - INTERVAL '30 days'
)
SELECT
  COUNT(DISTINCT lb.user_id)::float / (SELECT COUNT(*) FROM archivists) AS pct_with_labels,
  COUNT(DISTINCT l.user_id)::float / (SELECT COUNT(*) FROM archivists) AS pct_with_public
FROM labels lb FULL OUTER JOIN lists_all l ON lb.user_id = l.user_id
WHERE l.public = true AND l.deleted_date IS NULL;

Persona — Trial Explorer {#trial-explorer}

Currently in a Pro trial. Median tenure 4.6 years. Not new signups — long-time free users finally trying paid.

Snapshot

n = 1,420 · share = 2.0% of active users
Tenure: avg 1,695 days (~4.6 years)
Plan: trialing on team_productivity
Weekly stickiness: 89.7%

Behavioral signature

Avg 96 lifetime lists — already heavy users before trial
0.91 new lists/month — actively building during trial window
20.6% label adoption (jumps from ~9% in tenured-free)
11.5% public lists (jumps from ~4%)

What they do (and don't)

Heavy: triggering trial during a moment of need (a project, a season, a new role)
Heavy: testing Pro-gated features rapidly
Avoids: blind upgrade — they wait for triggers

Retention shape / conversion

The historical canceled-Pro count (101,229 monthly + 1,113 yearly) vs active Pro (685 monthly + 7,058 yearly) implies a long-run trial-to-paid conversion of roughly 7–8% to yearly Pro retention. The current trialing pool of 8,833 (DB-wide) suggests a trial is the dominant pre-paid funnel stage.
Per cancellation reasons, 39% of churn is not_using and 37% too_expensive — the trial fails when Pro doesn't surface enough new value over free, OR the price isn't justified. Only 2% cite missing features.

Inferred jobs-to-be-done

(inference, not fact)

"Test if Pro is worth $X for the work I'm about to do this month"
"Try the new AI / smart-organize feature I just got a survey about"
"Unlock a free-tier limit I just hit"

Pain-point hypotheses

Trial onboarding may not surface a big enough delta from free, given that 39% of cancellers say not_using (signal: cancellation reasons distribution)
Pricing-sensitivity is real — too_expensive is virtually tied with not_using
The "missing_features" signal at 2% suggests the feature isn't the gap; the experience of value during trial is

Evidence

Defining query:

WITH active_30d AS (
  SELECT id FROM users WHERE deleted_at IS NULL AND last_active >= NOW() - INTERVAL '30 days'
), trial AS (
  SELECT DISTINCT ut.user_id FROM user_teams ut JOIN subscriptions s ON s.team_id = ut.team_id
  WHERE s.status = 'trialing'
)
SELECT COUNT(*) AS n FROM active_30d a WHERE a.id IN (SELECT user_id FROM trial);

Validation query (trial-tenure surprise):

WITH trial AS (
  SELECT DISTINCT ut.user_id FROM user_teams ut JOIN subscriptions s ON s.team_id = ut.team_id WHERE s.status = 'trialing'
)
SELECT
  ROUND(AVG(EXTRACT(DAY FROM NOW() - u.created_at))::numeric,0) AS avg_tenure_days,
  PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY EXTRACT(DAY FROM NOW() - u.created_at)) AS median_tenure_days
FROM users u WHERE u.id IN (SELECT user_id FROM trial)
  AND u.last_active >= NOW() - INTERVAL '30 days';

Provisional segments (below sample-size floor or insufficiently distinct)

sleeping-lurker — n=2,306 (3.3% of active 30d). Active users with zero lifetime lists. Currently absorbed into casual-tab-saver. Why interesting: they log in but produce nothing — could be account-recovery flows, bookmarklet test users, or session-only consumers of someone else's shared list. Not promoted to its own persona because behavior is defined by absence rather than a positive fingerprint, and we don't yet know why they return.
returning-reactivator — not yet measured. Active users who have at least one canceled subscription in their history (downgraded from Pro back to free but still active). Would split from tenured-free-organizer. Investigation needed: cohort-attach cancellation_reasons.user_id to current 30d-active users.
enterprise-pocket — net not yet quantified. Email-domain analysis shows visible org pockets (netflix.com 165, servicenow.com 100, amazon.com 80, bytedance.com 55, umich.edu 58). Distinct enough behaviorally? Unknown — would need to check whether they cluster on Team plan, multi-team, or shared lists. Sample size per domain is below floor individually, but aggregated "corp-domain" segment could be meaningful.

Schema drift

No schema regression detected this run (first run from blank memory; baseline established below in learnings.schema.*).
Soul-vs-reality drift: agent soul describes Toby as a customer-support tool (Freshdesk, tickets, conversations); production schema is a tab/bookmark organizer (cards, lists_all, labels, shareable_links). No tickets / conversations / messages / freshdesk_* tables exist. Flagged in pending_review — operator should reconcile the soul.
teams_all.toby_use field exists but has only 25 non-empty rows, and those 25 rows contain Lorem-ipsum / Latin filler rather than user-entered intents. Feature appears non-functional in production OR populated with seed/fixture data. Flagged.

Gaps & next investigations

Why is the Free-Tier Archivist not paying? A 1,848-strong segment averaging 224 lists, 28% labels, 19% public sharing should be the highest-converting Pro pool. Either they actively chose free (won't pay) or the upgrade prompt never lands. Suggested follow-up: pull user_surveys.response JSON to see if any survey explicitly asked them.
Cohort retention by segment — current cohort retention is global (39% W4, 31% W12). We don't know the per-persona shape. Need a longitudinal join: classify users at signup using behaviors at week-1 and re-measure at W4/W12.
Geography / language — Chinese-domain share (~2.2%) and Russian-domain share (~0.6%) suggests international personas exist but aren't surfaced in our schema. Would need IP / locale / preference-language data.
Mobile vs extension — the monorepo has separate mobile and extension apps. The DB has no client-app field on user activity. Without per-client telemetry, we can't split the "extension power user" from the "mobile-first reader" persona — both could be hiding inside tenured-free-organizer.
Why is trial duration ~4.6y? Are these manually-issued trials, organic re-engagement trials, or a flag mis-set? subscriptions.trial_end and teams_all.trial_initiated_at could disentangle.
Lapsed payer reactivation — historical 101,229 canceled monthly Pro subs is 14× the active Pro base. Even a 5% reactivation campaign would move the needle materially.
Card-level activity recency — cards table has 111M rows, no usable index on created_at for the queries we tried (queries timed out). For ongoing persona work we should request an index, or build a daily aggregate table (user_id, day, cards_created, cards_modified).

Methodology

Connection: Toby Prod (Read Only) (id be55a66b-c905-4759-9ce1-a97785bb69e6). PostgreSQL. Read-only access; only SELECT issued.
Sample-size floor: persona promoted if n ≥ 50 users OR ≥ 5% of active 30d users (whichever is lower → 50). All 7 personas exceed both thresholds.
Active definition: users.last_active >= NOW() - INTERVAL '30 days' AND users.deleted_at IS NULL. Total = 70,095 on 2026-05-09.
Segmentation logic: priority cascade. Each user is assigned to exactly one segment by the first matching rule:
1. trialing on Pro → trial-explorer
2. paid (non-trial) on Pro/Team → solo-pro-power-saver
3. in a multi-member team → multi-user-collaborator
4. tenure ≤ 60 days → new-adopter
5. ≤ 3 lifetime lists → casual-tab-saver
6. ≥ 100 lifetime lists → free-tier-archivist
7. otherwise → tenured-free-organizer
Frameworks applied: collectibles-cpo:user-lens (archetype harm-check, fluidity awareness, what-they-need lens) and growth:product-market-fit-analysis (segment-specific PMF — strongest fit lives in Solo Pro; W12 retention curve flattening is the survival proxy in absence of a Sean Ellis disappointment survey).
Privacy: zero PII embedded. No emails, names, IPs, raw URLs, card titles, list titles, or free-text user content. Only counts, aggregate fingerprints, and anonymized OAuth-domain percentages.
Reproducibility: every persona's defining query above is read-only and re-runnable. The full segmentation cascade is a single CTE-based query (active_30d → uls → paid → trial → team_size → in_multi → classed) shared across personas.
This document is fully regenerated on every run — do not edit by hand. Per-persona files are intentionally not created; all personas live as ## sections inside this file.

Toby — Personas

TL;DR#

Headline numbers#

Personas at a glance#

How segments compare#

Persona — Tenured Free Organizer {#tenured-free-organizer}#

Snapshot#

Behavioral signature#

What they do (and don't)#

Retention shape#

Inferred jobs-to-be-done#

Pain-point hypotheses#

Evidence#

Persona — Solo Pro Power Saver {#solo-pro-power-saver}#

Snapshot#

Behavioral signature#

What they do (and don't)#

Retention shape#

Inferred jobs-to-be-done#

Pain-point hypotheses#

Evidence#

Persona — Multi-User Collaborator {#multi-user-collaborator}#

Snapshot#

Behavioral signature#

What they do (and don't)#

Retention shape#

Inferred jobs-to-be-done#

Pain-point hypotheses#

Evidence#

Persona — Casual Tab Saver {#casual-tab-saver}#

Snapshot#

Behavioral signature#

What they do (and don't)#

Retention shape#

Inferred jobs-to-be-done#

Pain-point hypotheses#

Evidence#

Persona — New Adopter {#new-adopter}#

Snapshot#

Behavioral signature#

What they do (and don't)#

Retention shape#

Inferred jobs-to-be-done#

Pain-point hypotheses#

Evidence#

Persona — Free-Tier Archivist {#free-tier-archivist}#

Snapshot#

Behavioral signature#

What they do (and don't)#

Retention shape#

Inferred jobs-to-be-done#

Pain-point hypotheses#

Evidence#

Persona — Trial Explorer {#trial-explorer}#

Snapshot#

Behavioral signature#

What they do (and don't)#

Retention shape / conversion#

Inferred jobs-to-be-done#

Pain-point hypotheses#

Evidence#

Provisional segments (below sample-size floor or insufficiently distinct)#

Schema drift#

Gaps & next investigations#

Methodology#

TL;DR

Headline numbers

Personas at a glance

How segments compare

Persona — Tenured Free Organizer {#tenured-free-organizer}

Snapshot

Behavioral signature

What they do (and don't)

Retention shape

Inferred jobs-to-be-done

Pain-point hypotheses

Evidence

Persona — Solo Pro Power Saver {#solo-pro-power-saver}

Snapshot

Behavioral signature

What they do (and don't)

Retention shape

Inferred jobs-to-be-done

Pain-point hypotheses

Evidence

Persona — Multi-User Collaborator {#multi-user-collaborator}

Snapshot

Behavioral signature

What they do (and don't)

Retention shape

Inferred jobs-to-be-done

Pain-point hypotheses

Evidence

Persona — Casual Tab Saver {#casual-tab-saver}

Snapshot

Behavioral signature

What they do (and don't)

Retention shape

Inferred jobs-to-be-done

Pain-point hypotheses

Evidence

Persona — New Adopter {#new-adopter}

Snapshot

Behavioral signature

What they do (and don't)

Retention shape

Inferred jobs-to-be-done

Pain-point hypotheses

Evidence

Persona — Free-Tier Archivist {#free-tier-archivist}

Snapshot

Behavioral signature

What they do (and don't)

Retention shape

Inferred jobs-to-be-done

Pain-point hypotheses

Evidence

Persona — Trial Explorer {#trial-explorer}

Snapshot

Behavioral signature

What they do (and don't)

Retention shape / conversion

Inferred jobs-to-be-done

Pain-point hypotheses

Evidence

Provisional segments (below sample-size floor or insufficiently distinct)

Schema drift

Gaps & next investigations

Methodology