PM, PO, 기획자가 각각 어떻게 다른지 등에 대해서는 갑론을박이 많고 많은 사람들이 글을 쓰던데, 나중에 나의 의견도 한번 써보겠다. 현재 나의 회사에서의 직무 이름이 PO니까, 통칭해서 PO(Product Owner)라고 하고, 본인이 맡는 프로덕트의 성격이나 성장단계에 따라서 PO의 역할이 어떻게 다를지에 대해서 써보기로 했다.

시작(PMF를 찾기 전)과, 성장(Growth 단계), 그리고 고도화 단계로 나누어질 수 있을 것 같다. 시작 단계라고 할 수 있는 PMF를 찾기 전부터 설명하겠다.

재작년쯤이었나? 토스에서 진행한 PO session이라는 강의를 들은 적이 있었다. 엄청 혜자스러운 강의였는데, 각 회사의 PM, PO로부터 신청을 받고, 토스의 PO들이 일 하는 법에 대해서 몇 주말 동안 대표님과 토스의 PO분들이 직접 겪은 내용을 공유해 주셨었다. 이때 토스 대표님은 회사의 첫 PO는 대표라고 하셨다... PMF를 찾기 전의 PO의 역할은 단 하나라고 생각한다

서비스가 망하기 전에 PMF를 찾는 것

본인이 대표이면, 회사 돈 다 떨어지기 전인 거고, 대표가 따로 있는데 PO인 거면 회사에서 계획한 자금이 떨어지기 전, 혹은 회사에서 '됐다'라고 하기 전까지 찾는 것이 목표일 것이다(토스에서는 PO가 '그만해야겠다'라고 할 때까지라고 한다) 만약 PMF를 못 찾았는데, '고도화하면 사용자가 많아지고 돈을 많이 벌 것이다'라고 생각하시는 분들이 있을 텐데, 10중 8-9는 고도화하다가 애매하게 조금씩 성장하다가 말 것이다.(이게 회사의 유일한 프로덕트이면 좀비기업 돼서 정부 지원금 타 먹거나 외주 하면서 회사가 버텨지거나, 다른 돈 버는 서비스가 있는 회사이면 '좀 먹는 서비스'로 이러지도 저러지도 못하고 있겠지... '이번 업데이트하면 사용자가 많아질 거야'..라는 희망을 품으면서..)

그럼, PMF를 찾기 위해서는 어떻게 해야 하나?

PMF를 찾기 위해서 해야 하는 행동은 결국,

1. 고객을 찾고

2. 그들의 욕구나 필요성을 찾아서

3. 그들에게 어떤 가치를 제안할지 정의하고

4. MVP를 만들어서 고객에게 검증하면서

5. 가설-> 실험-> 학습-> 학습된 거 바탕으로 또 가설-> 실험-> 학습 이렇게 계속 이터레이션을 돌리는 거고, 그러다가 서비스의 리텐션이 40%가 넘거나, 우리 서비스가 없다면 너무 고통스럽다고 하고 그러다가 여기저기 자연스럽게 추천하는 고객이 많아지면 PMF를 찾았다고 한다고 한다.

내가 직접 'PMF를 찾았다'라고 확신 든 경험은 없지만, 그렇게 찾으신 대표님들의 이야기를 들어보면, PMF를 찾았는지 안 찾았는지 의심할 필요도 없이, 고객이 밀려 들어서 정신을 차릴 수 없을 정도라고 한다. 끝없이 쏟아지는 고객들로부터 욕먹고 대응하고, 개선하고 그러느라...

PMF를 찾기 전까지는 '프로덕트', '비즈니스'가 아닌, 아이디어에 대한 시장 검증이라고 봐야 한다. 우리의 목표는 '성장률'이 되어야 하고, 주간 성장률이 7% 이상이 될 때까지 계속 테스트하고 실험을 해서, 하루 만에도 아이디어를 생각해서 구현해서 검증을 해야 한다고 한다. 언제 프로덕트가 바뀔지 모르니, 엄청난 문서가 필요한 게 아니라 내부 팀원들끼리 빠르게 공유하고 실험 결과를 기록해서 다음 스텝으로의 액션 아이템으로만 만들면 될 것이다. 엄청난 코딩을 하고, 아름다운 기획서를 통해서 멋진 기능과 UI를 세련되게 하는 것도 좋지만, 그러면 늦다. 대부분의 스타트업이 시작한 지 얼마 안 되었다면, 그거보다 중요한 것을 해야 한다. '고객이 진짜 원하는 무언가'를 최대한 빨리 찾기 위해 테스트하고 검증하는 것.

