MCP HubMCP Hub
SKILL·843ECA

mom-test

wondelai
업데이트됨 15 days ago
5 조회
2,020
206
2,020
GitHub에서 보기
테스팅testingapidesign

정보

이 Claude Skill은 개발자들이 가상 상황 대신 과거 행동을 논의하는 Mom Test 원칙을 적용해 편향 없는 고객 인터뷰를 진행할 수 있도록 돕습니다. 아이디어 검증, 인터뷰 대본 또는 피드백 편향을 언급할 때 활성화되어 유도 질문과 허위 긍정을 방지합니다. 본 스킬은 칭찬이나 모호한 피드백을 피하면서 대화에서 의미 있는 신호를 추출하는 데 중점을 둡니다.

빠른 설치

Claude Code

추천
기본
npx skills add wondelai/skills -a claude-code
플러그인 명령대체
/plugin add https://github.com/wondelai/skills
Git 클론대체
git clone https://github.com/wondelai/skills.git ~/.claude/skills/mom-test

Claude Code에서 이 명령을 복사하여 붙여넣어 스킬을 설치하세요

문서

The Mom Test Framework

Framework for customer conversations that won't lead you astray, based on a fundamental truth: everyone is lying to you -- not maliciously, but because you're asking the wrong questions. The Mom Test provides rules for asking questions so good that even your mom can't lie to you.

Core Principle

Good customer conversations are about their life, not your idea. The moment you mention what you're building, people switch from sharing truth to performing politeness. Talk about their problems, their lives, and their existing behavior instead of pitching, and ask about specifics in the past, not hypotheticals about the future. Above all, talk less and listen more.

Scoring

Goal: 7/7. Score a conversation (or interview plan) by the seven-row Quick Diagnostic below: 1 point per row that passes.

  • 6-7 = focused on their life and past behavior, concrete facts captured, a real commitment (time/reputation/money) secured, they talked 80%+, and beliefs got updated.
  • 4-5 = some past-behavior facts but leaking into hypotheticals, compliments accepted as signal, or ending without an ask.
  • <=3 = a pitch in disguise: leading questions, opinions and fluff, a polite zombie lead, no learning.

Always state the current score out of 7, name the failing diagnostic rows, and give the specific fix for each.

Framework Sections

1. The Mom Test Rules

Core concept: Three rules that make it impossible for even your most supportive loved ones to give you false validation, shifting conversations from opinion-gathering to fact-finding.

Why it works: People are unreliable predictors of their own future behavior, so opinions are worthless. Past behavior is the only reliable data and can genuinely inform product decisions.

Key insights:

  • Rule 1: Talk about their life, not your idea -- never mention your solution until the end, if at all
  • Rule 2: Ask about specifics in the past, not generics or hypotheticals about the future
  • Rule 3: Talk less, listen more -- aim for them to speak 80% of the time
  • A question fails the Mom Test if the answer is always "yes" regardless of whether the business will succeed
  • Good questions could potentially destroy your currently imagined business

Product applications:

ContextApplicationExample
Idea validationAsk about the problem, never the solution"Tell me about the last time you tried to [problem area]" not "Would you use an app that does X?"
Feature prioritizationDiscover what people do vs. what they say"Walk me through how you handled this last week"
Pricing researchAnchor to existing spending behavior"What are you currently paying to solve this?" not "Would you pay $X?"

Copy patterns:

  • "Tell me about the last time you..."
  • "What else have you tried?"
  • "Why does that bother you?"

See: references/question-patterns.md when drafting an interview script -- a 5-tier question hierarchy, domain-specific question banks (SaaS/consumer/marketplace), and four formulation exercises.

2. Good vs Bad Questions

Core concept: Most interview questions are broken because they ask people to predict the future, evaluate hypothetical products, or confirm your assumptions. Good questions anchor in observable past behavior and extract concrete facts.

Why it works: Asking "would you buy this?" is like asking "will you go to the gym next week?" -- the answer is always yes, the follow-through rarely there. Behavior that already happened can't be rationalized away.

