PM으로 일하다 보면 개발자, 디자이너 분들을 설득하거나 목표를 공유하기 위해 '데이터'를 자주 들여다보고 언급하는 경우가 많습니다. 하지만 메이커들이 데이터에 대한 이해도가 너무 낮거나 관심이 없으면 설득이나 논의가 쉽지 않겠죠.
- 이 글은 메이커와 원팀으로 일하고 싶은 한 PM이 어떻게 메이커들을 '데이터'로 하나되게 했는지의 과정을 담았습니다.
메이커와 원팀으로 일하고 싶은 PM, 데이터 드리븐 의사결정을 팀 전체로 확장하고 싶은 PM,
그리고 개발자·디자이너와 처음 함께 일하게 된 PM이라면 모두 흥미롭게 읽으실 수 있을 거예요.
"사실 궁금하긴 했어요."
때는 2025년 5월, 스쿼드가 새롭게 개편된 시기였습니다. 팀워크를 다지고 서로를 알아갈 시간이 있으면 좋겠다는 가벼운 마음으로, 주제는 미정인 채 스터디를 제안했는데요. 반응이 영 뜨뜻미지근했습니다. 돌이켜보면 이유가 있었습니다. 팀원분들은 큰 프로젝트를 막 마무리한 뒤 다소 지쳐 있었고, 목적과 주제가 불명확한 스터디에 적극적으로 반응하기 어려운 상황이었던 거죠.
"모여야 해서 모이는" 그런 스터디는 저도 싫었습니다. 그렇게 첫 스터디 시간에 팀원들에게 "스터디에서 어떤 걸 얻고 싶으세요?"라고 물었을 때 공통적으로 나온 답이 "데이터", "수치", "지표"였습니다.
메이커분들도 사실 그동안 해왔던 작업들의 결과에 관심은 있는데 어떻게 접근해야 할지, 어떤 지표를 볼 수 있는지조차 막막한 상태셨던 거죠. 그때 저는 이런 그림을 그렸습니다.
"앞으로는 개발자, 디자이너도 나보다 먼저 지표를 궁금해하고, 내 기획안 속 데이터와 논리에 대해 날카로운 피드백을 던지는 팀이 되면 좋겠다!"
또, 메이커분들이 자신이 만든 것이 얼마나 가치 있는지, 비즈니스에 어떤 임팩트를 주는지 직접, 손쉽게 알아낼 수 있으면 좋겠다고 생각했습니다. 그런 비장한 꿈을 갖고 스터디를 준비하기 시작했습니다.
실습으로 흥미를, 최종 목표로 동기부여를!
스터디 방향을 잡고 구체화하면서 팀원분들의 스터디 만족도도 높이기 위해 저는 7주 분량의 커리큘럼을 미리 짰습니다. 커리큘럼은 '오늘은 이거 배웠다!'고 설명할 수 있는 한 줄이 있어야 하고, 메이커들의 흥미가 떨어져서는 안된다는 전제로 짜려고 노력했어요.
주차 | 주제 | 구성 |
1주차 (5/15) | 데이터의 종류와 이해 | 데이터의 종류와 각각의 차이점 / 데이터 분석의 5R 원칙
함께) 알고 싶은 데이터 늘어놓기 |
2주차 (5/22) | 데이터 리터러시(문해력) | 데이터 문해력이 중요한 이유 / 5R 원칙 적용해보기
실습 1) 실생활 속 문제를 프레임워크로 |
3주차 (5/29) | 우리 회사가 데이터를 보는 방법 | 스프레드시트, 앰플리튜드, 리대시 등
실습 2) 앰플리튜드 만져보기 |
4주차 (6/5) | 북극성 지표 | 북극성 지표에 대하여
실습 3) 타사 리서치, 예상해보기 |
5주차 (6/12) | 데이터로 결론 만들기 | 결과와 평가 구분하기
실습 4) 앙케이트 결과 분석해보기 |
6주차 (6/19) | 심층인터뷰 방법론 | 심층 인터뷰 잘하는 법
실습 5) 심층 인터뷰 질문지 함께 완성하기 |
7주차 (6/26) | 최종 실습 | 나만의 대시보드 만들어보기 |
커리큘럼을 구체화하면서 가장 신경 쓴 건 깊이보다 허들을 낮추는 것이었습니다.
사실 개발자나 디자이너분들은 PM 수준만큼 데이터를 깊이 파야 할 이유가 없죠. (물론 저도 엄청나게 높은 수준을 갖춘 건 아니지만요.) 데이터 자체에 흥미와 관심을 갖게 하고, 보는 방법에 대한 진입 장벽을 낮추는 것이 먼저라고 생각했기에 매주 '실습' 시간을 넣었고 아이스 브레이킹으로 퀴즈를 준비하기도 했습니다.
그리고 스터디의 최종 결과물도 처음부터 명확히 정해놓고 시작했죠. 막연하게 이론적인 내용을 배우는 것이 아니라 "이걸 만드는 게 목표다"라는 공동의 방향이 있으니 참여 동기도 훨씬 높일 수 있을 것 같았습니다.
1. 아이스브레이킹 퀴즈
데이터가 쌓이고 있지만, 들여다보지 못했던 지면을 퀴즈로 만들어 관심을 갖게 했고, 그 지표는 어떻게 보는지 사용해야 할 툴과 방법, 적절한 차트 타입을 알려드리기도 했어요.
2. 주관적 해석/객관적 데이터 구분해보기
제가 실제로 어느 프로젝트에 대한 데이터를 2~3page로 상세 분석한 노션을 인쇄해 나눠드리고, 저의 분석 중 어떤 것이 객관적인지/주관적 해석은 없는지 형광펜으로 구분해보시도록 하기도 했어요.
스터디, 그 후가 더 중요해요.
7주간의 스터디는 매주 성실하게 진행됐고, 팀원들은 "강의 만족도 5점 만점이다"라는 장난 섞인 칭찬도 더해주셨어요. 저라는 PM에 대한 신뢰도 어느 정도 생긴 것 같다고 느끼기도 했죠.
하지만 더 중요한 건 실제로 일하는 모습에서 온 변화였습니다. 스터디가 끝난 이후에도 저는 지속적으로 팀원들이 '데이터'에 대해 관심을 갖고 더 알고 싶어하길 바랐고, 손 닿는 곳에 항상 '데이터'가 있는 환경을 만들어야겠다 생각했습니다.
그 일환으로 저는 프로젝트 배포 후 1~2주 차가 지났거나 잠시 잊혀질 때쯤, 종종 [흥미로운 데이터 공유] (일명 흥.데.공) 라는 제목으로 슬랙 스레드를 주기적으로 올렸습니다.
점차 메이커분들이 이 스레드에 반응하는 태도도, 깊이도 달라졌습니다.
그런 변화를 보며, 저도 이러한 데이터 공유가 일회성 이벤트가 아니라 주기적으로 계속되어야 한다고 느꼈고, 이제는 데이터 공유를 저의 "주요 업무" 중 하나로 삼고 꾸준히 챙기려고 노력하고 있습니다.
데이터라는 공통의 언어이자 자신감
여러 시간과 노력들을 거듭하며 가장 크게 달라진 점은, 스쿼드 팀원들이 먼저 지표를 물어보기 시작했다는 겁니다. "이거 결과 지표가 궁금해요." "혹시 이 수치는 왜 보는 건가요?" 이제 디자이너도, 개발자도 제가 미처 생각하지 못했던 시각을 던져주실 때도 있고요. 그러면 저도 신이 나서 더 열심히 살펴보고 공유하게 됩니다.
스터디를 준비하면서 점점 교과서적인 내용에 빠지기도 하고, '자료'를 만들어야 한다는 강박에 이론적인 내용이 길어지기도 했는데요. 그럴 때마다 저는
스터디의 '진짜 목적'을 다시 떠올리며 메이커들을 움직이고 싶다는 마음을 다잡았습니다. - 우리 스터디의 목적은 데이터를 정복하는 것이 아니라 데이터와 친해지는 것이었습니다.
- PM으로서 저의 목표는 팀원들이 이 스터디를 통해 데이터를 먼저 묻고, 데이터 해석을 함께 하게 되는 것이었고요.
- 저도 데이터 전문가가 아니고, 그저 같이 데이터를 잘 보고 싶은 사람이니까요.
- 이런 분위기가 모여 저희 스쿼드는 단순히 '만들어 주는 사람'이 아니라, '만들어 가는 주인'이 되어간다고 느끼고 있어요. '오너십'이라고도 하지요.
- 내가 만든 것이 어떻게 작동하고 있는지, 어떤 가치를 만들고 있는지를 지속적으로 느끼고 직접 찾아볼 수 있는 것. 그게 곧 내 일의 가치를 직접 체감할 수 있는 방법이기에, '데이터'에 대한 기초 지식을 갖추고 지속적으로 관심을 갖게 한 스터디는 하기를 참 잘했다는 생각이 들기도 합니다.
이제 저희 스쿼드는 데이터라는 공통의 언어로 소통하는 것을 넘어, 메이커 개개인이 '우리 제품의 KPI를 달성하기 위해 어떤 일을 할 수 있을까, 어떻게 기여할 수 있을까'를 고민하기 시작했습니다.
배움에 열려 있고, 학습의 곡선도 가파른 우리 스쿼드 팀원들이 또 얼마나 큰 변화와 성장을 만들어낼지 기대가 되는데요, 다음에는 그 고민이 어떤 결과를 만들어낼지 이야기할 수 있으면 좋겠습니다☺️
Share article