일잘러 PM/PO는 '이것'할 수 있는 사람이다 (1)
[PM 북클럽] <프로덕트 오너(2020)> 요약 및 정리
서론:
PM/PO는
어떻게 생각하고,행동할까?
대학교에서 문화서비스산업 융합전공을 이수하면서 서비스 기획이라는 직무를 알게 됐다. 좀 더 공부하다 보니, 요즘은 서비스 기획보다도 PM/PO라는 직무가 대세라는 이야기를 들었다. "다 같은 기획자인데 뭐가 다를까?"하는 생각을 갖고 있던 나는 코드스테이츠 PMB 10기를 수료했고, 서비스 기획과 PM/PO의 차이점이 무엇인지 배웠다. 심하게 압축하자면 서비스 기획은 산출물과 문서 위주로 업무 사항을 가시화하는 직무에, PM/PO는 문제 정의와 문제 해결에 초점을 맞추어 관리하는 직무에 가깝다.
따라서 PM/PO라는 직무는 '이런이런 업무를 한다'라고 설명되기 어렵다. 또, 회사마다 업무 범위에 크고 작은 차이가 있기 때문에 PM/PO라는 같은 직무명을 달고서라도 하는 일이 판이할 수 있다. 그래서 PM/PO라는 직무는 "무엇을 하는가?"보다는 "왜 하는가?"로 설명될 수밖에 없다. PM/PO는 결국 고객 감동을 위한 솔루션이 실행될 수 있는 모든 수단과 방법을 동원하는 사람이기 때문에, 이 직무에게 중요한 것은 수단이나 방법이 아닌 목적이다. 이럴 때 나는 PM/PO라는 직무에 대해 다음과 같이 설명하길 즐긴다.
프로덕트 팀을 하나의 거대한 선박에 몸을 실은 선원들이라고 가정한다면, PM/PO는 배의 선미에 앞서서 망원경으로 수평선을 내다보고, 작은 조각배를 띄워 직접 그곳까지 다녀와 본 다음, 되돌아와서 팀원들에게 어떻게 하면 저쪽으로 가장 효율적으로 도달할 수 있을지 바닷길을 안내하는 직무이다.
그래서 이번 북클럽에서는 김성한 쿠팡 PO의 저서인 <프로덕트 오너>를 읽게 됐다. 수많은 PM/PO 필독서 중에서 내가 이 책을 추천한 건 PM/PO 직무에 대한 이해도를 높일 수 있는 책이었기 때문이다.
현재로서 나는 담당하는 서비스가 없다. 앞으로 어딘가에 속하여 일을 하게 될 텐데, 그렇다면 그 기업 or 프로덕트의 문제, 상황, 시장, 고객 등등이 무엇인지도 모르는 상태에서 실무 방법론을 익히는 건 무용하다는 생각이 들었다. 그래서 PM/PO 직무라면 응당 해내야 하거나, 하지 말아야 할 것을 뼛속에 새겨두자는 마음으로 이 책을 고르게 됐다. 북클럽 구성원들도 <프로덕트 오너>로 4주간의 사이클을 진행하는 데 위와 같이 동의해주었다.
1. 고객의 관점에서 고객에게 집착하기
프로덕트는
사람을 향해야 한다
책의 추천사에서, 김광수 NH농협금융지주 회장은 다음과 같은 말을 남겼다. "디지털 혁신의 수단은 기술이지만 목적은 '사람'이어야 한다." PM/PO는 (대체로) IT 기술에 기반한 프로덕트를 담당한다.
그러한 기술이 세상에 존재하는 문제를 해결하는 데 지대한 도움이 되는 건 사실이다. 도로에서 손을 흔들어 택시를 잡을 필요가 없어지고, 메뉴를 찾아 배달 책자를 뒤적이지 않아도 되고, 영화관에 가지 않아도 최신 영화를 집에서 볼 수 있게 만들어준다.
그러나 고객은 편리함만으로는 서비스를 선택하지 않는다. 고객은 고객의 일상에 파고드는 서비스, 즉 고객 감동을 주는 서비스를 선택한다. 이때, PM/PO는 고객 감동을 제공하려고 집착하며 하나의 프로덕트에 대한 일괄적인 책임을 지는 사람이다. 이를 위해 기획, 분석, 디자인, 개발, 테스트, 출시, 운영까지 주도하고, 때로는 다양한 방법을 시도하기도 한다. 이밖에도 고객의 서비스 경험의 A부터 Z를 커버하기 위하여 다양한 영역에서 사용되는 수많은 기능을 관리한다.
흔히들 PM/PO를 '미니 CEO'로 부르기도 하지만, 그건 PM/PO에게 막강한 권력이 주어지기 때문이 아니다. PM/PO는 팀원들에게 결정을 통보하는 사람이 아니라, 사실에 근거하여 설득을 거듭하고 타인의 의견을 겸손한 자세로 경청하는 사람이다.
PM/PO의
이성과 감성
얼핏 보면 PM/PO는 냉철한 이성만으로 똘똘 뭉친 직무인 것도 같다. 그러나 반은 맞고 반은 틀리다. 그러한 이성의 출발점은 결국 고객, 즉 사람에 대한 속깊은 관심에 있다. 고객의 수많은 요구사항들을 한꺼번에 모두 들어줄 수 있다면 참 좋겠지만, 현실적인 여건 때문에 그럴 수 없다. 이때 우선순위를 설정하기 위하여 이성의 힘을 빌리는 것뿐이지, 사실 PM/PO의 근본은 감성이다.
PM/PO는 고객을 대신하여 고민한다. 사실은 고민을 넘어 집착해야 한다. 현장, 공장, 판매처 가릴 것 없이 고객과의 접점이 있다면 달려가볼 수 있어야 한다. 고객 인터뷰나 UT를 진행하는 방법도 있고, 고객센터에서 고객의 진짜 목소리를 들어볼 수도 있다.
어쨌거나 PM/PO는 고객을 바라볼 때 늘상 촉각을 곤두세워야 한다. 그리고 이때 획득한 인사이트를 동료들에게 전달하여 고객 경험적 가치에 다같이 집착하는 문화를 조성할 수 있어야 한다. 동료들이 노력하여 만든 프로덕트가 고객에게 얼마나 큰 감동을 줄 수 있는지 전달하는 것 또한 PO의 몫이다.
프로덕트를
고용하는 고객
'밀크세이크 이야기'는 PM/PO 뿐만이 아니라 애자일 문화에서 일하는 개발자, 디자이너 등의 관계자라면 익히 들어봤을 법하다. (나 또한 여러 번 언급했었기 때문에 오늘만큼은 위 링크를 타고 들어갈 수 있는 첨부 자료로 대체!)
결국 이 이야기가 전달하는 바는 제품이 '구매'된다는 관점 대신, 고객이 무엇을 해결하기 위해 어떤 제품을 '고용'했는지 바라봐야 한다는 것이다. 이는 JTBD라는 고객 문제 접근법의 일종으로, "이거 해주세요, 저거 해주세요"라는 고객의 목소리를 곧이곧대로 듣는 대신 그 기저에 깔린 진짜 니즈를 파악하는 방법론이다.
"해결해야 할 일이라는 관점을 가지고 있으면, 고객의 피부 아래로 파고들어 그가 하루 종일 무엇을 하는지 지켜보며 계속 '왜 그렇게 했지?'라는 질문을 던질 수 있게 됩니다."
― 클레이튼 크리스텐슨의 2011년 <하버드 비즈니스 스쿨> 인터뷰
출처=https://worldhotels.tistory.com/entry/10waysofdigitalmarketingsegmentation 이처럼 PM/PO는 표면적인 고객 정보에만 매몰되어서는 안 된다. 이를 방지하기 위하여 실제 고객 경험을 토대로 업무를 진행하는 방식을 숙지할 필요가 있다. 이를 세그멘테이션이라고 하는데, 이때의 기준은 성별, 나이, 거주지 등으로 간단하게 나뉠 수 없다. 본질적으로 각각의 고객의 의도를 파악하여야 제대로 된 분류가 가능해지고, 프로덕트 개선을 위한 유의미한 결과 도출이 가능해진다.
PM/PO는 동일한 프로덕트라 하더라도 이를 고용하는 고객의 목적이 다 다를 수 있다는 걸 기억해야 한다. 그리고 그 다양성 속에서 동일한 의도를 찾아내어 묶을 줄 알아야 하고, 그렇게 도출한 고객의 니즈에 따라 프로덕트를 개선해야 한다. 이렇듯 PM/PO는 고객에 집착하고, 고객을 꿰뚫어보고, 고객을 이해할 줄 알아야 한다.
2. 요구사항과 커뮤니케이션
가장 무서운 현상,
병목(Bottleneck)
출처=https://mysoftwarekeys.com/what-is-bottleneck 유리병의 널따란 부분에서 출발하여 좁은 부분을 통과하는 모래 알갱이들을 상상해보자. 너무 많은 요소들이 좁은 공간에 한꺼번에 몰리게 된다면 자연스레 위 그림과 같은 지체 현상이 발생할 것이다. 같은 지체 현상을 병목 현상이라고 부른다. 이 병목 현상은 우리 일상 어디서나 생길 수 있으나, 업무에서 발생했을 때 특히 치명적인 문제로 번질 가능성이 높다. 그리고 이러한 병목 현상을 가장 경계하고 예방해야 하는 건 PM/PO이다.
출처=https://www.youtube.com/watch?v=egJL3WzZgG0PM/PO는 '미니 CEO'로서 동료들이 자신의 직무에 집중할 수 있도록 부수적인 일들도 도맡게 된다. 이때, 앞서 언급했던 겸손한 저자세가 요구된다. PM/PO는 독재자처럼 군림해서는 안 된다. PM/PO가 다른 직무들에 비해 결정권이 많은 건 사실이다. 그러나 그건 PM/PO에게 특정한 권력이 주어졌기 때문이 아니라, 개발자가 개발을 맡고 디자이너가 디자인을 맡는 것처럼 PM/PO는 논리적인 근거에 입각한 선택과 결정을 도맡기 때문이 다름 아니다.
아래와 같은 조시 앨먼의 말처럼 PM/PO는 팀원과 팀원, 팀원과 업무 사이에 막힘이 없도록 꾸준히 기름칠을 해주는 사람이기도 하다. 결국 업무가 일정 안에 원활하게 진척될 수 있도록 관리하는 일 또한 PM/PO의 주 업무 중 하나이다. 그래서 PM/PO는 항상 협업하는 이들의 상태를 꾸준히 살피고, 이들이 최대한 효율적으로 일할 수 있도록 도와야 한다.
잘 이행된 프로덕트 관리는 회사와 제품을 향상시키기 때문에 가장 중요한 기능이 될 수 있지만, 제대로 하지 않았을 경우 회사와 팀에 엄청난 해를 끼칠 수도 있다.
― 조시 앨먼 "Let's talk about Product Management."
업무의 흐름에
막힘이 없으려면
내가 PM/PO 직무를 공부하면서 가장 설레면서도 두려웠던 업무에 대한 이야기가 있다. "PM/PO에게는 모든 질문이 들어와요."라는 말이 그것이다. 공부를 할 때는 "에이, 설마."라며 갸웃거리기도 했다. 그러나 실제 업무를 경험해보니 그 말은 틀림 하나 없는 사실이었다(...).
팀 내 여러 직군 중에 개발자를 상정하고 이야기해보자. 개발자가 가장 잘하는 일이면서도 가장 많은 시간을 들여야 하는 일은 다름 아닌 개발이다. 그런데 자신이 어떤 일을 해야 할지 몰라 하릴 없이 놀고 있거나, 개발을 하던 중 자꾸만 의문이 생겨 멈추고 시작하길 반복한다면 궁극적으로 고객에게 제공하는 가치가 떨어질 수밖에 없다. 그리고 자신이 최대한의 리소스를 투여해야 하는 개발 대신 업무에 대한 궁금증을 해소하러 다니느라 시간과 노력을 허비하고, 더 나아가서는 업무에 대한 회의를 느낄 수도 있다. PM/PO는 이러한 일을 사전에 철저하게 방지해야만 한다. PM/PO는 궁금증을 해소해야 하는 사람이기도 하기 때문이다.
그렇다면 어떻게 업무의 흐름에 막힘이 없도록 할 수 있을까? <프로덕트 오너>에서는 그 해답을 요구사항에서 찾았다. 이때 요구사항이란 프로덕트가 갖추어야 하는 기능, 고려해야 하는 제약, 추구하고자 하는 목표 등을 설명하는 것이다. 고객경험적 가치에 초점을 맞추어 우리 프로덕트의 고객에게 어떤 경험과 가치를 제공해야 하는지 객관적으로 설명할 수 있어야 한다.
PM/PO는 팀원들에게 최대한 설득적이고 구체적인 요구사항을 전달해야 한다. 설득력이 없다면 업무 시작 전부터 팀원들의 의문이 끊이지 않을 테고, 구체성이 없다면 업무를 진행하는 중 문제가 발생하게 된다. 최선의 노력을 다해 요구사항을 다듬고 또 다듬는 것은 PM/PO가 팀원들에게 존중받는 가장 확실한 방법이기도 하다.
PM/PO는 고객의 니즈, 회사의 방향성, 그리고 이 둘을 고려한 최적의 솔루션이라는 세 꼭짓점을 모두 고려하여 요구사항을 작성하고, 이를 메이커들에게 전달할 수 있어야 한다. 사전에 명확한 요구사항을 전달하고, 이후로도 구성원들이 원할 때 언제든 최신 업무 정보를 습득할 수 있는 환경을 조성해야 한다. (공유 문서, 티케팅, 백로그, 스몰톡 등 어떤 방식이어도 좋다.)
물론 명확한 요구사항을 정하는 일은 쉽지 않다. 프로덕트의 안녕에는 수많은 요소가 관여한다. 고객, 기술, 운영, 법률상 다양한 변화와 문제가 시시각각 발생하며, 당장 가까운 미래도 어떻게 바뀔지 알 수 없다. PM/PO는 이러한 불확실성 속에서 진실을 간파하는 통찰력을 길러야 한다.
그러기 위해서는 도출한 솔루션이 기술적으로 개발 가능한지, 디자인 관점에서 타당한지 등을 메이커들로부터 확인하며, 사업적인 관점에서 비용에 대한 고민을 나누고, 운영단에서 불편함은 없는지 살펴야 한다. 결국 의자에 엉덩이 붙일 새 없이 돌아다니며 소통, 또 소통을 거듭해야 한다는 뜻이다. PM/PO가 최선의 요구사항을 정의하려면 우선적으로 다른 사람들의 말을 들어야 한다. 경청 없이는 좋은 결정도 나올 수가 없다.
* 3번부터는 이후 포스팅 <일잘러 PM/PO는 '이것'할 수 있는 사람이다 (2)>에서 이어질 예정입니다.