Key insights:

  • Bad: "Do you think it's a good idea?" -- always gets a yes
  • Bad: "Would you buy a product that does X?" / "How much would you pay?" -- hypothetical, anchored to please you
  • Good: "How are you dealing with this problem today?" -- reveals actual behavior
  • Good: "What have you tried before and why did you stop?" -- reveals past decisions
  • Good: "Where does the money come from for solutions like this?" -- reveals real budgets
  • The scariest questions -- ones with the power to change what you're building -- produce the most useful data

Product applications:

ContextApplicationExample
Problem validationConfirm the problem exists and matters"When did this last come up? What did you do? What didn't work?"
Market sizingCheck if enough people share the problem"Who else in your industry deals with this? How do they handle it?"
Competitive analysisFind real alternatives already in use"What tools/processes do you currently use for this?"

Copy patterns:

  • "What's the hardest part about [doing this thing]?"
  • "How often does this come up?"
  • "Walk me through what happened the last time this came up"

3. Avoiding Compliments and Opinions

Core concept: Three types of bad data feel like progress but actively mislead: compliments ("That's a great idea!"), fluff (hypotheticals, maybes, future promises), and ideas (feature requests disconnected from real problems). Deflecting these and digging for truth is the core skill.

Why it works: Compliments are the fool's gold of customer development -- they feel amazing but contain zero information about whether anyone will pay or use the product. Only specifics about real past behavior and genuine commitments provide signal.

Key insights:

  • Compliments: deflect immediately and return to concrete facts about how they handle the problem today
  • Fluff: generic claims ("I usually," "I always," "I would never") are worthless without a specific instance
  • Ideas: dig into the motivation behind every feature request -- what's driving it, when they last needed it
  • Fishing for compliments ("Don't you think this would be useful?") is unconscious validation-seeking
  • Symptom of a bad conversation: you walk away feeling great but with no concrete facts or commitments

Product applications:

ContextApplicationExample
Post-demo feedbackDeflect "this looks awesome""Thanks! What part of your current workflow would this replace?"
Feature requestsDig for the underlying job"Why do you want that? Can you show me the last time you needed it?"
Investor conversationsSeparate encouragement from interestAsk for customer intros, not "great idea" feedback

Copy patterns:

  • "Thanks, but to make sure I'm not wasting your time -- what does your current process look like?"
  • "When you say you'd 'definitely' use this, what would you stop using?"
  • "That's a great feature idea -- what problem would it solve for you specifically?"

See: references/avoiding-bad-data.md when a conversation feels good but yields no facts -- how to spot and deflect the three bad-data types (compliments, fluff, ideas) in real time.

4. Commitment and Advancement

Core concept: The currency of a customer conversation is commitment, not compliments. End every conversation with a clear advance toward adoption or a clear rejection -- the worst outcome is a "zombie lead" who is polite but never commits.

Why it works: Saying "I'd definitely buy that" costs nothing; offering an intro, a deposit, or a pilot invests something real. Commitment closes the dangerous gap between what people say and what they do.

Key insights:

  • Commitment currencies: time (meeting, trial), reputation (intro, testimonial), money (deposit, pre-order, letter of intent)
  • Advancing moves the relationship toward a sale; spinning wheels produces pleasant, useless meetings
  • Know your "ask" before the meeting -- the minimum commitment that proves this is real
  • A "no" is more valuable than a "maybe" -- you can learn from it and move on
  • If they won't give you their time, they definitely won't give you their money

Product applications:

ContextApplicationExample
Early validationRequest a commitment that tests interest"Can I follow up with a prototype next week for 15 minutes of your time?"
B2B salesAdvance toward the decision-maker"Could you introduce me to the person who handles the budget for this?"
Pre-launchCollect pre-orders or letters of intent"Launching in 8 weeks -- want to join the first cohort at 40% off?"

Copy patterns:

  • "Who else should I talk to about this?"
  • "Would you be willing to try a prototype next week?"
  • "If I built this, would you be willing to pilot it for 30 days?"

See: references/commitment-advancement.md when a conversation ends without a commitment -- the currency ladder (time/reputation/money) and scripts for advancing instead of spinning wheels.

5. Finding Conversations

Core concept: The best customer conversations happen casually -- warm intros, industry events, online communities, coffee. Formal "customer interview" framing triggers performance mode; casual framing produces honest data.

Why it works: "Can I interview you about your problems?" makes people polished and guarded; "I'm trying to learn about the industry -- can I buy you coffee?" makes them open up. The framing determines the quality of the data.

