PO = Problem Owner?

현재 회사에서 3년째 PO(Product Owner) 역할을 하고 있다. 지난 3년간 회사는 AI 분야에서 급성장을 했고 내가 입사했을 때 15명이던 직원은 어느덧 130명을 넘었다. 비즈니스의 성장과 함께 Product에도 많은 발전이 있었는데 이 과정에서 나는 총 7개의 Product을 담당했다. 이번 포스팅에서는 7개의 Product을 관리하면서 깨닫게 된 PO의 역할에 대해서 이야기하고자 한다.

문제를 정의하는 것

Product의 개발은 그냥 나의 개인적인 욕심으로 진행되지 않는다. 명확한 문제정의를 기반으로 구체적인 목표를 설정하고 팀원들의 공감을 통해 진행된다. 여기에서 가장 중요한 것은 문제를 정의하는 것이다. 그렇다면 문제를 정의한다는 것은 무엇일까?

예를들어, 유관부서에서 아래와 같은 요청이 왔다고 치자.

 "회원가입한 신규 회원들이 FAQ를 보지 않고Q&A에 동일한 질문을 하다보니 CS 리소스가 많이 투입된다. 신규가입을 하면 FAQ 내용을 팝업으로 띄워달라" 

위 요구사항을 그대로 이해하면 아래와 같이 잘못된 문제정의를 하게 된다. 아래 방식은 전형적으로 표면적 현상과 문제정의를 혼동한 예시이다.

• 문제정의 : 신규 회원들이 FAQ를 보지 않는다.
• 해결방안 : 신규 회원들이 FAQ를 강제적으로 보도록 회원가입을 하면 FAQ 안내 팝업이 나오도록 한다.

표면적 현상과 문제정의를 구분하면 아래와 같은 방식으로 문제를 해결할 수 있다.

• 표면적 현상 : 신규 회원이 FAQ를 보지 않아서 CS인입이 늘고 있다.
• 문제정의 : 회원들은 FAQ에 자신이 궁금해하는 사항에 대한 답변이 있을 것이라고 생각하지 않아서 FAQ를 찾아보지 않는 것이다. 이는 지금까지 웹의 이용경험에서 비롯된 편견때문이다.
• 해결방안 : FAQ 페이지를 사용자가 스스로 찾아보도록 하면 된다. 신규회원들이 CS로 들어오는 문의를 확인해보니 대부분 프로모션 참여 방법에 대한 문의였다. 그래서 FAQ 버튼 옆에 다음 문구를 추가한다. “프로모션에 참여하여 합리적인 소비를 하는 방법”

사실 위 내용은 현재 회사에서 내가 실제로 경험한 내용이다. 위와 같은 간단한 방식으로 신규가입자의 문의량을 기존 대비 40%미만으로 줄일 수 있었다.

그래서…나는 어려운 문제일 수록 기획의 50% 정도는 문제를 정의하는데 시간을 투자한다. 상황에 따라선, 70%까지도 투자한다. 주니어 기획자들은 이 과정을 어려워한다. 문제를 정의하는 기간 동안에는 산출물이 없으므로 마음이 불안하기 때문이다. 그래서 시간이 지날수록 마음이 불안하여 일단, 문제정의 없이 문서를 만들기 시작하곤 한다. 내 역할 중 하나는 Product Manager들이 문제를 정의하는데 충분한 시간을 투자할 수 있도록 환경을 만드는 것이다.

그래서 Product Manager들은 JIRA에 스토리티켓을 생성 할 때 꼭 지켜야 할 원칙이 있다.

문제를 정의하기 위해 토론하는 것.

특정 안건에 대한 미팅을 할 때 내가 생각하는 가장 비생산적인 시나리오는 다음과 같다.

• A가 아이디어를 낸다.
• B는 아주 합리적으로 그 아이디어는 문제가 있다고 지적한다.
• 듣고 있던 C가 또 다른 아이디어를 낸다.
• 이번엔 A가 C가 낸 아이디어에 대해 문제가 있다고 아주 합리적으로 지적한다.
• 그 중 임원급의 사람이 해당 안건의 중요성을 언급하며 다른 아이디어를 더 내보라고 한다.

아주 익숙한 시나리오 아닌가? 그런데 위 시나리오에는 치명적인 문제가 있다. 문제를 정의하는 과정이 없이 해결을 위한 아이디어만 존재하는 것이다. 사실 이 상태에서는 아이디어를 내는 것 자체가 모순이다. 문제가 명확하지 않으면 해결방법도 존재할 수 없기 때문이다.

그래서 PO들은 해결방법을 토론하기보다 무엇이 본질적인 문제인지를 토론하는데 많은 시간을 소비한다. 예를들어, 이번 달 영업리드건의 수가 지난달보다 15% 줄었다면….

