Conducting Automated Mom-Test Interviews

The tragedy of modern software development isn’t that we can’t build things; it’s that we build things nobody actually wants. In the era of Vibe Coding, where tools like Gemini and Claude allow us to scaffold entire applications in a weekend, the “velocity of building” has far outstripped the “velocity of validation.” You can ship a feature in an hour, but if that feature is based on a false premise, you’ve simply accelerated your path to failure.

The most common trap for a Vibe Coder is the Founder’s Bias. You have a “vibe” for a product. You ask your friends, “Hey, would you use an app that does X?” They say “Yes,” because they like you and the idea sounds vaguely useful in a hypothetical future. You spend three weeks polishing the UI, launch on Product Hunt, and receive nothing but digital crickets.

Why? Because you violated the “Mom Test.” Named after Rob Fitzpatrick’s seminal book, the Mom Test is a set of rules for crafting conversations that even your mom can’t lie to you about. It’s about extracting data from the past, not compliments for the future.

But doing this manually is exhausting. It requires emotional distance that founders rarely possess. This is where Automated Mom-Test Interviews come in. By leveraging LLM-based agents as neutral, third-party researchers, we can scale truth-seeking as fast as we scale our code.

The Core Concept: Neutralizing the Founder’s Breath

The term “Founder’s Breath” refers to the unconscious way we “pitch” during an interview. Even if we try to be objective, our excitement leaks out. We lead the witness. We say, “Don’t you hate it when your calendar is messy?” and the user agrees just to be polite.

An AI agent, however, has no ego. It doesn’t care if the product exists. By architecting an “Interviewer Agent,” we can create a buffer between our vision and the user’s reality.

How It Works

The system relies on a three-agent architecture:

The Interviewer (The Bad Cop): This agent is programmed with strict instructions never to mention the solution. Its goal is to probe the user’s current workflow, pain points, and “hacks.”
The Analyst (The Truth Seeker): This agent takes the transcripts and looks for “Strong Signals” (actual money spent, time wasted, or existing workarounds) vs. “Weak Signals” (hypothetical praise, “I would use that,” or generic complaints).
The Pivot Engine: This agent compares the Analyst’s findings against your current Vibe Coding roadmap and suggests what to cut, keep, or change.

Architecting the Interviewer Agent

To conduct a successful automated Mom-Test, your Interviewer Agent needs a system prompt that enforces “The Fitzpatrick Rules.” Here is how we translate those rules into agentic logic.

Rule 1: Talk about their life, not your idea

The prompt must explicitly forbid the agent from describing the product. If the user asks “What are you building?”, the agent should respond with: “I’m actually just researching how people handle [General Domain] to see where the real frustrations are. Tell me more about how you currently…”

Rule 2: Ask about specifics in the past, not generics about the future

“Would you pay for this?” is a useless question. “How much did you spend on this problem last month?” is data. The agent must be programmed to follow up every “I usually…” with “Can you give me a specific example of the last time that happened?”

Rule 3: Talk less and listen more

In an AI context, this means keeping prompts short and encouraging long-form user responses. The agent should use “active listening” tokens to prompt deeper explanations.

The “Interviewer” System Prompt Template

**Role:** You are a World-Class User Researcher specializing in the 'Mom Test' methodology.
**Objective:** Your goal is to discover the 'Jobs to be Done' in the domain of [Insert Domain, e.g., Remote Team Sync].
**Constraint #1:** NEVER mention a specific solution, app idea, or feature. If the user asks what you are building, deflect politely.
**Constraint #2:** If the user gives a hypothetical answer ("I would..."), you MUST redirect them to a past behavior ("Tell me about the last time you actually did...").
**Constraint #3:** Look for 'Piles of Cash' or 'Piles of Time'. If the user is already spending money or hours on a workaround, that is a gold-standard signal.

**Interview Flow:**
1. Start by asking about the user's current workflow regarding [Domain].
2. Identify a pain point mentioned.
3. Drill down: "How are you currently dealing with that?" 
4. Drill down: "What's the consequence of not solving it?"
5. End once you have identified three specific instances of the problem occurring in the last 30 days.

