PM이라는 직군은 익숙하지만 PO라는 직군에 대해서는 이해도가 떨어졌기 때문에, 정확히 어떤 역할을 하는 사람인지 궁금해서 이 책을 읽어보게 되었다.
이 책은 PO(Product Owner)라는 역할이 조직 안에서 어떤 가치를 만들고, 어떤 자질을 갖춰야 하며, 어떻게 행동해야 하는지를 실제적인 예시와 함께 매우 구체적으로 풀어낸 책이다. 책을 읽으며 인상 깊었던 내용을 정리해보았다.
PO는 어떤 직군인가?
“최소한의 자원으로 최대한의 고객 경험을 만드는 사람”
PO는 최소한의 자원으로 최대한의 고객 경험을 만드는 사람이다. 문제를 단순히 드러난 현상만 보고 판단하지 않고, 그 원인을 깊이 있게 파고들 수 있어야 한다. 고객이 진짜 불편해하는 부분이 무엇인지, 어떤 점에서 감동을 느끼는지를 찾아내는 것이 중요하다.
이때 PO는 항상 이성적이고 중립적인 태도를 유지해야 한다. 모든 이해관계자가 보고 있는 자리인 만큼, 판단은 객관적이고 논리적이어야 한다.
PO의 핵심 역할
핵심 설정하기: 식스페이지
PO는 판단을 내릴 때 일관된 기준을 가져야 한다. 이를 위해 식스페이지 문서를 작성하는데, 이는 일종의 헌법과 같은 역할을 한다. 우리가 고객을 위해 무엇을 하는지, 이 프로젝트가 회사 안에서 어떤 의미를 가지는지, 과거에는 어떤 시도가 있었고 어떤 실패를 겪었는지를 담아야 한다. 또 어떤 방향으로 개발할지, 성공 여부는 어떤 수치로 판단할지도 명확히 적는다.
이때 모든 것을 개발할 순 없으므로, 우선순위를 정해야한다. 이때 근거는 핵심을 바탕으로 해야한다. 우선순위가 명확하지 않을 때에는 극단적인 상황을 가정해보면 도움이 된다. 예를 들어 “리테일 거래자와 우량 거래자 중 한쪽만 선택해야 한다면?” 같은 질문을 스스로에게 던지고, 어떤 쪽이 프로덕트에 더 큰 영향을 주는지를 비교해본다. 이렇게 극단적으로 상상해보면 중요도가 명확하게 드러난다.
고객에게 집착하기
PO는 고객보다 더 많이 제품을 사용하고, 고객보다 더 예민하게 문제를 인식할 수 있어야 한다. 실제 현장을 찾아가 고객의 목소리를 직접 듣고, 데이터에 잡히지 않는 불편함을 체감하는 것이 중요하다. 다양한 사용자 유형을 구분하고 각기 다른 니즈를 파악하려는 노력도 필요하다.
서비스를 사용하는 연습도 중요하다. 다양한 앱을 직접 써보면서 처음에는 아무 생각 없이 사용하되, 불편함이나 편리함을 느낀 순간을 기억해두었다가 그 이유를 분석하는 방식이다. 고객이 우리 제품을 왜 사용하는지, 어떤 가치를 느끼는지를 정확히 짚는 감각이 중요하다.
데이터 기반 팀 리딩
PO는 팀원들이 각자의 역할에 집중할 수 있도록 팀의 방향성을 명확히 제시하고, 필요한 정보를 미리 정리해 제공해야 한다. 고객의 입장만 대변하는 것이 아니라, 회사의 자원과 전략을 함께 고려해 균형 잡힌 결정을 내려야 한다.
데이터는 항상 맥락과 함께 해석되어야 하며, 수집 방식이 타당한지도 검토해야 한다. 데이터에 노이즈는 없는지, p값은 충분히 낮은지를 확인하고, 엑셔너블(바로 행동으로 이어질 수 있는)한 데이터만을 활용해야 한다. 어떤 데이터를 봐야 하는지 판단하는 능력을 가지는 것도 중요하다.
PO는 항상 가설을 먼저 세우고, 테스트와 데이터를 통해 이를 검증해야 한다. 왜 이 기능을 만들려고 하는지, 어떤 방식으로 검증 가능한지를 명확히 하고, 성공 기준도 사전에 정해둬야 한다. 필요하다면 과감하게 기능을 포기할 줄도 알아야 한다. 개발 자체가 목적이 되어선 안 되며, 효과가 없다고 판단되면 빠르게 의사결정을 내리는 게 중요하다.
PO의 커뮤니케이션
PO는 감정을 드러내지 않고 이성적으로 소통해야 한다.
디자이너와 협업할 때는 개인적인 취향을 전달하지 않도록 주의해야 하며, 요구사항은 명확히 전달하되 피드백은 항상 고객의 입장에서만 해야 한다. 회의 중 구두로 논의된 사항은 반드시 기록해서 디자이너와 공유하고, 어떤 결정이 내려졌는지도 분명히 전달해야 한다.
일정 산정 시에도 마찬가지다. 그 일정이 정말 달성 가능한지 묻고, 어렵다면 왜 그런지 원인을 파악해 기능을 미루거나 인력을 조정하는 방식으로 해결책을 찾아야 한다.
스프린트 회의를 진행할 때는 이전 스프린트에서 무엇을 완료했고, 그것이 주요 지표에 어떤 영향을 주었는지를 돌아봐야 한다. 완료하지 못한 항목이 있다면 그 사유를 명확히 하고, 기술 이슈나 버그가 발생했다면 인시던트 리뷰를 통해 재발 방지 방안을 마련해야 한다. 스프린트 회고에서는 잘한 점과 개선할 점을 구체적으로 정리하고, OKR 진행 현황을 바탕으로 다음 목표를 설정해야 한다.
인상깊은 글귀
PO는 중심에 있어. 모두가 보고 있단 말이지. 절대로 감정을 공개적으로 보이지 마.
PO는 언제나 회사 내부에서도 귀 기울이며 모두가 동의하는 결정이 내려질 때까지 대화를 이어간다. 반대하는 입장에 부딪혀도 데이터에 기반한 근거를 제시하며 설득하도록 한다. 만약 PO가 명백하게 틀렸다면, 바로 수긍한다. 그렇게 결정이 내려지고 개발되어 고객에게 더 나은 경험을 선보일 때까지, PO는 경청하고 최선의 결정을 내려야 할 책임이 있다.
문제가 발생하면 PO에게 질문과 눈길이 쏠리지만, 큰 성공을 거두면 PO와 함께 이룬 동료들에게 공을 돌린다. 그들이 직접 두 손으로 만든 서비스이기 때문이다. 부여된 책임감은 많지만, 권한이 없는 PO는 언제나 겸손해야한다.
PO는 직관에 의존하면 안 된다고 생각한다. 매 결정이 상당히 큰 영향을 끼치므로, 최대한 이성적으로 판단할 수 있도록 데이터에 기반한 사고방식을 갖추도록 한다. 자신이 바라보는 관점이 맞는지, 예상이 맞을지 확인하는 것도 데이터로 검증한다. 그리고 그 데이터가 제대로 된 방법으로 얻어진 것인지 검토하라.
가설은 PO의 생각을 증명하기 위해 꼭 필요한 수단이다. 아무리 논리적으로 접근하고 설득해도, 테스트와 데이터를 통해 증명할 방법을 마련하지 못하면 개발에 착수하지 않아야 한다. PO의 제안이 틀렸는지 증명하고, 당장 기능을 제거해야 하는지 결정 내릴 잣대가 있어야 한다. 가설과 그걸 증명할 테스트가 필수인 이유다.
늘 이성적으로 문제를 바라봐야 진정으로 그걸 해결할 수 있다. 개인의 감정, 자신의 바람 등을 철저하게 배제하고 중립적인 자세로 가설을 도출하라. 그리고 그 가설을 증명할 수 있는 방법을 꼼꼼하게 검토하자. 데이터에 노이즈가 있다면, 반드시 제거해야한다. 노이즈 때문에 자신의 가설이 맞는 것처럼 보일 수도 있으니, 명확한 결과를 얻기 위해 치밀하게 검증하길 바란다.
PO가 가설을 설정하고, 테스트하고, 새로운 기능을 선보일 때마다, 그 과정을 “펀딩받았다”라고 표현하기도 한다. 회사로부터 펀딩, 즉 투자받았으니 테스트도 할 수 있는 것이다. 만약 회사가 PO에게 그 자원을 허용하지 않았더라면, 모든 게 불가능해진다.
