성장단계 IT 회사의 PM, PO 기획자의 역할
Growth 단계 에서의 PO의 역할
운 좋게, PMF를 찾았다거나, 찾은 지 얼마 안 된 스타트업에 합류했다고 치자!
스타트업이라면, 대충 시리즈 B, C 정도의 투자를 받았을 거고 이미 캐시카우가 있는 와중에 신규 프로젝트라고 하면, 이제 회사에서 여기에 인력을 더 투입하려고 할 것이다.
당장 회사 문 닫거나 서비스 접을 고민은 안 해도 된다는 것이다.(물론, PMF를 찾았다고 착각하면서 꾸역꾸역 버티면서 외부 투자유치를 받는 스타트업도 있을 수 있고, 큰 회사의 신규 프로젝트가 있을 수 있다.)
고객들은 계속해서 우리 서비스 욕을 할 것이고, 사내에서는 다양한 사업모델에 관심이 많을 것이다.
또, 우리가 찾은 사업모델을 카피하려고 하는 경쟁사가 슬슬 나올 것이다.
번개장터에서도 들어보니, 비슷한 중고거래 서비스하겠다고 지나간 망한 업체가 30개가 넘는다고 했었다.
여기에서 중심을 잘 잡아야 한다.
이떄즘 되면, 서비스에 따라서 PO(혹은 기획자)가 한 명이 아닐 것이다.
대충 (1)일반 고객이 쓰는 앱/웹 프런트 영역을 맡은 PO와, (2)회사 내 직원 또는 비즈니스 파트너가 활용하는 어드민 영역을 맡은 PO, 또 (3)기존 서비스에 신규 사업 영역을 맡은 PO 정도로 나누어질 수 있을 것 같다.(항상 이야기 하지만 회사에 따라 기획자 또는 PM이라 부를수도 있다)
물론 서비스의 특성에 따라서, 일반 고객이 활용하는 영역이 없으면, 비즈니스 파트너가 활용하는 어드민만 있을 수도 있고, 두 개를 한 명의 PO가 할 수도 있고, 아직 신규 사업 영역을 맡은 PO가 없이 BD(사업기획)하는 사람이 알아보면서 개발자나 PO에게 물어보면서 스케치만 하고 있는 과정일 수도 있지만 대부분은 이 정도가 큰 틀일 것이다. 뭐, CPO나 기획팀장 한명이 방향성 제시하면, 주니어 기획자가 각 디테일한 영역을 기획서로 만드는 작업을 하는 구조도 있고.
1. 일반 고객이 쓰는 앱/웹 프런트 영역을 맡은 PO가 하는 일은 주로 우리 서비스를(0)인지하고 (1) 들어와서 (2) 회원가입하고 (3) 우리가 원하는 핵심 기능을 쓰고 (4) 결제하고 (5) 다시 들어오고 (6) 괜찮으면 친구에게도 추천하는 정도로 나눌 수 있는 고객의 우리 서비스 사용 흐름 중에서 가장 큰 누수를 막고 더 충성도 높은 고객을 많이 만들면서, 돈을 더 쓰게 할 수 있는 작업을 하는 일이다. (0) 인지 영역은 주로 마케터의 영역이겠지만, 여기서도 뭔가 마케터가 요청하는 개발적인 요청이 있으면 할 것이고, 나머지 단계는 서비스의 성격에 따라서 결제를 안 하거나, 핵심 기능 쓰기 전에 결제를 하거나 그렇긴 하겠지만 대략적으로 저렇다는 이야기다.
이것을 있어 보이는 말로 Growth Hacking이고, 주로 AARRR이라는 프레임워크로 활용할 것이다.
그래서 회사에 따라 그로스 해커와 협업을 할 수도 있을 것이다.
여기서 일을 잘한다는 것은 가장 회사에서 필요한 일을 가장 좋은 효율을 낼 수 있게 하는 일 것이다.
일단, 가장 회사에서 필요한 일이 무엇인지는 스스로가 판단할 수도, 경영진 또는 구성원들과 함께 협의할 수도 있을 것 같다. 이것을 유식한 말로, OMTM이라고 하는 것 같기도..
OMTM도 회사의 상황에 따라 바뀌기 나름이다.
만약 욕을 먹는 어떠한 이슈가 우리 서비스의 성장에 가장 문제가 되는거라면 그것이 우선순위가 될 수 있지만, 욕을 많이 먹는다고 꼭 가장 먼저 해결해야 할 문제는 아닐수도 있다.
인기 많은 서비스라면 다양한 니즈의 고객이 있고, 그런 스페시픽한 컴플레인이 당장 가장 중요한게 아닐 수 있다. 욕먹는건 두려워하지 말되, 서비스의 발전 관점에서만 바라보자.
2. 회사 내 직원 또는 비즈니스 파트너가 활용하는 어드민 영역을 맡은 PO가 하는 일은 비즈니스 요구 사항에 따라 우리 서비스가 더 많은 역할을 해서 돈을 더 벌 수 있게 기능을 추가하던가, 기존에 MVP로 만들다 보니, 해당 어드민 사용자가 수기로 했던 일을 이제는 기능화해서 업무 효율을 높이는 일을 할 것이고, 여러 가지 기능을 그때그때 추가하다 보니 복잡해지는 어드민 UI를 보기 편하게 다시 정비하는 작업 등을 할 것이다. 그러면서 어드민 사용하는 사람들을 위한 가이드를 만들고 공지하고, 오류가 생기면 그때 그때 해결하고, 그 오류를 해결하기 위한 여러 방안을 만들어서 그걸 또 스펙에 추가하는 등의 일을 할 것이다.
여기서 일을 잘한다는 것은, 1. 다양한 요구사항을 얼마나 공통화해서 다른 시스템에 영향을 안 미치고 비슷한 기능을 또 개발하지 않고 한 번에 기능을 제공할 수 있는지 2. 어드민 사용자, 개발자들과의 중간에서 스펙을 얼마나 잘 조율하고 일정에 문제없이 해결할 수 있는지 가 있을 것 같다. 그러기 위해서는 현재 시스템의 DB와 API 구조를 잘 이해하고, 비즈니스 요구사항을 잘 이해하면서 각자의 스테이크 홀더를 잘 설득하는 것이 역량일 것 같다.
3. 기존 서비스에 신규 사업을 붙이는 일을 맡은 PO는 현재 서비스에 또 어떤 서비스를 얹어서 더 시너지를 낼 것인가? 에 대한 고민을 주로 할 것이다. 물론 프런트 영역이 필요하면 1번 PO와 협업을 할 수도 있고, 어드민에 추가되는 부분이면 2번 PO와 협업할 수 있어서 비즈니스 영역만이라고 하면 아예 BD가 각 PO와 협업해서 할 수도 있고, 회사의 구조에 따라서 PO가 직접 진행할 수도 있다. 물론, 신규 어드민이 필요하면 만들면서 그 어드민의 PO가 본인이 될 수도 있겠지...
번개장터에 있을 때, 번개카 서비스를 시작했던것은 신규 사업을 붙이는 일이라고 할 수 있고, 번개장터 고객 프론트에 번개카를 위한 앱프론트 영역, 번개카 딜러를 위한 새로운 어드민이 추가로 만들어 졌었다.
이런 PO라면, 다양한 비즈니스에 대한 관심도 또는 이해도, 그리고 역시나 새로운 PMF를 찾는 관점에서 서비스를 고민해야 할 것이다. 빠르게 가설-> 테스트-> 검증-> 가설 이러면서 찾고, 또 그게 얼마나 시너지가 나는 일인지 검증하는 일을 꾸준히 할 것이다.
프로덕트 영역으로 나누면 대충 이럴 것 같고, 뭐 레거시가 너무 쌓이면 리팩터링을 어떤 영역에서는 하게 될 수도 있고, 그런 일을 PO가 개발자분들과 함께 일을 하면서 서비스가 발전될 것이다.
아, 그리고 이제부터는 서비스와 회사의 미래를 고민해야 하니까 협업과 히스토리 관리를 위한 문서관리, 업무 관리 등을 본격적으로 하게 될 것이다. 보통 히스토리 관리를 위한 위키로는 컨플루언스를, 업무 프로세스 관리 및 협업 관리를 위해서는 지라를 많이 쓴다.(둘 다 같은회사 것이다)
서비스가 고도화되면 고도화될수록, 프런트를 담당하는 PO도 영역에 따라서 나누어질 수도 있고, 어드민 역시도 다양한 프로덕트와 PO로 나누어질 것 같은데, 그건 고도화 단계에서 이야기해 보겠다.
