프로덕트 오너는 결국 이타적이어야 한다. … 고객의 감동을 통해 세상을 조금 더 발전시켰다는 사실을 확인하며 만족할 수 있어야 한다.

이 책, 304쪽

이 책의 풀 네임은 ⟪조직을 성공으로 이끄는 프로덕트 오너⟫. 표지에 있는 홍보 문구는 “쿠팡의 PO가 말하는 애자일 혁신 전략”이다.

김성한, ⟪조직을 성공으로 이끄는 프로덕트 오너⟫ (2020)

글쓴이는 NHN NEXT에서 소프트웨어 엔지니어로 근무, (회사명이 공개되지 않은) 다수의 스타트업에서 근무, 암호화폐 거래소 코빗에서는 프로덕트(?)를 관리하는 업무를 했고, 현재 쿠팡에서 프로덕트 오너(Product Owner, 이하 ‘PO’)로 일하고 있다.

이 책에서 말하는 ‘프로덕트’(product)란 무엇일까. 그리고 ‘프로덕트 오너’란 어떤 일을 하는 직책일까. 나는 이런 질문을 품고 이 책을 읽었다.

목차는

  1. 프로덕트 오너(PO)는 미니 CEO다
  2. 고객의 목소리를 어디까지 반영할 것인가
  3. 데이터 속에서 진실을 찾는 법
  4. 효율적인 일정 관리의 비밀
  5. 디자이너를 최고의 파트너로 삼는 법
  6. 개발팀과의 협업을 성과로 이끄는 애자일 전략
  7. 고객 테스트 결과만큼 강력한 데이터는 없다
  8. 프로덕트를 출시하는 최적의 시기
  9. 테스트 중 가설을 효과적으로 검증하려면
  10. 론칭한 서비스의 문제를 바로잡기
  11. 어떤 인재를 PO로 선발해야 하는가

위 목차에서 짐작할 수 있듯, 이 책은 ① PO라는 업무 포지션에 관한 설명과, ② 글쓴이 본인이 PO로 일하면서 PO라면 응당 이렇게 일해야 한다, 나는 PO로서 이렇게 일해왔다 등을 기록한 일종의 ‘PO론’을 담고 있다.

그러니,

  • 어떤 회사 — 주로, tech 기업 — 에는 ‘프로덕트 오너’(PO)라 부르는 직책 또는 직무가 있던데, 어떤 업무를 수행하는지 궁금하다. (주의: 회사마다 job description이 다를 수 있다.)
  • 현재 PO role을 수행하고 있거나 앞으로 career를 꿈꾸고 있는데, 현직의 다른 PO는 어떻게 일하고 있는지 알고 싶고, (만약 글쓴이가 훌륭한 PO라면) 그로부터 배울 점을 찾고 싶다.

정도의 목적을 가진 독자라면, 이 책을 통해 원하는 바를 얻을 수 있으리라 생각한다.

특히, 글쓴이는 PO로 살려면 꼼꼼히 메모하고, 일의 우선순위를 정하고, 내∙외부 고객 및 유관 부서와 커뮤니케이션을 잘 해서 기대치 관리를 해야한다는 조언을 하는데, 이건 꼭 PO가 아니더라도 일을 하는 사람이면 누구에게나 도움이 되는 조언이다.

책을 읽고 내가 궁금했던 건, ‘PO는 반드시 필요한가’였다.

이미 프로젝트 관리(PM), 사업 기획, 서비스 기획 등의 이름으로, PO와 비슷한 직무를 수행하는 사람이 있다. 그런데 굳이 특정 프로덕트에 대한 오너십을 갖는 PO가 필요한 것일까. 소프트웨어 개발과 디자인 작업 과정을 깊이 있게 이해하고, 서로 다른 직무를 가진 사람들 사이 또는 여러 부서 간(cross-functional, XFN) 커뮤니케이션을 하면서 프로덕트가 중심을 잃지 않고 올바른 방향으로 나아갈 수 있도록 리딩하는 역할이라면 PM으로도 충분하지 않을까. 프로덕트에 관한 오너십을 주는 것이 경우에 따라 사람에 따라 risk한 업무 배분이 될 수도 있지 않을까 하는 의구심이 든다.

