by
Jan 23. 2023
오늘도 PM이 안 된다고 말했다.
Product Manager(PM)와 일하는 방법
출근길 오늘은 평소보다 기분이 좋다. 왠지 회사에서도 좋은 일이 일어날 거 같은 느낌이다. 시간을 때우기 위해 보던 SNS 글 중에서 어느 스타트업의 성공 사례가 눈에 뜨인다. 재미있게 글을 읽고 있는 도중 갑자기 회사 서비스에 적용할 수 있는 번쩍이는 아이디어가 떠올랐다! 가슴이 두근 거린다. 내가 생각한 이 멋진 아이디어가 서비스를 발전시켜 동료들이 나에게 박수를 받치는 모습을 상상한다. 회사에 도착하고 가장 먼저 설레는 마음으로 같은 팀 PM에게 나의 큰 그림을 설명한다.
오늘도 PM이 안 된다고 말했다.
실제로 있던 일은 아니다. 비슷한 일은 있었지만.. 단지 개발자로 처음 Product Manager(PM)와 일을 시작했을 때 쉽지만은 않았다는 걸 표현하고 싶었다. 직군에 대한 이해와 커뮤니케이션 능력이 부족했고 적응 기간이 필요했다. 시간은 걸렸지만 노력한 결과 이전보다 협업을 잘할 수 있게 되었다. 돌이켜 생각해 보면 PM은 성공적인 프로젝트 진행에 중요한 역할을 하고 나에게 큰 영향을 준 포지션이라고 생각한다. 오늘은 내가 평소에 PM과 일하면서 중요하게 신경 쓰는 부분들에 대해 이야기해보려고 한다.
스스로 PM과 일하면서 부족했다고 느낀 부분들이고 앞으로도 개선할 부분이 많이 있어 노력하려고 해요. 글 내용 중 다른 의견이 있으시거나 추가하실 내용있으면 댓글에 달아주시면 큰 도움이 될거 같아요 :)
PM은 무슨 일을 할까?
먼저 PM이 하는 일에 대해 이야기해 보자. 처음 Product Manager라는 이름만 듣고는 쉽게 어떤 일을 하는지 상상하기 힘들었다. 내가 잘 모르기 때문이기도 하지만 지인들에게 이야기를 들어봐도 회사와 팀의 성향에 따라 역할들이 다양했다. 검색 사이트에 검색을 해봐도 나와 같은 궁금증에 답해주는 글들을 찾아볼 수 있다.
내가 경험한 PM에 대해 써보자면 목적 조직에서 최대한의 성과를 내기 위해 사용자와 시장에 대한 이해를 바탕으로 서비스의 비전과 방향성 그리고 전략을 고민하고 구체적인 목표를 정한다. 이후 휴먼 리소스와 일정 관리를 통해 프로젝트를 순조롭게 진행하는 역할을 한다. 이 모든 것들을 위해서 기본적인 데이터 분석 능력도 가지고 있다. 다양한 방면을 고려해야 하는 포지션이기 때문에 만능을 요구한다. 빠르게 변하는 시장에서 최소의 리소스로 서비스를 성공시키는 중요한 역할이다.
그래서 PM은 무엇을 궁금해할까?
서비스 개선을 위해 프로젝트 제안부터 진행까지 많은 부분 PM과 소통을 한다. 자연스럽게 회의도 많아졌다. 일하기 시작한 초반에는 회의를 진행해도 제시간 안에 결론을 내기 어려웠고 좋은 피드백을 주고받지 못하는 일이 반복되어 어려움을 겪었다. 스스로 고민도 해보고 함께 일하는 PM에게 조언을 받아본 결과 회의 때 내가 준비한 내용이 주로 시스템 구조와 알고리즘 같은 구체적인 구현 설명으로 이루어져 있다는 걸 알 수 있었다. 프로젝트 진행에 중요한 내용들이지만 구체적인 모든 사항이 PM에게 꼭 필요한 정보인지 다시 한번 생각해봐야 한다. 배경 지식이 다르기 때문에 짧은 시간에 이해하기 어렵고 관련해서 조언을 해주기도 어렵다. 모두 설명하기보다는 최대한 쉽게 요약하거나 방향성을 전달하고 나머지 부분은 내가 주도적으로 진행하면 되는 부분이다. 대신 서비스의 방향과 프로젝트 관리 측면에서 의사결정에 필요한 일정에 대한 이야기나 작업의 결과물이 서비스에 주는 영향을 잘 정리하는 것에 집중해야 한다.
제안할 때는 구체적으로 말하기
서비스 개선을 위해 새로운 기능을 만들거나 고도화가 필요해 프로젝트를 제안할 때가 있다. 이때 내 생각을 동료들에게 공유하는 과정이 필요하고 많은 경우 PM도 대상에 포함된다. 내 머릿속에 있는 생각을 타인에게 전달해야 하기 때문에 나에게는 가장 어려운 커뮤니케이션에 속한다. 원활한 소통을 가장 먼저 챙기는 부분은 하고 싶은 게 무엇이고 이를 통해 해결하고 싶은 게 무엇인지 구체적으로 말해 상대방이 내가 하고자 하는 것을 상상하게 쉽게 만드는 것이다. 검색 서비스에 오타 교정 기능 적용을 제안하는 예시를 들어보겠다.
사용자가 검색어를 입력할 때 잘못된 타이핑으로 의도하지 않은 검색어를 입력하는 경우가 있어요. (어이폰14프로 -> 아이폰14프로, 로ㅇ패딩 -> 롱패딩). 잘 못 입력한 검색어의 결과는 만족스럽지 않거나 보여줄 내용이 없는 경우가 많아, 결국 검색 결과 클릭수에 안 좋은 영향을 줘요.
실수로 입력한 검색어를 인식하고 원래 의도한 검색어를 찾아주는 모델을 만들면 좋겠어요. 검색 클릭수 증가에 도움이 될 거 같아요. 오타를 입력한 사용자에게 올바른 검색어를 제안하거나 강제로 검색 결과를 변경할 수 있을 거 같아요. 서비스 적용은 간단하게 모델을 만들고 성능을 측정한 이후에 고민해 봤으면 좋겠어요.
실수로 타자를 잘 못 입력하는 케이스 이외에도 '삼성아이폰14' 처럼 잘못된 지식으로 잘못입력하거나, 한영키를 변경하지 않아 발생하는 'dhxk(오타)'도 존재한다. 사람에 따라 다양하게 해석할 수 있기 때문에 예시와 구체적인 설명을 추가했다. 의도가 잘 못 전달 되는 걸 막고 보다 집중력 있게 회의를 진행할 수 있다. 다음으로 이 기능으로 해결하고 싶은 문제나 어떤 긍정적인 효과를 주는지 언급하고, 프로젝트 범위에 해당되지 않는 부분도 정리해 공유하면 좋다. 예시는 간단하게 작성했지만 좀 더 상세한 설명과 수치적 근거를 제안하면 더 좋을 것이다. PM은 이런 정보들을 바탕으로 프로젝트 방향을 고려해 조언해 주고 우선순위와 필요한 리소스도 같이 고민해 줄 거다.
서비스에 어떤 영향을 주는지 전달하기
방법론도 중요하지만 내가 작업한 결과물이 결국 서비스에 어떤 영향을 주는지 설명할 필요가 있다. 다시 강조하면 PM은 결국 팀이 하는 일이 서비스를 어떻게 변화시키는지 궁금해한다.
[...] 이번에 변경한 검색 랭킹 알고리즘은 전체 대비 약 23% 검색의 결과에 영향을 줘요. 그렇기 때문에 AB 테스트 실험을 통해 서비스 배포 여부를 정하면 좋겠어요.
검색 결과가 없는 검색어 중 6%는 이번에 개발한 오타교정 모델로 올바른 검색 결과로 연결해 줄 수 있어요. 이를 잘 활용하면 보다 많은 콘텐츠를 사용자에게 연결시켜 줄 수 있어요.
가능하다면 내가 작업 모델이 전체 검색의 어느 정도 규모의 비율로 영향을 주는지 공유하는 편이다. 모델에 따라 비중이 적고 많을 수 있는데 이는 서비스에 주는 영향도와 리스크에 대해서 가늠할 수 있는 수치가 된다. 상대적이지만 만약 전체 검색에 적은 비율(대략 1~10%)로 영향을 준다면 도전적으로 서비스에 반영해 볼 수 있다. 반대로 비중이 크면(80~90%) AB 테스트 실험 같은 보수적으로 접근이 필요하다.
오타교정 모델 예시처럼 수치를 통한 설명을 통해 해당 모델이 서비스에 미칠 긍정적인 효과를 알 수 있고 우리가 팀의 목표에 어느 정도 영향을 주는지 성과를 측정하기 위한 지표로 무엇을 봐야 하는지 결정하는데 도움을 준다.
서비스 관점으로 시작해 WHY 고민하기
모델링과 개발을 주로 하다 보니 최근에 이슈가 되는 기술이나 유명 기업의 적용사례를 보고 아이디어가 떠오를 때가 있다. 그리고 최근에 읽은 글에도 일부 큰 기업에서 기술 부서에서 정한 목표와 비전을 따라가는 예시를 읽은 적이 있다.
N사 검색에는 오타 검색어에도 자동완성 결과가 나오고 있어어 저희 서비스에도 적용하면 좋을 거 같아요.
요즘 딥러닝 기반의 벡터서치가 화두가 되고 있는데 저희도 적용해 봐요!
다른 회사에는 급상승하는 검색어를 보여주고 있는데 저희는 없는 거 같아 만들어보면 좋겠어요.
이런 접근이 잘못된 건 아니지만 다른 회사 서비스와 현재 개선하고 있는 서비스는 상황과 맥락이 다를 수 있다. 결국 이 기술을 통해 현재 어떤 문제들이 해결이 되고 그 과정이 팀의 목표에 맞는지 고민하고 이해시켜야 하는 과정이 필요하다. PM과 소통을 떠나서 서비스를 만드는 입장에서 필요한 과정이라고 생각한다. 만약 혼자 고민하기 어렵다면 동료들과 함께 논의해 보자 다양한 의견이 나올 수 있고 이런 시간이 많아질 수 록 개선에 필요한 도메인 지식을 늘리는데 도움이 된다. 이렇게 글을 쓰지만 필자도 서비스를 고려해 이유를 찾는 게 쉽지만은 않다. 만약 당장 이유를 찾기 어렵다면 개인 시간을 활용해 내가 생각해 본 기능을 사이드 프로젝트로 구현해 보는 편이다. 속도 감 있게 작업할 수 있고 만족하는 결과가 나올 때까지 충분히 고민할 수 있다. 이후에 가능하면 잘 정리해서 동료들에게 공유를 하는데 이를 통해 다양한 의견을 들을 수 있다. 당장은 아니어도 시간이 지나 다시 언급되어 프로젝트로 진행되는 경우도 있다. 결국 마지막까지 서비스에 반영되지 않아도 회사 데이터를 통해 충분히 공부하고 경험한 걸로 만족한다 (게다가 멋진 동료들의 피드백까지!). 꼭 내 진행하고 싶은 아이디어라고 해서 무조건 서비스에 반영될 필요는 없다. 욕심이라고 생각한다.
주도적인 일정관리
프로젝트의 대략적인 일정은 PM이 정하지만 이후 세부적인 일정은 각 담당자가 주도적으로 정하는 게 좋다. 세부적인 일정은 작업을 하면서 구체화되는 경우가 많고 한 프로젝트에는 다양하고 많은 동료가 포함되기 때문에 PM 혼자 챙기는 건 쉽지 않다. 내 일정과 관계있는 동료와 따로 시간을 가지고 구체적인 진행 방향을 이야기하고 일정을 정하는 시간을 가지자. 변경이 되거니 일정을 맞출 수 없게 되면 미리미리 공유하자. 당연한 이야기지만 신경 쓰지 않으면 놓칠 때가 있다.