Key insights:

  • Cold outreach: keep it short, lead with their expertise, don't pitch
  • Warm intros are the best source -- one well-connected advisor can open dozens of doors
  • Go where customers already gather: industry events, meetups, online communities (participate genuinely first)
  • "I'm trying to learn" beats "I'm doing customer research"
  • Use the five-part structure for getting meetings: vision / framing / weakness / pedestal / ask

Product applications:

ContextApplicationExample
Pre-idea explorationImmerse in the target community3 industry events and 20 casual conversations before writing code
B2B prospectingWarm intros through advisors"Our advisor [Name] suggested I ask how you handle [problem area]"
Consumer researchIntercept at the point of behaviorTalk to people in line at the store, the gym, the coworking space

Copy patterns:

  • "I'm researching how [industry] handles [problem] -- could I learn from your experience over a 15-minute coffee?"
  • "[Mutual contact] suggested I talk to you because you know a lot about [area]"
  • "I'm not trying to sell anything -- I'm just trying to understand the space"

Ethical boundary: Never disguise a sales call as a learning conversation -- if you already have a product and are selling, be transparent.

See: references/finding-conversations.md when you need to source interviews -- cold vs warm outreach templates, the five-part meeting ask (vision/framing/weakness/pedestal/ask), and how to keep it casual.

6. Processing and Learning

Core concept: Conversations are only useful if processed: distill raw notes into beliefs, update them regularly, and share with your team. Without a system you'll cherry-pick quotes that confirm your biases.

Why it works: Memory is biased toward recent and emotionally charged information, so teams selectively remember confirming data. Processing as a team prevents any one person's bias from dominating the narrative.

Key insights:

  • Take notes during or immediately after -- never rely on memory
  • Separate facts (what they said and did) from interpretations (what you think it means)
  • Share raw notes with your team, not filtered summaries
  • Update your three key beliefs after each batch: the problem, the customer segment, the solution
  • Stop talking and start building when conversations start repeating
  • Use a simple spreadsheet: who, date, key quotes, facts, commitments, belief changes

Product applications:

ContextApplicationExample
Team alignmentReview notes together weekly5 conversations per week reviewed as a team; belief board updated
Pivot decisionsTrack evidence against core beliefs8 of 10 conversations reveal a different problem than expected -- pivot
Feature validationCount unprompted mentionsA problem named by 7 of 10 people is real; 1 of 10 might not be

Copy patterns:

  • "Our current belief is X -- here's what confirms it and what challenges it"
  • "We've heard this from N of M people -- is that enough signal?"
  • "Time to stop talking and build -- conversations are repeating"

See: references/processing-learning.md after a batch of interviews -- the notes-to-beliefs spreadsheet template, team-review cadence, and signals that it's time to stop talking and build.

Common Mistakes

MistakeWhy It FailsFix
Pitching your idea instead of asking about their lifeTriggers politeness; produces compliments, not factsDon't mention your idea until the very end, if at all
Asking "would you buy this?"Hypothetical yeses cost nothingAsk what they've already done: "How much are you spending on this now?"
Accepting compliments as validation"Great idea!" carries zero information about behaviorDeflect immediately: "Thanks -- but what are you doing about this today?"
Talking too muchYou learn while listening, not talkingThey should talk 80%+ of the time
No clear ask at the endProduces zombie leads that go nowhereKnow your advance before the meeting: trial, intro, pre-order
Running formal "interview" sessionsTriggers performance mode and filtered answersKeep it casual: coffee, hallway conversations, Slack DMs
Not processing notes as a teamIndividual bias filters data into confirmationShare raw notes weekly; update shared beliefs together

Quick Diagnostic

QuestionIf NoAction
Did the conversation focus on their life and past behavior, not your idea?You ran a pitch, not a Mom Test conversationRedo with zero mention of your solution
Did you get concrete facts about what they've already done?You collected opinions and hypotheticalsAsk about the last time the problem occurred and what they did
Did they give a commitment (time, reputation, or money)?Likely a zombie lead -- polite but not interestedAsk for a specific next step: trial, intro, or pre-order
Did they do most of the talking?You talked too much and learned too littlePractice silence; let awkward pauses work for you
Did you learn something that could change what you're building?You asked safe, confirming questionsAsk the scary questions you've been avoiding
Did you update your beliefs based on the conversation?You're collecting data but not learningReview notes with the team; update problem/segment/solution beliefs
Can you summarize the key facts (not opinions)?Poor notes, or opinions confused with factsSeparate facts from interpretations immediately after

