PM 7개월차, 이런 것들이 보입니다 (1)
개발 모르는 사람의 우당탕탕 PM 되기
바쁘다 바빠 현대사회 이런 분들이 읽으면 좋습니다
"PM 안해봤는데 할 수 있을까? 그 업무 하는데는 뭐가 중헐까? 라는 질문이 있는 분"
PM 업무 이전에는 광고 매출 관리 및 전략을 세우는 일을 했다. 데이터를 다루면서 보고서를 만들고, 필요한 기능을 정리해서 광고 플랫폼 PM분들께 전달하고, 내부 관계자들을 설득하여 프로젝트가 굴러가도록 하는 일이었다. 좀더 마켓, 세일즈쪽에 가까웠던 셈이다.
비즈니스에 있을 때와 PM으로 있을 때의 차이점을 중심으로 소회를 말해보려고 한다. 회사마다 PM의 역할도 천차만별이고 연차도 적지만, 7개월차만 보이는 것이 있다는 15년+차 리드님의 응원을 받아서!
참, 그리고 다르게 생각하시는 부분이 있다면 알려주세요! 어떤 생각들이 있는지 궁금해요!
1. 짬에서, 나오는, 바이브
비즈니스는 숫자를 읽을 수 있고 분석 및 리서치를 할 수 있으면 day1 at work에도 기본적인 일을 어떻게 해야할지 감이 잡힌다. 객관적인 자료를 보고 회의를 준비하기 때문에 미리 질문을 예상하고, 답변도 준비할 수 있다. 특히 데이터를 근거로 일하는 팀이라면, 해결책은 여러갈래일 수 있지만, 대부분 같은 문제를 인식한다.
PM은 문제와 할일을 데이터만 보고 짚어내기 어렵고, 볼 수 있는 눈이 있어야 한다. 기획에 대해 dev가 가질 의문을 최대한 내부적으로 검토하지만, 미처 고려해보지 못한 부분에 대한 질문을 받을 때가 있다. 볼 수 있는 눈이 있을수록, 그 질문을 미리 예상하거나 빨리 이해하고 답변을 전달할 수 있어서, 커뮤니케이션 효율성이 올라간다.
그래서 초반에 다각도로 고민해보고 커뮤니케이션 cost를 줄여주는 PM을 모두가 좋아한다. 다만 beginner PM 이면 일의 경험이 적어서 고민해야할 사항들이 잘 안보일 수 있다. a로 만들었더니 b라는 문제가 있더라. 그런데 그건 dev에서 c로 처리해줄 수 있으니 known issue로 알고 a로 가시죠. 라고 말할 수 있는 짬바는 만들어봐야 나온다. 그래서 더 많은 챌린지를 받고, 레거시를 이해하고, dev와 다양한 방법으로 문제를 해결하다 보면 비로소 개발이 답답해하는, 거기까지 고민해서 줄 수 있다. 시장 반응에 따라 빠른 대응이 필요하거나 전례없는 것에 도전할 일이 많은 비즈보다, 좀더 경험의 영향력이 큰 역할 같다.
참고로, 볼 수 있는 눈을 기르는 데 가장 좋은 방법은 코딩을 배우는 것이다. 개발자가 구현하면서 생길 질문들을 미리 예상하는 것이다. Pseudo-code 수준으로라도 만들려는 것을 구현할 수 있다면 내 로직에서 어디가 비어있고 상충되는지를 자가 판단해볼 수 있다 (파이썬이 가장 큰 도움이 되었습니다!)
2. 일어나 KPI 달성해야지, 근데 이제 UX를 곁들여서
전략적 서비스가 아니라면, 비즈니스는 의사 결정의 기준이 매출이므로 방향성에 대한 컨센서스를 만들기 쉽다. 그런데 PM은 좀더 넓게 고민해야한다. 운영 편의성과 비용, 서비스 안정성 등등 고려해야할 것이 많다. 단순 세일즈에서 얼마나 푸쉬하는지, 개발 리소스가 얼마나 드는지의 손익만 계산해서 방향성을 결정하기 쉽지 않다.
가장 흔하고 어쩌면 outdated된 사례가 광고 플랫폼이다. 플랫폼의 매출 극대화를 위해 비싼 광고만 많이 노출되도록 최적화해버리면, 광고가 편중되어 광고주의 이익을 고루 보전하지 못한다. 롱텀으로는 (노출되지 않은) 나머지 광고주로부터 외면받고, 특정 광고주 디펜던시가 커질 수 있는 위험이 있다. 물론 요새는 이런 단기적 관점으로만 밀어붙이는 비즈는 없..(겠지?)
그래서 매출 극대화처럼 모두가 동의하는 기준이 없기에 근거를 내가 만들어야하고, reasoning이 중요하다. 특히 개별 사안에 대해 그때그때 결정하는 것이 아니라, 제품의 goal과 리소스 등 여러 상황을 고려한 통일성 있는 reasoning이 필수적이다.
3. 이거 OO님이 만드셨죠? 프로덕트에서 PM이 보여요...
앞서 말한 의사 결정의 기준과 비슷한 맥락이다. 어떤 가치를 우선순위로 두고 의사결정을 해야하는지 고민하는데, 기본적인 제품의 goal에 맞는 가치들을 최우선순위에 두고, 남은 영역들에서는 PM -혹은 속한 팀- 이 중요시하는 가치도 꽤 많이 반영된다.
예를 들어서 우리 팀 분들은 정확성, 재사용 가능성, 확장성을 중요시하며, 그래서 제안하실때 본인이 "걱정 인형"이기 때문에, 나중을 대비해 넓은 스콥까지 고려하는 바임을 종종 언급하신다. 자주 일어나는 케이스가 아닐지라도 대비를 위해 유효성 검사를 하나 더 넣고, 당장 쓰지 않을 변수도 보관해둔다. 이런 점이 비즈에 있다가 온 내가 적응하고 있는 부분이다. 나는 문제를 좀더 단순하게 접근해서, 필요 없으면 쓰지 않는 경제성을 우선순위로 두고 업무를 진행해왔다. 따라서 없앴을 때 생기는 문제를 고려하지 못한 기획을 할 때가 종종 있었다.
더불어 이 부분은 '뭘 만들지'에도 반영되지만 '어떻게 만들지'에도 반영된다. 운영 편의성 등을 제하고 시간내 필수 기능만 빠르게 출시하고 나중에 변경할지, 나중을 위해 초반에도 범용적인 관점으로 설계할지가 달라진다.
4. 숲을 보다가 나무 나이테도 봐야하는 직무
PM은, 특히 큰 회사의 플랫폼 기획으로 있다면, bird eye's view로 다른 서비스와의 연계도 생각하면서, 동시에 안내창 팝업에 영단어를 대문자로 적을지 소문자로 적을지까지 생각하는 디테일까지 챙겨야한다. 숲은 당연히 봐야하고, 필요하면 나무 나이테까지 꼼꼼히 따져야하는 직무. 이건 추후에 기회가 되면 예시로 더 자세히 설명하겠다.
아직 갈길이 먼 만큼, 이 포스트를 시작으로 PM 업무에 대한 재밌는 이야기를 이어나가려고 한다.
근데 브런치에서도 이런거 하나요? 라이킷 구독 눌러주세요! 공유도 해주세요! :)
(+커버는 Gazuo Ishiguro의 '클라라의 태양'이라는 책입니다. AI 친구가 있다면 어떨까? 마냥 좋기만할까? 라는 호기심어린 궁금증으로 시작했지만 반전이....)
