조직을 성공으로 이끄는 프로덕트 오너
1장. 프로덕트 오너는 미니 CEO다.
PO는 중심에 있다
"PO는 모든 사람들이 지켜보는 존재야. 개발자, 디자이너, 비즈니스 애널리스트 등은 물론, 회사 내/외부 고객과 사업부, 심지어 나 같은 경영진까지 지켜보고 있어."
"그래, 명심해. PO는 중심에 있어. 모두가 보고 있단 말이지. 절대로 감정을 공개적으로 보이지 마."
PO는 전혀 다른 경험을 원하는 고객 집단이 하나로 모여있을 때, 고객이 요구하는 사항을 모두 경청라고, 그 중에서 우선순위를 정한다. 그후 그게 회사가 추구하는 사업 목적과 부합하는지 확인해라. 자원은 한정적이기에 모든 고객의 목소리를 반영할 순 없기 때문이다.
독재자형 리더는 안된다
프로젝트 매니저는 시장을 조사하고, 프로토타입을 만들고, 실험하고, 디자인 또는 개발 자원과 협업하고, 최종 제품을 고객에게 선보여야 한다.
강의나 책을 찾아서 봐야겠다는 생각이 들었다.
"프로젝트 매니저를 떠올리면 '비전'이나 '프로덕트 CEO'같은 단어들이 학생들 사이에서 거론되곤 하지만, 현실은 관리 업무도 함께해야 해요. 마치 과하게 미화된 스태프 같기도 하죠."
PO는 누군가에세 결정을 통보하고, 실행하는 CEO가 아니다. 오히려 그 누구보더 더 저자세로 임하고, 경청하며, 사실만을 토대로 설득을 거듭하는 고독한 자에 가깝다.
나는 데이터를 가지고 설득을 하는, 아니 설득이란 것을 하는 자체를 잘 못하는데, 이 부분을 고쳐야겠다는 생각이 들었다.
책임은 있지만 권한은 없다
하지만 PO에게는 그런 권한이 없다. 야밤에 에러가 생기면 PO에게 제일 먼저 연락이 오고, 책임감 때문에 새벽까지 뜬눈으로 긴장하지만, 실제 원인을 제공한 자에세 책임을 물을 수는 없다.
오히려 건강한 관ㄴ계를 유지하기에는 PO에게 권한이 없는 편이 낫다. 다른 이들에게 일방적으로 지식하기보다는, 더 효율덕으로 협업하기 위한 방법을 찾을 수 있기 때문이다.
문제가 발생하면 PO에게 질문과 눈길이 쏠리지만, 큰 성공을 거두면 PO는 함께 이룬 동료들에게 공을 돌린다. 그들이 직접 두 손으로 만든 서비스이기 때문이다. 부여된 책임감은 많지만, 권한이 없는 PO는 언제나 겸손해야 한다.
고객에 집착하고 또 집착하라
브랜드 맨
1. 자신에게 주어진 브랜드의 출고량을 한 개 단위까지 주의 깊게 관찰한다.
- 브랜드의 제품이 활발하게 판매되거나 증가 추세를 보이는 곳일 경우, 그것을 가능하게 한 원인을 주의깊게 살펴보고, 그것을 다른 비슷한 지역에 동일하게 적용하려 노력한다.
- 브랜드의 제품 출고량이 저조할 경우
----a. 해당 브랜드의 과거 광고 및 홍보 이력을 분석하고, 직접 딜러나 고객을 만나서 그 지역의 특성을 파악한 수 문제점을 찾아낸다.
----b. 우리의 취약점을 발견했다면 그 특정 지역에서 발생되고 있는 문제를 해결할 계획을 수립한다. 당연히 계획만 구축하는 게 아니라, 문제를 해결할 수 있다고 확신할 만한 비용을 적절히 선정해서 제안한다.
----c. 이 계획을 출고량이 저조한 지역을 담당하는 디비전 총괄자한테 상세하게 보고하고, 문제점을 고칠 수 있도록 그로부터 권한과 지원을 얻는다.
----d. 계획을 시행하기 위해 필요한 인적 자원과 물품을 준비하고, 각 지역에 해당 계획을 공유한다. 세일즈맨들이 준비 태세를 갖출 수 있도록 협업한다. 마지막 순간까지 모든 절차를 실행하고, 계획의 예상 판매 결과가 흐트러지지 않도록 책임진다.
----e. 필요한 모든 정보를 기록해두고, 의도한 결과가 계획을 통해 제대로 달성됐는지 검증하기 위한 현장분석도 진행한다.
- 단순히 출력된 홍보물 등을 평가하는 것이 아니라, 담당하는 브랸드와 관련된 모든 표현애 대해 전덕으로 책임을 진다.
- 브랜드의 적용된 모든 광고 비용에 대한 책임을 진다.
- 각 지역의 책임자와 일 년에 몇 번씩 직접 만나 발생 가능한 모든 문제점에 대해 논의한다.
PO가 이행해야 하는 가장 중요한 의무 중 하나는 고객에게 집착하는 것이다. 현장이 있으면, 현장으로, 공장이 있으면 공장으로, 판매처가 있다면 판매처, 심지어 단순하게 고객센터에 가서 전화 통화를 옆에서 들어도 도움이 된다. 그리고 각각의 고객이 무엇을 불편하게 여기는지, 어떤 경험을 원하는지 등을 데이터까지 분석하며 파악한다.
또한 이에 머물지 않고, 고객에게 집착하는 사고방식을 주변 동료들에게전파해야 한다. 단순히 개발을 하거나 디자인 시안을 만드는 것이 아니라, 그것이 고객에게 얼마나 큰 감동을 줄 수 있는지 각자 충분히 인지할 수 있도록 설명해주는 것도 PO의 몫이다. 모두가 고객에 집착할 때까지 PO에게는 직접 현장에서 터득하고 정보를 공유해야하는 책임이 있다.
* PO가 되기 위해 필요한 자질
- 학력 및 전공
- 업무 경험
- 성향 및 능력
위의 3가지라곤 하지만 나는 저것들에 부합하는 것이 없다. 이번에 풀잎에 참여해주신 분들도 경험이 제일 중요하다고 말했다. 물론 나는 경험도 없지만 일하면서 데이터가 쌓이면 점차 나아지지 않을까 한다.
2장. 고객의 목소리를 어디까지 반영할 것인가
고객은 제품을 사지 않는다, 고용한다
제품이 단순히 구매된다는 관점에서 벗어나, 고객이 무옷을 해결하기 위해 어떤 제품을 고용했는지 생각해봐야 한다. 오든 제품과 서비스를 고용의 대상으로 바라보면, 각각 어떤 일을 고객을 위해 해줘야 하는지 알 수 있다. 그게 고객에게 전달되는 실제 가치다.
나는 어떤 프로덕트를 만들기 전이다, 혹은 매 분기별로 문서를 하나 작성한다. 아마존 또는 쿠팡에서 식스 페이저(6-Pager)라고 부르는 이 문서 형태는 여섯 페이지 이내에 해당 프로덕트에 대한 핵심 내용을 담아내는 것이다. 프로덕트의 목적이 무엇인지, 과거에 어떤 관련된 시도를 했는지, 어떤 실패 사례가 있었는지, 앞으로 어떤 방향으로 개발할 건지, 그리고 어떤 수치를 활요애서 성공 여부를 확인할 것인지 등을 최대한 간결하고 정확하게 서술한다. 이 문서는 개발팀은 물론 임원진의 검토를 받고, 피드백을 통해 문서를 개선하고, 확정된 뒤에야 개발에 착수한다.
PO는 프로덕트를 기획하거나 개발 방향을 결정할 때, 어떤 고객이 왜 해당 프로덕트를 고용할지 철저하게 고민해야 한다. 설문 조사나 이미 지나간 과거의 데이터를 보고 시장의 수요를 추측하는 것은 PO에게 적절한 방식이 아니다. 당장 직면한 현재의 고객이 어떤 제품을 고용하고 있는지, 그리고 왜 그걸 선택하는지에 대한 관점으로 분석하도록 해야 한다.
고객은 언제나 해결해야 할 일들에 둘러싸여 있고, 그것을 해결해줄 제품과 서비스를 고용할 준비가 되어 있다. PO는 고객이 흔쾌히 고용할 프로덕트를 만들고 꾸준히 개선해야 한다.
서비스는 하나라도 서비스 유형은 다양하다
실제 고객 경험을 토대로 고객 분류를 한 다음, 그들이 어떤 일을 해결하기 위해 서비스를 고용하는지 생각해보면 경험을 보다 수월하게 개선할 수 있다. (...) 본질적으로 고객이 각각 어떤 의도를 가졌는지 파악해서 분류해야 서비스 개선 방향성을 잡을 수 있다.
PO가 범하기 쉬운 실수 중 하나는 프로덕트를 만드는 사람의 관점에서 고객을 바라보는 것이다. 그렇게 하면 무의식적으로 PO 자신이 만들고 싶어 하는 방향으로 데이터를 해석하고 결정해버릴 수 있다. PO는 절대로 자신의 직관이나 바람에 의한 결정을 내려서는 안 된다. 고객을 분류하는 방식을 완벽하게 터득할 때까지, 자신이 책임지는 프로덕트를 수도 없이 많이 사용해보는 것이 좋다.
PO라면 동일한 프로덕트를 고용하는 고객이 다양하다는 점을 명심하길 바란다. 그리고 그 다양성 속에서 동일한 의도를 찾아 고객을 분류하도록 하자. 각각 프로덕트를 고용하는 이유를 파악한 후, 그것에 맞춰 프로덕트를 개선해야 한다. PO가 고객 분류만 잘해도 절반은 성공적으로 완수했다고 본다. 모든 고객에 대한 이해가 이뤄져야 분류 자체를 온전히 할 수 있기 때문이다. 그 이후는 프로덕트를 어떻게 잘 개선해야 하는지에만 집중하면 된다.
모든 사람을 만족시킬 수는 없다
PO는 언제나 우선순위를 정해야 한다. 어떨 때는 명백하게 무엇을 해야 할지 눈에 보일 때도 있지만, 때에 따라서는 일부 고객의 요청을 잠시 보류해야 할 수도 있다. 그때마다 늘 한정된 자원을 어떻게 활용해야 가장 효과적일지 고민하도록 한다. 얼마만큼의 공수를 투입하여 얼마만큼의 임팩트를 낼 수 있는지 논리적으로 따져보고 최적의 결정을 내리는 책임을 지녔기 때문이다.
식스 페이저로 모두의 동의를 얻어 기록하라
내가 식스 페이저 문서를 작성할 때, 고객 분류와 더불어 공을 제일 많이 들이는 것이 바로 원칙이다. '가이드 원칙 Guiding Principle'이라고 부르는 이 부분에는 주로 4~6개의 원칙을 목록화한다. 해당 프로덕트를 개발하거나 운영할 때 꼭 지켜야하는 법 같은 것이다. 1번이 가장 중요한 원칙이고, 내려갈수록 부수적인 것들로 채운다.
이 원칙은 허투루 작성해서는 안 된다. 너무 길어서도 안 되며, 명확한 단어들로 구성한다. 동료, 상사, 경영진 등의 검토를 거치면서 보완하는 절차를 거쳐야 한다. 그리고 최종적으로 모두가 동의하는 원칙이 정해졌을 때, 개발에 착수한다. 만약 오늘 내가 담당하던 프로덕트가 다른 PO에게 넘어가더라도, 그 PO가 이 원칙을 그대로 따를 경우 문제 없이 개발이 이어질 정도로 정확해야 한다. 그만큼 단어와 뉘앙스 하나하나 완벽하게 잡기 위해 신경 써야 한다.
PO라면 자신이 책임지고 있는 프로덕트에 대한 원칙을 반드시 정하길 바란다. 단, 새롭게 맡은 프로덕트라든지 신규로 론칭하는 경우라면 시간을 투자해서 최대한 많은 부분에 대해 고민한 후에 원칙을 정해야 한다. 꼼꼼하게 검토하지 않고 원칙을 정해버리면 나중에 방향성을 바꿔야 할 수도 있기 때문이다. 그리고 원칙은 매 분기별로 점검하는 것을 추천한다. 고객과 사업이 요구하는 것들을 종합하여 원칙을 재정비하면 명확한 방향성을 잡을 수 있기 때문이다. 물론, 무조건 분기별로 고칠 필요는 없지만, 검토는 반드시 하도록 한다. 원칙이 잘 유지되면, PO와 협업하는 모든 이들이 프로덕트를 이해하기 수월해진다.
고객의 요청과 회사가 정한 목표가 충돌한다면
현실적으로 회사는 주어진 자원을 효율적으로 활용하여 궁극적으로는 이익을 추구해야 한다. 그래서 수많은 회사들이 매출과 수익을 목표를 설정하거나 장기적인 성장 전략을 수립한다. 회사가 생존하지 못하면 고객에게 최상의 경험을 제공할 수 없기 때문에, PO도 늘 회사의 상태와 목표를 잘 인지하고 있어야 한다.
때에 따라서는 PO의 입장에서 꼭 추진하고 싶은 프로덕트가 생길 수 있다. 그런데 회사의 복표에 당장 부합하지 않는 경우에는 설득을 통해 회사의 마음을 돌리는 방법이 있다. 이때, PO는 단순히 그 프로덕트가 고객에게 어떤 가치를 제공할지에 대해 논의하는 선에서 벗어나 비용, 회사에 끼치는 영향 등을 두루 설명해야 한다. 사업적인 관점에서 논리를 정리하도록 한다. 왜 그런 투자를 해야 하는지 잡득시켜야 하기 때문이다.
하지만 논의 끝에 회사에서 반대할 경우, PO는 바로 수긍해야 한다. PO는 회사의 성장 전략과 비용 관리 등을 하는 역할이 아니기 때문이다. 전문가의 판단하에 특정 프로덕트에 대한 투자를 단핼할 수 없다고 결정되면, PO는 그 방법을 제외하도록 한다. 어디까지나 PO는 주어진 자원을 활용해서 프로덕트를 개선해야 하는 책임이 있기 때문이다.
고객에게 더 나은 가치를 제공하기 위해 집착하는 PO이지만, 회사가 정한 방향성과 목표를 절대로 잊어서는 안 된다. PO가 사업적인 관점을 유지하고, 경영진의 시각을 이해하고 있어야 우선순위를 결정할 때 참조할 수 있다. PO는 단순히 프로덕트를 만드는 사람이 아니라, 고객과 회사 모두가 필요로 하는, 제대로 된 프로덕트를 책임지는 사람이라는 점을 명심하자, 고객에게 계속 최상의 경험을 제공하여면, 회사가 건강한 상태여야 한다. 그래서 PO가 회사의 목표에 부합하지 않은 결정을 내리면, 그 여파는 상당히 크다. 고객의 목소리에 귀 기울이는 것만큼 회사가 정한 목표와 의견에도 집중하도록 하자.
* 페르소나와 고객을 혼동하지 마라
고객이 누구인지 파악할 때는, 데이터와 사용 패턴 등을 감안하여 최대한 포괄적으로 접근해야 한다.
- 이프로덕트를 사용하는 사람은 누구인가?
- 개개인이 아닌 법인이나 단체가 이 프로덕트를 사용하는 경우도 있나?
- 사용자는 어떤 가치를 얻으려고 하는가?
- 프로덕트가 그 가치를 직접적으로 제공해줄 수 있나?
- 성공적으로 제공했다는 사실을 데이터로 증명 가능한가?
- 동일한 가치를 추구하는 사용자 집단을 묶을 수 있나?
프로덕트를 사용해서 어떤 가치를 얻으려고 하는지 이해한다면, 역으로 그 가치를 각각 추구하는 사용자들을 하나씩 그룹화할 수 있다. 더 이상 통합할 수 없는 단계까지 도달하면, 그게 PO가 고려해야 하는 고객의 목록이 된다.