See: references/case-studies.md when you want to see the rules applied end-to-end -- realistic SaaS, consumer, B2B, and marketplace interviews scored against this diagnostic.

Further Reading

This skill is based on Rob Fitzpatrick's Mom Test methodology:

About the Author

Rob Fitzpatrick is an entrepreneur and educator who founded multiple venture-backed startups and learned the hard way that most customer conversations produce misleading feedback. The Mom Test (2013) distills his evidence-based approach, has been translated into 20+ languages, and is required reading at accelerators including Y Combinator and Techstars. He also wrote The Workshop Survival Guide and Write Useful Books.

GitHub 저장소

wondelai/skills
경로: plugins/product-strategy/skills/mom-test
0
agent-skillsai-skillsbusinessclaude-codeclaude-code-marketplaceclaude-code-plugin
FAQ

자주 묻는 질문

mom-test Skill이란 무엇인가요?

mom-test은(는) wondelai이(가) 만든 Claude Skill입니다. Skill은 Claude가 필요할 때 불러오는 지침과 리소스를 묶어 추가 프롬프트 없이 mom-test 관련 작업을 수행할 수 있게 합니다.

mom-test은(는) 어떻게 설치하나요?

이 페이지의 설치 명령을 사용하세요. mom-test을(를) Claude Code 플러그인으로 추가하거나 저장소를 skills 디렉터리에 복제한 다음 Claude를 다시 시작해 Skill을 불러옵니다.

mom-test은(는) 어떤 카테고리에 속하나요?

mom-test은(는) 테스팅 카테고리에 속합니다.

mom-test은(는) 무료로 사용할 수 있나요?

네. mom-test은(는) AIMCP에 등록되어 있으며 무료로 설치할 수 있습니다.

연관 스킬

evaluating-llms-harness
테스팅

이 Claude Skill은 MMLU, GSM8K를 포함한 60개 이상의 표준화된 학술 과제에서 LLM 성능을 벤치마크하기 위해 lm-evaluation-harness를 실행합니다. 개발자들이 모델 품질을 비교하고, 학습 진행 상황을 추적하거나 학술 결과를 보고할 수 있도록 설계되었습니다. 이 도구는 HuggingFace와 vLLM 모델을 포함한 다양한 백엔드를 지원합니다.

스킬 보기
cloudflare-cron-triggers
테스팅

이 스킬은 cron 표현식을 사용하여 Worker를 스케줄링하기 위한 Cloudflare Cron Triggers 구현에 관한 포괄적인 지식을 제공합니다. 주기적 작업, 유지보수 작업, 자동화된 워크플로우 설정 방법을 다루며, 잘못된 cron 표현식이나 시간대 문제 같은 일반적인 이슈들을 해결하는 방법을 포함합니다. 개발자들은 이를 통해 스케줄된 핸들러 구성, cron 트리거 테스트, Workflows 및 Green Compute와의 연동 작업을 수행할 수 있습니다.

스킬 보기
webapp-testing
테스팅

이 Claude Skill은 Python 스크립트를 통해 로컬 웹 애플리케이션을 테스트하기 위한 Playwright 기반 툴킷을 제공합니다. 프론트엔드 검증, UI 디버깅, 스크린샷 캡처, 로그 확인 기능을 지원하며 서버 라이프사이클을 관리합니다. 브라우저 자동화 작업에 사용하되 컨텍스트 오염을 방지하기 위해 소스 코드를 읽지 않고 스크립트를 직접 실행하세요.

스킬 보기
finishing-a-development-branch
테스팅

이 스킬은 테스트 통과를 확인한 후 체계적인 통합 옵션을 제시하여 개발자가 완성된 작업을 마무리하도록 돕습니다. 구현이 완료된 후 머지, PR 생성, 브랜치 정리와 같은 워크플로우를 안내합니다. 코드가 준비되고 테스트가 완료되었을 때 개발 프로세스를 체계적으로 마무리하기 위해 사용하세요.

스킬 보기