PMF가 왔다는 신호는 만족도보다 먼저 팀 달력에 찍힙니다
고객이 좋아한다고 끝이 아닙니다. 팀이 매주 같은 요청을 같은 방식으로 처리하게 될 때, 비로소 시장이 붙기 시작합니다
PMF를 고객 만족으로만 보면 자꾸 늦게 알아차립니다
초기 스타트업에서 PMF를 말할 때, 보통은 고객 만족을 먼저 떠올립니다. NPS가 높다거나, 인터뷰에서 “좋네요”라는 반응이 나온다거나, 몇몇 고객이 칭찬해주는 상태를 생각하죠.
그런데 저는 초반 PMF를 그렇게만 보면 자주 놓친다고 봅니다. 실제로는 고객의 감정보다 팀의 일정표에서 먼저 티가 나는 경우가 많습니다.
예를 들어 5명짜리 SaaS 팀이 있다고 해보겠습니다. 월요일 오전 10시에 고객 A가 “CSV 업로드 형식이 안 맞아요”라고 연락하고, 화요일엔 고객 B가 같은 문제로 샘플 파일을 보내고, 목요일엔 창업자가 직접 줌으로 들어가 열 순서를 맞춰줍니다.
그다음 주에도 똑같은 일이 반복됩니다. 다만 이번엔 고객이 2곳이 아니라 6곳이고, 요청이 들어오는 속도가 더 빨라지죠. 저는 이런 순간이 꽤 중요하다고 봅니다. 고객이 만족하는지보다 먼저, 팀이 포기할 수 없는 반복 업무가 생겼는지를 봐야 하거든요.
이게 왜 중요할까요. 만족은 말로 표현되지만, 반복 업무는 행동으로 남습니다. 누가 언제 어떤 이유로 연락했고, 팀이 무엇을 수동으로 메웠는지가 기록으로 쌓여요.
First Round의 PMF 자료도 결국 비슷한 방향을 가리킵니다. PMF는 막연한 감각이 아니라, 특정 고객군에서 반복적으로 확인되는 강한 수요를 더 선명하게 만드는 과정에 가깝습니다.
초기 PMF는 “고객이 좋아한다”보다 “우리가 매주 같은 문제를 대신 처리하고 있다”에 더 가깝습니다.
조금 냉정하게 말하면, 고객 만족은 아직 호감일 수도 있습니다. 하지만 팀이 계속 같은 요청을 받는다면 그건 이미 업무가 되었고, 업무가 되었다는 건 고객의 실제 운영 어딘가에 제품이 자리를 잡았다는 뜻이에요. (이 차이를 처음 체감하면, 대시보드보다 슬랙 알림이 더 무섭게 보입니다.)
문제 검증은 인터뷰가 아니라 재발 빈도에서 갈립니다
정말 문제 검증이 됐는지는 뭘 보면 알 수 있을까요. 저는 “사람들이 이 문제를 중요하다고 말하는가”보다 “같은 방식으로 다시 찾아오는가”를 먼저 봅니다.
초기엔 이 차이가 생각보다 큽니다. 인터뷰 20번에서 18명이 공감해도, 실제 운영에서 반복 호출이 없으면 아직 우선순위가 아닐 수 있거든요.
Rob Fitzpatrick의 The Mom Test가 강조하듯, 미래 의견보다 과거 행동이 더 믿을 만합니다. “이 기능 있으면 쓰실 것 같아요”보다 “지난 2주 동안 이 문제를 몇 번 겪었고, 누가 몇 시간 썼나요”가 훨씬 낫죠.
예를 들어 채용 운영 툴을 만드는 4명 팀이 있다고 해보겠습니다. 인터뷰에선 HR 매니저 15명 중 12명이 “지원자 정리 너무 힘들어요”라고 말했습니다. 여기까지만 보면 시장이 커 보입니다.
그런데 실제 파일을 받아보니 달랐습니다. 12명 중 3명만 지난달에도 엑셀 정리를 밤 9시 이후까지 했고, 그중 2명만 이번 주 안에 템플릿을 바꿔보자고 했어요. 나머지는 불편하지만 분기 채용 시즌까지는 그냥 버틸 수 있는 상태였죠.
저는 여기서 문제 검증의 기준이 바뀐다고 봅니다. 문제를 느끼는 사람 수가 아니라, 문제가 반복될 때 바로 팀을 움직이게 만드는지가 더 중요합니다.
보통 PMF를 ‘찾아야 할 것’이라고 생각하지만, 실제로는 ‘반복되지 않는 요청을 버리는 과정’에 더 가깝습니다. 초반 팀이 바빠지는 이유는 고객이 많아서가 아니라, 아직 같은 문제만 남기지 못해서인 경우가 더 많습니다.
제가 보는 반복 업무의 기준은 꽤 구체적입니다
그냥 문의가 많다고 다 신호는 아닙니다. 저는 비슷한 요청이 아래처럼 겹칠 때 주목합니다.
- 같은 직군에서 2주 안에 비슷한 요청이 3번 이상 들어온다
- 창업자나 첫 PM이 직접 수동 대응하고 있는데도 고객이 계속 다시 찾아온다
- 그 요청을 처리한 뒤 사용 빈도나 재방문이 눈에 띄게 오른다
- 고객이 “이거 다음에도 해주실 수 있나요”라고 운영 프로세스처럼 기대하기 시작한다
이 네 가지가 같이 보이면, 단순 CS가 아니라 제품이 붙을 자리가 드러난 겁니다. 아직 기능은 부족해도, 적어도 문제는 허상이 아니라는 뜻이죠.
고객 만족도가 높은데도 PMF가 아닌 경우가 있습니다
한 번은 이런 경우를 봤습니다. 3명 팀이 AI 회의록 정리 툴을 만들고 있었는데, 첫 40개 계정의 피드백 점수는 꽤 좋았습니다. “요약이 깔끔하다”, “공유하기 편하다” 같은 반응이 많았죠.
그런데 유료 전환은 거의 안 일어났습니다. 왜였냐면, 회의록이 예쁘게 정리되는 건 좋지만 그걸 안 쓰면 일이 멈추는 사람은 별로 없었기 때문입니다.
반대로 같은 시기에 다른 팀은 6명 규모로 영업 문서 자동화 SaaS를 만들고 있었습니다. 첫 달엔 제품이 투박했고, 데모 때 오류도 종종 났어요. 만족도 조사만 하면 더 낮게 나왔을 겁니다.
그런데 고객사 8곳 중 5곳이 매주 금요일마다 같은 요청을 보냈습니다. “이번 주 제안서 11건 넣어야 하는데 지난번 템플릿 그대로 복사해달라”, “로고만 바꿔서 4개 버전 다시 만들어달라” 같은 요청이었죠.
이 팀은 한동안 제품회사가 아니라 대행사처럼 일했습니다. 창업자 둘이 금요일 저녁마다 직접 문서를 손봤고, 월요일 아침엔 그 작업을 기능으로 옮길지 회의했어요. 겉으로 보면 비효율의 연속인데, 저는 이런 상태가 오히려 강하다고 봅니다.
고객 만족은 결과 지표일 수 있지만, 반복 업무는 원인 지표에 가깝습니다.
Bessemer Venture Partners의 PMF 플레이북도 AI 제품에서 거짓 양성 신호를 조심하라고 말합니다. 반응이 좋고 체험은 활발해 보여도, 실제로 반복 사용과 구매 행동이 붙지 않으면 PMF처럼 착각하기 쉽다는 거죠.
초기 스타트업이 특히 헷갈리는 이유가 여기 있습니다. 만족도는 올라가는데, 팀의 우선순위는 여전히 흔들립니다. 반면 진짜 붙는 제품은 고객이 팀의 시간을 한 방향으로 집중시킵니다.
그 반복 업무를 어떻게 읽어야 제품 기회가 보일까요
반복 업무는 기능 요청이 아니라 운영의 빈틈을 드러낸 신호입니다.
예를 들어 고객이 “파일 업로드가 안 돼요”라고 말하면, 표면적으로는 버그 같아 보입니다. 그런데 같은 요청을 4개 고객사가 보내고, 모두 20~50명 규모 운영팀이며, 공통적으로 외부 파트너 파일을 매주 받는다면 얘기가 달라집니다.
그건 업로드 기능 하나의 문제가 아니라, 외부 데이터가 내부 워크플로우로 들어오는 접점이 엉성하다는 뜻일 수 있어요. 즉 고객이 돈을 내는 이유는 업로드 버튼이 아니라, 매주 반복되는 정리 작업을 없애는 데 있는 겁니다.
저라면 이때 요청을 기능 단위로 쪼개지 않습니다. 대신 이렇게 다시 적습니다.
- 누가: 운영팀 리드 또는 실무 담당자
- 언제: 매주 월요일 오전, 외부 파일 취합 직후
- 무엇 때문에: 형식이 제각각이라 수동 정리 2~3시간 발생
- 지금은 어떻게 버티는지: 엑셀 복붙, 열 이름 수정, 누락값 체크
- 그래서 원하는 것: 업로드 성공이 아니라 정리 없는 입력
이렇게 써보면 제품 로드맵도 달라집니다. “CSV import 개선”이 아니라 “외부 파일 표준화 자동화”가 되죠. 같은 개발 리소스를 써도 훨씬 PMF에 가까운 선택이 됩니다.
반복 업무가 생기면 팀 구조도 바뀝니다
초기엔 창업자가 세일즈, CS, PM을 다 합니다. 그런데 특정 요청이 계속 반복되면, 그때부터는 사람의 역할도 나뉘어요. 누군가는 고객 대응 템플릿을 만들고, 누군가는 수동 처리 과정을 자동화하고, 누군가는 어떤 요청을 버릴지 결정합니다.
이 변화가 은근히 중요합니다. PMF가 오면 팀이 덜 바빠질 것 같지만, 실제로는 바쁨의 종류가 바뀝니다. 랜덤한 일이 줄고, 같은 일을 더 자주 더 빠르게 처리하게 되죠.
Paul Graham이 말한 “스케일 안 되는 일을 하라”는 조언도 저는 여기서 다시 읽습니다. 초반 수동 작업은 임시방편이 아니라, 어떤 반복이 진짜인지 알아내는 센서에 가깝습니다.
문제는 많은 팀이 이 구간을 너무 빨리 자동화하거나, 반대로 너무 오래 대행처럼 버틴다는 데 있습니다. 둘 다 위험합니다. 3주 연속 같은 요청이 들어오면 제품화 후보로 올려야 하고, 3개월째 창업자가 같은 파일을 손으로 고치고 있다면 이미 늦은 거예요. (이쯤 되면 “우린 고객 친화적이야”가 아니라 그냥 야근 친화적일 수 있습니다.)
초기 스타트업이 PMF를 착각할 때 보이는 패턴
흔한 오해가 있습니다. 고객이 계속 요구사항을 주면 PMF에 가까워지고 있다고 생각하는 겁니다. 반은 맞고, 반은 틀립니다.
요구사항이 많다는 건 관심이 있다는 뜻일 수 있습니다. 하지만 그 요구가 서로 다른 방향이면, 팀은 고객 맞춤 제작 회사가 되기 쉽습니다.
예를 들어 한 주에는 병원 고객이 권한 관리 기능을 원하고, 다음 주에는 커머스 고객이 재고 연동을 원하고, 그다음엔 교육 고객이 출석 리포트를 원한다고 해보겠습니다. 다 절실해 보이죠.
하지만 이 세 요청 사이에 공통 운영 흐름이 없다면, 그건 PMF가 아니라 외주 파이프라인일 가능성이 큽니다. a16z가 ICP를 좁히라고 강조하는 이유도 여기에 있습니다. 최고 고객의 공통점이 없으면, 제품은 점점 설명하기 어려워지고 팀의 반복 업무도 축적되지 않거든요.
제가 초기에 보고 싶은 건 다양한 칭찬이 아닙니다. 오히려 조금 지겨울 정도로 비슷한 요청입니다.
“또 이거네”라는 말이 팀 안에서 나오기 시작하면, 그때부터는 짜증이 아니라 힌트로 봐야 합니다. 같은 문제, 같은 순간, 같은 역할에서 반복되면 그건 좁지만 단단한 시장일 가능성이 높습니다.
이럴 때는 아직 PMF라고 보기 어렵습니다
- 고객 인터뷰 반응은 좋은데, 지난달 실제 사용 빈도는 들쭉날쭉하다
- 유료 고객이 있어도 각자 쓰는 이유가 전부 다르다
- 창업자 수동 대응은 많은데, 그 대응 방식이 매번 새롭다
- 제품 로드맵이 가장 큰 고객 한 곳의 요구에 계속 끌려간다
- 문제는 인정하지만 “이번 분기 안에는 못 바꾼다”는 답이 반복된다
이 상태에선 만족도 조사보다 사용 로그와 반복 요청 기록이 더 솔직합니다. PMF는 박수보다 습관에서 먼저 드러나니까요.
그래서 저는 PMF를 이렇게 봅니다
초기 스타트업의 PMF는 고객이 제품을 좋아하는 상태가 아닙니다. 고객의 반복 업무 일부가 우리 팀의 반복 업무로 옮겨붙은 상태에 더 가깝습니다.
그 전이가 일어나면 팀은 힘들어집니다. 문의는 늘고, 수동 작업은 쌓이고, 같은 설명을 여러 번 하게 되죠. 그런데 바로 그 구간에서 문제 검증이 가장 선명해집니다.
고객이 “좋다”고 말하는 것만으로는 아직 멀 수 있습니다. 하지만 고객이 매주 같은 이유로 다시 오고, 팀이 그 요청을 더는 무시할 수 없고, 결국 그 수동 작업을 제품 기능으로 바꾸기 시작한다면, 저는 그때 PMF의 입구를 본다고 생각합니다.
초기 스타트업은 만족도를 쫓기보다, 포기할 수 없을 만큼 반복되는 일이 무엇인지 먼저 붙잡아야 합니다. 시장은 종종 칭찬보다 귀찮음의 형태로 먼저 도착하니까요.
비슷한 고민을 하고 계시다면, 지금 팀이 지난 2주 동안 반복해서 수동 처리한 요청 5개만 적어보셔도 좋습니다. 거기에 PMF의 초안이 이미 들어 있을 가능성이 큽니다.