당신은 PO를 아십니까? 프로덕트 오너

 

조금은 가벼운 마음에 이 책을 들었다.

내가 선택한 책은 아니었고 독서 모임에서 선택이 돼서 선정된 책인데 사실 독서모임에서 선정된 책들이 대부분 읽기에 그리 어려움이 없었던 책이라서 조금은 손쉽게 생각했었다. 사실 애자일도 그냥 읽어보고 '아 그냥 그런 조직이구나' 정도로 생각만 하고 있지 실제로 내가 다니는 회사에서는 적용이 되지도 않고 있고 적용할 의지도(?) 없어 보이기 때문에 남의 나라 이야기였다. 거기다가 PM이니 PO니 하는 이야기는 정말 들어본 적도 거의 없기 때문에(다른 사람 채용하는 것은 많이 본 거 같은데...) 책을 읽으면서 다소 어려운 점이 눈에 띄기 시작했다. 애초에 프로젝트 그룹이라는 것에 참여해 본 적이 없으니 내용 자체가 머릿속에 그려지지 않았던 것이다! 그럼에도 같은 독서 모임 사람들은 정말 좋은 책이라고 하니 그래도 한 번 진득하게 파 보기로 했다(그 덕에 책을 읽는 속도가 현저히 느려지는 단점이 있긴 했다)

 

<1장 프로덕트 오너는 미니 CEO이다>

1장에서는 프로덕트 오너란 어떤 사람인가에 대해서 나와 있는 부분이다. 사실 읽다가 보니 PO는 스스로가 플랫폼이자 플랫폼을 구축하는 역할을 하는 사람으로서 하나의 프로덕트에 있어서 최상의 귄위(?)를 가지고 있는 사람을 지칭한다. 특히 잘해야 하는 부분이라고 생각이 되는 것이 커뮤니케이션 부분인데 개발자와 고객의 최접점에 서 있는 사람이기 때문에 고객의 불만을 온 몸으로 받아내야 하고 개발자와의 불화를 최전선에서 부딪혀야 하는 입장이다. 결국 회사는 개발자보다는 고객 편이어야 하기 때문에 PO에게 많은 권한을 주고 개발자를 쪼으면 어떨까도 생각을 해 보았는데 그렇게 되면 개발자로 하여금 무언가 만들어서 성공시켜야 되는 의지보다는 'PO의 입맛에 맞게' 만든다는 생각을 갖게 되기 때문에 그리 좋은 방법은 아니라고 한다. 하지만 고객에 대해서는 집착을 끊임없이 해야 하는 자리는 맡는 것 같다.

 

<2장 고객의 목소리를 어디까지 반영할 것인가>

고객의 소리는 무엇보다 중요하다고 하지만 모든 고객은 한 목소리를 내지는 않는다. 따라서 반영은 하되 내부적으로 조율을 하거나 편의성을 증대시키는 것 자체에 대해서는 PO의 능력이 필요한 부분이 많다. 개인적으로 이러한 UI시스템에서 가장 의견 반영이 잘된다고 생각이 드는 회사는 카카오라고 생각이 되는데 매 번 업그레이드를 할 때마다 카카오톡을 쓰면서 추가 되었으면 하는 기능이나 새로운 기능들이 하나씩 늘어나고 안정화되면서 점차 '절대 없으면 안 되는 프로그램'으로 거듭나고 있다. 고객 입장에서는 다른 더 훌륭한 메신저가 나오더라도 워낙 카카오톡과 연동되어 있는 것과 편의성으로 인해서 절대 바꾸기 힘든 프로그램이 되어가고 있다는 의미이다. 다만 마지막 부분에 나오는 '고객과 회사의 입장 중 상충되면 어떤 것을 따라야 하는가?'에 대한 부분에 있어서는 회사의 장기 목표에 따라가는 것이 옳다는 의견이 재미있던 것 같다. 고객을 중요시 하지만 회사의 장기 플랜은 더 중요하다는 의미라기보다는 지향점에 있어서 흔들리지 않는다라는 표현이 더 옳은 표현인 듯하다.

 

<3장 데이터 속에서 진실을 찾는 팁>

'데이터를 신뢰하라'

