kooboy blog

TIL 좋은 Product Owner가 되기 까지는 멀고도 먼 길

April 24, 2020

TILProduct Owner

업계에서 유명한 PO 분을 만나 티타임을 가지게 되었다. 유명한 PO 님이라 부르면 너무 기니깐 ㅇㅇ님 이라고 부르겠다. 여러 방면에서 항상 도움을 주신던 분이라 밥과 차를 대접했다. 이런 산전수전 다 겪어본 스승과 같은 분이 내게 내어주시는 시간은 너무 귀해서 한 마디라도 더 듣고 잘 기억해야 한다.

나는 현재 회사에서 데이터 코스를 열기 위해 공부와 리서치를 병행하고 있다. 현재 팀원은 없지만 곧 오실 분을 생각하면 실질적으로 데이터 코스의 PO 역할을 하고 있는 셈이다. 그래서 나도 좋은 PO 가 되어야 한다고 요즘들어 남의 이야기가 아니라는 생각을 하고 있다. 오늘의 비공식? 인터뷰를 정리하면 다음과 같다. 아, 그리고 원래 PO != PM 이지만 이 대화에서는 PO=PM 으로 치환해서 생각해도 크게 무리는 없을 것 같다.

disclaimer: 대화는 실제 녹음된 기록이 없으므로 듣고 기억난 문장을 의역해서 기록한 것임을 밝힌다.

나: PO 라는 개념이 사실 그렇게 썩 익숙한 명칭은 아닌데요.

ㅇㅇ: 그렇다. 한국의 회사 조직 구조가 제품과 서비스 중심으로 팀이 꾸려지지 않는 것이 사실이다. 기능 위주, 팀 위주로 조직이 짜여있고, 서비스 런칭을 위해서는 여러 팀에서 서로 외주를 주듯이 일이 돌아가는 형편이다. 해외에선 제품 중심으로 조직이 꾸려져서 PO, 개발자, 디자이너 등이 함께 모여 해당 서비스, 제품의 명운을 위해 노력한다.

나: 왜 한국에선 제품 중심의 조직으로 꾸려지지 않는 건가요?

ㅇㅇ: 관리, 평가하기가 힘들어서다. 기능 위주로 가면 전통적이고 평가하는 것도 (해당 평가 방법이 좋건 나쁘건) 할 줄 안다. 하지만 제품 중심으로 가면 회사는 관리 및 평가 난이도가 높아진다고 생각하는 편이다.

나: 해당 제품의 명운에 따라 헤쳐 모여 하기가 어렵기도 해서일까요?

ㅇㅇ: 그렇게도 생각할 수 있다.

나: PO가 알아야 할 범위나 역량이 명확하지 않은 것 같아요.

ㅇㅇ: 그렇다. PO 역할을 하게 되면 정말 어디까지 알아야 하는지 스스로도 정의하기 어려운 경우가 많이 발생한다. 필요한 선보다 더 넘기도 하고 덜 가기도 한다. 예를 들어 이전에 디자인을 알아야 해서 스케치라는 툴을 직접 배웠는데, 지금 생각해보면 직접 할 줄 알아햘 필요까진 없던것 같다. 하지만 지금 와서 보면 스케치라는 툴을 할 줄 아는 것으로 얻는 유익이 크다.

나: PO는 결국, 개발, 디자인, 사용자 경험, 고객개발, PMF 등 모두를 조금씩 다 알아야 겠네요? 이거 스타트업 대표 아닌가요?

ㅇㅇ: 맞다. 조그만 스타트업 회사의 대표는 그래서 좋은 PO가 반드시 되어야 한다. 반드시. 말씀하신게 맞지만 그렇다고 PO가 여러 지식을 조금씩 그냥 아는 것에서 그치면 안 되고 이렇게 여러 역량을 종합해 내서 사용자가 좋아하는 제품을 만들어내는, 전문 분야로 인정받고 있다.

나: 개발자를 하다가, 디자인을 하다가, 기획 업무를 하다가 PO 로 커리어 전환을 하는 것은 이해가 되는데요. 신입으로 처음부터 PO 가 될 수 있나요?

ㅇㅇ: 될 수 있다고 생각한다. 얼마나 의지가 있는지가 중요하다. 예전엔 어느 업무로 시작하든지 멘 땅에 헤딩하며 배우다가 보니 PO에게 필요한 기술과 지식을 얻게 되는데, 꼭 필요한 내용과 기술들은 압축된 시간 안에서 충분히 교육이 가능하다고 본다. 물론 당연한 이야기지만, 이전 경력이 BDM, 기획자 혹은 기술이나 디자인 경험이 있으면 당연히 도움이 된다.

나: PO 가 되기 위한 필수 역량이나 동기가 있진 않을까요?

ㅇㅇ: 나같은 경우는 어느 회사가 투자를 받았다 하면, 해당 회사의 제품을 써 보는 편이다. 모바일 앱 같은 경우 다운 받아서 꼼꼼하게 하나 하나 다 눌러보고 경험을 노트에 기록한다. 이렇게 기록한 노트는 나중에 실제 내가 직접 서비스를 기획해야 할 때 엄청 도움이 된다. 그런데 이렇게 하나 하나 서비스를 써 보는게 내게 일이라고 생각하진 않는다. 취미이고 재밌다.