예를 들면 배달의 민족 초창기에는 앱으로 주문하면 회사 직원이 주문한 거 보고 그대로 업체에 전화해서 주문을 했다던가, 리멤버에서 명함을 찍으면 사람이 직접 입력을 했다던가 하는 등의 일이다. 어떻게든 최대한 빠르게 고객의 니즈를 최대한 빠르게 검증할 수 있는 방안을 마련하는 것.(보통은 개발보다 수기로 하는 게 많아질 것이다)

여기서 제대로 PMF를 찾으면 사람의 손으로 감당이 안될 것이고, 이런 것을 미리 예측하거나, 허덕이면서 프로덕트화 시켜서 시스템화시키는것이 PMF 찾고 나서 해야 할 것이다. 대부분 성장하는 스타트업에서 '시스템이 없다' 이런 이유 중 하나는 저런 이유도 있다고 생각한다. 시장이 어떻게 될지 모르는데, 어떻게 미리부터 시스템화 다 시켜두고 사람 척척 미리 다 뽑아서 예측하겠는가? 이렇게 고객의 요구사항에 허덕이면서 그렇게 욕하면서도 고객이 찾고, 그러다 보면 우선순위가 높은 기능부터 시스템화하면서 서비스가 성장하는 것이지. 그리고 개발자분들께도 양해를 구해야 한다... '당신은 아름다운, 나 다음에 들어올 개발자를 위해서 깔끔한 코드를 만들고 싶으시겠지만 지금 우리 회사는 그럴때가 아니라고..' 스파게티 코드라고 하나? 빨리 여러개를 테스트 하고 검증할수 있도록 해야 한다.

해당 역할을 대표가 하든, PO가 하든, 기획서를 쓰고, 스프린트를 돌리고, 에자일 방법론을 도입하고, 무슨 문화를 만들고 이런 거는 다 도구일 뿐이다.. PMF 못 찾으면 결국 회사의, 내 프로덕트의 존속을 위협할 테니...

그런데, 많은 분들은 이런 고민을 할 수도 있다. '우리가 준비하는 서비스는 B2B 서비스이고, 하나의 기능으로만 승부하는 게 아닌, 여러 가지가 제대로 기능으로 나왔을 때에만, B2B 고객으로부터 큰 호응을 얻고, 그들이 쓸 것이라고...

📌 그럼, B2B 서비스에서 PMF를 찾으려면 어떻게 해야 하나?

사실, B2B 서비스는 구축하기 전부터 PMF를 찾고 가야 한다고 생각한다. 일반적인 B2B 서비스이면, 그 업계에서 쓰고 있는 많은 서비스들이 있을 것이다. 그중에는 분명히 '이런 점이 너무 불편해' 하는 것이 있을 것이고, 그것만 해결해주면 내가 만든 서비스로 다들 갈아탈 것이라고 생각하시는 분들이 많은 것 같다. 그래서 어떻게 외주를 써서 본인들이 원래 쓰던 서비스와 비슷하면서 좀 더 개선된 기능 몇 가지를 붙여서 1년 동안 만들어서 '짠' 하고 시장에 내놓으면 아무도 안 쓰는 것이다. 보통은 그렇게 만든 개선된 서비스가 흔히들 이야기하는 '있으면 좋은 비타민이지만 안 먹으면 내가 너무 힘든 진통제가 아니기 때문'이다.

그렇기 때문에 접근을 아주 신중히 해야 한다.

사실 B2B 서비스는 B2C 서비스와 다르기 때문에 서비스의 구매 플로우가 다른 경우가 많다. 서비스의 사용자가 구매결정권자가 아닌 경우도 많고, 또 서비스에 적응이 되면 새로운 것에 적응하는 것이 더 귀찮아서 그냥 쓰게 되는 경우도 많다. 기업에서 원래 쓰는 솔루션을 실무자가 다른 것으로 바꾸려면 얼마나 많은 문서와 설득 과정을 거칠 것인지 생각해보면 된다. 예를 들어 슬랙보다 조금 좋은 커뮤니케이션 툴이 나왔다고 바로 바꾸겠는가? 이미 슬랙에 세팅 다 되어있는데?

결국, 해당 B2B 서비스업의 구매결정권자를 파고들거나, 한번 우리 서비스를 쓰면 정말 못 빠져나올 만큼 프로덕트를 아주 편하게 쓸 수 있게 만들거나, 그 프로덕트를 사용함으로 인해서 얻게 되는 경제적 이득이 상당히 크거나, 또는 그 프로덕트를 쓰게 됨으로 인해 다른 큰 시너지를 얻어야 하는데, 보통 그 이득이 10배가 되어야 움직인다는 말이 있더라.

