PM과 함께 자랄 준비 됐나요?
회사에 신입 분들이 들어왔다.
간단한 인사와 나의 직업 PM이라고 말하면,
이번에도 어김없이 같은 질문을 들었다.
저 PM이랑 일을 처음 해봐요, PM은 어떤 일을 하는 사람인가요?
PM과 어떻게 협업하나요?
저도 아이디어를 낼 수 있나요?
내가 오늘 들은 질문과 내가 지금까지 들었던 질문을 바탕으로
조금 더 깊게 PM이 어떻게 일하는지 어떻게 협업을 하는지를 작성해보려고 한다.
다시 한번 PM은 어떤 일을 하나요?
PM이란 고객의 문제를 발견하여 제품으로 끝까지 해결하는 사람이다.
고객의 문제를 발견하는 방법은 여러 가지이다.
(고객의 VoC를 보거나, 매트릭을 보거나, 고객의 제품 내 행동을 분석하거나 등등)
고객의 문제를 발견하고 그 문제를 제품으로 풀어내어 개선되거나 해결할 때까지 수단을 가리지 않고 그 일을 해결하는 사람이다.
다른 팀과 대화를 하다가 "이 기능 좀 만들어주세요"라고 들을 때가 종종 있는데
의식적으로 지금 문제가 뭐예요??라고 물으며 기능 자체보다는 문제만 들고 오려고 노력하는 편이다.
왜냐면 만드는 사람(디자이너/개발자)이 해당 문제를 깊게 이해하여 답을 같이 찾아야 공유된 이해를 유지할 수 있고, 일이 정해져 있어 시키는 일을 하는 느낌이 아닌, 문제를 같이 해결하며 제품을 만들기 때문에 제품의 스코프 관리도 더 잘되는 것 같았다.
조금 옆으로 샜는데,
그래서 PM 일의 첫 단계는 고객이 갖고 있는 문제를 정의하기이다.
문제를 정의했으면, 회의를 소집해 스쿼드 내 팀원들을 부르거나, 이 이슈를 같이 해결할 디자이너와 개발자에게 문제를 공유한다.
여기서 내가 중요하게 여기는 부분은 5명이 넘지 않는 사람이 모이도록 하고, 모두 같은 것을 생각하거나 볼 수 있도록 준비한다.(여기서 준비는 PPT나 거창한 기획서가 아니라 목표 숫자, 글로 된 사용자 스토리라도 충분하다)
서로 같은 문제 상황 인식과 문제의 공감이 충분히 됐다면 서로의 아이디어를 말로 주고받고 하나의 흐름으로 결정을 하거나 여기서는 pm의 재량으로 나온 아이디어 중 하나를 찍어 팀원들을 설득해도 괜찮다. 여기서 중요한 부분은 같이 만드는 사람들의 각자의 의견에 대한 존중과 생각을 하나로 통일시키는 게 중요하다.
회의에 참석한 모두가 1개의 설루션으로 설득됐거나 의견이 모였다면, 회의를 끝내도 된다.
회의가 끝난 후 PM은 자리로 돌아가 결정된 의견으로 PRD(제품 요구사항 문서)를 작성한다.
PRD(Product Requirements Document)에 꼭 들어가야 하는 항목은
해결하려는 문제
일을 처리하기 위한 가정(가설)
성공 지표
사용자 이야기(유저스토리)
디자인
질문과 결정사항
으로 시작하여 만드는 기능에 따라 히스토리를 붙이기도 하고 개발자가 적는 문서를 추가하기도 한다.
PRD가 완성되면 다시 한번 팀원들을 모아 PRD를 같이 보며 회의 내용이 전부 들어가 있는지, 개발이 오래 걸릴 거 같은 부분(우리가 2주 내에 이걸 만들 수 있을까요?)을 다시 한번 확인하여 디자이너에게 디자인을 요청한다.
여기까지 이루어졌으면 지금부터 PM의 일은 피드백, 결정, 정리하기에 가깝다. 문제를 기준으로 모든 게 커뮤니케이션됐고 결정을 같이 했기 때문에 한번 정한 흐름이 손바닥 뒤집듯 바뀌지 않는다.
이 부분에서 내가 중요하게 여기는 부분은 제품을 잘 만드는 것도 중요하지만 일단 우리가 생각한 부분을 마무리하는 것에 집중하기 위해 2주 내에 만들 수 있는지를 기준으로 결정을 한다.
개발 단계에서는 정말 개발자와 디자이너와 딱 붙어 결정이 필요한 부분과 만들면서 나오는 질문, 결정사항을 바로바로 해결하고 속도감 있게 일하는 편이다.
PRD대로 제품이 만들어지면 이때부터는 다시 PM의 시간이다. 생각한 대로 구현이 됐는지 빠진 게 없는지, QA를 하며 다시 유저스토리를 들여다본다. 그래서 피드백, 테스트의 연속이다.
어느 정도 다 만들면 이해관계자들을 위한 문서를 만들고 이것 역시 직접 만나 같은 문서를 보며 설명하는 걸 선호하는 편이다. 이렇게 하면 질문을 바로 받을 수 있고 만든 제품을 직접 보여주며 설명할 수 있어서 이해관계자들의 이해도가 훨씬 높았다.
공유가 끝나면 릴리즈 준비가 끝나고, 측정해야 할 매트릭 부분을 다시 한번 확인한다.
정말 많은 릴리즈를 했는데 릴리즈는 할 때마다 떨린다. 긴장감을 낮추며 릴리즈 노트를 쓰고 같이 고생한 동료들에게 감사 인사도 잊지 않는다.
그리고 꼭 릴리스하면 테스트할 때는 보이지 않았던 오류를 더 빨리 보기도 한다. 그래서 릴리즈 후 마지막으로 라이브 테스트를 하고 모니터링을 시작한다.
성공 지표를 심심할 때마다 들여다본다. 내가 지금 만드는 제품은 사용자가 그렇게 많지 않기 때문에 최소 2주 정도를 지켜보기도 하고 길게는 2달까지도(실험을 길게 하는 거지 이것만 들여다보는 게 아니다) 지표를 확인하며 문제가 없는지, 있는지를 지켜본다.
문제가 있으면 롤백하여 다시 문제를 확인하고 UX를 수정한다. 지표가 개선됐다면 모니터링을 중단하고 다음 문제를 해결하기 위해 떠난다.
사용자의 문제를 해결하기 위해 정말 많은 결정이 들어가 있다.
지표가 조금 개선해도 손뼉 치며 좋아하기도 하고,
좋게 해 주려다 사용자를 더 혼란스럽게 해서 성공 지표가 절반으로 줄어들기도 한다.
공들여 개발했지만 아무 지표에 변화가 없기도 하고,
우리가 같이 한 선택이 그럴 줄 알았다 하고 비난받기도 하고 정말 감사해요 라는 칭찬을 듣기도 한다.
이 모든 일을 같이 일하는 동료들과 함께 경험하며
오늘도 PM으로써 함께 자라는 중이다.
