프로덕트 오너는 어떤 일을 하는 사람일까??

프로덕트 오너 / 책 리뷰

얼마 전 쿠팡 PO출신이 출간한 프로덕트 오너 책을 읽었다.

스타트업에 관심이 많아서 관련 직무들을 찾아보니 프로덕트 오너를 알게 되었다.

이 책은 ‘프로덕트 오너 = Product Owner’라는 직무에 대해서 희미한 안개를 걷어주기에 충분한 책이라고 소개하고 싶다. 그 이유는 PO가 어떤 역할을 맡고, 무슨 일을 하는지, 누구랑 같이 협업을 하는지 알 수 있다.

또한, UT = User Test 실전 사례 + 스프린트 플래닝에 들어가기 전 문서들을 어떻게 작성하고 개발 조직원들에게 공유하는지 아주 자세하게 나와있다. 각 장마다 마지막 부분에 실전 TIP 부분들이 나오는데 질문을 통해서 왜 이런 생각을 가졌는지에 대해서 곰곰이 생각하게 만든다.  

사용자는 어떤 가치를 얻으려고 하는가?

성공적으로 제공했다는 사실을 데이터로 증명 가능한가?

1. 프로덕트 오너란?

프로덕트 오너는 ‘미니 CEO’라고 많이 불리는데, 말 그대로 하나의 프로덕트에 대한 책임을 지고 기획, 분석, 디자인, 개발, 테스트, 출시, 운영까지 주도하는 사람을 일컫는 말이다.

스마트폰 안에서 사용되는 모든 앱은 프로덕트고, 그걸 책임지는 사람이 PO다.

PO는 고객이 필요한 부분이 무엇인지 끊임없이 분석하고, 선보이려는 서비스가 사업 목표와 부합하는지 검증한다. 그리고 개발자나 디자이너 같은 메이커와 새로운 기능을 만들거나 기존 서비스를 개선하기 때문에 PO는 수많은 사람들을 만나고, 질문에 답하고, 결정을 내려줘야 한다.

중요한 역량은 늘 명확한 사실과 데이터로 분석하여 설득해야 한다는 점이다.

명확한 사실과 데이터 기반을 가지고 설득해야 개발자, 디자이너, 데이터 과학자 등 모두가 한 목표를 가지고 오류 없이 좋은 프로덕트를 만들 수 있다. 기본적으로 개발자, 디자이너, 데이터 과학자 등등 프로덕트에 투입되는 인력들의 기본적인 업의 특성에 대해서 이해를 해야 같이 협업이 가능하다. 직접 개발을 하지는 않지만 개발자들이 개발 프로그램을 무엇을 쓰고, 디자이너들이 쓰는 프로토타입 툴은 무엇인지, "작업 진척 상황이 왜 느린지?" 알려면 그들의 업을 이해하지 못하면 의사소통이 안되기 때문에 협업하기가 매우 어렵다. 앞서 얘기했듯이 "PO = 미니 CEO다." PO는 모든 사람이 지켜보는 존재이고 개발자, 디자이너, 비즈니스 애널리스트 등은 물론, 회사 내 외부 고객과 사업부, 심지어 경영진까지 지켜보고 있다. PO는 개발자, 디자이너, 비즈니스 애널리스트 등이 각자의 임무를 잘 이행할 수 있도록 요구사항을 명확하게 하고 방향성을 제시하는 데 집중해야 한다.

PO는 내부에서만 일을 하는 게 아니라 쿠팡의 전국 현장을 직접 들러 유관 부서원들을 만나고 의견을 취합한다. 스크럼 회의, 스프린트 플래닝 회의 때 개발 조직과 공유한다.

전국의 다양한 현장을 직접 보기 위해, 배송하기 가장 까다로운 곳 중 하나라는 경남 지역에 찾아가 며칠 머물며 갖가지 현장에서 쿠팡 맨과 실제 배송을 함께 했다. 직접 물건을 들어 나르고, 한 곳을 배송하기 위해 얼마나 많은 계단을 올라야 하는지, 그리고 몇 분이나 걸렸는지 등을 계속 측정하며 기록했다. 우리가 롯데월드타워를 계단으로 오른 것만큼이나 걸었다는 사실이 스마트 워치에 떴다. PO가 이행해야 하는 가장 중요한 의무 중 하나는 고객에게 집착하는 것이다. 현장이 있으면 현장으로, 공장이 있으면 공장으로, 판매처가 있다면 판매처, 심지어 단순하게 고객센터에 가서 전화 통화를 옆에서 들어도 도움이 된다. 각각의 고객이 무엇을 불편하게 여기는지, 어떤 경험을 원하는지 등을 데이터까지 분석하며 파악한다.
-프로덕트 오너 책에서

