[Team] 투미유 직무알기: Product Owner
Kooya에게 듣는 서비스 기획의 A to Z
'투미유 직무알기' 콘텐츠는 에듀테크 스타트업 '투미유'의 구성원들이 실제 자신의 직무에서 구체적으로 어떤 업무를 수행하고 있는지를 인터뷰 형식으로 보여줌으로써, 스타트업 진출을 희망하는 예비 팀원들이나 창업자, 또는 스타트업 내 업무 분장에 대한 고민을 가진 현역 스타트업 종사자들의 판단을 돕기 위한 목적으로 기획되었습니다. 스피킹 학습 서비스 시장에서의 높은 경쟁력 확보를 위해 투미유 팀원들은 자신의 직무에서 어떠한 역할과 업무 범위를 갖고 있는지, 업무 수행에 필요한 중점 역량은 무엇인지 등을 직접 들어보며 막연하게만 느껴지던 스타트업 직무의 세계를 좀 더 명확히 이해하는 데 도움이 되시길 바랍니다.
직무 인터뷰 #1. Product Owner (PO, 서비스 기획자)
- 인터뷰이 : Kooya
Kooya가 담당하고 있는 PO 직무란 무엇인가요?
Kooya) 'PO'는 Product Owner의 약자로서 투미유 팀이 주력으로 하는 '투덥'이라는 서비스를 하나의 제품으로 보고 우리의 제품이 더욱 나아질 수 있도록 만들기 위한 모든 것을 현실적 방법으로 구체화합니다. 최초 단계의 아이디어 기획을 시작으로 최종 개선 버전 출시에 이르기까지 제품 개선 프로젝트의 전 과정에 걸쳐 직접 관여하며 진행 중인 프로젝트의 중심을 잡고 이끌어 가는 역할을 수행합니다.
특히 PO는 '고객의 까다로운 요구사항을 정의하고 이를 구체적으로 실행하기 위한 기획' 부분에 많은 에너지를 쏟습니다. 제품과 가장 가까이에 위치해 있으면서 각종 데이터와 통찰을 통해 유저들의 숨겨진 니즈를 발굴하고, 이를 바탕으로 제품의 확실한 개선 방향을 논리적으로 그려나갑니다.
그렇다면 PO로서 지금 우리 제품에 무엇이 필요한 지 어떻게 알 수 있죠?
Kooya) 끊임없는 '리서치'와 '분석' 노력을 통해 알 수 있습니다. 우선 평상시에 정말 많은 서비스를 접해보고 직접 사용해 보려는 시도가 있어야 합니다. 리서치 범위의 경우, 우리와 비슷한 교육 서비스 분야로만 한정지어선 사고를 확장시키기 어렵기 때문에 어떤 카테고리의 무슨 서비스든지, 현재 인기 있는 것이라면 직접 다운로드해 사용해 보며 고객 선택의 이유를 찾아내려는 분석 노력이 필요합니다.
이러한 리서치와 분석 작업은 혼자 할 수도 있지만, 여럿이서 함께 고민할 때 더욱 높은 효율을 발휘합니다. 함께 이야기하는 과정에서 혼자서는 생각하지 못한 새로운 발견을 할 수 있기 때문입니다. 이는 투미유 팀이 다양한 사내 스터디를 진행하는 이유이기도 합니다. 디자인 하나, 기능 하나, 버튼 위치 등 어떤 이유에서 그 상황, 그 위치에 나타나게 되었는지에 대해 여럿이서 함께 사용해 보며 해당 서비스 기획자의 의도와 전략을 역으로 생각해 보고 인사이트를 얻고자 노력합니다. 특히 이때는 서로에게 '왜'를 질문하며 가장 합리적인 답을 찾고자 노력합니다.
서비스에 대한 개선사항을 내부에서 찾는 방법은 없나요?
Kooya) 있습니다. 가장 대표적인 방법은 데이터를 활용하는 것입니다. 지금 서비스 내에서 유저들이 무슨 행동을 주로 하는지, 우리의 의도대로 잘 따라오고 있는지 등을 확인하기 위해서는 데이터를 볼 수 있어야 합니다.
예를 들어 '더빙 작품의 활발한 공유를 통해 자연스러운 바이럴을 발생시킨다.'라는 목표를 달성하고자 관련 기능과 버튼 등을 제작한 상황이라면, 이후에는 그 과정에서 발생되는 데이터를 꾸준히 모니터링해야 합니다. 생각보다 유저들 사이에서 공유 기능이 제대로 활용되지 않고 있을 수도 있고, 공유는 되지만 비공개로 이루어져 적절한 바이럴이 생산되지 않고 있을 수도 있습니다. 즉, 우리의 작업이 목표 달성 과정에 어떤 영향을 미치고 있는지를 계속해 추적하고, 누적된 데이터를 분석함으로써 이후의 개선방향을 확인할 수 있어야 합니다.
그렇기 때문에 PO로서 서비스에 대한 누구보다 높은 책임감을 가져야 합니다. 하나의 기능이 출시되었다고 해서 그대로 끝이 아니며, 계속적으로 모니터링 함으로써 의도했던 데이터가 나오고 있는지 꾸준히 관심갖고 확인하려는 자세가 필요합니다.
리서치와 분석으로 인사이트를 얻고, 데이터를 통해 정보를 얻은 다음에는요? 드디어 기획 시작인가요?
Kooya) 본격적인 기획에 앞서 모든 기획의 밑바탕이 되는 여러 가설들을 세우게 됩니다. 먼저 진행했던 리서치와 분석 내용들, 우리 제품 내에서 발생한 실질적인 이용 데이터, 그 외 다양한 사회적 트렌드와 서비스 이용 패턴 등을 종합적으로 고려해 가설을 설정하고 앞으로의 구체적인 기획 방향을 결정하는 것입니다.
특히, 이러한 가설 설정의 순간에는 팩트에 기반한 객관적 내용들 외에, PO의 경험과 고민에서 비롯된 다양한 아이디어들이 필수적으로 요구됩니다. 실제 그 과정을 보면, 최근의 SNS 플랫폼 영향력이 갈수록 커져간다는 객관적 사실 아래, 입소문을 통해 큰 거부감 없이 새로운 제품에 호기심을 가졌던 과거 자신의 기억을 되살려 결과적으로 '유저들의 활발한 SNS 공유 활동은 바이럴 마케팅 효과로 이어지고, 이는 우리 서비스로의 신규 유저 유입을 야기할 것이다.'라는 가설을 수립하게 되는 것이죠.
어떤 아이디어든 자유롭게 반영해 다양한 가설을 세워볼 수 있습니다. 다만, 모든 가설을 전부 검증하는 것은 현실적으로 어렵기 때문에 많은 가설들 중에서도 논리적으로 가장 타당하고 현재 우리 상황에서 실현 가능한 가설들만을 선별해 이를 구체화하는 것이 중요합니다.
가설 설정 후에는 그 가설을 실현하기 위한 구체적 기획이 시작되는 거죠?
Kooya) 맞습니다. 가설이 가설로만 그치지 않도록 각종 상황과 기능들이 어떻게 되어야 한다는 구체적 기획에 들어갑니다. 특정 페이지에서 우리가 의도한 유저 행동을 발생시키기 위해서는 전반적인 UXUI 디자인이 어떻게 이루어져야 하는지, 또 무슨 버튼들이 어떻게 위치하며 이것이 기능적으로 어떻게 구현되어야 하는지 등을 디테일하게 기술한 스토리보드를 작성하는 것이죠. 이것이 우리가 흔히 말하는 기획서를 작성하는 과정이며 PO만의 뛰어난 기획력이 발휘되어야 하는 순간입니다.
그리고 이 단계부터 유관 부서들과의 협업이 특히 더 중요해지기 시작합니다. 1차적으로 기획서를 작성하는 것은 PO의 몫이지만 그렇다고 기획서를 처음부터 끝까지 PO 단독으로 작성하는 것은 아닙니다. 지금 작성하는 기획서는 이후 디자인팀, 개발팀, 마케팅팀 등 각 파트별 작업 방향의 기준이 되기 때문에 작성 중인 내용들에 대해 현재 우리가 가진 자원들로 구현 가능한 것인지를 유관 부서들과 수시로 소통해야 합니다.
당연한 말이지만 원활한 소통이 뒷받침될 때 좋은 기획서도 탄생할 수 있겠네요?
Kooya) 그렇죠. 앞서 말했듯 기획서 자체는 PO가 작성하는 것이라 해도 그 내용을 실제 구현하는 것은 현업의 디자인팀, 개발팀 분들이기 때문에 그분들의 의견을 경청하는 것이 중요합니다. 그리고 이러한 경청 과정에서 오히려 저 혼자서는 미처 생각하지 못했던 새로운 인사이트를 얻기도 합니다.
간혹가다 팀간 의견 차이가 발생해 평소보다 더 많은 시간을 소통에 쏟아야 할 때도 있습니다. 물론 모든 가설과 기획안에 대해 전부가 다 만족할 수 있다면 가장 이상적이겠지만, 서로가 중요하게 생각하는 부분이 다를 수 있기 때문에 의견 조율과 합의를 위한 노력이 필요할 수 있습니다. 가령 제가 생각한 신규 기능이나 새로운 와이어 프레임 구조 등에 대해 각각의 유관 부서에서 기존에 제가 배제했던 다른 의견을 제시하는 상황도 발생할 수 있다는 것입니다.
그렇기 때문에 PO로서 항상 '나의 생각과 다른 사람의 생각이 다를 수 있다.'라는 열린 자세로 자신과 다른 상대방의 이야기를 편견없이 들을 준비가 되어 있어야 합니다. 그리고 나의 생각 또한 기획 의도에 근거해 논리적으로 설명할 수 있어야 합니다. 이러한 생각들이 공유될 때, 단순 기획 과정을 넘어 팀 전체에 건강한 소통 문화가 형성될 수 있으며 그 속에서 우리 서비스 역시 한 단계 더 앞으로 나아갈 수 있을 것이라 생각합니다.
소통이 잦은 PO인만큼 유관 부서의 업무 지식도 많이 알고 있는 것이 중요한가요?
Kooya) 어느 정도 알고 있는 것이 좋긴 합니다. 물론 기획 과정에서 유관 부서들과 소통하며 기획서 내용 자체를 더욱 구체화해나가긴 하겠지만, 그래도 유관 부서들의 실제 작업 공정을 이미 알고 있는 상황이라면 1차적으로 기획 밑그림을 그리는 단계에서부터 보다 현실적인 기획서 작성이 가능할 것이라 생각합니다.
다만, 유관 부서 지식은 기획 과정에서 차차 쌓을 수 있고, 또 모르는 내용이 생길 경우 직접 해당 부서에 물어보면 해결할 수 있는 부분이기 때문에 그렇게 걱정할 부분은 아닐 것 같습니다. 오히려 저는 PO 능력의 핵심이라고 할 수 있는 기획력과 관련해 어떻게 하면 기획 내공을 탄탄하게 키울 수 있을지를 고민하는 것이 훨씬 더 중요하다고 생각합니다.
투미유 PO로서 기획력을 키우기 위한 Kooya만의 노하우가 있을까요?
Kooya) 평소 저는 제가 한 모든 일들에 대해 기록과 정리를 빠짐없이 하고자 노력하고 있습니다. 문득 떠오른 기획 아이디어를 비롯해 가볍게 리서치 한 내용들까지도 업무와 관련된 것이라면 모든 히스토리를 남겨두려는 것이죠.
기록하려는 노력은 일단 그 자체로 생각 정리에 도움을 줍니다. 사소하게 보고 지나칠 수 있는 상황도 직접 수고를 들여 그것을 따로 기록하는 과정을 거침으로써 자신의 생각을 함께 정리할 수 있으며, 기록한 내용은 그 자체로 레퍼런스가 되어 추후 기획서 작성 시 아이디어 도출 과정에서 유용하게 활용되기도 합니다.
또한, 꼼꼼하게 기록하려는 자세는 곧 꼼꼼한 업무 히스토리로 연결되어 업무 전체의 흐름을 파악하는 데 도움이 됩니다. 초반에 기획한 내용과 비교해 이후의 내용은 어떻게 달라졌는지, 그리고 그 과정에서 어떤 의도들이 추가되거나 수정되었는지, 우리가 빠뜨렸던 것은 무엇이었는지 등을 정확히 확인해 볼 수 있기 때문에 더욱 개선된 기획을 가능하게 합니다. 그리고 꼼꼼하게 남겨진 업무 히스토리는 추후 인수인계 시, 해당 내용을 처음 보는 사람이라 할지라도 관련 내용을 빠르게 이해하는 데 도움을 줄 수 있습니다. 따라서 PO라면 자신의 일을 꼼꼼하게 기록하는 자세만큼은 필수로 지녀야 한다고 생각합니다.
기획서 완성 후에는 기획서 내용에 따라 기능 단위의 구체적인 개발 업무가 진행될 텐데요. 이때 PO는 어떤 역할을 수행하나요?
Kooya) 기획서 내용에 따라 각 팀 단위에서 적절하게 업무가 진행되고 있는지를 수시로 소통하며 확인합니다. 작업 과정에서 나오는 팀별 의견을 조율하고 전체적인 일정도 챙기며 진도율을 체크하고 있습니다.
만약 작업 과정에서 기획서 내용이 수정되어야 할 필요가 발생했을 때에는 빠르게 미팅을 주선하여 소통을 통해 해결 방안을 마련하고자 노력합니다. 주어진 상황에 맞게끔 기획서 내용을 적절하게 수정해 가며 매 순간 최선의 판단을 위해 고민합니다. 그 외 작업 과정에서 새롭게 등장하는 아이디어들에 대해서는 다음 번 기획에 효과적으로 반영될 수 있도록 따로 기록해 둡니다.
계획한 작업이 모두 종료되었을 때는 새롭게 추가된 기능들이 제대로 작동하는지 확인하기 위해 QA 테스트를 준비합니다. 이번 기획 내용의 규모에 따라 전사적인 QA가 진행되어야 하는지, 부분적으로 진행되어도 문제가 없는지 등을 판단해 팀 내에 QA 일정을 제안합니다. 결과적으로 QA 테스트까지 완료한 후에는 최종적으로 업데이트된 서비스를 출시하게 됩니다. 이처럼 기획서 작성이 끝이 아니라 이후의 실질적인 모든 개발 과정 걸쳐 전반적으로 관여하며 중심을 잡고 컨트롤 해오고 있습니다.
인터뷰 감사합니다. 끝으로 PO를 꿈꾸는 분들에게 한 마디 해주세요!
Kooya) 평소 가설을 세워 실험을 통해 제품을 개선하거나 기존에 없던 정책과 기능을 만드는 데 관심이 있던 분이라면 PO로서 열정을 발휘할 충분한 준비가 되었다고 생각합니다. 덧붙여 앞서도 말씀드린, PO로서 제가 중요하다고 생각하는 4가지를 다시 한번 강조 드리고 싶습니다. '① 서비스에 대한 높은 책임감, ② 기획력, ③ 소통, ④ 기록하는 자세' 이 4가지를 잊지 않고 꾸준히 발전시켜 나가신다면 분명 훌륭한 PO로서 성장하실 수 있을 것이라 생각합니다. 저 또한 같은 PO로서 응원하겠습니다~!
(인터뷰 마침)
