Every app, number and person in this post is made up for teaching. The method is real; the data is not.
In the age of AI, some things won't change. Anyone can now build a product in a weekend, and analytics shows every tap a user made last Tuesday. What neither shows is what your users think: the beliefs underneath what they do. "The free version is enough." "Apps like this never stick." Those beliefs decide how you position your product, and positioning is the strategy for your product and your company. When everyone ships fast and decides fast, the edge is deciding on real users' beliefs, not on guesses. That makes talking to customers the most important skill a founder or PM has, and the Mom Test is still the best way to do it. Agents just let you do it with more of the right people, faster.
Let's imagine Pebble, a $7 a month habit tracker. Say 50,000 people have ever paid for it. 30% still have an active subscription, and of those only 25% opened the app in the last 30 days. That means about 3 out of 4 paying users are paying for something they don't use, and every dashboard still calls them "active".
None of them would tell you that in an interview. Ask them and they say the app is great. They are being polite, the same way your mom is polite about your startup idea. That is the whole point of Rob Fitzpatrick's book The Mom Test: people lie to you to be nice, so you stop asking for opinions and start asking about their life.
The book was written for founders with a notebook. I run it with agents now: data picks who I talk to, an agent preps a one-page card per person, and every conversation ends up as a line in one ledger of user facts. This post is that setup, with the prompts.
By the end of this post you can:
The Mom Test in three rules
If you remember nothing else:
The other idea from the book I use every week: a compliment is worth nothing. Real interest costs the person something: their time (a follow-up call), their reputation (an intro to a colleague) or their money (a pre-order, an upgrade). If you leave a call with only nice words, you learned nothing.
| Instead of | Ask |
|---|---|
| "Would you use a feature that does X?" | "How do you handle X today? Walk me through the last time." |
| "How much would you pay for this?" | "What did you pay for the last tool you bought for this? Who decided?" |
| "Do you like the app?" | "What did you open it for yesterday? What did you do right after?" |
| "Why did you cancel?" | "Walk me through the 30 days before you cancelled." |
Let data pick who you talk to, then don't trust the data
Most founders interview whoever replies to an email. That is a cohort too, just a bad one: the people with the most free time and the strongest opinions.
I start from usage instead. A cohort query pulls paying users who were active in the last 30 days, with real usage over the last 90 (sessions, things created, things shared), and ranks them. In our Pebble example, say the founder anchors the first run on one obvious power user, Lena, a nurse who logs a habit after every shift, and sets the thresholds at half of her numbers. The query returns 40 people. Too few, because the thresholds were fit to one person. Loosen them and the same pool gives 600 a week.
Then the data starts lying in more interesting ways. These are the traps I see over and over, shown with made-up Pebble numbers:
- The labels are wrong. Pebble tags users with AI personas like "fitness" or "wellbeing". When an agent reads what people actually track, only 60% of "fitness" users fit. The biggest misfit: people tracking medication, who look like fitness users because they log something every morning.
- Words fool classifiers. One "fitness" user, call him Marco, is a gym owner. His habits are full of gym words, but they are "pay the trainers" and "order protein bars for the shop". Nouns tell you the topic, the frame tells you the person.
- People don't describe themselves the way you label them. Say 45% of the users labeled "fitness" didn't pick fitness when onboarding asked why they downloaded Pebble.
- "Active" is a snapshot. A subscription flag copied once a day can say active for someone whose plan expired last week. Check the end date, not only the flag.
- Your own team leaks in. Staff on personal email addresses and test accounts like
name+test@end up in interview lists. The tell: a test address with nothing created is not a customer. - One person, two IDs. Someone who reinstalls or switches login method can get a second account, so a person you already emailed comes back in next week's batch.
The lesson: before you email anyone, have an agent read what each person actually did and mark "fits / doesn't fit / unclear". Split the list across a few reviewer agents, about 100 users each, have each one write its verdicts to a file and return only counts. In the Pebble example that check removes about a third of the list.
Talk to both ends of the cohort
Founders love power users, because those calls feel good. But power users only tell you why the product works for people it already works for. You learn why it fails from the other end.
Four cohorts by how much users pay and how much they use the app
| Cohort | Who | What you learn | First question |
|---|---|---|---|
| Power users | pay and use it all the time | the job they hired it for, workarounds you never built | "Walk me through the last time you used it, from what made you open it." |
| Paying ghosts | still paying, no open in 30 days | what replaced you, why they haven't cancelled yet | "What did you use last week instead, when this came up?" |
| Free heavy users | use it a lot, never paid | what "enough" means, what a price would have to buy | "What would have to break for you to pay for something like this?" |
| Cancelled or refunded | paid, then left | the real story of leaving | "Walk me through the 30 days before you cancelled." |
In the Pebble example, the paying ghosts are most of the paying base, so they deserve more calls than the fans. A power user call gives you a feature list. A ghost can tell you about the day the app stopped being part of their week.
Data also gives you better questions than you would think of. Say Pebble users who joined through a friend's invite pick the yearly plan twice as often as everyone else. Don't guess why on a slide. Ask: "Tell me about the day your friend sent you the invite. What were you trying to fix?"
Prep every call with a one-page user card
Before a call, an agent builds a card for that person from their data: when they joined, what they pay, what they actually create (titles, not counts), their busiest days and the last time they opened the app. Two minutes of reading turns a generic interview into "I saw you mostly log on Monday mornings, walk me through last Monday."
The card has one rule: facts from data only, with the source next to each line. No guessing at their job or age from vibes. If the data doesn't say, the card says "unknown". Inference gets labeled as inference.
Run the conversation
My running order for a 30-minute call:
For negative cohorts, the order is the same but the second step is the 30 days before they stopped. Never ask "was it the price?" It hands them an easy, face-saving answer.
Turn every conversation into user facts
This is where most interview programs die: 20 calls, 20 docs nobody reads again. So every call, ticket and review becomes lines in one ledger, and every line is a fact with a source:
| Fact | Cohort | Evidence | Source | Confidence |
|---|---|---|---|---|
| F-0142: Logs habits right after a night shift | power user | "I do it on the bus home, before I sleep" | interview #12, 2026-06-14 | high (said + data) |
| F-0143: Stopped opening after switching phone | paying ghost | last_open 41 days ago, new device 43 days ago | data + call, 2026-06-15 | medium |
| F-0144: Thinks the free tier is "enough" for a weekly habit | free heavy | "I only need it once a week, so why pay" | interview #14, 2026-06-16 | high |
Next to the facts, write down the beliefs: what the person thinks is true about the problem, your category or paying for it, in their words. F-0144's belief is "a habit I only do once a week isn't worth a subscription". Beliefs are what you position against. If many free users share that one, you either price for weekly users or position Pebble as the app for daily habits. Either way it is a strategy decision, and it came from a conversation, not a dashboard.
(The rows and the belief are made up, like everything else about Pebble.) Three rules keep it honest:
Then once a week an agent groups the ledger: what showed up three or more times, what's new this week, what contradicts last month. That weekly summary is what I bring to product decisions, not the raw calls.
Customer success is an interview you're already having
You don't need to schedule calls to start. Support tickets, store reviews, cancel-flow answers and refund requests are all people telling you about specific past events, without you asking. They go into the same ledger with the same rules: what happened, the quote, the source.
The difference is the cohort. Support is mostly negative cohort, people who hit a wall. Interviews are mostly positive, people who said yes to a call. Put them in one ledger and you finally see both ends of the same product.
Iterate on purpose
The loop: mine, check, card, talk, facts, decide
The loop has six steps and the last one feeds the first:
The step people skip is 6. If a week of calls changed nothing about what you build or who you talk to next, you were collecting stories.
The prompts
Each prompt stands alone. Paste it into Claude Code, Codex or any agent that can read your files. Replace the parts in angle brackets.
1. Mine a cohort (I keep this as a skill, called like /user-miner mine --theme "<segment>" --top 250):
Task: find <N> users worth interviewing for <product>.
Inputs: read-only access to <warehouse/table names>. Event window: last 90 days.
Include: paying now (check the subscription end date, not only an "active" flag),
opened the app in the last 30 days, real usage (<your events, e.g. created >= 1>).
Exclude: anyone in <contacted list file>, internal staff (match company names in the
email local part too), plus-tagged emails with zero created items, and every second
account ID that shares an email with an excluded one.
Output: a JSON file, one record per user: id, email handle, cohort, usage numbers,
last seen. Print only counts and the file path, never emails.
If a query would scan more than <budget> GB, stop and tell me the estimate first.
2. Check the labels:
Task: for each user in <cohort file>, read their last 20 item titles and decide whether
they fit the segment "<segment>".
Judge the frame, not the nouns: "Meeting about the school" is a professional, "Class
notes on X" is a student.
Output per user: fits / doesn't fit / unclear, plus one evidence title. Write results
to <file>. Return only the counts. If titles are empty, mark unclear, don't guess.
3. Build the user card:
Task: write a one-page card for user <id> before my interview.
Use only data: signup date, plan and payments, what they create (titles), busiest
days and hours, last open, what they share. Put the source next to every line.
Write "unknown" where the data is silent. Label anything inferred as inference.
End with 3 Mom Test questions based on this person's real past behavior, no
questions about the future and no description of our product.
4. Turn a transcript into facts:
Task: read <transcript file> and extract user facts for the ledger in <ledger file>.
A fact is a specific thing that happened, with a quote or event as evidence.
Also list the beliefs behind them: what the person thinks is true about the problem, the category or paying, with the quote.
Opinions, hypotheticals and compliments are not facts: list them separately as
"noise". Note any commitment they made (time, intro, money) as its own line.
Format: fact | cohort | evidence | source | date | confidence. Append, don't rewrite.
5. Weekly synthesis:
Task: read <ledger file> for the last 7 days and the 30 days before that.
Report: facts seen 3+ times (with ids), new facts this week, facts that contradict
older ones, and which cohort each pattern came from. Then suggest one decision
and the next cohort to talk to. Don't invent facts that are not in the ledger.
Where to start this week
You're done when you can point at one product decision and say which three facts, from which cohort, made it.
Power users are the pleasant calls. In a setup like Pebble's, the number that should change your plan is the 3 out of 4 paying users who stopped opening the app. No dashboard explains them, and none of them will volunteer it on a feedback form. That is the cohort I'd call first.
What's the last thing a user told you that turned out to be politeness?