• 과연 15% 줄어든 것이 유의미한 것인지 고민한다. 즉, 이것이 과연 정말 문제인지를 고민한다.
• 문제라고 결론을 내렸어도…어떻게하면 영업리드건을 올릴 수 있을지는 고민하지 않는다.
• 왜 지난달보다 떨어졌는지에 대한 고민을 먼저한다. 그리고 이 과정에서 엄청난 토론이 진행된다. 어떻게 문제를 정의하느냐에 따라 진행방향이 완전히 달라지기 때문이다.
• 그래서 문제를 정의하는 것은 합리적이고 논리적이어야 하며 상황에 따라서 데이터가 필요하다.
• 문제가 정의되면 해결방법은 어렵지 않게 도출된다. 즉, 문제가 정의되면 토론도 몇 분안에 끝난다.

해결한 문제에서 발생한 또 다른 문제를 해결하는 것

아무리 문제를 해결해도 또 다른 문제는 존재한다. Product은 계속 발전해야 하기 때문이다. 어떤 문제를 해결했으니 그 부분에서 더 이상 문제가 없을 것이라고 생각하는 것은 욕심일 뿐이다. 항상 문제는 존재한다. 문제가 없다는 것은 아직 문제를 발견하지 못했을 뿐이다.

그렇게 생각하는 것이 정신건강에 이롭다. 문제가 두려워서 스스로 문제를 발견하지 못하면 Product은 버그만 수정하는 수준에서 발전이 없다.

발견한 문제를 지나치지 않는 것.

문제는 해결하고자 할 때 비로서 문제로 존재할 수 있다. 아무리 중요한 문제라도 해결하고자 하지 않으면 그건 하나의 현상에 불과하다. 물론, 문제를 발견한다고 해서 항상 바로 해결할 수 있는 것은 아니다. 각자의 상황이 있기 때문이다. 그러나 이것은 현재 상황을 고려하여 우선순위를 자주적으로 선택하는 것이지 문제를 방관하는 것은 아니다. 문제인식이 있으면 언젠가 적당한 때가 온다. 그 시점까지 그 문제를 포기하지 않고 계속 인식하고 있는 것이 중요한 것이다.

인간관계의 문제도 해결하는 것.

PO는 리더이기도 하다. 팀원들이 나와의 관계가 좋다고 해서 팀원들끼리도 좋은 것은 아니다. 팀원들의 관계문제 또한 내가 해결해야 할 문제이다. 사람간의 관계문제도 해결을 하려면….결국 문제를 정의해야 한다.

관계에 대한 문제를 정의하려면….해당 문제의 대상자들 모두의 이야기를 아주 세밀하게 들어봐야 한다. 중요한 것은 세밀하게 들어야 한다는 것이다. 팀원의 문제를 해결하고자하는 마음이 너무 큰 나머지 특정 팀원의 말에 너무 쉽게 동조하거나 나 자신이 액션을 취하려고한다면 더 큰 문제를 발생시킨다.

상황에 따라서는 팀웍에 문제가 되는 팀원에게 본인의 문제점을 직접적이고 분명하게 알려줘야 한다. 그리고 해당 문제의 원인을 함께 고민해보는 시간을 갖기도 해야한다.

리더의 역할은 팀원이 스스로 해당 관계에서의 문제를 정의할 수 있도록 도움을 주고 문제를 피하지 않고 그들 스스로 해결을 할 수 있도록 도움을 주는 것이다. 그래서 이 부분이 참 어렵다. Product은 지식이나 논리적인 사고로도 문제를 해결할 수 있지만, 사람관계는 지혜가 많이 필요하다.

Product 이전에 문제가 있었다.

지난 10년 이상 기획자로서, PO로서의 업무경험을 돌이켜 생각해보면….모든 것에는 항상 문제가 있었다. 그리고 지금도 나의 백로그에는 많은 문제가 존재한다. 그리고 회사에서 매일 누군가는 급한 문제가 있다며 나를 미팅 캘린더에 초대한다. 내가 이미 알고 있는 문제보다 더 많은 양의 문제가 발견된다.

Product도 누군가 문제를 발견하고 그것을 해결하기 위해 존재한다. 그래서 Product도 문제 없이 존재할 수 없으며 PO 또한 문제없이 존재할 수 없다. 데이터도 마찬가지다. 문제정의가 없으면 유의미한 데이터도 존재할 수 없다. 애초에 데이터란 것도 문제를 발견하거나 해결하기 위해서 쌓고 분석하는 것이다.

그래서 나는 개인적으로 PO를 Problem Owner라고 칭해도 전혀 이상할 것이 없다고 농담처럼 말을 하곤 한다. 문제에 집중하면 자연스럽게 Product에 집중하게 되고 Product에 집중하면 또 다른 문제를 발견하게 된다. 이런 순환을 통해 PO도, Product도 성장할 수 있다.