조직을 성공으로 이끄는 프로덕트 오너

저자: 김성한

http://topclass.chosun.com/news/articleView.html?idxno=5505

김성한 쿠팡 프로덕트 오너 - 톱클래스

장르: 경제 경영
평점: 8/10
독서 기간: 2022년 5월 20일 ~ 2023년 7월 11일
독서 방법: ebook & PM 독서 스터디

 

왜 이 책을 읽었을까?

이 책은 M사 PM으로 입사하면서 당시 팀의 매니저가 읽어보라고 추천해 준 책이었다. 혼자서 읽다 말다를 몇 번 반복한 후, 같은 팀 팀원과 매달 1~2 챕터를 스터디 하는 형태로 결국 끝까지 읽어냈다. 오랜 기간 동안 읽었지만, 실제 PM들이 머리를 맞대고 현업의 업무와 책에 나온 내용을 비교해 가며 토론을 하며 읽었기 때문에 집중해서 읽을 수 있었다.

 

지극히 주관적인 감상평

이 책은 PO/PM에게 중요한 내용들을 빠짐없이 잘 정리한 책이다. 책에 재미있는 사례도 많이 나와서 지루한 책은 아닌데, 왜 읽는데 오래 걸렸을까. PM의 업무는, 특히 한국에서, 회사마다 업의 정의나 범위가 매우 다양한 편인데도 책에서 묘사된 부분들이 실제 현실과 많이 닮아 있었다. 그래서 많은 부분에 공감하면서 읽을 수 있었다. 그리고 이미 내용은 알고 있지만, 바쁘다 보면 놓치기 쉬운 것들, 실제로 지키기 어려운 것들을 다시 한 번 곱씹을 수 있어서 좋았다. PM으로 커리어를 전환하거나 새롭게 도전해 보고 싶은 분들께 추천! 이미 빡센 PM의 삶을 살고 계신 분들께는 살짝 당연하고, 지루하게 느껴질 수도..?

 

배운 것

새롭게 배운 내용은 없었지만, 중요한 개념들은 체화시켜서 자연스럽게 행동으로 이어지도록 해야 하므로 PM으로서 핵심 기본기들을 다시 곱씹어보는 시간들이었다.

좋았던 구절

(원문을 그대로 사용하지 않고, 중요하다고 생각하는 내용을 모아서 재구성하였습니다.)

 

<PO의 자질>

프로덕트 오너는 고객이 프로덕트에 감동을 느낄 수 있게 고객의 입장에서 고민을 거듭하고 프로덕트를 고안하는 사람들이다. PO에게 가장 중요한 자질은 진정으로 고객의 입장이 되어 고객이 무엇을 필요로 하는지, 무엇을 만족하는지, 그리고 무엇을 불편해하는지 공감하고 생각할 수 있는 능력이다. PO는 자신이 책임진 프로덕트가 어떤 고객을 위해 무슨 가치를 제공하고 있는지, 그리고 회사 전체의 목표에 어떤 역할을 하고 있는지 알고 있어야 한다.

PO는 문제를 해결해야 하는 존재다. PO는 자신이 어떤 문제를 해결하고 있고, 달성하고자 하는 목표가 무엇이고, 어떤 가설을 설정했고, 그걸 왜, 그리고 어떻게 증명해야 하는지 명확하게 알아야 한다. 이것이 PO가 존재하는 핵심 이유다. PO는 단순히 직감만으로 개발 결정을 내릴 수 없다. 모든 이를 설득할 수 있도록 가설을 만든다. 어떤 생각을 당연하게 여겨서는 안 된다.

<우선순위, 의사결정>

PO는 모든 상황의 중심에 있으므로 감정과 직관에 치우치지 않고, 사실을 기반으로 모두를 위한 최선의 우선순위와 결정을 내려야 할 책임이 있다. 우선 순위를 정하기 어려울 때는 ‘오직 한쪽만 택해야 한다’는 극단적인 상황을 가정하는 것이 도움이 된다. 우선순위를 정했으면, 그게 회사가 추구하는 사업목적과 부합하는지도 확인하라. 사업 관점에서 비용에 대한 고민도 하고, 운영단의 불편함은 없는지. 새로운 기능에 대한 고객 문의는 어떻게 대답해야 하는지도 협업을 통해 정한다. 법률적 문제를 미연에 방지하기 위해 법률팀의 검토도 받는다. 결론이 바로 내려지는 경우는 드물다. PO는 모두가 동의하는 결정이 내려질 때까지 대화를 이어간다. 입장에 부딪혀도 데이터에 기반한 근거를 제시하며 설득하도록 한다.