PO의 입장이 되어서 생각을 해 보면 본인이 일정기간 이상 일을 하게 되면 갖게 되는 '직관'이라는 것이 있다. 데이터에서 보이지 않는 무언가가 있다는 말로 표현이 되는 것이 있는데 어쩌면 그렇게 한 경우 성공이 되는 경우도 있으나 PO의 경우 전략을 연구하는 사람은 아니기 때문에 데이터를 신뢰하라는 내용이 나온다. 다만 그 데이터를 신뢰하기 위해서는 데이터의 신뢰성에 많은 공을 들여야 하는데 이런 조건을 잘 설정할 수 있어야 PO로서의 역할을 다 할 수 있다고 본다. 검증법도 확실해야 하고 가설과 조직의 방향성(OKR)까지 관리를 해야 하는 것을 잊으면 안 된다.

 

<4장 효율적인 일정 관리의 비밀>

일정 관리의 경우 사실 커뮤니케이션이 많은 비중을 차지하게 된다. 특히 목적/배경 정보/어떤 일을 하는지/원칙/목표/주요 지표/개발계획/FAQ 등이 명확하게 담겨 있다면 개발자로 하여금 다시 대화를 하거나 하는 시간 낭비를 줄일 수 있을 거라 생각해 본다. 개인적으로는 위의 내용 중에 '원칙'이라는 부분이 가장 마음에 와 닿는데 PO가 개발자로 하여금 무분별하게 지시를 하거나 개발자들이 자의적으로 판단을 하여 실제 필요한 내용을 넣지 못하고 진행하는 경우도 있는데 이런 부분에 있어서 원칙을 세우는 것은 매우 중요한 포인트라고 생각이 된다.

 

<5장 디자이너를 최고의 파트너로 삼는 법>

우리가 오프라인이든 온라인이든 모든 제품에 대한 정보는 인터넷으로 확인이 가능하다. 애플리케이션을 활용해서 하든 아니면 실제 웹페이지로 하든 시각적으로 보여주는 것이 굉장히 중요하다는 것인데 이런 부분에 있어서 UI/UX 부분은 굉장히 중요한 역할을 한다고 본다. 그래서 최근 역할이 굉장히 중요해지긴 했는데 여기서는 PO의 경우 디자이너가 아닌 고객의 입장에서 의견을 제시해야 한다고 한다. 이 부분이 불편함이 있는 경우 고객의 입장에서 가장 크게 불편함을 느끼게 되고 이탈을 하게 되는 원인이 되는데 이것을 바로잡기 위해서 자체적인 캐주얼 UT(User Test)을 통해서 자부서 혹은 자회사 사람들이(어쩌면 가장 많이 알고 있을) 가질 수 있는 불편함에 대해서 확인하고 사전에 그런 부분을 제거하며 디자이너로 하여금 나중에 일이 몰아치게 하는 것을 방지할 수 있다.

 

<6장 개발팀과의 협업을 성과로 이끄는 애자일 전략>
스프린트 플래닝에 대해서 아는가? 애자일에서 실행하는 실천법 중 하나로 애자일을 애자일답게 만드는 중요한 메커니즘이라고 하는데 보통 2주 단위 집중적으로 개발을 하고 성과 파악을 한 후 다시 2주 단위로 진행을 하는 것을 의미한다(스프린트는 전력 질주라고 생각을 하면 된다) 애자일 방식이 좋다고 하는 부분이 여기서 나오는데 반대로 개발자 입장에서는 이런 업무의 시작이 죽을 맛이지 않을까라는 생각도 해보게 된다. 다만 PO의 입장에서 이렇게 2주 단위로 하는 것을 하게 되면 문제가 생기거나 변동사항이 생겼을 때 즉각적인 대응이 가능하여 일정 조율도 어느 정도 가능하게 된다고 한다. 다만 항상 이슈가 되는 '완료일'의 경우 PO가 선정하는 데드라인 방식이 아니라 개발은 개발 매니저에게 디자인은 디자인 매니저에게 맡기되 조율하는 조율자가 되어야 하는 것이 중요하다고 한다. PO는 일방적으로 강요하지도 강요받지도 않아야 되는 입장이기 때문에 전반적으로 모든 일정 부분에 대해서는 빠삭하게 알고 있어야 하는 게 중요하다.

 

<7장 고객 테스트 결과만큼 강력한 데이터는 없다>