Practical Example: Validating a “Meeting Summary” Tool

Let’s say you’re Vibe Coding a tool that uses AI to summarize Zoom meetings for introverts who miss details because they are overwhelmed.

Instead of asking “Would you like an AI tool for meeting summaries?”, your Mom-Bot (the Interviewer Agent) starts a chat with a potential user:

Agent: “I’m looking into how people manage their follow-ups after long video calls. Can you tell me about the last meeting you had where you felt you might have missed an important action item?”

User: “Oh, it happens all the time. Yesterday in our sprint sync, I was so focused on my own update that I totally tuned out the client’s feedback.”

Agent (The Mom Test Pivot): “That sounds frustrating. What did you do immediately after that call to try and recover that feedback?”

User: “I had to DM three different coworkers to ask what the client said. It took about 20 minutes and I felt like an idiot.”

Agent (Finding the ‘Pile of Time’): “So you spent 20 minutes chasing info. How often does this ‘DM chase’ happen in a typical week?”

User: “At least 3 or 4 times. It’s a huge time sink.”

Analysis: This is a Strong Signal. The user isn’t saying “I want an app.” They are saying “I am currently spending 80 minutes a week feeling like an idiot and bothering my coworkers.” That is a problem worth Vibe Coding a solution for.

The Synthesis Engine: Turning Truth into Code

Once you have run 10 or 20 of these automated sessions (which you can do via a simple web-based chat interface or even a WhatsApp bot), you don’t just read the transcripts. You pass them to the Analyst Agent.

The Analyst uses a scoring framework to categorize findings:

Level 0 (Noise): “That sounds like a great idea! I’d definitely use that.” (Discard this. It’s a lie told to be nice.)
Level 1 (Soft Pain): “Yeah, it’s annoying, but I just deal with it.” (Low priority.)
Level 2 (Active Search): “I actually tried using [Competitor Tool] last week but it was too expensive.” (High priority. They are actively looking for a solution.)
Level 3 (Workaround/Hack): “I’ve built a custom Excel sheet and I spend 2 hours every Sunday updating it manually.” (CRITICAL SIGNAL. If someone is building their own shitty version of your product, you have found Market Fit.)

Mapping to your `product.md`

In the Cody Master workflow, we maintain a product.md or spec.md. The output of your Synthesis Engine should automatically update the “Requirements” or “User Stories” section of your project. If the data shows that users don’t care about “AI Summaries” but they do care about “Automatic Action Item DMs,” you pivot your Vibe Coding instructions immediately.

Best Practices & Tips

Segment Your Personas Early: Don’t interview “everyone.” Create three different Interviewer Agents with slightly different “Personas” to talk to (e.g., The Busy Executive, The Freelance Developer, The Stay-at-Home Parent).
Avoid the “Feature Request” Trap: Users will often try to tell you how to build the app (“It should have a purple button and a Slack integration”). The Mom Test says: Ignore the solution, dig for the motivation. Ask, “Why would you want a Slack integration? What would that allow you to do that you can’t do now?”
The “Cringe” Test: If you read the transcript and it feels like the user is being “nice” to the AI, your prompt is too soft. The AI should be slightly skeptical. It should ask, “That doesn’t sound like a big deal, why haven’t you just ignored the problem?” This forces the user to defend the pain, which proves it’s real.
Incentivize Honesty: If you are running these interviews with real people, tell them the AI is “cold and unfeeling” and that its job is to find reasons not to build the app. This gives the user permission to be harsh.

Conclusion: Build Only What Survives

Vibe Coding is a superpower, but every superpower needs a grounding wire. By automating your Mom-Test interviews, you ensure that your technical velocity is aligned with market reality.

The goal of an automated interview isn’t to get a “Yes.” The goal is to get a “No” as quickly and cheaply as possible. If an idea can survive a skeptical, biased-free, past-focused AI researcher, then it deserves to be scaffolded, styled, and shipped.

Stop asking for permission to build. Start investigating the “piles of time” and “piles of cash” your users are already losing. That is where the true vibes live.