<프로덕트 오너> PO의 시간관리법

IT 프로덕트를 만드는 메이커라면 한번쯤은 들어봤을 책 <프로덕트 오너> 를 읽고 있다. 대충은 PO(이하 프로덕트 오너)가 어떤 일을 하는 사람이고 어떤 자질이 필요하다는 것을 알고 있다고 생각했는데, 이 책을 읽으면서 그간 프로덕트 오너에 대한 나의 이해가 얼마나 얄팍했는지를 절실히 깨닫고 있다.

그래서 나는 이 책을 읽으면서 각 챕터별로 짧은 글을 작성하려고 한다. 때로는 단순한 내용에 대한 요약글이 될수도 있고, 때로는 나의 경험을 덧붙여 좀 더 글이 풍부해질수도 있다. 어떤 형태로든 책을 그냥 읽고 밑줄친 채로 넘겨버리는 것이 아니라 충분히 곱씹으면서 내용을 이해해보려고 한다.


PO는 다양한 관계자들과 소통하며 조직 및 프로덕트에 관련된 거의 모든 일에 관여한다. 때문에 프로덕트 오너는 효율적으로 일정관리를 할 수 있어야 한다. 조직의 일정이든, 팀의 일정이든, 본인 스스로의 일정이든 말이다.

1. 모든 소통은 문서를 기반으로

보통 새로운 기능을 개발할 때에는 아래와 같은 단계를 거친다.

  1. 2-3장짜리 문서 작성하여 조직과 공유. 신규 개발 건에 대한 조직 전체의 이해를 돕는다.

  2. 신규 개발을 위한 티켓 생성 (에픽 - 스토리 - 테스크)

  3. 중간 중간의 변경사항을 수시로 업데이트한 뒤, 스크럼에서 공유한다.

티켓 생성 전 작성하는 문서에는 다음과 같은 형식으로 작성하여 모든 사람들이 편하게 문서를 볼 수 있도록 한다.

  1. 목적

  2. 배경정보

  3. 고객을 위해 어떤 일을 하는가

  4. 원칙

  5. 목표

  6. 주요지표

  7. 개발계획

  8. 자주묻는질문

문서를 기반으로 소통할 경우, 모든 사람들이 같은 수준의 이해를 하기에 쉽고, 해당 이슈를 다른 이해관계자와 공유하기도 쉽다.

2. 소통의 창구는 한 곳으로 일원화

프로덕트 오너에게는 하루에도 수백 건의 요청 건들이 들어온다. 각각의 채널도 다양한데, 이메일, 전화, 메신저 등 다양한 통로로 각 팀의 요구사항을 전달한다. 이렇게 되면 프로덕트 오너 자신은 시간을 효율적으로 사용할 수 없고 그것은 팀 전체에게 영향을 미친다.

따라서 문의사항, 데이터 요청, 개발 요청 등은 모두 각각의 스프레드 시트를 만들어 일정한 템플릿에 맞춰 요청자가 직접 작성하도록 한다. 해당 문서에서 현재 업무 진행상황도 공유하고, 관련 문서도 태그한다.

다른 업무자와 요청 내용을 공유할 때에는 그 링크만 공유하면 끝이다. 모두가 최신 업데이트된 정보로 소통할 수 있으며, 같은 문서를 통해 자기와 연관된 정보를 확인할 수 있다.

3. 이것저것 다하지 않는다

국내에서는 아직 프로덕트 오너의 직무에 대한 이해가 낮기 때문에 잡부처럼 이것저것 다하는 사람으로 이해하는 조직이 상당하다. 심지어는 PO문화가 잘 정착된 쿠팡같은 큰 조직에서도 말이다. PO는 각 파트 사람들이 임무를 잘 이행할 수 있도록 요구사항을 명확하게 전달하고 방향성을 제시해야한다. 만약 PO가 기획, 디자인, 개발과 같이 다른 전문분야의 업무를 같이 이행해야하는 경우, 자신의 일을 제대로 수행하지 못할 가능성이 높다. 때문에 PO는 자신이 할 수 있는 일일지라도, 본업무에 최선을 다하도록 한다.

Last updated