PM이 가장 중요하게
생각해야 할 요소 6가지
업무를 하면서 이것만큼은 중요하게 생각하는 중!
지금 회사에서 PM으로 일한 지 200일이 조금 더 지났다. 플랫폼을 기획할 때와는 다른 견해와 업무 방식이 필요했기에 입사 후 지금까지 정신없이 배워왔던 것 같다. (물론 배우기만 하면 안 되고, 여러 번 시도하고 성공하고 실패하고 러닝 커브를 얻으며 성장하고 있다) 배울 점 많은 동료들, 성장하는 product, 여러 가지 테스트와 그로 인한 레슨런까지 사회 초년생으로 일해온 기간 자체가 그리 길지 않고 그동안 부족함과 뿌듯함도 많이 느꼈던 기간이지만, 확실한 것은 생각했던 것보다는 빠르게 성장할 기회가 많은 것 같다.
업무 외에도 회사 안에서 더 많은 인사이트를 얻고자 여러 스터디에 참여하고 있다. 스터디와 다른 PM 분들이 일하는 방식에서 배운, 실제 업무에 적용하며 중요하게 생각하는 6가지 요소에 대해서 정리해보았다. 업무를 하면서 내가 잘하고 있는지에 대해서 스스로 점검하는 시간을 가질 때 활용하는 지표로, 기준이 명확해지고 난 다음부터 확실히 일의 효율이 향상되었다고 생각하는 요소들이다.
(1) 북극성 지표를 잃지 않기
<북극성 지표 체크리스트>
1. 지표에서 가치를 읽을 수 있다. 이 지표가 고객에게 어떤 영향을 주는지 이해할 수 있다.
2. 비전과 전략을 대표한다. 회사의 프로덕트와 사업 전략이 지표에 반영되어 있다.
3. 성공의 선행지표다. 과거의 결과를 반영하기보다는 미래 결과를 예측하게 한다.
4. 실행 가능하다. 지표에 영향을 주기 위한 활동을 할 수 있다.
5. 이해 가능하다. Non-tech 동료도 이해 가능하게 평이한 언어로 쓰여있다.
6. 측정 가능하다. 프로덕트의 상태를 추적할 수 있다.
7. 허상 지표가 아니다. 북극성 지표가 변했을 때 의미가 있는 변화라고 자신 있게 얘기할 수 있다. (팀을 기분 좋게만 해주는) 장기적 성공을 예측할 수 없는 지표와 다르다.
출처 : https://benheo.github.io/2021/09/25/northstarmetric.html
회사에 들어와서 가장 신기했던 것은 정말 product와 관련해서 확인할 수 있는 지표가 많았다는 점이다. 내가 맡은 product 뿐만 아니라 대부분의 product에 대한 지표를 확인할 수 있었고, 다른 사일로나 팀은 대시보드를 어떤 식으로 가져가고 있는지 보면서 왜 해당 지표를 보고 있는지나 product의 특성은 어떠한지 등에 대해서 고민하곤 했다.
일을 하면서 가장 중요하게 생각하는 지표는 북극성 지표이다. 북극성 지표는 제품이 고객에게 전달하는 가장 핵심적인 가치를 측정할 수 있는 지표이다. 중요한 것은, 매출은 서비스의 핵심 가치를 반영하거나 매출이 상승함으로 인해 그다음 액션을 설계할 수 없기 때문에 북극성 지표로 가져가지 않는다는 것이다.
북극성 지표가 정해지면 product가 올바른 방향으로 나아가고 있는지에 대해 가치판단을 하기가 좀 더 수월해진다. 그렇기에 각 product의 생애주기, 사용자에 따른 해당 지표를 명확하게 정하고 이를 바탕으로 의사결정을 하는 것이 확실히 효율적이라는 사실을 배울 수 있었다.
(2) Data-Driven 의사 결정하기
<성공적인 Data-Driven 마케팅을 위한 질문들>
1. '목표'가 무엇인가
2. 우리의 고객은 누구인가
3. 고객의 전체 구매 경로를 고려한 측정 모델이 있는가
4. 가장 중요한 측정 항목은 무엇이며, 어떻게 평가할 것인가
5. 어떤 요소를 어떻게 테스트할 것인가
6. 규모가 아닌 숫자 이면의 의미를 파악하고 있는가
출처 : https://url.kr/bz3sto
Product를 만들어나가는 과정에서 가장 중요한 것은 유저라고 생각한다. 유저가 어려움을 느끼는 부분, 유저가 반응하는 아하 모먼트, 유저의 행동을 확인할 수 있는 데이터까지 그들의 반응으로 끊임없이 product의 가설을 세우고 검증하며 지표를 성장시켜나가야 한다.
이를 위해 여러 가지 Data-Driven 의사결정을 할 수 있다. Data-Driven은 마케팅에서 나온 개념으로, 데이터를 바탕으로 의사결정을 해나간다는 방법론이다. 기존에 존재하는 지표들을 바탕으로 그다음 step을 고민할 수 있고, 갑자기 변동되는 지표의 변화를 역순으로 거슬러 올라가며 개선점을 찾을 수도 있다. 유저와 직접 상호작용하며 product의 성장을 목표로 한다면 A/B test나 User test, 인터뷰 등을 예시로 들 수 있다.
(3) 급한 것과 중요한 것을 잘 정의하기
Product를 발전시킬 아이디어는 정말 다양하게 많다. 하지만, 한정된 maker의 리소스 내에서 아이디어를 검증하는 것은 쉽지 않다. 대학생일 때 처음 프로젝트를 기획할 당시, 개발자나 디자인의 시간이나 리소스를 전혀 고려하지 않고 모든 기능을 정의해갔던 적이 있다. 구조적으로 가능한지 불가능한지에 대한 고려도 중요하지만, 그 상황에서 가장 중요했던 것은 꼭 해야 하는 것인가? 에 대한 질문을 정말 많이 들었다.
처음에는 내가 생각했을 때는 다 필요했지만, 해당 기능이 없으면 작동하지 않는지나 처음 설계한 서비스의 목표에도 맞는 기능인지를 정말 꼼꼼하게 따져보면 mvp는 매우 작게 만들 수 있었다. 그래서, 그때부터 필요한 모든 것을 다 만드는 것이 아니라 급한 것과 중요한 것을 잘 고려해서 작은 단위로 설계하는 습관이 생기게 되었다.
일을 하면서도 늘 우선순위와 관련된 고민을 할 수밖에 없다. 그래서, 업무를 구분할 때도 긴급도와 중요도를 고려해서 우선순위를 정한다. 갑작스럽게 발생한 이슈나 CS의 급증 건에 대해서는 빠르게 처리해야 하기 때문에(=1순위) 제외하더라도, 급하기만 하거나/중요하기만 한 일에 대해서 고민할 때는 위의 그래프처럼 생각하는 것이 유용하다. 만약 하지 못한 일이 있으면 백로그에 넣어두되, 백로그에도 우선순위를 매겨서 리소스가 어느 정도 여유가 생길 시기를 노리다 적절하게 부탁드리면서 일을 하고 있다.
(4) 작은 변화로 큰 임팩트를 내기
급한 것과 중요한 것을 잘 구분하는 것과 이어지는 내용이지만, 좀 더 세부적으로 쪼개서 우선순위를 고민한다면 이 부분도 늘 고려하면서 일을 하는 것이 대부분 유용했다. 주로 백로그에 있는 것들 중 우선순위를 선정할 때 가장 최우선으로 고려하는 사항으로, 적은 리소스를 들이고도 보다 큰 임팩트를 낼 수 있는가에 대해서 많이 고민한다.
빠르게 시도하고, 빠르게 성공하거나 실패하고, 그곳에서 발생하는 러닝 커브로 next step을 고민할 수 있기 때문이다. 이 '변화'라는 것이 단순히 maker의 리소스를 쓰는 것을 의미하는 것은 아니다. 운영상의 변화를 준다거나, 내부 프로세스를 개편한다거나, fake test를 해보는 방법 등이 포함될 수 있다. 가설을 세우고 검증하는 과정에서 들어가는 리소스가 적을수록, 더 많은 시도를 할 수 있기 때문이다. 그래서, 우선은 내가 스스로 확인할 수 있는 부분 인지나 / 크거나 많은 변화 없이도 임팩트를 낼 수 있는 부분이 발견되면 빠르게 해 보는 편이다.
(5) 간결하고 정확한 요구하기
이 부분도 대학생 때 프로젝트를 하면서 배웠던 부분이다. PM이 product에 대해서 가장 잘 아는 사람이어야 하는 만큼, 변화를 시도할 때도 명확하고 간결하게 그 내용을 정의해야 한다.
나는 보통 바뀌어야 하는 스펙을 정의할 때, 1) 이걸 왜 해야 하고 2) 어떻게 해야 하고 3) 예상되는 임팩트는 무엇이다를 바탕으로 설득을 한다. 그 과정에서 "어떻게 해야 하고"를 잘 정의하지 않으면, 왜 해야 하는지나 임팩트가 무엇인지 공감하기 어려울 수 있다.
그래서 보통 "어떻게"를 정의할 때는 구분을 명확하게 나누거나, depth가 존재하는 변화라면 이미지를 첨부시키고, 마치 pseudo code를 그리듯이 요청을 드리려고 노력한다. 그래야 그들과 커뮤니케이션하는 비용이나 오차를 줄이고, 실수를 줄일 수 있기 때문이다. 이후에는 혹시나 내가 잘못 전달한 부분이 있는지나 이해를 하지 못한 부분이 있다면, 상세하게 설명을 추가하곤 한다.
(6) 문서화, 히스토리와 버전 관리 잘하기
마지막으로, 내가 개인적으로 이곳에서 가장 잘 해내고 싶은 부분이었다. 나는 문서화를 시키는 것에 자신이 있고, 이후에 찾기 쉽게 정리하는 것을 잘한다고 생각한다. 하지만 처음 입사를 했을 때 생각보다 문서를 찾는 것에 애를 먹었던 부분이 있다 (물론 내가 정리한 템플릿이 아니다 보니 익숙하지 않아서 찾기 어려웠던 부분도 있었지만, 논의 내용이나 결정 사항, 그리고 이후에 프로덕트를 이어서 만들어나갈 누군가를 위해서 정리하는 것은 정말 필요하다고 생각했다)
그래서 입사 이후에 우리 팀이 맡은 프로덕트가 N개이고, 플랫폼을 아예 처음부터 만들다 보니 문서화가 안되어있거나 히스토리 및 버전이 잘 관리되지 않으면 이후에 어려움이 많을 것이라 예상했다. 실제로 사이드 프로젝트나 이전 회사에서의 경우만 생각해봐도, 얼마 전에 했던 기억만 존재하고 문서를 찾을 수가 없어서(혹은 요청을 드려야 하는데 예전 버전이라 사라진 경우 등..) 고생했던 기억이 있다.
문서화에 너무 많은 시간을 쏟으면 이는 업무 비효율로 이어질 것이다. 그렇기에 나는 초기에 다양한 목적으로 활용될 수 있는 구조를 시간을 들여서 구성했다. 기존의 노션이 아니라 개발자분들이 바로 jira나 개발 문서로 연동하기 편한 confluence를 사용하자고 설득했다. 활용하기 편하게 구조를 잡았으며, 팀원 전체가 더 쉽고 빠르게 확인할 수 있는 문서화를 조금씩 해나가고 있다고 생각한다.
다른 직무도 그렇겠지만, PM은 더욱 다양한 분야를 끊임없이 공부해야 하는 역할이다. 개발자와도 소통해야 하고 디자이너와도 협업해야 하고, 그 밖에 product와 관련된 모든 이해관계자들과 논의하고 의사결정을 내려야 하기 때문이다. 그래서 적어도 내가 옳은 방향을 잃지 않고 가기 위해서, 그리고 더 좋은, 더 나은 의사결정을 내리는 PM이 되기 위해서 늘 노력할 수밖에 없다.
물론 노력하는 과정은 즐겁다. 공부하는 것을 그리 좋아하지 않는다고 생각했는데, 좋아하고 필요한 지식을 공부하는 것은 적성에 잘 맞는다고 느껴지는 요즘이다. 더 많이 배우고 성장하기 위해 노력해야겠다!
