[책리뷰] 조직을 성공으로 이끄는 프로덕트 오너

프로덕트 오너

서비스기획, PM, PO... 직무를 지칭하는 단어들이 비슷한 듯하면서 다르다. 사전적 정의가 있다고 하더라도 회사마다 요구되는 역할이 미세하게 다르다. 이와 관련해서 늘 논쟁의 여지가 있었지만, 어떤 용어가 맞느냐라는 문제는 중요하지 않은 것 같다. 기획자로서, PM으로서, PO로서, 내가 무엇을 해야 하는지 아는 것이 중요하다.

이 책은 기획자라면 누구나 들어봤을 기본서이다. PO로서의 자질부터 고객, 데이터, 일정관리, 이슈관리, 디자이너 및 개발자와의 협업 관리 등 프로덕트를 관리하는 노하우가 담겨있다. 막연하게 고객을 이해하자, 협업을 잘하자라는 추상적인 이야기가 아닌, 현업에서 어떻게 적용할 수 있는지 구체적으로 쓰여있었다. 그 중에서 내가 기억하고 싶고, 적용해보고 싶었던 부분을 일부 소개하려고 한다. 

 

---

1. 일정관리

일정관리를 할 때는 Hate Waste 원칙을 적용하여 PO, 디자이너, 백엔드, 프론트엔드별로 일정을 스케쥴링한다. 중간에 개발자의 시간이 빈다면, 백로그에 있는 개발물이나 플랫폼 개선에 자원을 할당해야 한다. 

 

2. 고객vs회사

고객과 회사 중에 무엇이 중요할까? 예전에 면접에서 "고객이 중요해요? 회사가 중요해요? 하나만 선택해보세요." 라는 질문을 받은 적이 있다. 고객 중심을 외치는 회사가 많고 수요 없는 공급은 리소스 낭비라는 생각이 들어 고객이 중요하다고 했지만, 이 책을 읽고 생각이 바뀌었다. 이 책에서는 고객의 요청과 회사의 목표가 충돌한다면 사업적인 요구사항을 선택해야 한다고 말한다. 우리는 회사의 자원을 활용하여 이익을 추구해야 하며, 회사가 없으면 고객에게 더 나은 경험을 제공할 기회까지 사라지기 때문이다.

 

3. PO의 자질

PO는 본질이 무엇인지 파악하고, 매사 원인이 무엇인지 탐구하며, 체계적으로 생각해야 한다. 또한 감정을 공개적으로 드러내지 않아야하고, 반대의견이 있다면 차분히 들은 다음 설득해야 한다. 긍정적인 모습을 보여주고 동시에 겸손해야 한다.

 

4. 티켓 관리

티켓을 발행하기 전에 문서를 작성한다. 문서에는 목적, 배경(필요성, 방향성), 원칙, 목표, 주요 지표, 개발계획 등이 포함되어야 한다. 새로운 프로덕트나 신규 기능의 경우 에픽을 발행하고, 그 아래에 스토리 티켓을 생성하여 관리한다. 에픽에는 목적, 목표, 수치 등을 기록하며, 스토리에는 구체적인 요구사항(디자인 시안, UX 흐름 문서 등)을 첨부한다. 태스크는 스토리가 완료되기 위해 개발되어야 하는 것으로서, 개발자가 직접 작성한다.

 

5. 협업

디자인에 대해 피드백을 할 때에는 시각적인 코멘트보다, 사전에 정한 원칙을 기준으로 고객이 사용할 때 어떠한 느낌이 드는지에 대한 관점에서 질문 형태로 의견을 전달한다. 개발자와의 협업에 있어서는 공수 산정은 개발자에게 맡기되, 개발 일정이 예상보다 길어진다면 개발 매니저와 논의하여 왜 그렇게 산정되었는지 원인을 파악해야 한다. 이후 특정 기능을 제거하거나, 할당된 업무를 미루거나 등의 조율로 최적의 일정을 산정한다.

---

책을 읽으며 나의 업무 방식을 돌아보게 되었다. 유사하게나마 수행해보았던 부분도 있어 안도감을 느끼기도 하였고, 미리 알았더라면 이렇게 했을텐데 라는 아쉬움이 남기도 하였다. 왜 기본서인지 알 수 있을 정도로 퀄리티가 높은 책이었다.