프로덕트 탄생과 성장, PM의 데이터 기반 의사결정 노하우

프로덕트 탄생과 성장, PM의 데이터 기반 의사결정 노하우

지난 11월, 오픈서베이가 ‘[Open Talk] 프로덕트를 성장시키는 데이터 기반 의사결정의 모든 것’ 웨비나를 열었습니다. 오픈서베이 내외부의 업무 경험과 커리어에 대한 이야기를 나누고자 진행하는 [Open Talk], 그 중 첫 번째로 진행한 해당 웨비나는 프로덕트 매니저(PM)로 15년 이상 경험을 쌓아온 오픈서베이 이해민 CPO(이하 해민)가 연사로 참여해 PM의 데이터 활용법과 그 사례를 이야기하는 시간이었어요. PM, PO, UX 디자이너 등 관심 갖고 참석한 많은 분들께 해민의 다채로운 실무 경험을 나눴답니다.

아쉽게도 웨비나에 참석하지 못한 분들을 위해, 실무자들의 고민에 해민이 직접 답을 드렸던 시간인 ‘Ask Haimin Anything’ 세션 내용을 중심으로 콘텐츠를 준비했어요. 이번 콘텐츠를 통해 시니어 PM 해민의 경험과 노하우를 만나보시길 바랍니다!

※ 이번 콘텐츠는 2022년 11월 3일 진행한 ‘[Open Talk] 프로덕트를 성장시키는 데이터 기반 의사결정의 모든 것’ 등록 시, 등록자의 사전 질문과 참석자의 라이브 질문에 대한 답변 일부를 정리해 작성하였습니다.

데이터 기반의 의사결정과 PM 업무

Q: 실무에서 데이터 기반으로 의사결정을 내릴 때 데이터를 활용하는 실용적인 꿀팁이 있다면 어떤 것이 있을까요?

실무에서 데이터를 기반으로 어떠한 의사결정을 하기 이전부터 적용할 수 있는 꿀팁을 말씀드리고 싶어요.

데이터 기반의 의사결정을 내리기 위해서는 우선 데이터에 기반한 커뮤니케이션이 기본이 되어야 한다고 생각해요. 그래서 제가 말씀드리는 팁은 업무 커뮤니케이션 상황에서 최대한 데이터를 많이 이용하는 겁니다.

예를 들어 설명해 드릴게요. 오픈서베이는 기획 단계에서 PM이 PRD(Product Requirements Document)를 씁니다. 이 중에 ‘이번 PRD에서 커버하지 않은 영역을 명확히 써주세요. 커버하지 않은 영역에 대해선 이유와 향후 플랜을 작성해주세요.’라는 항목이 있어요. 어떤 PM이 이 항목에 ‘A 기능 개선은 이번에 진행하지 않음. 이 기능이 사업부에 미치는 영향이 크지 않기 때문’이라 작성했다고 가정해볼게요. ‘크지 않다’는 건 영향이 없진 않지만 크지도 않다는 의미고 이대로 무리 없이 일을 진행할 수도 있습니다. 하지만 데이터를 기반으로 커뮤니케이션한다면 어떨까요? ‘이 기능의 변화는 10개 팀 중 하나의 팀에 영향을 줌. 해당 팀은 한 달에 한 번 정도 사용하는 기능임. 그러므로 우선순위에 따라 이번 개선 영역에서 제외함’이라고 쓴다면 PRD의 근거가 더 탄탄해집니다.

이렇게 커뮤니케이션부터 데이터를 활용하다 보면 자연스럽게 데이터를 기반으로 의사결정할 수 있게 됩니다. 그래서 실무에서 데이터를 활용하는 꿀팁이라고 한다면, 좀 더 명확한 커뮤니케이션을 위해 데이터를 계속 활용해서 말하고 글 쓰는 연습을 하시라고 말씀드리고 싶습니다. 데이터를 활용하다 보면 필요하지만 없는 데이터가 보이고, 이걸 찾고 모아 보완하면서 더 촘촘하게 데이터를 기반으로 의사결정할 수 있게 됩니다.

Q. 의사결정을 할 때 어떤 데이터를 가장 중요하게 보시나요? 데이터뿐만 아니라 의사결정에 도움이 되는 기준이 무엇이 있을까요?

모든 의사결정에서 ‘우리 팀이 근본적으로 추구하는 지표가 무엇인지’를 살핍니다. 때에 따라서는 그것이 일정일 수도 있겠죠.