나: PO가 기획도 해야 하나요?

ㅇㅇ: 기획은 기본이다. 잘 해야 한다. 기획을 넘어서서 Specification(스펙)을 작성할 줄 알아야 한다. 예를 들어 텍스트 인풋 창을 스펙에 넣었는데, 텍스트 길이가 박스 사이즈보다 길어질 경우 어떻게 되어야 한다는 구체적인 부분까지 명시가 되어야 한다. 이 일을 개발자에게 떠넘기면 안 된다.

나: 개발자 모임은 많은 것 같은데 PO 커뮤니티는 없는 것 같아요. 왜죠?

ㅇㅇ: 개발자들은 공유하면 할 수록 결국 스스로에게 도움이 된다는 것이 명확하게 서로 설득이 된다. 하지만 PO의 경우 범위가 너무 넓어서 어디서부터 무슨 목적으로 모임이 만들어져야 하는지 애매하다. 하지만 있으면 좋겠다고 생각한다.

나: 만들어 주시죠

ㅇㅇ: 생각은 하고 있다.

나: 그런데 PO라는 타이틀은 이미 규모가 좀 큰 회사에서나 채용하지 않을까요?

ㅇㅇ: 원티드에서 검색해 보면 과거에 기획자, 등으로 뽑던 채용공고가 모두 PM, PO로 바뀌어 있다. 트렌드가 반영되고 있는 것 같다.

나: 말은 그렇게 써 놓고 그냥 과거의 기획자 업무를 시키진 않을까요?

ㅇㅇ: 그럴 수도 있다. 하지만 트렌드가 있고, 실제 product-driven 되는 조직의 장점이 많이 공유될 수록 변할 수 있다고 생각한다.

나: 그 동안 ㅇㅇ님의 경험을 토대로 책을 써 주시면 어떨까요? 전 살게요.

ㅇㅇ: 책 쓰는게 보통이 아니지만 생각해보겠다.

ㅇㅇ: 평소에 Notion에 항상 기록한다. 동영상, 텍스트 등 여러 서비스에 대한 나의 느낌과 경험을 기록하는 편이다. (스마트폰으로 여러 개 보여주심)

나: 와 이거 엄청난 자료들이네요.

ㅇㅇ: 한 번에 공유하고도 싶은데 그러지 않고 있다.

나: 한 번에 공유하기 보단 정기구독 서비스로 컨텐츠를 하나 하나씩 공유해 주시면 어떨가요? 유료로 해도 전 구매할게요.

ㅇㅇ: 흐음.. 나만의 기록에서 공유가 되려면 약간의 폴리싱 작업이 필요한데 흙

나: PO 가 셀원 평가도 하나요?

ㅇㅇ: PO 가 평가까지 하게 되면 PO 일에 집중하지 못하게 된다. 평가란 매니저 역할을 해야한다는 것인데 그러면 과연 맡은 제품을 갈고 닦는데 집중할 수 있을지 잘 모르겠다.

나: 그렇지만 평가를 하는 매니저가 평가에 있어 PO 의 의견을 주로 들을 것 같은데요.

ㅇㅇ: 꼭 PO라고 해서 무겁게 듣기 보다는 다면평가로 다른 여러 셀원들의 의견을 듣는 것이 좋다.

나: PO 역할을 하기 위해 data의 어느 범위와 깊이까지 알아야 하나요?

ㅇㅇ: PO로서 제품을 런칭하고 성공시키기 위해 수 많은 가설 실험 검증을 해야 한다. 예를 들어 A/B 테스트를 해야 하는데 A/B 테스트를 설계하는데 왜 그렇게 해야 하는지, 무얼 알아보고자 하는 것인지, 이후 테스트 결과를 어떻게 해석하고 다음 액션을 위해 팀을 설득해야 하는지 할 수 있어야 한다. p-value 를 어떻게 구하는지 공식을 알거나 이해하진 못하더라도 이미 만들어져있는 계산 사이트에 적절히 값을 임력해서 결과를 보고 해석할 줄은 알아야 한다.

나: 퍼포먼스 마케터 처럼 여러 Tool 도 잘 알고 자유자재로 활용할 줄 알아야 하나요?

ㅇㅇ: 어떤 툴이 있고 해당 툴로 무엇을 할 수 있는지 알아야 한다. 그래서 필요하면 사용할 수 있어야 한다.

나: 저희 회사에서 PM 코스가 곧 개강하는데 특강 한 번 해 주시죠

ㅇㅇ: 할 수 있을 것 같다.

나: 그냥 정규 강의로 계속 해 주시죠

ㅇㅇ: 그.. 그건 좀 그렇다. 특강은 괜찮을 것 같다.

나: 감사합니다.


Johnny Ilmo Koo

Welcome to Johnny Ilmo Koo's blog

...