지난 글에서 제품을 이해하는 세일즈가 Feature Factory를 막는 필터라고 썼는데, 쓰고 나서 계속 걸리는 게 있었어요.
매출 압박 아래에서 세일즈가 제품의 가치까지 신경 쓸 수 있느냐? PM도 기능 출시 압박을 똑같이 받고 있는데, 고객의 문제가 풀렸는지까지 책임질 수 있느냐?
솔직히 "고객에게 도움이 되었는가?"라는 질문을 매주 파이프라인 리뷰에서 던지는 조직은 제가 본 적이 거의 없습니다. 다들 동의해요. 고객이 제일 중요하다고. 근데 동의하는 것과 매주 월요일 아침에 그 질문을 실제로 던지는 건 완전히 다른 일이거든요.
먹고살기 바빠서, 이번 분기 매출 채워야 해서, 로드맵에 넣기로 한 기능 일정 맞춰야 해서 — 이 질문이 밀려납니다. 밀려난 줄도 모른 채 그냥그냥 흘러가요. PM과 세일즈에서 이게 가장 선명하게 드러납니다.
PM KPI는 세 가지 덩어리로 나뉩니다: 비즈니스, 고객, 개발 효율
PM KPI는 보통 세 덩어리로 나뉩니다.
첫 번째는 비즈니스 성과 지표입니다. MRR, ARPU, 매출 성장률, CLTV. 제품이 돈을 벌고 있느냐를 봐요. 경영진이 가장 좋아하는 숫자들이고, 분기 리뷰에서 제일 먼저 나오는 슬라이드죠.
두 번째는 고객 engagement 지표입니다. DAU/MAU, Retention Rate, Churn Rate, NPS. 고객이 실제로 쓰고 있고 만족하느냐를 봐요. 이 숫자를 매주 챙기는 PM이 있는 조직은 제 경험상 드뭅니다.
세 번째가 제품 개발 효율 지표입니다. Time to Market, Feature Adoption Rate, Development Cycle Time. 만든 기능이 제때 나왔느냐를 봐요. 그리고 대부분의 PM은 이 세 번째 덩어리로 평가받습니다.
세 번째 덩어리가 문제의 시작점입니다.
PM과 세일즈는 같은 구조로 Feature Factory에 빠집니다
Marty Cagan은 SVPG에서 20년 넘게 실리콘밸리 제품 조직들을 코칭해온 인물입니다. 그가 반복적으로 지적하는 게 있어요. 대부분의 회사에서 PM이라는 직함을 달고 있는 사람들이 실제로는 프로젝트 매니저 역할을 하고 있다는 겁니다. 그는 이걸 "Product Management Theater"라고 불러요.
Feature Team에 있는 PM은 경영진이나 세일즈 리더가 정해준 기능 목록을 받아서 일정에 맞춰 출시하는 사람입니다. 이 PM의 성과 지표는 세 번째 덩어리 — Time to Market, Roadmap Delivery Rate, Development Cycle Time — 로 매겨져요. 얼마나 빨리, 얼마나 많이 찍어냈느냐가 곧 성과죠.
매출 압박 아래에서 세일즈가 "고객이 이 기능 달래요"라고 넘기면, PM은 검증 없이 백로그에 넣고 빨리 출시하는 게 자기한테 합리적인 행동이 됩니다. ICP 밖의 피드백에 흔들려 기능을 추가하면 누구도 만족시키지 못하는 제품이 되는 구조입니다.
경주마 트랙 위에 있는 건 세일즈만이 아닙니다. PM도 같은 트랙이에요. 인센티브 구조가 두 역할 모두에게서 "고객에게 도움이 되었는가?"를 물을 여유를 빼앗고 있습니다.
좋은 PM과 좋은 세일즈는 같은 KPI를 봅니다: Retention, Churn, CLTV
그러면 경주마 트랙에서 내려와서 이 질문을 실제로 던지는 PM은 어떤 지표로 평가받을까요.
Teresa Torres는 Product Talk에서 business outcome(매출, 수익)과 product outcome(Retention, Churn, NPS, Feature Adoption)을 나눕니다. 매출은 business outcome이고, 제품이 고객의 문제를 풀고 있는지를 보여주는 건 product outcome이에요. "고객에게 도움이 되었는가?"에 답하려면 product outcome을 봐야 합니다.
Cagan도 같은 맥락에서 기능 출시 이후까지 outcome에 책임지는 것이 어렵다고 썼습니다. 기능을 만들어서 내보내는 건 쉬워요. 그 기능이 고객의 문제를 풀었는지까지 책임지는 건 어렵죠. Nielsen Norman Group의 분석에 따르면, Cagan이 말하는 empowered product team — 만들 기능이 아니라 풀어야 할 문제를 부여받고 outcome에 책임지는 팀 — 은 현실에서 대부분의 회사가 구현하지 못하고 있습니다.
"고객에게 도움이 되었는가?"를 묻는 PM이 보는 지표는 Retention(고객이 계속 쓰고 있느냐), Churn(떠나고 있느냐), NPS(만족하느냐), CLTV(장기적으로 얼마나 가치가 있느냐)입니다. 기능을 몇 개 출시했느냐가 아니라, 출시한 기능이 고객의 문제를 풀어서 비즈니스에 기여했느냐를 묻는 거예요.
세일즈 쪽도 같습니다. 매출 압박에 눌려서 아무 딜이나 따오는 세일즈는 ICP 안 맞는 고객을 들여보냅니다. 그 고객들의 요구가 제품 방향을 틀어버리죠. 제품을 이해하는 세일즈가 보는 건 뭘까요. 이 고객이 계속 남아 있느냐(Retention), 떠나고 있느냐(Churn), 만족하느냐(NPS), 장기적으로 얼마나 가치가 있느냐(CLTV). 같은 질문을 던지는 PM이 보는 지표와 같습니다.
경주마 모드 | "고객에게 도움이 되었는가?"를 묻는 역할 | |
|---|---|---|
PM | 기능 출시 속도, 백로그 소화량 | Retention, Churn, NPS, CLTV |
세일즈 | 이번 분기 매출, 딜 클로징 수 | Retention, Churn, NPS, CLTV |
다만 Retention, Churn, NPS, CLTV는 전부 후행 지표(lagging indicator)입니다. Retention이 떨어지는 걸 확인한 시점에는 이미 고객이 나간 뒤예요. PM 쪽에서는 Feature Adoption Rate(신기능을 실제로 쓰는 비율)가 Retention의 선행 지표가 되고, 세일즈 쪽에서는 ICP fit 기반의 qualification rate(검증된 딜만 파이프라인에 넣는 비율)가 Churn의 선행 지표가 됩니다. 선행 지표까지 함께 봐야 "고객에게 도움이 되었는가?"가 사전 판단 기준으로 작동합니다.
Mind the Product에 실린 한 글에서 한 회사가 제품 매출을 PM팀의 유일한 성과 지표로 만든 사례가 나옵니다. PM 전원이 교체됐고, 교체된 인원의 절반이 또 교체돼서 총 150%가 교체됐대요. 과정은 험악했지만, 매출은 올라갔습니다. 그리고 그 과정에서 발견한 게 있어요. 세일즈가 프로덕트에 의존하는 정도가 그 반대보다 훨씬 크다는 것, 그리고 세일즈팀이 특정 제품 매출에 연결된 KPI를 가질 때만 진짜 alignment가 일어난다는 겁니다.
두 역할의 KPI가 수렴하는 지점은 "고객의 문제가 진짜 풀렸는가"입니다.
세일즈가 ICP가 아닌 딜을 거절할 수 있어야 Feature Factory가 멈춥니다
여기까지 읽으면 "그래, 고객한테 도움이 되었는지를 물어야지"까지는 이해가 되는데, 현실에서는 아무것도 안 바뀌거든요. PM과 세일즈가 같은 질문을 던져야 한다는 걸 아는 조직도 여전히 Feature Factory를 만듭니다. 아는 것과 실행하는 것 사이에 벽이 있습니다.
세일즈 쪽 벽부터 볼게요. 투자에서 미실현 이익에 취하는 심리와 B2B 세일즈에서 리드를 딜로 착각하는 구조가 동일합니다. 대기업 로고가 박힌 리드가 들어오면 검증 없이 리소스를 몰아넣고, PM한테 "이 기능 만들어야 해요, 대기업이 원해요"라고 넘깁니다. PM은 그 압박을 거절할 인센티브가 없어요. "이 기능을 추가하면 고객에게 도움이 되는가?"를 물을 틈이 없습니다. 여기서 Feature Factory가 시작됩니다.
이 패턴을 끊으려면 세일즈가 ICP 밖 딜을 disqualify할 수 있어야 합니다. "이 딜은 우리 제품 방향과 안 맞습니다"라고 말할 수 있는 세일즈가 있어야 PM이 기능 출시 압박에서 벗어나요. Disqualify가 세일즈에서 가장 어려운 판단인 이유는 이번 분기 매출을 포기하는 결정이기 때문입니다. 하지만 ICP 안 맞는 딜을 받아서 제품을 틀어버리면, 다음 분기 매출까지 같이 망가집니다.
PM이 고객을 모르면 Feature Factory는 멈추지 않습니다
PM 쪽 벽도 있습니다. 대부분의 제품팀은 세일즈팀이 쓰는 CRM 계정조차 없어요. 고객과의 대화에 담긴 맥락에 접근 자체를 못 합니다. 세일즈팀도 바쁜 일정 속에서 미팅 내용을 기록하고 정리하는 것조차 벅차요. "고객이 긍정적인 반응을 보였다"는 한 줄 미팅 노트가 PM에게 전달되고, PM은 그걸로 다음 분기 로드맵을 짭니다.
"우리는 정기적으로 유저 인터뷰를 해요"라고 말하는 조직도 많은데, 유저 인터뷰는 준비된 무대이고 세일즈 미팅은 실전입니다. 돈을 내고 제품을 사려는 순간에 고객이 던지는 질문과 우려사항에는 제품의 진짜 약점이 드러나요. 그 순간을 제품을 만드는 사람의 관점에서 직접 해석하는 경험은, 그 어떤 데이터 분석이나 미팅 노트로도 대체가 안 됩니다. 데이터는 '무엇이' 일어났는지를 보여줄 뿐, '왜' 일어났는지는 설명하지 못하거든요.
그래서 PM이 세일즈 미팅에 동석하는 수준이 아니라, 잠재 고객과의 대화부터 계약 성사까지 직접 경험해봐야 합니다. Cagan도 자기가 코칭하는 신입 PM에게 고객 30곳을 방문하기 전에는 단 하나의 의사결정도 허용하지 않았다고 써요. 고객에 대한 직접 지식이 있는 PM만이 세일즈가 가져온 요청에서 "이건 이 고객만의 문제"와 "이건 ICP 전체의 문제"를 구분할 수 있습니다.
벽과 해결 방향은 이 두 가지입니다.
세일즈 쪽: ICP 가 아닌 딜을 거절할 인센티브가 없다 → 세일즈 인센티브를 Retention/Churn에 연결
PM 쪽: 고객 접근권 없이 feature 목록만 받는다 → PM에게 고객 직접 접촉 보장, outcome 기반 평가
둘 다 인센티브 구조를 바꾸는 문제입니다. 구조가 바뀌어야 합니다.
Feature Factory를 멈추는 질문은 하나입니다
이 글에서는 PM과 세일즈를 다뤘지만, "고객에게 도움이 되었는가?"는 직군의 경계 안에서만 유효한 질문이 아닙니다.
개발자가 새로운 아키텍처를 도입할 때, 디자이너가 UI를 리뉴얼할 때, 마케터가 캠페인을 기획할 때 — 모든 의사결정의 끝에는 이 질문이 들어가야 합니다. "이 선택이 고객의 비즈니스를 더 나아지게 하는가? 고객의 일이 더 효율적으로 바뀌는가?" 자신 있게 예스라고 답하고, 어떻게 그렇게 되었는지 설명할 수 있어야 합니다.
당연한 말처럼 들리죠. 근데 당연한 것들이 먹고살기 바쁘면 제일 먼저 밀려납니다. 매출 압박이 이 질문을 밀어내고, 기능 출시 일정이 이 질문을 밀어내고, 밀려난 줄도 모른 채 분기가 지나갑니다. Feature Factory를 만드는 건 PM이 아니고 세일즈가 아닙니다.
이런 질문을 할 수 없게 만드는 조직의 구조가 문제인거죠.
다음 분기 파이프라인 리뷰에서, 다음 스프린트 플래닝에서, 이 질문을 한 번만 던져보세요. "그래서 이게 고객에게 도움이 되었는가?" 답이 바로 안 나오면, 거기가 시작점입니다.