프로덕트의 시작
아이디어 유입과 정당성 부여
PM은 제품의 처음과 끝을 책임지는 사람이다. 그럼 제품의 시작은 어떻게 시작될까? 그냥 단순히 생각해 보면, 대표님이 '내일까지 이거 만들자~'라고 할 수도 있고, 팀원 한 명이 엄청난 아이디어를 가져와 시작이 되는 경우도 있을 수도 있다. 영업팀에서 이게 꼭 있어야 많이 팔 수 있다고 해서 시작되는 경우, 전략실에서 이 것만 있으면 성공할 수 있다고 시작되는 경우 등 다양하게 존재한다. 영화나 드라마에서 보면 주인공이 엄청난 아이디어로 성공하는 케이스도 있고, 그냥 무시당하는 경우도 있다. 일부는 맞고, 일부는 틀릴 수도 있다. 그런 상상들이 프로덕트를 시작하는 것은 맞지만 현실은 그리 쉽지 않다..
제품이 처음 시작되는 케이스는 매우 다양하다. 갑자기 밥 먹다가 아이디어가 나올 수도 있고, 미팅 중에 나올 수도 있고, 영업부서에서 제안이 올 수도, VOC나 소비자의 직접적인 의견에서 나올 수도 있다. 하지만 어떤 케이스로 아이디어가 나오게 되던지, 그 아이디어가 얼마나 상품화가 잘되는지에 따라서 성공 유무가 결정이 된다고 해도 과언이 아니다. 아이디어가 아무리 좋아도 상품화가 안되면 세상에 못 나가고, 아이디어는 평범하지만 상품화가 잘되어서 시장에서 좋은 평가를 받으면 성공할 수도 있다. 상품화의 첫 단계는 요구사항을 정의하는 것이다. 일반적으로 PM에게 요구사항이 접수가 된다. 그게 신규사업을 위한 신상품이 필요하다는 내용일 수도 있고, 현장에서 필요한 운영 개선, 버그 수정도 있을 수 있고, 마케팅을 위한 이벤트나 데이터 추출 같은 기능이나, LMS나 가챠 시스템 같은 발송 툴, 이벤트 페이지 생성, 혹은 BI, 인프라, 결제, 빌링 같은 비즈니스 지원 기능일 수도 있다.
그럼 그때부터 PM은 요구사항을 분석하고, 시장조사, 경쟁사 조사, 현재 소비자의 수준, 타깃 유저 등 다양한 부분에서 검토하고 논의를 할 수 있게 준비한다. 무엇이 됐건, 회사에서 필요한 과제가 발생이 되면 PM이 내용을 파악하고, 내부적으로 가능한지, 일정, 예산, 인력, 꼭 필요한지, 시작할지 말지 등을 의사결정하거나 혹은 의사결정이 될 수 있도록 알기 쉽게 정리한다. 나는 PM은 통역하는 사람이라고 생각한다. 사업부서와 개발부서 간의 사상과 언어, 생각하는 방식등이 너무나 다르기 때문에, 서로 이해할 수 있도록 내부에서 정리하고 각각 알아들을 수 있는 언어로 설명해 주는 역할이 매우 중요하다.
PM의 가장 핵심적인 역할은 바로 프로덕트의 정당성 부여이다. 사실 이전 글에서도 얘기한 것처럼 PM은 직책자나 의사결정자가 아닌 경우가 많이 있다. 하지만 제품에 대한 거시적인 관점으로 제품화를 시켜서 업데이트 혹은 출시를 해야 한다. 그러려면 이 제품에 대한 정당성이 있어야 기획자, 개발자, 마케터, 디자이너, QA 등 다양한 사람들이 왜 열심히 잘 만들어야 하는지 이유가 생기기 때문이다. 간단한 제품이더라도 시장의 필요성이나 향후 발전 가능성에 대해서 잘 설명이 되어 있다면 더 열심히 분석하고 참여할 것이고, 아무리 복잡하고 좋아 보여도 필요성이 전혀 보이지 않고, 미래가 보이지 않는 제품이라면 아무도 안 하려고 할 것이다.
PM은 이해관계자들을 하나로 만들어서 제품을 완성해야 한다. 사장님이 갑자기 탑다운으로 하라고 하던, 사업부에서 오랫동안 고민해서 하자고 하던, 현장에서 긴급하게 필요하다고 요청하던, 신규 프로젝트를 발의하고 그 프로젝트에 의미를 부여하는 것이 매우 중요하다. 적어도 이 프로덕트에 직간접적으로 할당된 구성원들이 이 프로젝트를 하고 싶게 만들어야 성공할 확률이 올라간다고 생각한다. 사업기획, 신사업 등 각 담당자들이 검토를 하고 오지만 프로덕트에 대해서 제대로 이해하고 있는 경우는 매우 드물다. SWOT, 4P, STP 등 다양한 툴로 검토를 하지만, 사업의 입장이 아닌 프로덕트의 입장에서는 PM의 의견이 매우 중요하고, 실행 이유를 다양하게 설명할 수 있어야 한다.
[Product의 시작]예전 프로젝트 중에 직영점 인프라 시스템을 구축한 적이 있었다. 내가 진행했던 프로젝트 중에 제법 규모가 큰 프로젝트였고, 일정, 예산 등이 많이 필요했었다. 직원과 고객이 매장 운영을 잘할 수 있는 시스템을 만들어달라는 게 사업부의 요청이었다. 요구사항을 현장 직원들과 고객들을 상대로 인터뷰하고 구체화하였으며, 직영 사업에 얼마나 도움이 되고 필요한지 이 프로젝트에 정당성을 부여하였다. 무인 키오스크를 도입하여, 골프연습장 시뮬레이터와 연동하여 모바일로 타석을 예약하는 등 인프라의 영역이었다. 이해관계자들은 명확한 Why를 공감하고 하나의 비전을 바라보며 같이 개발했었던 것 같다. 처음에는 프로토타입으로 몇 개 매장에서 필드테스트하고, 순차적으로 적용하여 1년 만에 시스템을 구축하였다. 약 80개 정도 직영점에 도입하였는데, 만족도도 높고, 개발자들이 공감대를 형성하여 비교적 빠른 일정에 좋은 제품을 출시할 수 있었다. 그다음 해에 코로나 팬데믹이 되면서 무인키오스크와 예약시스템은 좋은 평가를 받으며 매출을 끌어올리는데 큰 기여를 했었던 것으로 기억한다.
대략적인 아이디어와 하고 싶은 내용이 있지만, 일반적으로 추상적으로 표현하는 경우가 많이 있다. 예를 들어 고객이 원하는 제품, 잘 팔릴 것 같은 제품 등을 추상적인 요구사항에 대해서 만들어 달라고 하면 뭘 만들어야 하는지 알 수 없다. 따라서 PM는 요구사항을 구체화시키고, 명확하게 하여, 이해관계자들이 이해할 수 있도록 정당성을 부여하고, 프로젝트를 시작해야 한다고 생각한다.
*요약
PM은 추상적 요구사항을 명확하게 정리하여, Why에 대한 정당성을 부여하고 프로젝트 혹은 프로덕트를 시작하는 사람이라 생각한다.