이론 말고, 현실에서 PM으로 살아남기
회사만 가면 뭐할지 모르겠는 주니어 PM들을 위한 글
약 4년전, 서비스 기획자로 일하다가 PM(Product Manager)으로 이직을 했다.
해야 하는 일의 종류와 범위가 크게 다르지 않을 것이라 예상했지만, 현실은 꽤 많은 부분이 달랐다.
PM, PO의 역할이 섞인 회사였고, 그곳에서 느낀 바를 말하자면..
역할은 회사 바이 회사이므로 다르다. 위 항목들은 나의 개인적 경험이다.내가 처음 PM으로 일했던 회사에서는 아래와 같은 사람을 바랬다.
- 일정, 결과를 숫자로 설명할 수 있어야 하는 사람
- 프로덕트의 흥망성쇠를 책임져야 하는 사람
- 비전과 이유를 가지고, 의사결정을 확실하게 해야 하는 사람
분명 좋은 말이고, 저렇게만 하면 될 것 같은데 '어떻게 해야 잘'할 수 있을지 도저히 감이 안 잡히더라.
뭘 어디서 배워야 할 지 모르겠으니, 책과 강의로 이론을 집어넣자!
- 책 : 프로덕트 오너, 프로덕트 리더십, 린 분석, 린 스타트업, 린 고객개발, 임파워드, 각종 데이터 관련 서적
- 강의 : 탈잉, 패스트 캠퍼스, udemy의 온갖 PM, PO/데이터 강의들..
책과 강의로 이론을 집어넣던 나.. 뭔가를 배워야 할 때, 나는 당연하게 책과 강의를 먼저 찾았던 것 같다.
하지만 이론으로 배운 것을 현업에 바로 적용하기엔 무리가 있었다. 우리 조직에 필요한 모양이 동그라미였다면, 나는 그 당시 조금 삐져나온 사각형이었다.
사각형에서 동그라미로, 우리 조직에 맞는 PM이 되기 위해 내가 한 것은 레슨런 (TIL : Today I Learned)이다.
나를 빠르게 성장시켜준 방법, 레슨런 (TIL : Today I Learned)
이렇게 매일 잘 한 점, 개선할 점, 배운 점을 적고 계속해서 조직에 맞는 PM이 되는 수련의 시간을 보냈다.
사실 '잘하는 PM'이라는 것이, 정해진 하나의 답/이상적인 모습이 있는 것이 아니고 팀에 '필요한 PM'의 모습은 모두 다르다.
그렇기 때문에 각자의 경험에서 암묵지를 쌓아 나가는 것이 가장 중요하다.
명시지는 강의, 책을 통해 습득할 수 있다.
하지만 저 심해까지 뻗어있는 암묵지는 현장에서 시행착오와 경험을 통해 체화할 수 있는 영역이다. 누군가 조언을 해 줄 수는 있지만, 내가 속한 조직에서 내가 맞는 조각이 되려면 암묵지를 쌓는 것이 정말 중요한 것이다.
레슨런을 통해 PM으로서 배운 것들을 몇 가지 이야기하고자 한다.
삽질하며 쌓은 PM/PO 레슨런들
1. PM은 항상 다음, 그 다음을 고민해야 한다.
"우리 이거 한 다음에 뭐해요..?"
당시 정말 많이 들었던 팀원들의 질문이었다.
서비스 기획자일 때에는 이미 정해진, 주어진 프로젝트를 주로 했기 때문에 PM이 처음 됐을 때 로드맵의 중요성조차 잘 모르는 상태였다.
처음 저 질문을 받았을 때 벙-쪘다.
문제를 정의하고 PRD를 작성해서 디자인, 개발/QA, 릴리즈의 프로세스를 돌고 있다고 치자.
PM은 이번 프로젝트의 디자인이 진행되고 있을 때 다음에 진행할 피쳐를 고민하고 만들어둬야 한다.
1번 프로젝트의 디자인을 개발에 넘기면, 바로 다음 피쳐를 리뷰하고 작업에 착수할 수 있도록 준비해야 하는 것이다.
꼭 다른 피쳐가 아니더라도, 이번 프로젝트를 어떤 phase로 끊어서 갈 것인지 그래서 다음엔 무엇을 해야 하는지가 명확하게 나와 있어야 한다.
2. Product Designer와 협업 시 주의할 것
책에 보면 'PM은 디자인에 대해 개인적 선호를 배제하고 기능 원칙/고객 시점 기반으로 판단한다.'를 강조한다.
하지만 나는 초반에 아래와 같은 만행을 저질렀다 �
Product Designer와 협업 시, 개인적 선호를 배제하고 아래 세 가지를 설명하면 된다.
1) 만드는 이유
2) 추구하는 목표
3) 고객의 Value
선택적으로) Core Flow, 꼭 고려되어야 하는 제약/예외 사항 등
저것을 '어떻게' 유저에게 보여줄지는 디자이너의 역량이다.
유저 스토리 기반으로 경험이 충족되는지, 제약사항들이 고려됐는지 확인하는 것이 그들의 전문 영역을 존중하며 협업할 수 있는 방법이라고 생각한다.
이후 나는 아래와 같이 협업을 시작했다.
3. 데이터! 명확하게 요청합시다. ⭐️분모, 분자 꼭 챙깁시다!⭐️
가장 많이 삽질했던 영역이 데이터 관련된 이슈들이었어서, 진짜 몸에 아로새겨졌다..
예를 들어 DA에게 리텐션 데이터를 요청하는 상황이었다고 해보자.
지금 봐도 부끄럽다..
3월 내 7일동안 들어온 이력이 있는 유저의 수?
-> 분모가 뭔데? 7일 동안 한 번만 들어와도 돼? 3월 전체야? 기간이 모호해..
이 날 거의 머리를 쥐어뜯으면서 나 왜 이렇게 바보같지..를 100번 새기며 레슨런을 썼었다.
괴로움이 느껴지시는가..
'아니 이건 데이터를 알고 모르고의 문제가 아니라, 내가 뭘 보려는지 제대로 몰라서의 문제다'
아직도 데이터를 잘 모르는 데린이이긴 하지만, 아래 가지는 꼭 지켜서 보려고 한다.
1) 분모, 분자 (뭐 대비 뭐야?)
2) 분모 분자를 정했다면 더 디테일하게.
3) 요청하는 경우라면 이 데이터가 왜 필요하고, 언제까지 필요하고, 어떤 기대효과가 있을지 명확히.
4. 직감 그만. 데이터로 결정합시다.
구매 전환율을 높여야 하는 미션을 갖고 있다고 하자. 어떻게 접근할 것인가?
과거의 나는 '뭐.. 체류시간 높이고 상품 더 보여주면 구매 전환율이 높아지지 않을까?'의 사고가 익숙했다면, PM이 되고 나서는 사고 흐름이 변했다.
(이것 또한 수많은 삽질과 수많은 깨짐을 겪으며, 말그대로 얻어 터지며 체화한 것들..)
구매 전환율을 높여야 한다.
1) 구매 전환율이라는 output metric (end goal)에 영향을 주는 지표들(metrics)이 뭐가 있지? 를 본다.
2) metrics에 영향을 주는 metric들을 찾아낸다.
3) 액션 아이템을 짜고, 소위 어디부터 조져야 할지 데이터를 본다.
5. 우리 서비스를 쓰는건 고객이다. 유저 테스트는 필수
많은 회사에서 유저 테스트, In depth Interview의 중요성을 알고 있을 것이다.
전문성을 갖고 있는 UX 리서처가 있다면 좋지만, 대부분 없는 환경에서 고군분투 하는 경우가 많을 것이다.
처음 PM이 되어 실수했던 것이, 우리 팀에서는 계속 보던 기능이라 사용성에 불편을 느끼지 못하고 바로 릴리즈를 했다.
그 후 유저 사용성 테스트를 진행했는데, 그 기능이 어디 있는지 조차 모르는 것이 아닌가...?
그 이후에 서비스를 오픈하기 전, 유저 테스트를 진행하는 것을 프로세스로 정해두었다.
당연히 테스트 하는 것이 좋다는 건 다 알고 있을 것이다.
근데 현실에서는..
어느 세월에 대상자 찾고, 컨택하고, 인터뷰 진행 후 수정하고.. 물론 어렵다.
내부 동료를 활용하자.
생각보다 우리 서비스를 많이 쓰지 않는다. 간단한 사용성이라도 꼭 체크를 하고 릴리즈 하는 것이 1명의 고객보다 2명의 고객을 남길 가능성이 높아진다.
아마 회사 바이 회사, 사람 바이 사람이기 때문에 나의 모든 경험이 맞다고 할 수는 없다.
내가 속한 곳에서 경험하며 체화한 암묵지이기 때문이다.
내가 강조하고자 하는 것은 TIL! 레슨런을 놓치지 않고 쌓자는 것이다.
노션에 기록한 나의 레슨런들바쁘게 하루를 살다보면, 내가 성장할 수 있는 포인트들이 많은데 놓치고 지나가는 경우가 많다.
이것들은 시간이 지날수록 기억에서 사라지고 같은 실수를 반복할 확률이 높아진다.
PM, PO는 특히나 다양한 직군과 커뮤니케이션하고, 그 회의체들의 중심에 있기 때문에 다양한 레슨런들을 쌓아서 어떤 퍼즐칸에도 맞는 조각이 되어야 한다.