실질적으로 모든 제반이 만들어지면 UT를 진행하게 된다. 대상이 많으면 많을수록 P값에 의거하여 데이터의 신뢰성을 늘릴 수 있지만 그것이 마음처럼 쉽지 않은 경우가 있을 것이다. 다만 그런 부분에 있어서 PO는 최대한 고객 테스트의 결과에 대해서 신뢰성을 높일 수 있도록 조건을 지정하며 대상자 섭외에 힘을 들여야 한다. 또한 이에 대한 정리를 잘해두면 나중에 동일한 이슈로 문제가 되는 것을 미연에 방지할 수 있다.

 

<8장 프로덕트를 출시하는 최적의 시기>

이건 뭐 딱히 내가 정리할 필요가 없이 책에 깔끔하게 나와 있다.

- 개발 조직이 정한 배포 일정이나 절차가 있는지 먼저 확인한다.

- 다른 팀과의 협업이 필요한 상황이라면, 최대한 미리 배포 일자를 협의한다.

- 가급적이면 저녁 늦게 또는 금요일에 배포하지 않는다.

- A/B테스트를 통해 트래픽을 분산시킨다.

뭐, 이 정도면 되지 않을까? 실제 해 본 경험이 없어서 딱 이 정도가 나의 한계인 듯하다.

 

<9장 테스트 중 가설을 효과적으로 검증하려면?>

대학원 때 배웠던 것을 활용하는 부분이 되었다. 경영통계 시간에 배웠던 유의미한 P값에 대한 내용인데(문제는 내가 지금도 그걸 이해를 못했다는 건데...) 신뢰성 높은 데이터를 위해 노력을 하고 그것에 대해서 실패한 결과가 나오는 경우 인정하고 새로 다시 해야 더 나은 경험을 제공할 수 있게 된다. 특히 인간이 가질 수 있는 '자기중심적 편향'의 영향에서 최대한 멀게 이성적으로 판단하는 것이 중요하다. 이런 부분은 경험이 말해줄 수도 있지만 노력을 해도 유의미하지 않다면 다른 가설을 설정해야 한다. 그것이 PO의 큰 역할 중 하나이다.

 

<10장 론칭한 서비스의 문제를 바로잡기>

새로운 서비스가 론칭하면서 큰 변화가 있을 수 있다. 국내의 많은 기업들이 참 못하는 것 중 하나가 대규모 업데이트 이후 문제가 생겼을 때 정작 소비자와 최접점에 있는 고객센터에서는 무슨 내용인지 전혀 파악이 되지 않는 경우가 있다는 점이다. 하청을 주거나 높게 평가하지 않아서 그런 문제가 생기는 경우가 왕왕 있는데 누구보다 빠르게 알아야 하는 것이 고객센터가 아닌가 생각이 된다. 그리고 모든 프로덕트는 '당연히 완벽하지 않다.' 그래서 그런 문제를 바로 잡는 것도 중요한 부분이다(심하면 롤백을 해야 하니 말이다) 국내 게임 업체들 중 이러한 부분을 제대로 대응하지 못해서 역사 속으로 사라진 곳도 꽤나 있다. PO는 특히 사무실에 앉아서 가만히 플랫폼의 역할만 하는 것이 아니라 그곳을 탈피해서 직접 고객의 소리를 들어보는 것도 중요하다고 한다. 뭔가 내용이 걸러져서 오는 것보다 실제 고객들의 불만을 직접 들어보는 것도 방법이라는 생각이 든다.

 

<11장 어떤 인재를 PO로 선발해야 하는가>

나요.

장난이고 위와 같은 업무를 하면서 항상 긴장감이 있고 조율이 필요하며 24시간 대기를 해야 하는 경우가 발생한다. 어쩌면 책임은 크고 업무량은 과다하며 권한은 그리 없는 존재이기 때문에 최근 MZ세대에게는 매력 없는 직무일 수도 있으나 반대로 보자면 이런 업무를 완벽하게 할 수 있는 사람이 없기 때문에 각광받는 직종이 될 수도 있다(그래서 저자도 이직 좀 했나 보다) 오너십이 필요하고 일감과 환경에 따라 PO직무 자체를 채용해야 하는가 마는가에 대해서 정할 필요도 있다. 최근에는 전반적으로 경력을 뽑는 케이스가 늘어나고 있는 듯한데 회사 입장에서 장기적으로는 신입사원 때부터 여러 직무를 할 수 있는 사람을 미래 PO로 점찍어서 발전시키는 것도 필요하다고 생각이 된다. PO 본연의 업무도 알아야 하지만 회사 내 조직 구성과 현황을 가장 잘 아는 사람이 유리하다는 의미도 된다.