개발하고 있을 때 PO는 뭐 하나요?

페이스북 본사 벽면에 걸려있는 슬로건

데이터 분석가로 일할 때 인테리어 업자들의 평균 마진율을 구해달라는 요청을 받은 적이 있다. 우리는 그런 데이터를 수집하고 있지 않는데 어떤 데이터로 마진율을 추론할 수 있을지 고민하고 있었는데, PO가 디비가 아니라 기사나 정부 자료를 찾아보라는 조언을 해줬다. 모든 걸 떠먹여 줘야 했던 나는 '음.. 그런데 이거 찾을수록 끝이 없는데, 어느 정도 수준을 원하세요?'라고 되물었다. 그러자 내일 점심까지 알아보고 그때까지 알게 된 사실을 다시 공유해 달라고 했다. 이때의 경험으로 두 가지를 배웠는데 하나는 데이터 분석가의 분석 범위는 데이터베이스에 국한된 것이 아니라는 것이었고, 다른 하나는 일을 할 때는 완성도가 아니라 시간을 정해두고 해야 한다는 것이었다.

우리는 엉성한 사실 혹은 그보다 못한 가설을 들고 기획을 한다. 그리고 일이 진행되는 과정에서 실제 데이터를 수집해 엉성한 사실은 구체적인 사실로 변한다. 다시 말해 PO는 처음부터 모든 것을 완벽하게 파악한 상태에서 기획을 하는 것이 아니다. 오히려 훌륭한 PO들은 일이 진행되는 과정에서 내가 틀렸고, 다른 방향으로 가야 한다는 선언을 잘한다. 아무튼 PO는 엉성한 사실을 바탕으로 한 기획 문서를 제안하게 된다. 그래서 데이터를 확인하기 전까지 내 제품이 실패할 수 있는 이유를 적고, 그것을 보완할 방법을 준비해야 한다. 내가 주로 하는 방법은 방금 배포된 기능과 유사한 서비스의 리뷰를 둘러보면서 유저들이 느끼는 장단점을 정리해 보는 것이다. 그리고 우리가 개선할 수 있는 포인트 몇 가지를 나열한 뒤에 해결방안을 정리한다. 지표를 확인하자마자 가치를 줘야 할지 유저가 느끼는 허들을 없애야 할지 확인한 뒤 바로 움직일 수 있기 위함이다. 이 타이밍에 이런 유저는 이렇게 움직일 것 같고, 저런 유저는 저렇게 움직일 것 같다는 등의 유저 페르소나도 같이 정리하게 된다.

또한 이 시점의 중요한 일은 일이 되게 하는 것이다. 막상 PO를 해보면 기획보다는 일이 되게 하는 것이 가장 어려운데, 가설에 동의하지 않는 개발자와 디자이너를 설득해 가며 법무팀과 재무팀의 제약 사항을 반영해야 한다. 모든 제약 사항을 고려하면 제품 스펙은 비대해지고, 일은 한없이 늘어지기 때문에 이런 상황을 마주할 때 적절한 협상을 해야 한다. 서버 구조를 바꾸지 않는 선에서 스펙 변경할 수 있는 기획으로 변경하고, 디자인적인 요소들은 실험의 영역으로 빼둔다. 법을 어기지 않는 선에서 디자인 수정을 최소한으로 만들기도 해야 하고, 가끔은 넷플릭스 봐야 한다며 일찍 들어가는 개발자를 상대로 이번 주만 야근을 요청해야 할 수도 있다.

만약 이런 것을 할 것도 없이 평온한 상태라면 조용히 백로그를 쌓고 있기도 한다. 제품을 만들다 보면 순서의 차이가 있을 뿐 무조건 해야 하는 일들이 있기 마련이다. 예를 들어 브런치 같은 블로그 서비스를 만든다면, 네이버나 구글에서 검색이 되도록 해야 한다. 또, 금칙어를 설정한다거나 페널티 제도를 도입하는 등의 작업은 서비스를 개시하는 첫날이 아니라도 언젠가는 만들어야 하는 기능이기 때문에 미리 기능 요구서를 작성해 둘 수 있다.

PO는 지금 작업을 진행시키면서 다음 작업을 준비하는 사람이기 때문에 배포 후에 유저들이 어떻게 사용할 것 같은지 상상하고, 또 우리 구성원들이 결과에 어떻게 반응할 것인지 등을 미리 생각해 일이 빠르게 진행될 수 있도록 준비할 필요가 있다.