예를 들면 A라는 서비스를 활용하면 무언가를 달성하는데 클릭을 10번 하고 화면을 5번 이동해서 60초 걸리는데, 우리 서비스를 활용하면 원버튼으로 5초 만에 된다던가.. 근데 그게 아주 자주 사용된다던가... 그런데 그것을 통해서 실수도 줄이게 된다던가... 문제는 그렇다고 하더라도, 회사 입장에서는 '그거 그냥 네가 60초 걸려서 하면 되잖아'라고 생각할 수 있는 것이다. 결국 회사에게 그것을 통해서 숫자적으로 눈으로 볼 수 있는 이득이 되어야지 옮길 것이다. (아니면 영업을 엄청 잘해서 그냥 따오던가)

그게 뭔지는 나도 잘 모르겠다. 하지만 혹시 당신이 어떤 분야의 B2B 서비스에서 그러한 분야를 캐치했고, 그 분야의 플레이어들에게 이것을 해결해주면 우리 서비스를 쓸 수밖에 없는 것이다.라고 판단했다면, 아마 프로덕트를 만들고 싶을 것이다. 만약 이런 회사에 PO로 일을 한다면, 첫 목표는 MVP 출시 후 피드백 -> 개선이 될 것이며, B2C 서비스보다는 MVP 출시까지는 시간이 꽤나 걸릴 것이고, 일단 워터폴로 요구사항 분석-> 설계-> 구현-> 배포를 해야 할 것이며, 이후 점진적 개선을 고객과 함께 고객의 문제가 큰 부분부터 개선시키면서 발전하게 될 것이다.

원래 IT 프로덕트를 하던 전문가인데, 어떤 기회로 해당 분야를 캐치했고, 그 분야의 꼭 해결하고 싶은 고통(돈을 주고라도, 혹은 솔루션을 바꾸더라도)을 발견했다면, 일단 그 분야의 기존 대체제는 무엇이고, 그럼에도 불구하고 그 고통이 해결 안 되는 이유는 무엇이고, 그것이 해결되었을 때 소비자가 얻는 가치, 그리고 그것을 대체시키는 프로덕트를 만들었을 때 기대수익도 어느 정도 예상하고 가야 할 것이다. 진짜 그 고통을 느끼는 사람들 인터뷰도 많이 하고, 기왕이면 구매의향서라도 받아놓고 시작하면 좋을 것이다. 프로토타입을 계속 만들면서도 계속 인터뷰하고 그러면서 개선해 나가면서, 이 역시 뒤에서는 최대한 수동으로 또는 다른 툴을 통해서 해결할 수 있는 방안을 계속 만들면서 해야 할 것이다. 최대한 빠르게 만들어서 고객들에게 제공하고 욕먹으면서 계속 고치는 것이다. 위에서도 이야기했지만, 그냥 만들면 아마 아무도 안 쓸 것이다. 1. 그것을 씀으로 인해 얻는 이득이 체감적으로라도 10배가 되게 하던가 2. 영업을 엄청 잘해서 따와야 한다.

만약, 당신이 해당 업의 전문가이고, 그 고통을 스스로 많이 느꼈고, 그것이 IT로 해결되었을 때 정말 그 업계가 바뀔 정도의 큰 고통과 솔루션이라고 한다면, 일단 스스로를 돌아봐야 한다. 너무 그 아이디어에 매몰된 것은 아닌지, 나 같은 고통을 느끼는 사람이 많은지..

그러고 나서도, 이것을 어떻게 해결할 것인지를 고민해야 할 것이다. 만약에 그 솔루션이 개발 외주 몇 명 붙여서 만들어서 될 정도의 서비스라면, 왜 그전엔 안 했을까? 내가 천재라서 이런 솔루션을 우리 업에서 가장 처음으로 문제를 느꼈고, 나의 행동력이 최고라서 나만이 이것을 직접 구현할 생각을 한 것인가?

대부분의 이런 분들이 생각하는 건, 프로덕트를 일단 완벽하게 만들어서 출시하면 아무 문제가 없을 것이고, 그때부터는 운영인원 몇 명과, 이슈 생겼을 때 해결해줄 개발인원(외주이든 내근이던) 몇 명이 있으면 알아서 잘 굴러가고, 잘 써줄 것이라고 생각한다. 일단 내가 해당 업의 전문가라면, 해당 문제를 해결하기 위해 1. 외주를 주고 관리해서 잘 만들다 2. 회사에 새로 사람을 채용해서 팀을 구성한다(내제화) 이 2가지 방안 중에 하나를 선택할 것이다. 나 스스로는 아직까지 이 1,2번 두 가지 다 제대로 워킹하는 것을 보지는 못했다. 내가 모를 뿐, 찾아보면 있을 수도 있다.

이주형 PM님이 쓰신 글입니다!