데이터는 일정 수준 쌓여야 인사이트가 됩니다. 데이터가 충분히 없으면 PM들의 인사이트에 의존하는 때도 종종 있습니다. 물론 이 또한 PM에게 내재화된 ‘데이터’가 아닐까 싶습니다.

Q: PM이 가장 중요하게 관리해야 하는 지표는 무엇이라고 생각하시나요?

프로덕트 초기에 핵심 가치가 반영된 북극성 지표(North Star Metric)를 정하고 그에 따라 세부 지표를 수립하는 것이 굉장히 중요한 일입니다. 프로덕트에 대해 의사결정을 내릴 때 그 지표가 가이드 역할을 해주거든요.

회사마다 프로덕트마다 중요하게 관리해야 하는 지표는 다 다를 거예요. 중요하게 관리할 지표를 알기 위해서는 내 프로덕트의 성공을 정의하는 지표는 무엇인지를 먼저 파악해야 하죠. 나의 프로덕트는 무엇이며 이 분야에서 중요한 지표는 무엇인지를 찾는 것이 중요합니다. 예를 들면 검색 PM이라면 DAU(일일 이용자 수), 문의/질문 수일 수 있고, 광고 PM이라면 광고 수익이 될 수도 있죠. 각각 특성에 맞게 지표를 잘 찾아야 합니다.

제가 팁을 하나 드린다면 세 가지 특성을 고민해 지표를 설정하는 겁니다. 첫 번째 measurable 측정 가능해야 하고, 두 번째 trackable 추적 가능해야 해요. 측정 가능할 수 있지만 매번 기준이 달라진다면 지표의 방향을 파악할 수 없겠죠. 마지막으로 movable 이 내가 이 프로젝트를 함으로써 움직일 수 있는 지표여야 합니다. 예를 들어 전 세계 인류의 행복을 지표로 설정하면 어떨까요? 하나의 프로젝트로 이 지표를 움직일 수 있다면 물론 좋겠지만 사실상 어렵죠. 이건 지표를 잘 설정했다고 보기 어려워요. 그래서 내 프로젝트의 범위를 정확하게 인지해 지표의 범위를 좁히고 명확하게 하는 것이 필요해요.

정리하자면, 내 프로덕트의 성공을 정의할 수 있는 measurable, trackable, movable 지표를 찾아서 관리하시는 게 중요하다고 생각합니다.

Q: 새로운 서비스를 기획할 때, 증명할 가치가 있는 좋은 가설을 세우는 단계가 가장 어렵습니다. 가설을 세울 때 주의해야 할 점이나 도출하는 방식에 대해 조언 부탁드려요.

완전히 새로운 서비스를 만드는 건 쉽지 않은 일이에요. PM의 상상력이 정말 많이 필요하기도 하고, 또 PM이 마련한 그 판에서 관련 담당자들의 집단 지성이 상당히 많이 필요한 일입니다.

우선, 가설을 세우기 앞서서 CUJ(Critical User Journey)라고 말하는 핵심 고객의 여정을 그려보는 것이 필요하다고 생각합니다. 저는 기획 초기에 사용자의 입장이 되어 끊임없이 상상해보면서 새로운 서비스에 대한 CUJ를 써봐요. CUJ는 최종적으로 나의 프로덕트가 사용자 니즈를 다 충족시키는가에 대한 질문의 답을 찾는 데 큰 도움이 되고, 또 팀이 사용자에게 계속 집중할 수 있도록 만들어 줍니다.

CUJ를 정리할 때 나의 상상력으론 부족하다면 두 가지 방법이 있어요. 관련 담당자를 모두 불러 모아서 ‘A를 기획하려는데 이 프로덕트를 사용한다고 생각하고 CUJ를 써달라’고 도움을 요청해보세요. 또 하나의 방법은 리서치를 하는거에요. 패널에게 해당 서비스나 기능을 가장 잘 나타낼 수 있는 그림이나 설명 자료를 주고 물어보는 거죠. 사용자로서 이 서비스로 무엇을 하고 싶은지, 무엇을 하고 싶은지 간단하고 빠르게 물어보고 좋은 답을 얻을 수 있습니다.

이렇게 CUJ를 리스트업하고, 이 리스트가 마련되면 우선순위에 따라 하나의 CUJ에 도달하는 태스크 리스트를 만들고, 그 태스크를 수행할 수 있는 기능 리스트를 만들어요. 이렇게 범위를 좁혀나가면서 진행하면 사용자 여정에 맞춰진 서비스를 기획해갈 수 있겠죠. 가설을 세우는 건 이 CUJ를 확인하고 검증하는 과정이라고 보면 비교적 쉽게 진행할 수 있습니다.

