The Mom Test

These first few points are covered in The Mom Test by Rob Fitzpatrick. How can the lessons and techniques from the book to the future of software engineering as a career?

The Mom Test becomes more—not less—relevant when AI makes implementation cheap. If an agent can build almost anything, the central risk shifts from “Can we build it?” to “Are we building something grounded in reality?”

The book’s core lesson is that customers are unreliable when asked to predict their behavior or validate your idea. AI does not fix this. In fact, it can make the problem worse by generating polished products from weak assumptions at enormous speed.

Translating The Mom Test into future software engineering

1. Discuss actual behavior, not imagined demand

Weak:

• “Would you use an AI assistant for this?”
• “Would automatic reporting be helpful?”
• “Would you pay for this?”
• “What features should it have?”

Stronger:

• “Walk me through the last time you produced this report.”
• “What triggered the work?”
• “Which systems and people were involved?”
• “Where did it go wrong?”
• “What did the failure cost?”
• “What have you already tried?”
• “Who has authority to change the process?”

This matters because LLMs are exceptionally good at filling gaps with plausible stories. If your evidence consists of hypotheticals, an agent can turn those hypotheticals into a coherent—but possibly imaginary—product strategy.

The future engineer needs to anchor agents in observed events, artifacts, constraints, and commitments.

2. Ask about the past, then inspect the evidence

Software discovery will become more forensic. Do not stop at interviewing someone. Ask to see:

• The spreadsheet they actually use
• Recent support tickets
• An anonymized failed transaction
• The email chain used to resolve an exception
• The unofficial checklist taped to someone’s monitor
• Calendar entries showing how often the task occurs
• Existing contracts and compliance requirements
• Logs showing where users abandon a workflow
• The workaround employees created after the official tool failed

People’s descriptions of their work differ from their actual work. That gap is often where the valuable software opportunity lies.

A future engineer might spend less time manually implementing a solution and more time obtaining trustworthy evidence about the environment in which an AI-generated solution must operate.

3. Treat compliments as noise and commitments as evidence

A beautiful AI-generated prototype can attract praise without creating value. The Mom Test distinguishes encouraging words from meaningful advancement.

A useful evidence ladder might be:

1. “That sounds cool.”
2. Agreement to another meeting.
3. Introduction to the person who owns the process.
4. Access to real, appropriately sanitized data.
5. Time spent configuring or testing the system.
6. Agreement to run a limited pilot.
7. Acceptance of workflow disruption or migration costs.
8. Payment.
9. Deployment into real operations.
10. Continued use and renewal.

The future engineer should optimize for movement up this ladder rather than for enthusiastic reactions to demos.

This is especially important because AI will make impressive demos almost free. A demo will cease to be strong evidence of either engineering capability or customer demand.

4. Separate the problem from your proposed solution

If you begin with “I can build you an AI agent,” you will tend to reinterpret every complaint as a need for an agent.

A better sequence is:

1. Identify a costly or frustrating recurring event.
2. Understand the existing workflow and incentives.
3. Determine why previous solutions failed.
4. Define what a successful outcome would look like.
5. Consider nonsoftware solutions.
6. Only then decide whether AI, conventional automation, process redesign, or no intervention is appropriate.

In many organizations, the right answer may be a better form, a changed approval rule, a database constraint, or removal of an unnecessary process—not an autonomous agent.

As implementation becomes cheaper, the ability to say “this should not be built” becomes more valuable.

From requirements gathering to evidence engineering

Traditional requirements gathering often produces a list of requested features. A stronger future discipline would produce an evidence-backed model of the problem.

For each proposed capability, record:

• The observed event that motivates it
• How frequently that event occurs
• Who experiences the problem
• The current workaround
• The measurable cost
• The risks of intervention
• The relevant source artifacts
• The assumptions that remain uncertain
• The experiment that could resolve each uncertainty
• The acceptance test for a solution

For example:

“Add AI email triage” is a feature request.

An evidence-backed specification might instead say:

“During the previous eight weeks, 14 of 230 quote requests were not answered within two business days because they were sent to an unmonitored shared inbox. The pilot succeeds if it identifies at least 95% of genuine quote requests, never sends a price or contractual commitment autonomously, and reduces the median acknowledgment time below four hours.”

An agent can now implement and test against something connected to reality rather than merely producing a plausible email bot.

Applying this to an AI-heavy engineering workflow

A practical engagement could look like this.

1. Define learning goals

Before interviews, list the uncertainties that could kill the project:

• Does this problem occur often enough?
• Is it expensive enough to matter?
• Who owns the budget?
• Is the data accessible and legally usable?
• Is automation acceptable?
• What happens when the system is wrong?
• Can success be measured?
• What previous attempts have failed?

This prevents discovery from becoming an open-ended conversation.

2. Interview around recent concrete events

Ask the person to reconstruct the last instance of the problem. Follow the sequence closely:

• What happened first?
• What did you do next?
• Why?
• Which tool did you open?
• Who else became involved?
• Where did you hesitate?
• What happened in the unusual cases?

Observe the workflow when possible. Users routinely omit steps that seem too obvious, embarrassing, or unofficial to mention.

3. Give AI the evidence, not just a transcript summary

An AI research assistant could:

• Transcribe and index interviews
• Extract claimed workflow steps
• Link claims to exact passages
• Compare accounts from different roles
• Identify contradictions and unanswered questions
• Cluster recurring incidents
• Generate candidate experiments
• Search logs and tickets for corroboration

But it should preserve provenance. “Three users struggle with approvals” is much less useful than a claim connected to specific incidents, quotations, logs, and observed artifacts.

4. Use agents to generate competing hypotheses

Do not ask only, “What should we build?” Ask agents to argue several possibilities:

• The stated problem is real and common.
• It is real but too rare to justify intervention.
• The apparent software problem is actually an incentive problem.
• The requested automation would transfer work to someone less visible.
• The workflow exists primarily for legal or political reasons.
• The organization cannot safely provide the required access.
• A simpler process change would outperform software.

This uses AI to challenge a narrative rather than merely elaborate it.

5. Build the smallest reality test

Because prototypes are cheap, “MVP” can become misleading: teams may build a feature-rich product before validating the central risk.

Instead, build a minimum evidence-producing experiment:

• A manual concierge service
• A read-only recommendation system
• A shadow-mode agent that takes no actions
• A classifier run retrospectively on historical cases
• A prototype using fake data
• A narrow integration serving one employee
• A temporary script used for one reporting cycle

The goal is not to impress. It is to make an important uncertainty collapse.

6. Require commitment before increasing investment

Cheap generation can tempt engineers to keep building despite weak evidence. Establish gates:

• No production integration without a process owner.
• No sensitive-data access without security review.
• No autonomous action before shadow-mode evaluation.
• No broad rollout without measurable adoption.
• No customization without a paid engagement or equivalent commitment.

The cost of generated code may be small, but the cost of complexity, integration, review, and maintenance is not.

What this means for a software engineering career

The resulting role is not merely “programmer who also talks to customers.” It is closer to an embedded investigator and systems designer who can move through the entire loop:

1. Discover a real problem.
2. Gather trustworthy evidence.
3. Model the workflow and incentives.
4. Define measurable outcomes.
5. Direct agents to create candidate interventions.
6. Test them against reality.
7. Deploy them with appropriate controls.
8. Observe consequences and revise the model.

That loop is harder to automate than code generation because it crosses organizational boundaries and depends on trust, access, accountability, and local context.