PO, 기획자 등 라벨링보다는 일의 본질 (우아한형제들)

배달의민족 유튜브의 <[우아한형제들] PO 미신, 파랑새를 찾아서 - CPO 김용훈> 영상을 정리한 글입니다.

 

 

영상을 통해 느낀 점은..

• 결국 프로덕트 매니저로 일을 할 때, 일의 본질Why를 생각하라는 주제로 볼 수 잇음
• 인터넷에 돌아다니는 프로덕트 매니저, 프로덕트 오너, 기획자 등의 역할, 업무 방법론 등에 대한 공유가 많아짐. 조직을 관리하는 리더부터 커리어를 만들어가는 구성원의 입장에서 혼란이 생길 수 있는 상황.
• 그럼에도 Product Manager라 불리는 일의 본질은 변하지 않음. 현재의 상황과 문제로부터 우리가 원하는 이상적인 결과로 가는 과정에서 자원을 효율적으로 사용하면서, 결과를 극대화 시키는 일. 그 과정에서 초기에 빠른 실험과 실행이 필요할 때는 Product Owner의 역할로 일을 할 수도 있으며, 처음에 Product Owner로 입사했어도 조직의 규모가 커지고 비즈니스 성과가 중요해진다면 이런 것들을 고려하는 Product Manager로 일을 할 수도 있음

---

강연 배경

• 배달의 민족 내부에서 고민이 존재. 초기와 비교할 때, 사람도 많아지고 프로덕트도 고도화가 됨
• 하지만 내부적으로 기획자라고 관성적으로 불렀지만, 이것이 옳은 표현인가에 대한 고민을 하기 시작함

 

기획자의 시작

• 98~99년 인터넷 붐이 한창이던 시점에 홈페이지를 만들던 사람들이 기획자로 주목받음
• 이들은 제안, 발표, QA, 스토리보드 등 개발을 제외한 모든 것을 하는 사람들
• 웹 기획자들이 많아지고 에이전시나 IT회사를 다니면서 일을 하기 시작. 이후 자연스러벡 모바일로 감

 

왜 프로덕트라 불리기 시작했을까?

• 앱을 만든다는 것은 웹보다 훨씬 더 많은 자원이 필요하게 됨. 개발 난이도부터 필요한 것들이 많아짐
• 웹을 필요한 개개인이 잘 만들던 시대를 넘어서 많은 자본이 투입되고, 방법론이 공유됨
• 그 과정에서 표준화가 가능하다고 판단되면서, 이걸 프로덕트라고 부르게 된 것은 아닐까 생각함
• 당연히 워터폴 방식이 Agile방식으로 일함. 모바일을 지속적으로 고도화 시키기 위한 방법.
• TPM, QA, PMO 등이 나타나면서 과거에 비해 일이 줄어들고 전문화가 되기 시작함.
• 더 이상 기획자에게 높은 수준의 와이어프레임이나 스토리보드를 요구하지 않음. 프로토타이핑 툴은 워낙 잘 나오면서, 디자이너가 숫자만 조정하면서 원하는 수준을 확인할 수 있음. 실제 프로덕트 디자인으로도 역할이 많이 넘어감.
• 적은 자원으로 효과적으로 만들 수 있는지 알려주거나, 비즈니스 가치에 집중하는 쪽으로 Product Manager의 역할이 정의됨

(Photo - jpattonassociates)

• 특히, 위에 나온 Output을 최소화 한다는 것. PM의 역할은 최소의 자원으로 최대의 임팩트를 만들 수 있을지 고민함
• T직군은 이미 분리됐지만, 희소가치와 연봉테이블이 다르기 떄문에 인사 등의 불편함이 있음. T직군에서 인사제도에 포함. 반면 P 직군의 경우, 전문성에 대한 경계가 명확하지 않았던 상황이기 때문에 L직군이었지만 따로 분류.
• T직군이 워낙 희소자원이기 때문에, 밸류는 계속 올라가는데 프로덕트 매니저 한명이 같이 영업하는 테크 엔지니어가 평균 2명 이상이기 때문에 프로덕트 매니저가 어떻게 일을 하느냐가 개발 성과를 내는데 많이 기여한다고 생각. 직군 세분화나 처우에 대해 고민.

 

PM과 PO?

• Product Owner는 직군이 아니라 역할의 개념. Agile 방법론의 Scrum은 기민하게 의사결정하면서 좋게 만들어가기 위한 방법인데, 스크럼 마스터, 프로덕트 오너 등이 함께 돌 때 사용자 입장을 전파해주는 사람. 그런 관점으로 이제 프로덕트의 가치를 높이기 위해서 우선순위를 관리하거나, 소통하는 사람들을 PO로 불려옴.
• 소프트웨어 공학 관점에서 봤을 때는 PM이 PO보다 넓은 관점

Product Manager	Product Owner
전체적, 장기적인 관점에서 제품에 대한 큰 그림을 그리는 것	큰 그림보다 작은 디테일을 보는 역할, 단기 초점
제품의 비전	제품 비전을 실행가능한 백로그로 만드는 것
고객 이해	고객의 요구 옹호
기능의 우선순위 지정	팀 개발의 필요성 강조
프로덕트 로드맵	백로그, 에픽, 사용자 스토리

 

• 그러면 한국에서는 왜 PO가 더 큰 의미처럼 이해가 되고 있을까? 실리콘밸리의 IT회사들이 PO를 중심으로 시도하는 기민한 방식을 따라가려고 노력했고, 그분들이 시장에서 PO중심으로 커짐. 테크 브랜딩 측면에서 어떻게 일하고 있는지 PO 중심으로 맞아 떨어짐.
• J-Curve의 시작 단계에서는 반복적으로 시도와 실패를 경험하게 됨. Product-market fit을 찾을 때까지 지속적인 실패를 할 수 밖에 없는 것이 스타트업. 이 때는 PO 주도적으로 일을 하는 것이 당연하며, 이들은 Product의 Value를 높이기 위해서 애써야함.
• 반면 J-Curve 이후 성장기에는 프로덕트의 가치를 늘리고 지속가능성을 높여가야함. 한번 Sweet Spot을 경험한 사람들은 고객과 마켓에 대한 감각이 있기 때문에, 같은 고객을 대상으로 프로덕트를 성공시킬 확률이 높아짐. 이후에는 프로덕트가 많아지거나 팀이 커지면서 프로덕트 조직이 되게 커짐. 이제는 프로덕트 오너가 주도적으로 의사결정 할 수 없는 상황도 생겨나게 됨. 즉 프로덕트 밸류보다 비즈니스 밸류가 중요해지는 시기가 오게 됨
• 여러 이해관계자들과 조율하면서, 설득하거나 타협하면서 요구사항을 되게 잘 팔로우할 때도 있음. 프로덕트나 프로덕트 조직이 훨씬 복잡해지는 상황이 오게 됨. PO가 할 수 있는 자기의사결정권이나 자원의 크기는 달라질 수 밖에 없음.
• 요약하면 방법론이나 역할, 명칭에 너무 매몰되지 않기를. 모든 조직은 상황과 동료에 따라서 어떻게 일을 하는지는 달라지게 됨