Q: 프로덕트를 만들고 운영하는 데 있어서 최소한의 문서가 필요하다면 어떤 것이 있을까요? 현재 내부의 체계를 잡아가는 과정으로 품질 관리나 히스토리 관리에 도움이 될 문서는 무엇이 있는지 궁금합니다.

품질 관리나 히스토리 관리 등을 위한 문서는 아마 도메인마다 조금씩 다를 거예요. 참고하실 수 있도록 일반적인 소프트웨어 회사에서 필요로 할 문서 종류를 말씀드릴게요. 제품 기획 단계에서 작성하는 PRD(Product Requirements Document)와 그걸 토대로 엔지니어링 팀에서 작성하는 문서 (SRS: Software Requirements Specifications 또는 DD: Design Document)로 크게 두 축을 이룹니다. PRD는 각 서비스 레벨의 기획서, SRS나 DD는 PRD를 개발 측면에서 실행할 수 있게 하는 문서가 되죠. 그리고 그에 앞서 비저닝 문서를 정리한다면 팀 전원이 한 곳을 바라볼 수 있는 효과가 있습니다. 비저닝 문서는 로드맵과 함께 우리가 올라가려는 봉우리를 본 느낌을 줄 수 있어야 하고요. 이 정도가 기본적으로 필요한 문서일 것 같고, 더해서 프로젝트별로 이슈를 트래킹할 수 있는 문서나 도구도 있어야 한다고 생각합니다.

초기 프로세스를 세팅할 때 우리 회사에서 꼭 필요한 문서의 종류가 무엇인지, 가장 이상적인 상태를 상상해보시면서 한번 적어보시면 좋겠습니다. 예를 들어 ‘기획 문서를 공유 드라이브에 저장하고 언제라도 꺼내 볼 수 있도록 한다’와 같이 프로세스적인 결정도 내려보면 좋겠어요.

Q: UX리서치를 할 때 PM이 직접 수행하면 좋은 것과 전문 리서처가 수행하면 좋은 영역이 있을까요?

과거 구글에서 UXR(UX Research) 팀과 많은 시간 같이 일했는데, 그때의 경험을 떠올려 보면 각 포지션이 잘 할 수 있는 영역이 따로 있는 것 같아요.

프로덕트를 가장 잘 아는 건 담당 PM이기 때문에, PM이 리서치 전문가가 아니라고 해도 직접 수행하면 좋을 영역이 있습니다. 비교적 프로덕트에 집중된 리서치라면 PM이 리드하고 리서처가 서포트하는 형태가 많아요. 이때는 보통 PM이 먼저 해당 프로덕트에 대해 리서처에게 설명해드립니다. 또 데이터를 통해 검증하고 싶은 가설을 이야기하고, 리서처는 이를 더 이해하기 위해 질문하며 리서치를 기획합니다. 경험이 많은 PM은 가설도 쉽게 세우고 정량 조사를 진행할 일인지, 일대일 정성 조사를 해야 할 상황인지 판단을 내릴 수 있겠죠. 만약 아직 경험이 부족하다면 리서처가 그 가설을 검증하고 더 효과적인 리서치가 되도록 가장 좋은 리서치 방법론을 제안해주기도 합니다.

반면 리서처가 리드하는 케이스도 있어요. 예를 들면 스마트 워치 마켓 트렌드, 위치 공유에 대한 Z세대 인식과 같이 다소 광범위한 주제에 대한 리서치입니다. 이렇게 전문 리서처는 프로덕트에만 집중하는 PM에게 시야를 넓혀주는 리서치를 많이 하시고 PM에게 인사이트를 주는 역할을 하시는 것 같아요.

PM 커리어

Q: PM 채용 시 가장 중요하게 보는 요소는 무엇인가요? 다시 말해 어떤 PM이 좋은 PM이라고 말할 수 있을까요?

‘사용자에게 훌륭한 프로덕트를 제공할 수 있는 역량이 있는가?’ 가장 중요한 포인트라고 생각합니다. 어떤 것을 ‘훌륭하다’고 정의할 수 있을지는 회사마다 당연히 다르겠죠. 하드웨어 만드는 회사와 소프트웨어 만드는 회사는 각각의 기준을 가지고 있을테니까요.

