PO의 핵심 업무는 리소스를 집중시키는 것이다
'프로덕트 오너'를 읽고
'프로덕트 오너'에서 말하는 Product Owner(이하 PO)는 Product Manager(PM) 상위에서 전략적인 업무에 포커스 된 역할에 가깝다. 회사에 따라 조직에서 PM이 PO의 역할을 하거나, 혹은 PO가 따로 없는 조직 등 다양한 형태로 구성되기에 이 부분을 먼저 명확하게 할 필요가 있다.
<프로덕트 오너> 발췌현재 PM이지만, 이 책의 많은 내용들이 업무를 수행하는데 도움이 되거나, 혹은 반성하게 만드는 내용들이 많았기 때문에 그런 내용을 중심으로 느낀 점들 중심으로 정리해 봤다.
1. PO는 제품과 관련한 기획, 분석, 디자인, 개발, 출시 그리고 운영까지 다양한 영역을 관리하기 때문에, 특정 프로덕트에 대한 '미니 CEO'라고 불린다. 그렇지만 실제 CEO와 달리 인사권은 없기 때문에, 어쩌면 더 높은 수준의 커뮤니케이션 능력이 요구된다. 단순 지시를 통해서 결과물을 만들어내는 선택지는 불가능하다 보니, 제품에 대한 생각을 일치시키기 위해 많은 대화를 하고, 많이 설득해야 한다.
일을 하면서, 커뮤니케이션을 잘하는 것이 역량의 끝판왕이라는 생각을 자주한다. 일례로 커뮤니케이션을 잘하는 PM이나 팀장님을 보면, 일단 도메인이나 개발, 디자인 등 지식에서 크게 막힘이 없다. 완전 전문적인 부분은 서로 대화를 주고 받으면서 다듬어가지만, 큰 그림은 거의 다 '파악'하고 있었다. 더 나아가, 해당 팀에서 누구와 소통해야 일이 진행되는지, 현재 해당 팀 리소스가 대략 어떤지 등 조직 운영적인 부분까지 파악하고 소통을 한다. 그래서 커뮤니케이션을 잘한다는 것은 정말 엄청난 역량이라는 것을 느낀다.
2. 고객을 이해하는 것이 필수다. 하지만 고객을 이해한다는 것이 단순히 성별, 연령, 소득 등으로 파악하는 것은 아니다. 고객을 이해한다는 것은 '그들이 갖고 있는 문제'를 이해한다는 것이다. 책에서는 그 제품을 왜 '고용'했는지를 이해해야 한다고 말한다. 예를 들면, 내가 재직 중인 회사의 프로덕트를 이용하는 자사몰을 개발하는 비용을 최소화하고, 자사몰 매출을 극대화하기 위해서 우리 프로덕트를 고용했을 것이다. (물론 세부 프로덕트로 내려가면 더 많은 고용 목적이 생길 것이다.)
부끄럽지만 1월부터 PM으로 일한 이후에, 내가 정말 '고객'에 대해 깊게 고민했던 적이 있었나 반성하게 됐다. 다행히 현재 PO이신 팀장님께서 실제 쇼핑몰을 제작해 보게 만드는 등, 고객 관점에서 생각하고 운영할 수 있도록 팀원들을 많이 끌어주셨다. 하지만 그런 과정을 제외한다면 내가 일을 하면서 '고객의 문제'에 대해 놓쳤던 일은 많은 것 같다. 추하게 변명을 얹자면, 1월엔 Top-down의 업무가 많았기에, 개발 구현과 리소스/일정에 관한 고민이 더 많았다. 그럼에도 이 부분에 대한 고민은 놓지 않도록 스스로 상기해야겠다.
3. PO가 고민해야 할 것은 한정된 자원의 최적화다. 한정된 자원의 최적화라는 것이 단순히, 기능 개선의 리소스가 적어 보이는 Low-hanging fruit의 유혹에 넘어가는 것을 의미하지 않는다. 고객의 요구사항 중 더 임팩트 있는 것을 찾고, 그것이 프로덕트의 원칙이나 회사의 방향성과 맞는지 등을 검토해야 한다. 더 나아가, 리소스가 많이 투입되더라도 전략적인 측면에서 정말 필요한 지점이 있다면, 그 내용을 구성원에게 공유하고 일이 추진될 수 있도록 만드는 것도 필요하다.
PO의 문제 같지만 사실 PM에게도 똑같이 적용되는 것 같다. PM으로 일을 하다 보면, 일정을 맞추고, 개발 리소스를 최적화하고 싶은 마음에 나에게 편한 것을 선택한 적이 있다. PM으로 일하면서 어떤 것을 '단순 숨김처리'를 하는 쪽으로 기획한 적이 있다. 그때 팀장님께 들었던 피드백 중 하나가 '숨김처리하면 기획과 개발은 편하지만, 고객에게 편한 방향이 아닐 수 있다.'는 피드백을 받았다. PM 역시 업무 중 Low-hanging fruit에 넘어갈 일이 많은데, 그러지 않도록 주의해야겠다.
4. PO는 데이터에 집중해야 한다. 데이터를 다양하게 수집하고, 고객에 대한 정보를 넓고 깊게 알고 있어야 한다. 분석의 결과에 대해 다른 내외부 요인이 없는지 검토하고, 데이터를 쌓을 때도 잘못된 데이터가 쌓이지 않도록 비즈니스 애널리스트(BA)나 데이터 애널리스트(DA)와 논의한다. 대시보드를 통해 지표를 점검하며, 액셔너블한 데이터가 아니면 모두 정리한다.
실제 내가 BA로 일하면서 배웠던 원칙이나 방식에 대해서 자세하게 설명하고 있다. 그 이야기는 PO가 데이터를 제대로 보기 위해서는 주니어 BA급으로 데이터에 대한 이해도가 있어야 한다는 것을 말한다. 혹은, 개발을 직접 하지 않더라도 일하는 것처럼 어떤 일을 요청하고 어떻게 작업할지 명확하게 정의해줘야 한다. 책을 읽으면서, 내가 BA로 일했다지만 'PM으로 분석가와 잘 협업하는 방식도 안다고 말할 수 있을까?'에 대해서 많이 생각해 보게 되었다.
5. PO의 일에 집중할 수 있어야 한다. 예를 들면, 프로덕트와 관련한 핵심 문서를 잘 제작해서 확장성 있는 지식을 배포 Scalable Knowledge Transfer를 하거나, 요구사항을 더욱 구체적으로 다듬어서 개발자, 디자이너가 필요한 일을 잘할 수 있도록 만들어줘야 한다. 이처럼 PO는 프로덕트의 방향성을 고민하고, 고객의 입장에서 생각하고, 데이터를 분석하면서 여러 가지 결정을 내리는 일에 집중해야 하기 때문에, 직접 개발을 하거나, 대시보드를 만드는 등 시간을 낭비하지 않도록 주의해야 한다.
PM, PO의 일은 전문성이 있지만 상대적으로 General 하기 때문에, 자칫 핵심 업무에서 벗어나는 다른 업무까지 진행하는 경우가 생긴다. 나 역시 BA로 일했던 전적과 회사 차원에서 분석가 리소스 또한 부족하기 때문에 팀의 데이터와 관련된 실무를 함께 보고 있다. 물론 니일내일을 따지기보다 필요한 일이 되도록 하는 것이 우선이다. 그럼에도 내 실제 업무에 집중하기 위해서는 AI를 활용하거나 부서 간 협업을 요청하는 등 어떤 형태로든 이 일을 덜어낼 방향은 계속 찾아야 한다고 느꼈다.
