brunch

You can make anything
by writing

C.S.Lewis

by 헤비듀티 Jul 30. 2022

새로 합류한 PO가 먼저 해야 할 일(02)

프로덕트 오너는 입사하면 무엇부터 해야 할까

여러 스타트업의 JD를 보면 우대사항으로 '스쿼드 조직 구조', '크로스 펑셔널팀'에서의 경험이 있다. 애자일 문화, 인함 등의 이유로 이런 조직 구조가 스타트업의 표본이 되고 있다. 본질적으론 회사의 전략을 가장 잘 수행할 수 있는 최선의 대안으로 평가받는 듯하다. 그 회사가 궁금하면 먼저 조직구조를 보면 된다. 무엇에 얼마큼 집중하고 있는지 알 수 있기 때문이다.

흔히 제품팀이란 표현도 쓰는데, 프로덕트 오너/프로덕트 매니저가 최근 더욱 각광을 받는 것도 이러한 조직구조 때문이다. 제품이 있고, 제품을 담당하는 팀이 있어야 프로덕트 오너나 프로덕트 매니저가 있을 수 있기 때문이다.

내가 새로 합류한 회사도 이런 조직 구조이며, 내가 맡은 스쿼드는 새로 신설된 팀이지만 나를 제외하곤 기존에 있던 분들이다. 스쿼드 조직 구조가 아닐 때는 각 직군별로 자신이 맡은 부분(e.g. 개발자는 서버, API와 같은 부분만)의 KPI를 달성하고 문제가 안 생기게 하는 것이 목표였다. 반면 스쿼드 조직구조는 모든 구성원들이 맡은 제품에 대해 오너십을 갖고 있다. 모든 팀원들의 목표가 제품의 성공이 되어야 하는 것이다.

거기서 프로덕트 오너(혹은 경우에 따라 프로덕트 매니저)는 제품의 전략/방향성을 제시하고 많은 액션 아이템 중 우선순위에 대한 의사결정 권한이 있다. 그렇다고 수직적인 조직 구조에서 팀장의 TOP-DOWN 방식이라 생각하면 안 된다. 팀원들의 의견을 이끌어내고 설득하고 공감시켜야 한다.(물론 TOP-DOWN과 BOTTOM-UP 이 적절히 조화되는 것이 필요하다.)

새로운 스쿼드. 기존에 있던 사람들. 새로운 프로덕트 오너. 이런 상황에서 나(프로덕트 오너)는 무엇부터 해야 할까. 먼저 강력한 리더십이 필요할까. 기가 막힌 전략이 우선일까. 모든 게 새로운 팀이라면(팀원들까지) 강력한 리더십이 작동할 수도 있다. 일하는 방식/문화가 정립되지 않았기 때문에 프로덕트 오너가 처음부터 끌고 나갈 필요가 있다.

반면 프로덕트 오너만 새로 합류한 상황이라면 조금 다른 방식이 좋을 수 있다. 빨리 나를 증명해야 한다는 압박이 있겠지만(특히 연차가 높은 경력자일수록), 분명한 건 나의 성과가 아닌 제품의 성공이 최우선이다. 그게 나를 증명하는 것과 같기 때문이다. 그러기 위해선 제품을 만들어나가는 팀원들과의 신뢰가 우선이며, 나는 이걸 '이 팀에 스며들기'라고 표현한다. 기존 팀원들은 그들만의 방식과 문화가 있다. 이를 무시하고 급격하게 변화를 모색한다면 오히려 함께 일할 사람들의 반발을 살 수 있다.

하드 스킬, 소프트 스킬 구분 없이 처음 합류하게 됐을 때, 내가 가장 먼저 해야 할 업무 리스트다.

1. 제품 파악하기

- 내가 맡은 제품이 무엇인지, 고객은 누구인지 정의해야 한다. 그리고 현재 진행하고 있는 태스크, 앞으로 해야 할 태스크만 파악하는 것이 아니라 과거까지 파악하면 좋다. 과거(히스토리)는 놓치기 쉬운데, 오히려 이게 앞으로의 속도에 걸림돌이 될 수 있다. 뿐만 아니라 현재 이 일을 왜 하고 있고, 앞으로 해야 할 일이 어떻게 결정됐는지 알 수 있다.

- 제품의 정책/원칙을 숙지하고, 현재 상태의 제품의 핵심 기능과 부족한 부분을 정량적/정성적(voc 등) 데이터로 파악한다. 추가로 가능하다면 제품의 고질적인 문제까지 파악할 수 있으면 더 좋다.

