PM의 무기는 무엇이어야 하는가
제품과 비즈니스를 아우르는 균형잡힌 시각
"이 탭은 다른 기능으로 구성해야 하지 않아요?"
"더보기 화면에 이런 정보가 들어가는 게 맞나요? 너무 어색해요."
프로덕트 매니저로서 업무를 할 때면 수도 없이 질문과 답변으로 점철된 커뮤니케이션을 하게 된다. A라고 정의했어도 '그것이 맞는지, 그렇다면 왜 그렇게 해야 하는지, 예외 상황은 없는지, 다르게 표현할 수는 없을지..' 각 직군별 담당자들과 논의하는 과정이 계속된다. 구현 관점에서, 사업 관점에서.. 각 사이드에서의 많은 이야기들을 듣게 된다.
요 몇 년 간, 기획자는 PO, PM 다양한 직군으로 변화해온 것 같다는 생각을 한다. 들리는 말로는 실제로 하는 일은 별반 차이가 없음에도 불구하고 직군을 지칭하는 명칭만 다른 경우도 있다고 하고, 조직이 기능 조직이냐 목적 조직이냐에 따라 직군의 변화를 가져온 경우도 봤다. 혹은 IT산업이 점차 글로벌화되면서 실리콘밸리의 업무 방식과 구조를 -흔히들 PO/PM으로 구성된 조직이 이끄는 조직-경험해온 이들이 전파한 데서 기인하기도 한다. 사실 이 부분은 내가 전문가도 아니고 많은 경험을 해본 것도 아닌지라, 무엇이 정답인지도 모르고 '여기선 이렇게 일한다더라'라는 곁가지로 들은 정보들만으로 인용하는 것이 전부이지만. 다 차치하고 결론적으로 조직에서는 점차적으로 PO/PM를 지향하는 변화의 물결을 계속 체감하고 있다.
도대체 뭐가 달라진 거지? 그렇다면 뭐가 달라야 하는 거지?
다시 처음으로 돌아가서,
저 예시처럼 제품의 기능을 개선할 때 이런 주제들로 굉장히 많은 이야기를 한다. 모바일 기반 서비스의 경험이 익숙한 시대. 좋은 서비스를 많이 경험하고 사용할 기회는 더 많아지고, 더더군다나 전문가들이기에 더 많이 레퍼런스를 던질 수 있다. 그 누구든 '기획한 내용'에 또다른 관점의 논리로 '기획을 얹을' 수 있게 된 거다.
때론 디자이너가, 때론 개발자가, 때론 데이터 담당자가.. 서비스에 관심이 많고 적극적인 사람들은 제품의 성장에 집중해서 다양한 이야기들을 건넨다. 과거였으면 '기획한 내용에 왈가왈부한다'며 R&R에 대해 기분나빠했을 수도 있지만 이제는 그런 것들이 의미가 없어진 거다. 목적이 제품의 성장에 달렸고 모두가 같은 KPI를 들고 고민한다는 걸 알기 때문에. 더이상 과거처럼 프로덕트를 기획하는 것이 '기획자의 전유물'이 아니게 된 셈이다.
그렇다면, 누구나 기획에 아이디어를 던지고 레퍼런스를 자신있게 내어놓을 수 있는 시대에 PM의 무기는 도대체 무엇이어야 하는가라는 고민을 해보게 됐다. 과거처럼 디테일하고 꼼꼼하게 기능을 정의하고, 그걸 개발할 수 있는 수준으로 정의해서 건네고, 와이어프레임을 그리고, 동작에 대해 고민하고.. 요 수준이면 되는 걸까?
결국 지금의 시대에 PM은 더이상 기획서만 쳐내려가는 스킬만 가지고는 살아갈 수 없다. (PM에게 기대하는 포지션이 아닐 거기도 하고) 그렇다고 일정 관리를 하고 프로젝트를 관리하는 일만 가지고는 더더욱 살아갈 수 없다. 그것은 기획자 출신의 PM이 아니어도 충분히 가능한 일이다.
"이 탭은 다른 기능으로 구성해야 하지 않아요?"
"더보기 화면에 이런 정보가 들어가는 게 맞나요? 너무 어색해요."
탭의 기능에 대한 제안은 솔직히 누구나 할 수 있다. 서비스에 애정만 있고 관심만 있다면 누구든 아이디어를 내고 제안해볼 수 있는 이야기다. 다만 PM이라면 이런 구성원의 제안에 명확히 답변해 줄 수 있어야 한다. 서비스 전체를 아우르는 관점에서. 왜 이 탭이 이 기능일 수밖에 없는지. 더보기 화면엔 이런 정보가 들어가야 하기로 결정한 근거가 무엇인지.
거시적 관점에서 우리 프로덕트의 방향성과 KPI는 무엇인지 - 단기간에 이루어야 할 KPI는 어떤 것인지.
이 영역을 통해 우리 프로덕트가 달성하고자 하는 정성적/정량적 목표는 무엇인지.
이 영역이 사용자에게 어떤 가치를 줄 수 있는지. 그 가치를 왜 설정했고, 왜 그것이어야만 하는지
이 영역의 기능을 정의하기 전에 어떤 가설을 근거로 목표로 정했는지. 가설 검증은 어떻게 이루어 갈 것인지
이건 기획서를 기반으로 기획 의도를 설명하는 것과는 결이 다른 관점에서의 이야기이다.
사용성에 대한 이해는 UX/UI 디자이너가 더 잘 알 수 있다. 기능과 기술 관점에서의 이해는 당연히 개발이 더 잘 알 수 있다. 사업의 이해 역시 사업을 운영하는 주체인 사업 부서에서 더 잘 알지 않을까. 하지만 PM은 제품과 사업, 둘 다 완벽하게 알아야 한다. 그리고 이것을 기반으로 이해관계자들을 논리적으로 설득해가야 하는 것이다. '안다' 라는 단어로만 말하기엔 두 글자뿐인 것이 너무 아쉽다. 이 지식은 하루 아침에 쌓이지 않는다. 제품에 대한 끊임없는 성찰, 사용자를 샅샅들이 이해하고 분석하는 일, 비즈니스 분야와 산업에 대한 지속적인 지식이 쌓여 이루어지는 길고 지난한 과정이 필요한 일이다.
하지만 결국 이것이야말로 남들이, 그리고 기획자가 절대 가질 수 없는 무기이자 PM만의 역량이 된다.
결국 PM은 프로덕트 그리고 회사 전체 관점에서의 비즈니스와 목표를 명확히 인지하고 있어야 하고, 뿐만 아니라 제품과 사용자에 대한 방향성도 놓지 않고 있어야 한다. 그래야 양쪽 모두 균형을 이루어가면서 어느 한쪽이 무너지지 않게 고려할 수 있고, 궁극적으로는 제품이 비즈니스를 성공적으로 서포트할 수 있는 방향으로 성장시킬 수 있다. 여기서 오해하지 말아야 할 것은 비즈니스의 성장은 사용성의 포기를 말하지 않는다는 것이다. 사용자가 만족하는 서비스라야 비즈니스도 성공적으로 안착할 수 있음을 당연히 내포한다.
번외로, 끄적끄적...
나도 그 전엔 전통적인 IT필드에서 '기획자'의 포지션으로 일해왔지만 요 최근 1년, 이직을 하며 'PM'으로 직군을 변환한 케이스다. 개인적으로 체감한 바로는 이전보다 조금 더 서비스의 앞단에서 큰 그림과 방향성을 그리며 조율하게 된 점, 비즈니스 관점에서 프로덕트를 바라볼 수 있는 시야를 가지게 된 점, 프로젝트(project) 하나가 아니라 제품(product)의 성장을 뚜렷한 목표로 일하게 된 점.. 이런 정도이고 나머지 기획하는 일은 거의 비슷한 것 같다. 엄연히 말하면 PM과 기획자 어디 그 즈음.. 과도기인 것 같기도 하고. 자신있게 PM으로서 100%몰두하고 있냐고 하면 '잘 모르겠다'가 정답이다. PM답게 일하기라는 스터디가 있다면 더 많이 경험하고 배워보고 싶다는 갈증도 크고.
아무튼 여전히 애매한 영역 그 어딘가에 머물러있지만 그래도 나에게 주어진 미션이 제품은 비즈니스의 성공을 서포트해야 한다는 것임은 잊지 않고 일하기를 다짐해본다. 결정한 방향에 대한 수많은 역제안들, 아이디어의 발산을 어제도 받았고 오늘도 받았다. 다만, 그들에게 '이것이 정답이야'라고 밀어부치기보다는 명확한 방향을 제시하고 설득하는 스마트한 PM이 되고 싶다는 생각이 더욱 더 강하게 들었다.
자꾸 자꾸 시도하다 보면 성장해있는 날이 오겠지. '성장과 배움이 있는 일하기'를 하고 싶다.
