PO 미신, 파랑새를 찾아서 - CPO 김용훈

2022.08.04 우아한 PM의 밤

  • 조직의 크기가 커지고 서비스 기획자의 역할도 분명 달라졌음에도 관성적으로 '기획자'라는 단어를 사용해왔었다.

    • 기획자라는 포지션 명으로 그들을 부르는 것이 과연 맞는가 하는 물음에서 시작

  • 서비스 기획자는 90년대 말, 2000년대 초 인터넷 기업, 웹 에이전시에서 시작되었다.

    • 당시만해도 기획자는 제안, 계약, 프로젝트 관리 등 디자인과 개발 이외의 거의 모든 업무를 담당하는 사람

    • 클라이언트나 사업부의 요구를 받아서 기획/디자인/개발로 이어지는 전형적인 폭포수 개발 방식으로 프로덕트가 만들어졌고

    • IA, UI 중심의 스토리보드가 주요 산출물이었다.

폭포수 방식에서 사용되는 전형적인 화면 기획서의 예

그럼 언제부터 도대체 기획자 -> 프로덕트 매니저로 바꿔 부르기 시작했나?

  • 웹의 시대에서 앱의 시대로 넘어가면서 서비스에서 프로덕트로 자연스럽게 넘어가게 되었다.

  • 웹서비스보다 앱서비스에서는 훨씬 더 많은 자원이 필요했고, 기술의 난이도도 높아졌다.

  • "프로덕트"라는 단어는 공산품을 의미한다. 웹에서 앱으로 전환이 되면서, 서비스는 가내수공업 형태에서 산업혁명을 거쳐 공산품을 빠르게 만들어내는 것처럼 변화했다.

  • 기존과 비교하여 많은 자본이 투입되고 시장이 커진 상황에서 '우리가 만든 앱을 어떻게 하면 잘 만들 수 있을까'하는 고민이 시장에 널리 퍼지게 되었고, 방법론 같은 것들이 공유되기 시작했다.

  • 자연스럽게 널리 퍼진 방법론을 기반으로 앱을 만드는 것들이 당연해졌고 (agile 로 만들어야하고, 표준화가 가능할 것 같고 등등) 이를 완성된 형태의 '프로덕트'라고 부르는 것이 자연스러워졌다.

  • 결국 서비스 기획자에서 프로덕트 매니저로 부르는 이름이 변화된 이유는 기술적인 변화, 우리가 다루어야 하는 미디어의 변화에 기인한 것이 아닌가 생각한다.

프로덕트의 시대에서 기획자의 역할 변화

  • agile 개발방식, 도메인 단위 목적 조직 보편화

  • 분업을 통한 업무 전문화 - PMO, TPM, QA, 리서치 등

  • 프로토타이핑 툴 보급, 인터페이스의 고민은 프로덕트 디자이너에게로 많이 넘어감

  • 산업 고도화, 모바일 경험 상향 평준화, 낮아진 사용자 호기심

    • 더이상 프로덕트 매니저에게 차별화된 앱경험 등을 요구하지 않는 시대가 되었다.

  • 데이터 기반 의사결정, 잦은 A/B 테스트

  • 고객 경험보다는 사업가치, Creativity 보다는 Productivity 로 중심점이 많이 옮겨가고 있다.

이전에는 UX 쪽에 치우쳐있던 능력이 Tech, Business, 더 나아가 Data 쪽으로 옮겨가고 있다.

  • 왼쪽이 현재 상황이고 오른쪽이 만들어야 하는 것이라고 한다면, 다양한 인풋으로 결과물을 만들어야 한다.

    • 이때 주목해야할 점은 바로 Output을 Minimize 해야한다는 것이다.

  • PM은 항상 시간이 부족하고 예산은 적고, 개발자는 모자르고 자원이 한정되어있다. 그렇다면 결국 PM의 역량과 전문성이라는 것은 어떻게 하면 가장 최소의 자원으로 최대 임팩트를 만들 수 있을지 고민하는 것이다. 그래서 우선순위를 결정하는 능력이 중요하게 여겨진다.

PM vs. PO

저희는 PO 없나요?

  • PM은 권한도 없고 현실에 쩔어있는 느낌인데 PO는 슈퍼맨같고 엄청난 권한을 가지고 주도적으로 일하는 사람 같은 느낌

  • PO 는 사실 특정 상황에서 주어지는 역할이지 직군은 아니다. 스크럼을 돌 때, 조직 내부에서 가장 사용자의 입장을 대변하여 프로덕트에 대한 의견을 제시하거나 왜 그것이 유효한지 설득하는 역할

PM 과 PO의 비교
  • 우리나라에서는 훨씬 큰 의미로 PO가 해석되고 있다. 오히려 PM이 PO보다 더 높고 큰 포지션으로 인식되고 있다.

  • 실리콘밸리 제품개발 방식을 따르고자 하는 우리나라 스타트업들이 PO를 앞세워 마케팅을 했고 제품의 성공과 맞아떨어지면서 그 방법이 먹히기 시작함

  • 흔히 말하는 조직의 성장 단계에서 PMF 에 도달하기까지, 무수한 실패를 반복하는 시기에는 비전을 입증하기 위해 PO 중심으로 빠르게 시도하고 실패하며 PMF 를 찾는 과정이 필요하다. 유효하다.

  • PO는 프로덕트의 성장 자체에만 집중하며 100%의 힘을 프로덕트에만 쏟을 수 있다.

  • 하지만 PMF 를 찾고 J커브를 그린 이후에는 성장기에 접어들게 되고, 이때는 프로덕트의 가치를 늘리고 지속성장성을 증명해야한다.

  • 한번 스윗스팟을 맛본 사람들은 고객과 시장에 대한 감각이 있기 때문에 그 뒤에 시도하는 경우에도 성공하는 프로덕트를 만들어낼 확률이 계속 높아지게 된다.

  • 이러한 시기에는 프로덕트에 대한 범위도 커지고, 조직도 커지게 된다.

  • 온전히 프로덕트에만 집중하던 상황에서 바뀌어서 이제는 설득해야하는 사람들이 많아지게 된다.

  • PO의 의견을 중심으로 프로덕트를 개발하던 방식에서 PO가 주도적으로 의사결정을 할 수 없는 상황들이 조금씩 생겨나게 된다.

  • 완숙기에 접어들면 규모, 수익성, 생산성을 신경써야한다.

  • 여러 이해관계자들을 설득하고 의사소통하는 것이 훨씬 더 중요해진다.

  • 초기에 비하면 PO의 자기의사결정권, 활용할 수 있는 자원의 크기와 같은 것들은 당연히 달라질 수 밖에 없다.

정리하자면, PO는 특정 조직에서 지속 가능한 PMF 를 찾기 전 단계에서 프로덕트 가치를 높이기 위해 경영진의 강력한 지원 아래 빠르고 기민하게 프로덕트에 대한 의사결정을 자기주도적으로 할 수 있을때 유효

Owner 라는 표현의 부작용

  • Own 하지 못하는 Owner 는 동기가 저하되고

  • 높은 자기 책임감 대비 부족한 권한

  • 자기 주도적인 의사결정을 과신하고 하향식 의사결정에 대한 거부감

  • 맹신적 사용자 중심주의 -> 비즈니스 가치를 폄하할 수 있다.

PM/PO 라는 이름에 너무 스스로 매몰되지 말자. 조직의 단계별로 필요한 역할과 직군이 있다.

분명 모든 PM들은 성과를 내기 위한 나만의 방법들이 있을 것이다.

Last updated