AI를 활용한 PMF 식별
AI로 세그먼트·유스케이스를 펼치고 채점해 첫 공략 대상을 좁히는 법. 구조화 출력·반복 채점 같은 기술 디테일과, 누가 2주 동안 무엇을 하는지 현업 실행안까지 붙였습니다.
AI로 "누구에게 무엇을 팔지" 후보를 넓게 펼치고 같은 기준으로 채점하면, 첫 공략 대상을 며칠이 아니라 몇 시간 만에 좁힐 수 있습니다. 실제로 쓰려면 AI가 매번 같은 답을 내게 만드는 기술적 장치와, 그 답을 2주 안에 고객에게 확인하는 실행 계획이 함께 있어야 합니다.
요약
Canva와 Atlassian에서 제품 마케팅을 해 온 Daniella Latham은 버그 화면을 녹화해 공유하는 개발자용 SaaS를 가상의 예로 들어, 스타트업이 PMF(제품이 시장의 실제 수요와 맞아떨어지는 상태)를 찾는 과정을 AI로 시연합니다. AI에게 스타트업 컨설턴트 역할을 맡겨 세그먼트(회사 유형과 그 안의 역할)와 유스케이스(제품으로 해결하려는 구체적인 일)를 다섯 개씩 뽑게 하고, 각각을 구매 결정권자, 문제 인식, 문제-해법 적합, 유통 접근성, 경쟁의 다섯 기준에 0~5점으로 매기게 합니다. 이어서 업계가 이미 믿는 흐름에 문제를 연결해 설득 논리를 세우고, 경쟁 3사와 비교합니다.
그 결과 첫 공략 조합으로 대형 IT 서비스 기업의 개발 중 버그 추적이 꼽힙니다. 예산을 쓸 권한을 가진 구매자가 뚜렷하다는 점이 1위의 이유였습니다. 저자는 이 과정으로 핵심 세그먼트와 놓치기 쉬운 기회를 짧은 시간에 찾을 수 있다고 말합니다. 아래 두 절은 이 방법을 실제로 돌릴 때 필요한 기술 설정과 현업 실행 계획입니다.
기술 디테일: AI가 매번 같은 답을 내게 하려면
결과를 표로 받습니다. 채팅 답변 대신 아래처럼 필드가 정해진 JSON(또는 CSV)으로 받으면, 스프레드시트에 붙여 정렬하고 회차별로 비교할 수 있습니다. 근거와 출처를 필드로 강제하면 “그럴듯한 말”이 줄어듭니다.
{
"segment": "대형 IT 서비스 기업",
"role": "QA 리드",
"use_case": "개발 중 버그 추적",
"scores": {
"buyer": 5, "awareness": 4, "fit": 4, "channel": 3, "competition": 2,
"sales_cycle": 1, "data_readiness": 3
},
"rationale": { "buyer": "QA 도구 예산을 QA 리드가 직접 집행", "...": "..." },
"evidence": [{ "claim": "경쟁사 X는 무료 플랜 없음", "url": "https://...", "checked_at": "2026-10-24" }],
"unknown": ["channel"]
}한 번에 하나씩, 여러 번 채점합니다. 25개 조합을 한 프롬프트에 몰아넣으면 앞쪽 후보가 유리해지는 순서 편향이 생깁니다. 조합마다 따로 호출하고, 같은 채점을 35회 반복해 평균과 표준편차를 봅니다. 표준편차가 1점을 넘는 항목만 사람이 다시 봅니다. API로 돌린다면 temperature를 낮게(00.3) 두고, 가능하면 다른 회사의 모델로 한 번 더 채점해 둘이 크게 갈리는 항목을 찾습니다.
채점표에 중간 점수까지 적어 줍니다. 0점과 5점뿐 아니라 3점이 어떤 상태인지도 정의하고(아래 채점표), 근거를 모르면 점수를 지어내지 말고 unknown에 넣게 합니다.
최신 사실은 검색이 되는 도구로 따로 돌립니다. 경쟁사 가격·기능, 업계 트렌드는 웹 검색이 되는 모델이나 Perplexity 같은 도구로 조사하고, 출처 링크와 확인 날짜를 함께 받습니다. 링크를 직접 열어 확인한 항목만 남깁니다.
상상 대신 내 데이터를 먹입니다. 세그먼트 후보를 뽑을 때 CRM의 리드 목록, 놓친 딜의 사유, 고객 지원 티켓, 앱스토어·G2 리뷰를 함께 넣으면, AI가 일반론이 아니라 실제 고객의 말에서 세그먼트를 찾습니다. 개인정보는 빼고 넣습니다.
가중치는 사람이 정합니다. 다섯 기준의 중요도가 같지는 않습니다. 스프레드시트에서 기준별 가중치(예: 구매 결정권자 ×1.5, 판매 주기 ×1.5)를 팀이 정해 합계를 계산하고, AI에게는 원점수만 받습니다.
| 기준 | 0점 | 3점 | 5점 |
|---|---|---|---|
| 구매 결정권자 | 누가 돈을 낼지 모름 | 후보는 있으나 결재 라인이 불분명함 | 예산과 결재 권한을 가진 사람이 분명함 |
| 문제 인식 | 고객이 문제를 못 느낌 | 불편은 알지만 따로 해결하려 하지 않음 | 이미 돈이나 시간을 써서 해결하려 함 |
| 문제-해법 적합 | 제품이 문제의 일부만 건드림 | 문제의 절반쯤을 줄여 줌 | 핵심 문제를 바로 줄여 줌 |
| 유통 접근성 | 닿을 채널이 없음 | 소개나 파트너를 거치면 닿음 | 지금 가진 채널로 바로 닿음 |
| 경쟁 여유 | 강자가 이미 장악 | 대안은 있지만 불만이 많음 | 뚜렷한 대안이 없음 |
| 판매 주기 | 도입까지 6개월 이상, 보안 심사 필수 | 1~3개월, 담당 팀장 결재 | 2주 안에 카드 결제로 시작 가능 |
| 데이터 준비도 | 필요한 데이터가 없거나 흩어져 있음 | 있지만 정리에 1~2개월 필요 | 바로 쓸 수 있게 쌓여 있음 |
현업 실행 디테일: 누가, 2주 동안, 무엇을
세 사람이면 됩니다.
| 역할 | 누가 | 맡는 일 |
|---|---|---|
| 오너 | PM 또는 제품 마케터 | 프롬프트 실행, 점수표 관리, 최종 보고 |
| 현실 점검 | 영업 담당 1명 | 세그먼트별 판매 주기, 결재 단계, 보안 심사 여부 확인 |
| 도메인 확인 | 고객을 잘 아는 CS·현장 담당 | AI가 뽑은 역할과 유스케이스가 현장 언어와 맞는지 확인 |
시작 전에 모을 것. 제품 한 장 설명(누구의 어떤 문제를 어떻게 줄이는지), 기존 고객과 리드 목록, 최근 놓친 딜 10건의 사유, 지원 티켓 30건 샘플입니다.
| 기간 | 할 일 | 산출물 |
|---|---|---|
| 1~2일 | 내 데이터를 넣어 세그먼트·유스케이스 8개씩 뽑기, 조합별 3회 채점 | 점수표 v1 (평균·편차) |
| 3일 | 영업이 판매 주기·결재 단계 점수를 채우고, 팀이 가중치 확정, 상위 3개 조합 선정 | 점수표 v2, 인터뷰 대상 3조합 |
| 4~8일 | 조합마다 5명, 총 15명 인터뷰. 기존 고객 소개, LinkedIn, 업계 커뮤니티로 모집 | 인터뷰 노트 15건 |
| 9~10일 | 인터뷰 결과로 점수 덮어쓰기, 1개 조합 결정 | 1장 보고서 |
인터뷰에서 물을 것. 의견이 아니라 행동을 묻습니다.
- 이 문제가 마지막으로 생긴 게 언제였고, 그때 어떻게 처리했나요?
- 지금은 어떤 도구나 방법을 쓰고, 거기에 한 달에 시간과 돈을 얼마나 쓰나요?
- 새 도구를 들이려면 누가 결정하고, 보통 몇 주가 걸리나요?
- 우리가 해결해 준다면, 다음 달에 2주짜리 파일럿을 해 볼 의향이 있나요?
진행 여부를 숫자로 정해 둡니다. 예를 들어 15명 중 6명 이상이 “지금 이 문제에 돈이나 시간을 쓰고 있다”고 답하고, 3명 이상이 파일럿에 동의하면 그 조합으로 진행합니다. 기준은 인터뷰 전에 정해야 결과를 보고 끼워 맞추지 않습니다. AI 점수와 인터뷰 결과가 다르면 언제나 인터뷰를 따릅니다.
AX PoC에 쓸 때. 세그먼트를 부서(품질, 구매, SCM)로, 유스케이스를 그 부서의 의사결정(예: 불량 원인 판정, 공급사 선정)으로 바꿉니다. 이때는 판매 주기 대신 데이터 준비도(그 결정에 필요한 데이터가 이미 쌓여 있는가)와 현업 스폰서 유무가 가장 무거운 기준이 됩니다.
원문 사례
| 항목 | 내용 |
|---|---|
| 제품 | 미국 개발자를 위한 버그 리포팅 SaaS. 여러 플랫폼에서 버그·크래시·오류 화면을 녹화해 공유합니다. |
| AI에게 준 역할 | 10년 경력의 스타트업 컨설턴트 |
| 뽑힌 세그먼트 5개 | 대형 IT 서비스 기업, 중견 소프트웨어 개발사, 독립 소프트웨어 벤더(ISV), 스타트업 SaaS 기업, 비IT 기업의 사내 IT 부서 |
| 뽑힌 유스케이스 5개 | 개발 중 버그 추적, 고객 지원, 배포 후 모니터링, 제품 개발 문서화, 교육·역량 강화 |
| 세그먼트 순위 | 1위 대형 IT 서비스 기업(구매 권한을 가진 고객이 뚜렷함) · 2위 스타트업 SaaS(문제 인식과 구매력) · 3위 중견 개발사 |
| 유스케이스 순위 | 1위 개발 중 버그 추적 · 2위 고객 지원 · 3위 배포 후 모니터링 |
| 문제를 설명한 근거 | ① 버그 리포트가 명확하면 디버깅 시간과 비용이 준다 → 화면 녹화가 그 해법 ② 비개발 직원도 버그 보고에 참여하는 추세 → 쓰기 쉬운 도구 수요 |
| 비교한 경쟁사 | Airbrake, Backlog, Rollbar |
| 경쟁사 | 강점 | 약점 |
|---|---|---|
| Airbrake | 실시간 알림, 폭넓은 언어 지원 | 인터페이스가 덜 직관적, 가격 민감도 |
| Backlog | 프로젝트 관리와 버그 추적을 한 곳에서, 단순함 | 고급 기능 부족, 규모가 커지면 한계 |
| Rollbar | 실시간 상세 진단 | 작은 스타트업에는 비싸고 배우기 어려움 |
핵심 개념
- 세그먼트
- 같은 이유로 같은 제품을 살 법한 고객 묶음. 회사 유형과 그 안의 역할을 함께 적어야 채점할 수 있습니다.
- 유스케이스
- 그 세그먼트가 제품으로 해결하려는 구체적인 일. 같은 제품도 세그먼트마다 다릅니다.
- 구매 결정권자
- 실제로 예산을 집행할 권한이 있는 사람. 사용자가 원해도 이 사람이 없으면 거래가 성사되지 않습니다.
- 문제 인식도
- 고객이 그 문제를 이미 문제로 느끼는 정도. 낮으면 제품보다 문제를 먼저 팔아야 합니다.
- 유통 접근성
- 지금 가진 채널(파트너, 커뮤니티, 영업망)로 그 세그먼트에 닿을 수 있는지.
내 메모
TODO: 내 생각 추가
원문은 Daniella Latham의 「Using AI to identify product-market fit」입니다. 요약은 원문을 AX Review가 다시 정리한 것이고, 기술·현업 실행 디테일과 JSON 예시, 채점표, 인터뷰 질문, 도식은 원문에 없는 내용으로 새로 작성했습니다. 원문의 실제 프롬프트와 결과 화면은 원문 링크 또는 2024년 Ghost 번역본에서 볼 수 있습니다.