PO의 역할
-습관
-데이터 속에서 진실을 찾는 법

순전히 고객이 느낄 불편함을 제거할 목적으로 질문해야 한다. 우선순위는 고객을 위한 최적의 프로덕트를 탄생시키는 것이지, 동료의 감정을 살피는 것이 아니기 때문이다. 개발자와 디자이너가 최대한 본연의 업무에 집중할 수 있도록, PO가 대신 소통을 책임지는 것이다. PO는 요구사항을 전달해야 한다. 요구사항이란 프로덕트가 갖춰야 하는 기능, 고려해야 하는 제약, 추구하고자 하는 목표 등을 설명하는 것이다. 오로지 고객 중심적인 관점으로 어떤 경험을 제공해야 하는지 객관적으로 설명해야 한다.

PO는 오로지 고객을 대변하는 입장이어야 한다. 감정, 관계 등을 일체 배제한다.

개발하고자 하는 기능에 대해 정한 원칙에 기반하여 판단한다.

디자이너에게는 질문의 형태로만 의견을 피력한다. 절대로 지시하지 않는다.

질문한 후에는 디자이너의 의견을 경청한다. 모든 시안은 고심의 결정체다.

구두로 거론된 내용을 회의 직후 기록하여 전달한다. 디자이너가 선호하는 방식을 따른다.

저자는 1000개가 넘는 앱이 상시 설치된 적이 있었다. 전자상거래, 게임, SNS, 음악, 이메일, 사진, 편집, 핀테크 등 분야를 막론하고 새로운 서비스는 다 사용해보려고 했다고 저자는 말한다. 이렇게 하는 이유는 (UX, UI)적인 측면이 어떤 플랫폼이 뛰어난지 또 어떤 앱이 불편했는지 느낄 수 있기 때문이다. 잘 만든 앱, 못 만든 앱의 차이가 어디에서 파생되는지 분석하지 않으면 고객들에게 잘 팔리는 프로덕트를 제공할 수 없다는 저자의 이야기이다. 한 번에 많은 플랫폼을 다운로드하는 것보단 현재 내가 자주 이용하는 플랫폼(앱)들을 분석해보는 것도 좋은 방법이라고 생각한다.  

ex) 쿠팡, 카카오톡, 배달의민족 <- 이 플랫폼들은 왜 성공하게 되었는지 + 나는 왜 이 플랫폼을 자주 이용하는지 본인의 경험을 살려서 분석하면 조금 더 가슴에 와닿는 직관이 생길 것이다. 이런 작업을 매일 아니더라도 새로운 플랫폼 혹은 핫한 플랫폼이 나오면 잘 될지 안 될지 꾸준하게 분석하다 보면 플랫폼을 분석하는 능력이 상승할 것이라고 나는 확신한다.

나는 기존에 KB은행을 이용했지만, 토스 뱅크로 옮겼다.

why? 왜냐하면 어렵지 않고 간단하게 만들었다는 점이다. 돈을 송금할 때 타 은행 및 증권 계좌들을 한눈에 보기 좋게 나와 있기 때문에 외우지 않고 송금 버튼만 누르면 되는 편리함을 느꼈기 때문이다. 그리고 매일매일 이자가 쌓이는 혜택으로 한 달에 치킨값 이상씩 매달 이자를 받고 있다. KB는 토스만큼 좋은 혜택과 UX가 안 좋았기 때문에 나처럼 토스로 이동한 고객들이 많았을 것이라고 생각한다. 사소한 습관 하나가 수십 개, 수백 개, 수천 개가 쌓이면 혁신이 일어난다. 그렇기 때문에 편리함 또는 불편함을 느꼈을 경우, 기억해뒀다가 무엇이 불편했는지 좋았는지 기록하는 습관을 가져보자.

-안내문구

-버튼의 위치

-사용된 색상, 글꼴, 글자 크기 등등

고객의 관점으로 플랫폼을 보는 습관을 가지다 보면 남들과 다른 관점이 생길게 분명하다.

