캐치테이블에는 인턴부터 10년 차 이상의 시니어까지 다양한 연차의 PM들이 있는데요. 그중에서도 캐치테이블에서 신입으로 PM 직무를 시작해서 2년이 넘는 시간 동안 피부로 직접 느끼고 깨달은 것들에 대한 우리들의 이야기를 들려 드리려고 합니다!
캐치테이블 신입 PM 3인방을 소개합니다!
종문: 안녕하세요! 캐테서비스파트 PM 최종문입니다. 저는 캐치테이블에 입사 후 B2B향으로 캐치테이블 포스, 키오스크 신규 서비스를 런칭하고 운영하다가, 지금은 캐치테이블 앱 내 지도와 검색 도메인의 고도화를 진행하고 있어요.
지영: 저는 플랫폼서비스파트 PM 윤지영입니다. 종문님과 같이 포스 서비스의 런칭부터 운영까지 함께 하다가 지금은 도메인을 확장해서 캐치테이블 전반의 결제서비스를 책임지고 있어요.
윤정: 안녕하세요, 캐테서비스파트의 PM 황윤정입니다. 저는 지영님, 종문님과 포스 1차 런칭을 함께했고, 후에 1년 동안 웨이팅 서비스를 런칭하고 운영했어요. 지금은 캐치테이블 앱으로 넘어와 주로 매장 전시 도메인과 신사업 과제를 담당하고 있어요.
본격적인 이야기에 앞서, 이런 이야기를 해보려고 해요!
저희 셋 모두 신입 PM으로 커리어를 시작했다고 하면, 주변 후배/친구들에게 비슷한 질문을 많이 받았어요.
“PM이 도대체 뭐 하는 사람인가요?”
“스타트업에서 PM 직무를 시작하는 건 어떤가요?”
“PM이 되려면 뭘 해야 하나요?”
PM은 특히나 신입을 잘 뽑지 않는 직무이기도 하고, 주변에 정보도 많지 않아서 비슷한 고민들이 많은 것 같았어요. 그래서 저희가 스타트업에서 신입으로 PM 직무를 시작하면서 몸으로 부딪히며 배운 경험들을 나누면 좋을 것 같았어요. 저희의 이야기가 모든 케이스를 대표할 순 없지만 ‘PM 직무’와 ‘스타트업’ 두 키워드에서 아래 고민이 있는 분들이 읽어주시면 좋을 것 같아요!
- “PM이 도대체 뭐 하는 사람이야?”를 생각해본 사람들에게
- “캐치테이블의 PM은 어떻게 일할까?”를 궁금해 하는 사람들에게
- “스타트업에서 PM 직무를 시작해봐도 될까?”를 고민하는 사람들에게
PM에게 가장 중요한 역량은 ‘이거’에요
윤정: PM에게 가장 중요한 역량은 문제 정의, 실행과 설득이라고 생각해요. 진짜 문제가 무엇인지 잘 찾고, 그 문제를 해결하기 위해 어떻게든 방법을 찾고 실행에 옮기는 것을 말하는데요. 주어진 문제 상황에 대해 Why라는 물음을 갖고 하나씩 파헤치다보면 진짜 문제를 발견하게 되는 것 같아요. 그래서 늘 “왜?”에 대한 질문을 잊지 않으려고 노력하는 편이에요.
또, 문제를 잘 찾았다면 현재 상황에서 이 문제를 해결할 수 있는 최선의 방법은 무엇인지 동료분들과 논의를 통해 고민해요. 특히, 논의의 과정에서 같은 문제를 인식할 수 있도록 배경과 목적을 전달하는 설득의 과정을 중요하게 생각해요. 해당 문제에 대해 공감대를 형성해야 빠르고 정확하게 문제 해결이라는 목표 달성을 이룰 수 있기 때문이에요.
종문: 추가적으로 ‘프로덕트에 대한 애정’이 중요하다고 생각해요. 마치 부모님이 ‘내 자식이 잘 자랐으면’하는 마음과 비슷할 것 같아요. 물론 그 애정이 너무 과해서 서비스를 객관적으로 바라보지 못하면 안 되겠지만요.
- 내 자식이 더 좋은 사람이 됐으면 = 우리 서비스가 더 많은 가치를 줄 수 있으면
- 내 자식이 아프지 않았으면 = 우리 서비스가 많은 버그를 앓지 않았으면
- 내 자식이 모두에게 사랑받았으면 = 우리 서비스의 MAU가 떡…상 했으면
지영: 두 분 말씀에 공감해요. PM 채용 공고들을 보면 거의 모든 채용 공고에서 ‘고객 입장에서의 문제 정의와 문제 해결’을 필수 역량으로 꼽아요. 그만큼 PM에게 고객 입장에서 객관적으로 문제를 정의하고 해결하는 역량이 중요하다는 방증이죠.
문제 정의, 왜 중요할까요?
윤정: 문제 정의는 일종의 방향성이라고 생각해요. 문제를 어떻게 정의하느냐에 따라 만들어내야 하는 결과물이 달라져요. 그래서 문제 정의를 잘못하게 되면 전체 프로젝트가 산으로 갈 수 있고 원하는 결과를 얻기 어려울 수 있어요. 또, 불필요한 리소스를 쓰게 될 수도 있고 비효율적으로 일이 진행될 수도 있어서 초반의 문제 정의는 정말 중요하다고 생각해요.
저는 예전에 내부의 의견을 토대로 고객의 문제를 정의했고, 고객이 겪고 있는 진짜 문제를 과제 진행 중간에 확인하여 과제를 드랍했던 적이 있어요. 이 경험을 통해 ‘이게 진짜 문제가 맞을까?’라는 의심의 눈초리(?)를 갖고 꼼꼼한 문제 정의가 중요하다는 걸 배웠어요.
지영: 저도 윤정님과 비슷한 경험이 있어요. 입사 초기에 문제 정의를 만만하게 봤다가 큰코다쳤죠. 문제의 본질을 파악하지 못하면 결국은 표면적인 문제만 해결하게 되고, 같이 협업하는 메이커들을 설득하기가 정말 힘들어요. 제대로 문제를 정의하지 않고 리뷰를 진행했을 때는 서로 다른 방향의 피드백이 정말 많이 나왔던 기억이 나요. 지금 돌아보면, 문제 정의가 명확하지 않아서 기획의 목표가 흐트러졌고, 그로 인해 협업하는 분들과의 과제 배경과 목적에 대한 씽크업이 전혀 되지 않았던 것 같아요.
종문: 프로덕트의 도메인마다 각기 다른 큰 비전을 가지고 있을 수 있지만, 결국 PM은 ‘제품을 통해 고객에게 여러 형태의 가치를 선사해야 한다!’라고 생각해요. 결국 문제 정의는 지금 만들고자 하는 것이 고객에게 어떤 가치를 줄 수 있을지를 설정하는 과정이라고 생각해요. 문제 정의를 잘못한다면 결국 고객이 느끼는 가치의 임팩트가 없거나 적어질 수밖에 없어요. 어떤 가치를 줄 수 있을지가 잘 설정되어야, 실제로 고객들이 우리의 제품에서 만족감을 느낄 수 있겠죠?
우리가 캐치테이블에서 문제를 정의하는 방법
#1. VOC 수집하기
종문: 캐치테이블 앱 사용자에게 VOC가 직접 수집되는 경우가 많은 것 같아요.
메신저 알림이 울리면 바로 확인하는 채널이 있는데, 바로 사용자분들의 피드백이 쌓이는 채널이에요. B2C 사용자분들의 경우 불편함이 느껴지면 본인의 불편함을 적극적으로 표현하지 않고 바로 이탈하는 경우가 많은 것 같아요. 그렇기 때문에 사용자 피드백을 통해 불편을 즉시 감지하는 게 중요한 것 같아요.
실제로 사용자 피드백에 “앱 배지(앱 위 알림 숫자 표기) 지워지지 않아요!” 라는 VOC가 꾸준히 접수되어 올해 초에 관련 개선 작업을 진행했어요. 저는 앱 배지에 크게 신경 쓰는 타입이 아니라, 제 기준에서는 문제라고 접근 자체를 못 했을 텐데 채널에 인입된 내용 덕분에 문제를 인지하고 해결할 수 있었어요.
윤정: 저는 매장 VOC를 통해 기존 기능을 균형 잡힌 시각으로 개선할 수 있었어요. 웨이팅 런칭 시, 맨 마지막 순번으로만 미루기를 할 수 있는 ‘맨 뒤로 미루기’ 기능을 만들었어요.
사장님 입장에서 여러 고객이 계속 미루기를 하면 대기 명단을 관리하는 데 어려움이 있을 것 같아, 맨 뒤로만 순번이 미뤄지면 리스트를 확인하는데 더 용이할 것이라고 생각했어요. 물론 고객 입장에서도 어느 순번으로 미뤄야 할지 판단하기 어려우니 마지막 순번으로 미뤄지는 게 결정하는데 고민을 줄여줄 수 있을 거라고 생각했죠. 근데 정작 매장에서 ‘원하는 순서로 미루기’ 기능을 만들어 달라는 VOC가 인입됐어요.
대기가 많은 매장에서는 맨 뒤로 미루기 시, 순번이 너무 많이 밀려 고객의 이탈이 발생해 노쇼, 취소로 이어진다는 문제가 있었어요. 특히, 고객의 편의성을 최우선으로 하는 매장일수록 해당 기능에 대한 니즈가 높았고, 고객이 원하는 순서로 미루기 할 수 있도록 하여 웨이팅 과정 중 이탈을 최소화하고 궁극적으로 착석을 유도하고 싶다는 니즈였죠. 이 경험을 통해 사장님을 이해하려면 고객도 함께 이해해야 한다는 것을 배웠고 너무 일부분만 보았던 과거의 저를 반성했어요 ㅎㅎ
종문: 몇백만 사용자분들을 모두 직접 만나 뵐 순 없으니, 올해 초에는 앱 사용 빈도에 따라 사용자 군을 나눠 60명 대상으로 전화 인터뷰를 진행한 적이 있어요. 정량적인 데이터로 모든 답을 얻을 수 있으면 좋겠지만, 사용자의 실질적인 목소리를 통해 알 수 있는 것도 있기 때문이죠.
최대한 자연스럽게 인사이트를 얻기 위해 질문을 준비했던 것 같아요. 예를 들면 “주말에 친구 3명에서 성수동 맛집 찾는다고 하면, 어떻게 찾으세요?” 같이요. 실제로 여기서 얻은 인사이트들을 토대로 올해 많은 개선이 이루어졌고, 이루어지고 있어요. 진정으로 사용자만을 생각하고 그들의 목소리에 집중해야만 우리 앱이 나아가야 할 방향성을 올곧게 정할 수 있다고 생각해요.
제가 지도 도메인의 전체적인 Flow 개선하기 전에 한 유저 분께 들었던 말이 기억나네요.
“아.. 캐치테이블도 지도가 있었나요?!” → 지금은 잘 쓰고 계시죠?!
지영: B2C뿐만 아니라 B2B의 경우에도 마찬가지에요. 한 번은 포스 매장에서 한 개의 메뉴 카테고리에 100개의 메뉴를 등록하고 싶다는 VOC가 운영팀을 통해 전달된 적이 있어요. 그 당시에는 한 개 카테고리당 최대 25개 메뉴만 등록할 수 있었기 때문에, 메뉴가 25개를 초과하는 매장에서는 [주류 카테고리 (1)], [주류 카테고리 (2)]처럼 동일한 이름의 카테고리를 여러 개 만들어서 사용해야 했죠.
이 VOC를 계기로 매장들의 카테고리 등록 패턴을 살펴보니, 동일한 이름의 카테고리를 여러 개 설정한 매장이 꽤 많았어요. 캐치테이블 매장 특성상 다양한 종류의 주류를 취급하는 곳이 많았기에 이로 인해 불편함이 발생했죠. 자칫 놓칠 수 있었던 이 불편함을 VOC 덕분에 파악하고 해결할 수 있었어요.
#2. 데이터 확인하기
지영: VOC를 확인하는 것도 중요하지만 VOC만으로 문제 상황을 속단하지 않도록 주의해야 해요. VOC 이면에 숨어있는 진짜 문제를 파악할 수 있어야 하고, 그러기 위해서는 데이터를 함께 보는 것도 정말 중요하거든요.
웨이팅 서비스의 블랙 리스트 관리 기능을 검토했을 때가 생각이 나요. 어떤 매장에서 외국인 고객이 웨이팅을 하는 경우, 연락처가 없어서 임의의 번호(예: 010–0000–0000)로 웨이팅을 등록하고 호출하는 사례가 발생했어요. 그 번호가 실제로 존재하는 번호여서 번호 주인으로부터 강성 컴플레인이 여러 차례 들어왔죠. 결국 번호 주인분은 “내 번호가 매장에 등록되지 않도록 처리해달라”는 요청을 하셨어요.
그런데 운영팀을 통해 유사한 VOC를 추가로 수집해 보니, 총 건수는 10건도 안 되었어요. 혹시나 하는 생각에 규칙성이 있는 번호로 등록된 대기 등록 수 데이터를 함께 살펴보았는데, 건수가 미미했죠.
강한 VOC가 여러번 들어왔다고 해서 시급한 과제라고 착각할 수 있었지만, 실제로 그렇지 않았어요. 게다가 고객님이 요청하신 블랙 리스트 기능을 개발하지 않고도, 매장에 올바른 사용 방법을 안내함으로써 문제를 쉽게 해결할 수 있었어요. VOC 수집도 정말 중요하지만, 데이터를 함께 확인하여 과제 우선순위와 해결 방향을 판단하는 것도 정말 중요하다는 걸 깨달았어요.
윤정: 저도 지영님처럼, 문제와 관련된 데이터들을 참고하는 편이에요. 데이터는 누구에게나 확실한 설득의 근거가 되어줄 수 있기 때문에 중요한 것 같아요. 초대장 발송률, 수락률을 높이기 위해 게스트 발송 기능을 만들 때, 추가적인 방안을 모색하기 위해 기존 초대장 발송/수락 데이터를 분석했어요. 전체 발송 건에서 100% 수락하는 비중 데이터를 확인했는데 40%밖에 안 되더라고요. 그래서 방문 1일 전 100% 미수락 예약 건에 한해 예약자에게 리마인드 알림 톡을 발송하는 기능을 추가하는 것을 제안했어요. 덕분에 발송 및 수락률을 높이는 데 도움이 되었던 것 같아요.
또, 배포 후에 성과 지표를 꼼꼼히 확인하려고 하는 편이에요. 우리가 해결하고자 하는 문제가 맞았는지, 해결 방안이 적절했는지를 확인하기 위함이에요. 특히 저는 배포 전후 데이터를 비교하고 인사이트를 정리해서 함께 작업했던 담당자분들께 공유를 꼭 하려고 노력해요. 우리의 가설이 맞았는지, 열심히 만든 기능이 어떻게 작동하고 있는지를 전달하고 추후 개선 작업까지 동기 부여할 수 있어서 중요하다고 생각해요.
종문: 데이터는 사용자들의 이용 패턴을 기반으로, 가장 직관적으로 문제에 접근하는 수단으로 쓰일 수 있는 것 같아요.
지도 관련 개선 사항을 도출할 때 어떤 것부터 어느 수준으로 개선해야 할지 다소 막막한 상황이 있었어요. 당시 낮은 접근성과 불편한 사용성으로 많은 사용자가 이동하진 않았지만, 우선 사용자들이 어떻게 쓰는지를 확인하기로 했어요. 그리고 아래와 같은 과정으로 문제를 정의할 수 있었죠.
- 지도 검색 시 불러오는 매장 수
2. 불필요한 지도 확대 과정 생략
*참고: 지도에는 레벨이라는 개념이 존재해요.
- 지도 확대 → 레벨이 낮아짐 (13레벨 → 1레벨)
- 지도 축소 → 레벨이 높아짐 (1레벨 → 13레벨)
데이터를 보니 사용자들이 불편해하고 있을 부분이 뚜렷하게 보였고, 이를 토대로 비교적 간단한 방식으로 문제를 해결할 수 있었어요. PM은 ‘나의 관점’보다는 ‘데이터의 관점’을 기본적으로 잘 장착해야 한다고 생각해요. 내 경험만으로 제품을 만들면 ‘나’에 특화된 제품이 만들어질 테지만, 사용자의 데이터를 기반으로 제품을 만들면 ‘사용자’에 특화된 제품이 만들어질 테니까요!
#3. 현장의 목소리 듣기
저희 셋 모두 B2B 도메인에서 직무를 시작했다 보니 사장님들의 목소리를 듣기 위해 직접 매장을 발로 뛰었던 적이 있어요. 그 이야기를 한번 해볼까요?
지영: 사무실 자리에 앉아서 수집되는 VOC와 데이터만으로 모든 것들을 판단하기에는 한계가 있어요. 현장에서 발로 뛰며 보고 듣는 것들이 판단의 근거가 되어주는 경우가 정말 많거든요.
포스 서비스를 런칭하고 얼마 안 됐을 때 과제 우선순위에 대한 논의를 정말 많이 했어요. 하지만 갓 런칭한 신규 프로덕트는 사용자 데이터도 충분하지 않고 VOC도 많지 않아서 논의가 직감에 의존하기 쉬웠죠. 결국 향후 과제의 우선순위와 임팩트를 판단하기 위해서는 현장의 목소리를 들어야겠다는 결론에 이르렀어요.
현장에 나가기 전, 다같이 회의실에 모여 ‘이런 기능이 있다면 우리 포스 서비스를 사용할 것이다’라는 주제로 브레인스토밍을 했어요. 그 과정에서 나온 몇 가지 기능을 추리고 다듬어 매장에 보여줄 자료를 준비했죠. 그렇게 약 200여개의 매장을 돌며 각 기능들에 대한 반응을 살피고 점수화했어요.
결과는 제 예상과 달랐어요. 개인적으로 예약 가맹 매장 특성상 임팩트가 클 것이라고 예상했던 ‘코스 메뉴 관리 기능’에 대한 반응은 약했던 반면, ‘예약자 데이터와 주문/결제 데이터의 연동’에 대한 반응은 훨씬 더 컸어요. 파악된 매장의 니즈를 기반으로 포스 업무에 대한 과제의 우선순위를 식별하고 로드맵을 수립할 수 있었어요. 직관만으로는 정답을 찾기 어렵다는 것을 또 한 번 느꼈던 값진 경험이었어요.
윤정: 캐치테이블 웨이팅을 런칭할 때 몇몇 매장들을 돌아다니며 인터뷰를 진행한 적이 있어요. 인상 깊었던 것은 매장에서 운영하는 테이블마다 회전율이 다르다는 점이었어요. 또, 포장과 매장 취식 유형별로 회전율이 달라 매장에서는 각각 대기표를 주거나 대기 줄을 관리하고 있었어요. 대기 줄을 한 줄이 아닌 여러 줄로 나눠 관리하고자 하는 니즈가 있다는 점을 확인하고 ‘유형별 웨이팅 설정 및 관리 기능’을 런칭 스펙에 추가했어요. 직접 현장에 나가지 않았다면 알기 어려웠던 문제를 발견할 수 있었고, 타사에서는 제공하지 않는 경쟁력 있는 기능을 만들 수 있었어요.
윤정: 또, 저는 한동안 주말마다 웨이팅 매장을 돌아다니는 게 나름의 취미였는데요ㅎㅎ 맛집 탐방도 하고 매장에서 고객과 사장님이 어떻게 저희 서비스를 쓰는지 구경도 하고.. 일석이조 취미생활이죠 ㅎㅎ 덕분에 실제 현장에서 어떤 어려움이 있는지, 어떤 패턴으로 웨이팅을 등록하고 매장에 입장하는지 사무실에서 혼자 상상하며 기획하던 유저 스토리를 현장에서 직접 확인할 수 있었어요. 유저와 현장에 대한 이해도도 깊어져서 이후에 개선 과제 진행할 때도 큰 도움이 되었어요.
종문: 포스 서비스 신규 런칭을 준비하던 때가 기억에 남아요. 알바할 때 잠깐 써보기만 했던 포스인데 ‘내가 잘 만들 수 있을까..?’라는 두려움이 앞섰던 것 같아요.
그럴 때는 정말 현장의 목소리가 도움이 많이 됐어요. 식당이나 카페나 결제가 필요한 곳을 가든 웬만한 곳에는 포스가 있잖아요? 포스기가 보이는 자리가 있다면 거기에 앉기도 하고, 친구끼리 밥을 먹어도 늘 제가 대표로 계산하면서 사장님들의 결제 패턴이 어떻게 되는 지를 봤어요.
기존의 PC형 포스는 화면이 넓으니, 대부분 테이블을 찍고 별도의 Depth 없이 카드 결제 버튼을 누르는 형태를 띠고 있었어요. 그러나 저희는 태블릿 앱으로 포스를 만들고 있었기에 분할 결제/포인트/할인 등을 제공하기 위해 당시에는 화면 이동이 불가피한 것으로 보였죠. 그러다 어느 날 ‘대부분 손님이 다 카드 한 장으로 결제하네..? 그러면 카드 결제만이라도 Depth 없이 하면 되잖아?’라는 생각이 든 거죠!
그렇게 캐치테이블 포스의 ‘카드 즉시 결제’ 기능이 탄생했어요! 포인트/할인/분할 결제 없이 바로 카드로 결제한다면 ‘카드 즉시 결제’ 버튼을 누르고 결제를 완료할 수 있어요. 태블릿 포스의 한계는 분명 존재했지만, 현장에서 답을 찾고자 계속 고민했기에 단순하게 문제를 풀 수 있었던 것 같아요.
모든 것의 시작은 문제 정의에서부터
결국 회사와 도메인을 막론하고 PM에게 가장 중요한 것은 ‘문제 정의’라고 해도 과언이 아니에요. 문제 정의는 첫 단추를 끼우는 과정과도 같아서 문제 정의가 잘 되어야 그다음의 기획부터 구현까지의 모든 과정이 매끄러울 수 있어요.
자, 그러면 문제를 정의했다면 문제를 해결해야겠죠?
다음 2편에서는 저희가 어떻게 문제를 해결하는지에 대한 방법을 가지고 돌아올게요.