제 과거 경험을 말씀드리면 채용 인터뷰에선 다음의 역량을 중심으로 확인했습니다. 우선 프로덕트 비저닝이 가능한지, 그 비전을 이루기 위한 전략을 세울 수 있는지입니다. PM은 의사결정을 해야 하는 상황이 정말 많아요. 그럴 때 적절한 결정을 내려야 하기 때문에 분석적인 사고가 가능한지도 중요하죠. 또 커뮤니케이션 역량도 중요합니다. 비전을 수립했다면 이 방향으로 가기 위해 디자이너, 개발자 등 여러 포지션과 협의하고 설득하는 것도 PM의 역할이기 때문이에요. 회사에 따라 테크니컬 백그라운드가 있는지가 중요한 요소로 작용하기도 합니다. 이런 역량을 가진 분이라면 좋은 PM이라고 말할 수 있을 것 같아요.

더불어 채용 인터뷰에선 교과서적인 대답은 별로 중요하지 않은 것 같아요. 경험에서 우러나오는 답변이 중요합니다. 시험은 교과서를 보면 알 수 있는 정답이 있지만, PM의 일은 매번 정해진 일들만 생기는 게 아니거든요. 상상도 못 할 일의 연속일 때가 정말 많아요. 그래서 앞서 말한 역량과 함께 상상력의 한계를 보기 위해 경험을 중요하게 봅니다.

그래서 좋은 PM이 되려면 ‘내 경험이 나를 교육하고 성장시킨다’라고 생각하시고 매번 도전적인 상황에 나를 던지는 연습이 필요하다고 생각합니다

Q. 업무 경력은 없는데 앞으로 PM으로 일하고 싶습니다. 이럴 경우 어떻게 PM으로 커리어를 시작할 수 있나요?

저는 PM 경력이 없다면 PM으로 바로 지원하는 것을 추천하지는 않습니다. 왜냐하면 업무의 다양한 경험이 쌓여서 결국 PM의 역량이 되기 때문이에요. 그래서 다양한 방면에서 업무 경험을 더 많이 쌓으시길 추천해 드립니다.

더불어서 향후 PM으로 성장할 수 있도록 자신을 훈련할 수는 있습니다. PM 업무에서는 분석 역량, 기술적 지식, 커뮤니케이션 스킬, 리더십, 비저닝 등의 역량이 기본적으로 필요합니다. 이런 역량을 염두에 두시고 다양한 경험을 쌓아간다면 훌륭한 PM으로 성장하는 데 분명 도움이 될 거고, ‘다양한 경험’은 본인이 가장 자신 있는 분야에서 리더십을 쌓으면서 혹은 창업을 통해 쌓아갈 수 있습니다.

Q: 시니어 PM이 되시고서는 무엇으로 동기를 부여받으며 성장해 오셨는지 궁금합니다.

프로덕트 매니저라는 역할로 성장해오면서 저는 일에서 제 나름의 기준을 갖게 되었어요. 그 기준에 따라 일에 대한 동기도 생기고 마음도 다잡았습니다. 생각보다 간단한데요. 첫 번째는 내가 재미를 느낄 수 있는 일인가입니다. 그리고 두 번째는 충분히 도전적인가, 그래야 제가 성장할 수 있으니까요. 마지막 세 번째는 일의 영향력이 큰가예요. 세 가지를 생각해보고 이 기준에 해당하는 일이라면 지금도 동기를 얻으며 일하는 것 같습니다.

Q. 경험하신 기업 문화 중, 스스로를 가장 빠르게 성장시켜 주었던 문화는 어떤 것인가요? 새로운 영역에서 일을 시도해야 할 때 어떤 방법으로 문제를 풀어가셨나요?

가장 빠르게 성장시켜 주었던 문화는 제가 실패하거나 성공할 수 있도록 다양한 기회를 준 문화예요. 즉, 제가 직접 기획해서 끌고 간 결과에 대해 받아들이고 그걸 딛고 더 나은 방법을 찾을 수 있도록 기다려준 회사와 그 문화에서 마음껏 성장할 수 있었던 것 같습니다.

저는 이제껏 PM으로 일하며 레퍼런스 없이 첫발을 내딛는 경우가 굉장히 많았어요. 많은 경험을 해본 결과 잘 모르는 영역일수록 사용자 조사를 많이, 아주 많이 하는 것이 중요하다는 걸 알게 되었고, 그렇게 문제를 풀어왔습니다. 문제의 답은 사용자 안에서 찾아야 한다고 생각합니다.

시니어 PM 해민이 함께 하는 오픈서베이가 궁금하다면
오픈서베이 팀을 만나보세요