결정을 내릴 때 언제든지 잣대로 삼을 수 있는 원칙이 필요하다. PO 스스로 결정을 내릴 때, 다른 이와 토론할 때, 주장을 뒷받침할 때 유용하다. 원칙은 오늘 내가 담당하던 프로덕트가 다른 PO에게 넘어가더라도 그 PO가 이 원칙을 따를 경우 문제 없이 개발이 이어질 정도로 정확해야 한다.

<데이터, A/B 테스트>

PO는 자신이 책임지고 있는 프로덕트와 관련되어 어떤 데이터가 축적되고 있는지 명확하게 알아야 한다. 만약 기존 데이터만으로는 유의미한 테스트가 불가능하다고 판단되면, 개발팀과 논의하여 필요한 데이터가 쌓일 수 있는 구조로 개선하도록 하자.

A/B 테스트의 목적은 가장 중요한 수치 몇 가지의 변화를 검증하는 것이다. 일단 테스트를 시작해놓고 어떤 수치가 긍정적으로 변화하는지 지켜보면 절대로 안 된다. 새로운 기능이 끼치는 영향을 세밀하게 보려면, 성공지표뿐만 아니라 프로덕트 전반의 수치도 봐야 한다. 만약 A/B 테스트 결과가 원래 설정해뒀던 지표를 달성할 수 없을 것 같으면 포기해야 한다. 테스트 결과가 유의미하지 않으면 그동안 투자한 시간을 아까워하지 말고, 결과를 납득하고 그 다음 가설을 설정해야 개발 조직과 디자이너도 시간을 허비하지 않는다.

행동을 부르지 않는 데이터는 버린다. 도움이 되는 데이터 분석은 데이터를 통해 얻은 인사이트를 토대로 그 다음 어떤 행동으로 옮겨야 하는지 명확하게 제시되어야 한다. 모든 데이터 분석의 결과는 actionable 해야 한다.

<디자인>

PO는 도출되어야 하는 결과와 의사 결정 과정에서 지켜야 하는 원칙을 명확하게 알려주는 의무만 있을 뿐이다. 실제로 고객에게 선보일 방식, 고객 경험과 관련된 결정 권한은 전적으로 디자이너에게 맡겨야 한다. 디자인 시안을 처음 접할 때에는 PO의 입장이 아닌 일반 사용자의 관점에서 볼 수 있도록 연습한다. 디자이너의 결과물을 리뷰할 때에는 질문의 형태로만 의견을 피력한다. 절대로 지시하지 않는다.

캐주얼 UT를 통해 주요 사용법과 불편한 점을 확인하는 것만으로도 충분하다. 대상자 한 명으로부터 너무 많은 것을 얻어내려고 하지 말고, 짧게 짧게 다수의 대상자를 통해 진행한 후 대다수가 느끼는 부분을 확보하는 것이 훨씬 더 유용하다. 일정을 계획할 때 미리 UT 일정을 확정하고 피드백을 반영할 시간까지 계획해놔야 한다.

<론칭 및 론칭 후 커뮤니케이션>

새로운 디자인이나 기능을 배포할 때는 곧바로 모든 사용자에게 보여주기 보다는 소수에게 먼저 보여준 다음 점차적으로 노출 빈도를 높이자. 시스템 또는 회사 매출 등의 데이터를 보면서 악영향을 끼치지 않는지 검증할 수 있기 때문이다. 프로덕트는 계속해서 개선될 뿐, 완벽한 프로덕트는 없다. 문제가 발생할 경우 언제 문제가 발생했고, 문제를 인지할 때까지 시간이 얼마나 소요됐는지, 고객에 끼친 영향의 규모, 문제 발생 원인, 단기, 중장기 솔루션 등을 문서화 하자.

PO에게 VOC만큼 소중한 정보는 없다. 고객의 의견을 수렴하고, 고객이 느끼는 불편함을 제거하고, 고객이 원하는 가치를 제공하는 프로덕트를 만들 때, 고객의 생각을 생생하게 접할 수 있다는 것은 축복에 가깝다.