자문자답을 해보자면, PO든 PM이든 이름표가 무슨 상관이겠는가 쥐만 잘 잡으면 됐지, 이다. 쿠팡을 비롯 다른 tech 회사에 PO라는 직책이 생겨난 데에는 고맥락(high context) 배경이 있을 것이다. 회사나 프로덕트의 규모에 따른, 성장 과정에 따른 차이도 있을 것이다. 그러므로, 이 책을 읽고 프로덕트, 특히 디지털 프로덕트를 만드는 회사에는 반드시 PO가 필요하다는 결론을 내리는 건 섣부르다. 기존 PM이 충분히 커버하지 못했던 업무 영역이 무엇인지 확인하고, 이를 보완/보강하려면 어떻게 해야하는지를 점검해보는 정도면 충분하다.

아래는 책의 내용을 필요에 따라 일부 요약하였다.

PO는 무엇인가 / 무슨 일을 하는 자리인가

  • PO는 mini CEO다.
    • 특정 서비스에 대한 책임을 지는 자다. (24쪽) — 어떤 ‘책임’을 말하는 것일까?
    • 책임지고 있는 프로덕트에 대한 원칙(Guiding Principle)을 정한다. (86쪽)
    • OKR 설정에 있어 조직과 프로덕트에 대한 이성적인 가설을 제시한다. (123쪽)
    • 프로덕트에 관련된 사항이라면 무조건 책임지고 문제를 해결해야 한다. (277쪽)
    • 프로덕트 오너십 — 프로덕트에 대한 직접적인 가설 설정과 요구사항 정의 — 를 갖고 있다. (285쪽)
  • PO는 전략가이자 기획자다.
    • 프로덕트 기획 문서(ex. Amazon의 6-pager)를 작성하고 기록하고 공유한다.
    • 회사 내 전문가들의 의견을 종합하고 고객의 목소리를 함께 고려하면서 프로덕트가 발전될 수 있는 방향을 고민한다. (89쪽)
    • 해결하려는 문제의 가설을 설정하고, 이를 데이터로 검증한다. (123쪽)
    • 티케팅(ticketing); 개발 요구사항을 작성하고 전달한다. (135쪽)
    • 개발팀과 스프린트 플래닝을 하고 스프린트에 대한 회고를 진행한다. (182~193쪽)
    • 프로덕트의 배포 일정을 계획한다. (224쪽)
    • 직무별 업무 일정을 계획한다. (266쪽)
  • PO는 고객/사용자 조사 및 데이터 전문가다.
    • 실질적으로 고객이 무엇을 필요로 하는지 끊임없이 분석한다. (24쪽)
    • 고객에게 집착한다. 고객을 이해하고 더 나은 경험을 제공할 수 있게 한다. (52쪽)
    • 고객이 흔쾌히 고용할 프로덕트를 만들고 꾸준히 개선해야 한다. (66쪽)
    • 고객 조사 데이터를 통해 인사이트를 추출해야 한다. (102쪽)
    • 사용자 테스트(UT, User Test)를 준비하고(검증사항 등), 진행한다. (204~210쪽)
    • 프로덕트의 1인 고객센터이다. (234쪽)
    • 고객의 소리(VOC)를 접할 수 있는 환경을 조성해야 한다. (272쪽)
  • PO는 협업과 커뮤니케이션 전문가다.
    • 디자이너, 개발자 같은 메이커(maker)와 끊임없이 소통하며 프로덕트를 만들고 개선한다. (24쪽)
    • 타 유관 부서의 요청사항을 받는 등 회사 내 다른 부서와 협업하고 커뮤니케이션 한다. (151쪽)
    • 개발 매니저, 기술 매니저(TPM, Technical Program Manager)와의 R&R을 명확히 구분한다. (147쪽)
    • 내∙외부 고객 및 유관 부서와 건강한 관계를 유지할 수 있도록 기대치 관리(Expectation Management)를 해야한다. (276쪽)