- 뿐만 아니라 나의 제품을 계속 써보기, 유저의 목소리를 직접 들어보기, 경쟁사의 제품과 비교해보기는 기본이다.

2. 팀의 문화/업무방식 파악하기

- 기존 팀이 올바른 방향으로 가고 있는지 파악해야 한다. 그러기 위해선 명확한 비전과 목표가 잘 세워졌는지, 그리고 이를 달성하기 위한 전략과 로드맵 있는지 파악해야 한다. 단순히 팀원들이 공감하는 목표와 전략이 있는 것보단, 구체적으로 이에 대한 근거가 되는 데이터까지 확인하는 게 좋다.

- 그리고 실행이 잘 되고 있는지 알아야 한다. 목표와 전략을 세우고 실행은 효율적으로 못할 수 있기 때문이다. 어떤 방식과 얼마큼의 속도로 진행하는지는 알기 위해선 구체적인 하드 스킬에 대한 내용이므로 여기선 다루지 않겠다. 크게 보면 우선순위는 어떻게 정하는지, 일의 낭비가 없는지, 리스크를 가장 나중에 확인하는 건 아닌지, 팀의 목표를 달성하기 위한 핵심 인력이 있는지, 생산성은 어떤지를 확인하면 된다.

3. 1on1

- 제품팀의 과거와 현재를 파악하기 위해서, 그리고 신뢰를 쌓기 위한 가장 중요한 일이다. 기본적으로 생산적인 1on1은 어렵다. 처음부터 완전한 솔직함을 보여주는 팀원은 많진 않을 것이다. 그럼에도 성공적인 제품팀을 만들기 위해선 함께 만들어나가는 사람들이 가장 중요하다는 것을 잊지 않아야 한다.

- 초반 1on1은 제품과 제품팀을 알아가는 것을 집중해야 한다. 현재 팀원들은 나보다 제품을 더 많이 알고 있다. 즉, 권한과 역할 때문에 모르는 걸 감추는 것이 아니라 반대로 더 많이 빨리 알아야 한다는 모습을 보여주어야 한다. 예를 들어 1on1마다 내가 우리 제품과 팀에서 가장 먼저 알면 좋은 것들, 가장 필요한 게 무엇인지, 가장 중요한 건 무엇인지, 가장 문제가 되고 있는 건 무엇인지 물을 수 있을 것이다. 그리고 이것을 더 구체적으로 알기 위해 봐야 할 문서나 기록에 대해서도 물어보는 것이 좋다.

- 그리고 팀원들의 개인적인 커리어 패스도 알아가는 게 좋다. 다른 업무를 하고 싶은지, 직군 자체를 변경하고 싶은지, 매니저가 목표인지 스페셜리스트가 목표인지 등에 따라 팀을 어떻게 꾸려야 할지 계획을 세울 수 있다. 또한 팀원 입장에서도 단순히 '내가 목표를 달성하기 위한 도구'로 느끼지 않게 하고, 함께 성장하고 함께 고민할 수 있는 원팀이구나를 느낄 수 있어야 한다.

쉬운 일은 없지만, 훌륭한 프로덕트 오너/프로덕트 매니저는 어렵다. 결정은 하지만 설득과 공감이 바탕이 되어야 한다. 즉, 항상 설득하는 일이라 보면 된다. 또한 못하는 프로덕트 오너/프로덕트 매니저는 바로 티가 난다. 방향을 잘 못 잡으면 아무리 노를 잘 저어도 목적지에 갈 수 없기 때문이다. 뿐만 아니라 팀 내부적으로도 단결이 안된다.

그러나 훌륭한 프로덕트 오너/프로덕트 매니저는 빨리 티가 안 날 수 있다. 매일 바빠 보이지만(실제 바쁘기도 하다) 결과물이 없을 때가 많고, 컨텍스트 스위칭이 매우 잦아 '지금 내가 뭐 하고 있지'라는 생각이 들 수 있다. 본인은 많은 콘텍스트를 대응해야 해도 팀원들에겐 몰입할 수 있는 환경을 만들어줘야 하며, 권한은 많지 않더라도 제품과 팀의 최종 책임은 프로덕트 오너/프로덕트 매니저에게 있다.

외롭고 힘든 직업이지만, 그만큼 누구보다 많은 것을 얻을 수 있다.(제품과 사람으로부터, 금전적인 건 보너스)

keyword