나는 매주 1주일에 한 번 VC동향을 체크하면서 수많은 점들을 쌓아나가고 있다.

저자는 자사 플랫폼 쿠팡을 이용하면서 리뷰를 남겼고, 탑 리뷰어 배지를 달았다고 한다. 이렇게 경험하여 구축한 사용자 관점 덕분에 고객 경험과 디자인에 대한 비평을 할 수 있었다고 말한다.

<데이터 속에서 진실을 찾는 법>

PO는 자신을 믿지 말고 데이터를 신뢰해야 한다.

PO라면 자신에게 주어진 데이터를 그대로 받아들여서는 안 된다. “치킨 카테고리 노출이 더 잘되도록 제가 변경했기 때문에 치킨 매출이 올랐다”라고 공표하기 전, 그게 얼마나 유요한 결론인지 검증해야 한다.

특히 긍정적으로 보이는 데이터일수록 거짓이라고 가정해본 후 철저하게 파고들어야 한다.

마케팅 부서에서 치킨 주문 관련 프로모션을 진행하지 않았나?

영업 부서에서 치킨 판매처를 추가하지 않았나?

초복이나 중복 같은 복날이 지난주에 있었나?

고객 수가 증가하지 않았나?

데이터를 분석할 때 이런 외부 요인에도 관심을 갖고 연관성을 확인해봐야 한다.  

Ex) 월드컵, 초복

내 외부 요인이 없었다면 단순히 고객 수가 증가했을 수도 있다.

앱스토어 메인 화면에 노출되었거나, 입소문 등으로 인해 고객 수가 늘어서 주문량이 많아졌을 가능성이 있다. 이럴 경우 그 전주 대비 고객 수의 증가량, 그리고 고객당 평균 치킨 구매율 등도 확인해본다.

데이터를 뜯어보고 또 보고, 데이터가 축적되는 방식까지도 검증하도록 한다.

프로덕트 오너 총정리

PO가 데이터를 보고, 고객의 소리를 듣고, 가설을 설정하지 못한다면, PO는 필요 없다. 프로덕트 오너는 본질이 무엇인지 파악하지 못하고 문제를 해결하지 못한다면 개발자, 디자이너, 애널리스트 들은 나의 의사결정 때문에 계속 기다릴 것이다. 기다린 만큼 그들의 작업은 다음 단계로 진행이 안 되는 것이다. 그렇기 때문에 문제를 제대로 파악하고, 주어진 자원이 무엇인지 고민해본 다음, 로직을 짜 본 후, 프로덕트를 어떻게 구현할지 설명하고, 검증하는 절차까지 고려하여 문제를 해결해야 한다.

<프로덕트 오너의 역량>

-이성적으로 수치화하고, 원칙에 의거해 판단할 수 있는 논리적인 사고방식은 필수다.

-다양한 정보를 집요하게 파고들어 인사이트를 도출해낼 수 있는 분석 능력도 필요하다.

-수많은 사안 중 어떤 것을 먼저 처리해야 할지, 우선순위를 정할 수 있는 거시적인 시야를 갖춰야 한다.

-여러 직무 집단 사이에서 공통적인 목적을 명시하고 구체적인 요구사항을 정리하는 커뮤니케이션 능력이 있어야 한다.

-사용자 관점에서 어떤 시안이 가장 효과적인지 판단할 수 있는 디자인적 소양도 도움이 된다.

-한 번 시작한 업무를 끝까지 이어갈 수 있는 추진력도 필요하지만, 실패를 인정하고 빨리 포기할 수 있는 결단력도 있어야 한다.

-선보이고자 하는 프로덕트의 고객이 누구인지 판단하고, 집요하게 집착해서 최상의 경험을 제공하고자 하는 끈질김이 필요하다.

책에 나와있는 내용들을 가지고 나의 생각들도 정리를 해보았다.

스타트업에 관심이 있다면 필독해야 하는 책이다.

추천한다.

"프로덕트 오너의 본질은 고객 집착과 목표 지향적 사고입니다"

출처 - 아웃스탠딩

저의 책 리스트가 궁금하다면 확인하세요

불도저가 운영 중인 독서 커뮤니티 관심 있다면 확인하세요

� 좋은 책을 읽고 함께 얘기하는 클럽

� 매일 밤 12시 경제 신문보기

� 매주 월요일 VC 동향 체크