PO와 개발 매니저, 기술매니저(TPM) 사이의 R&R 정리 예시 (147쪽)

PO는 어떻게 일해야 하는가

  • 감정과 직관에 치우치지 않고 사실을 기반으로 모두를 위한 최선의 우선순위와 결정을 내려야 한다. (28쪽, 252쪽, 276쪽)
  • 주어진 권한이 전혀 없으므로, 늘 명확한 사실과 데이터를 갖고 설득해야 한다. (33쪽)
  • 언제나 겸손해야 한다. (41쪽)
  • 프로덕트에 관한 적절한 대시보드(dashboard)를 만들어 수시로 데이터를 확인해야 한다. (109쪽)
  • 개발자에게 요구사항을 명확하게 전달하여야 한다. (142쪽)
  • 유관 부서의 요청사항을 전달받는 경우가 많으므로 메모를 꼼꼼히 한다. (150쪽, 275쪽)
  • 소통 과정에서 병목현상이 생기지 않도록 최대한 효율적인 커뮤니케이션 방법을 고안한다. (155쪽)
  • 디자이너와 협업할 때, 1차 시안이 완료될 때까지는 디자이너가 자신의 업무에 집중할 수 있도록 기다린다. (163쪽)
  • PO는 디자이너가 아니므로 의견(=개인적인 견해)를 전달하는 게 아니라, 요구사항 — 프로덕트가 갖춰야 하는 기능, 고려해야 하는 제약, 추구하고자 하는 목표 등을 설명해야 한다. (179쪽)
  • PO는 디자이너, 개발자의 궁금증을 곧바로 해소하고 질문에 언제든 답할 수 있도록 조금 더 멀리 내다보면서 미리 예상 질문을 만들고 답을 마련한다. (199쪽)
  • 내부 고객용 프로덕트가 새롭게 업데이트 되면, 안내 메일을 보내고 사용 안내서를 상세히 작성하여 공유한다. (233쪽)
  • A/B 테스트 결과에 따른 의사결정(포기, 재검증 등)을 신속하고 확실하게 내림으로써 개발 조직과 디자이너가 시간을 허비하지 않고 다른 목표 달성에 집중할 수 있도록 한다. (249쪽)
  • 프로덕트 업데이트가 완료되면 고생한 팀원들에게 감사를 표한다. (259쪽)
  • PO의 삶에 적응하려면, ①이해한 바를 꼼꼼히 기록하고, ②우선순위를 정하고, ③올바른 기대치를 형성하는 것을 잘 지켜야 한다. (277쪽)
  • PO는 고객에게 최적의 경험을 제공하려고 무언가를 만들어야 한다는 마음가짐을 갖춰야 한다. (303쪽)
PO와 PM/TPM의 역할 차이 설명 (284쪽)

이 책의 내용에 관심이 있는 분이라면 분명 알고 계실테지만, 아직 모르고 계신 분들을 위하여 Andrew Ahn님의 블로그를 함께 소개한다. 이 블로그의 ‘Product’ 카테고리에 속해 있거나 ‘Product Management’라는 태그가 달린 글만 먼저 보아도 제품 관리자(Product Manager)라는 직무를 이해하는 데 도움이 될 것이라 생각한다.


제가 쓴 글을 읽어주셔서 감사합니다. 이 책에 대한 관심이 생기셨다면 아래 링크를 통해 구입하실 수 있습니다.

조직을 성공으로 이끄는 프로덕트 오너:쿠팡의 PO가 말하는 애자일 혁신 전략, 세종서적

위 링크를 통해 책을 구입하실 경우, 이 글의 작성자인 제가 쿠팡 파트너스 활동을 통해 일정액의 수수료를 받을 수 있음을 알려드립니다.

참고로, 쿠팡 파트너스 가입은 여기에서 할 수 있습니다. 가입시 추천인코드를 입력할 수 있습니다. 저의 추천인코드는 AF1603507 입니다. 추천 부탁드립니다.

Posted by:박세희 (Park Sehee)

성장의 기쁨, 나눔의 즐거움. hubby, daddy of two sons, lawyer, ever learner.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.