병아리 PM의 성장기

제가 PM을 준비할때 가장 궁금하고 막연했던 부분이기도 했던 내용이어서,오늘도 도움이 되길 바라며 공유드립니다. ✔️ 어디까지 분석할 수 있어야 할까? (제가 일한 회사에는 DA가 없었다는 점을 참고해주세요)DA가 없는 회사에서 데이터를 설계하고 분석하는 과정을 수행하며 터득한 3가지 노하우를 공유드립니다. 첫째는, 회사의 상위 KPI에 영향을 주는 다양한 지표가 무엇인지 파악할 수 있어야 합니다.이를 위해서는 지표를 쪼개서 생각할 수 있어야합니다.(ex. 구독제 매출 = 신규 구매 전환율 + 기존 유저 갱신율)이 사고를 탑재해야 비즈니스 임팩트를 고려한 프로젝트를 진행할 수 있습니다. 둘째는, 정량+ 정성 데이터를 결합해서 문제 원인을 집요하게 찾을 수 있야 합니다.정량 데이터만 활용하면 답이 안 나오..

PM 하면 어떤 모습이 떠오르시나요?카리스마 있게 팀원들을 앞장서서 이끌고,일정을 조율하고, 문제를 해결하는 모습이 떠오르지 않나요? 저는 외향성과 내향성 그 사이 어딘가의 성격을 가지고 있어요.그래서 PM으로 직무를 전환했을 때팀원들을 휘어잡는(?) 카리스마가 있어야 한다고 생각해서 약간의 부담감이 있었어요. 회의에서 한 마디라도 더해야 하지 않을까?혹은 팀원의 고충을 미리 알아주는 이런 것들이 필요하지 않을까? 하는 고민이요. 하지만 일을 하다보니 성향보다 더 중요한 건 정확한 논리를 기반으로 명확하게 소통하는 것이었어요.(팀원들 또한 의미없는 논의가 이어지면서 회의가 마냥 길어지는 것보다는짧고 명확할수록 좋아하구요 ㅎㅎ) 제가 실제로 일하면서 팀원에게 신뢰를 얻는데도움이 되었던 몇 가지 커뮤니케이션..

여러분은 왜 PM이 되고 싶으신가요?직접 경험해보기 전까지는 알기 어려운 PM의 장점과 단점을 솔직하게 풀어 볼게요.이번 인사이트를 통해 직무 이해도를 높이고 “나는 왜 PM이 되고 싶은지” 한 번 더 생각해 보는 계기가 되길 바랄게요. ✔️장점: 나의 결정이 팀과 제품을 움직인다제가 생각하는 PM의 가장 큰 장점이자 PM을 하고 싶은 이유는 제품의 가장 앞에서 방향을 결정하고 주도할 수 있다는 점입니다. 내가 세운 가설을 팀원들에게 설득하고,그 가설을 검증하기 위해 함께 몰입해서 결과를 만들어 간다는 점이 큰 보람으로 느껴졌어요. 저의 경우 학부 시절부터 팀플, 동아리에서 사람들을 동기부여하고,주도적으로 리딩해 왔기에 그런 성향이 PM과 잘 맞는다고 느꼈습니다. 또한, 우리가 만든 기능을 실제로 시장..

취업을 준비하는 과정에서 제가 가장 궁금하고 관심있었던'데이터 분석, 어디까지 할 수 있는지'에 대한 내용을 공유드립니다. 어디까지 분석할 수 있어야 할까? 첫째는, 회사의 상위 KPI에 영향을 주는 다양한 지표가 무엇인지 파악할 수 있어야 합니다.이를 위해서는 지표를 쪼개서 생각할 수 있어야합니다.(ex. 구독제 매출 = 신규 구매 전환율 + 기존 유저 갱신율)이 사고를 탑재해야 비즈니스 임팩트를 고려한 프로젝트를 진행할 수 있습니다. 둘째는, 정량+ 정성 데이터를 결합해서 문제 원인을 집요하게 찾을 수 있어야 합니다.정량 데이터만 활용하면 답이 안 나오는 경우가 있습니다.이 때는 해당 시기 혹은 세그먼트의 voc를 분석하거나, 데이터가 부족한 경우 직접 사용자 인터뷰를 진행하는 방법이 있습니다...

PM 필독서 중 하나, “오늘도 개발자가 안 된다고 말했다” 읽어보셨나요? [독서 기록📚] 오늘도 개발자가 안 된다고 말했다 (1) 가깝고도 먼 개발자1. 어딘가 이상한 비전공자의 협업 기획자 김 군의 협업 ✔️기획서 목적협업에서는 기획의 의도를 정확히 전달하는 것이 가장 중요하고, 기획서는 그 의도를 정리한 커뮤니케이션 문서라는 것alwayshappydaysforever.tistory.com 만약 개발자가 안 된다고 말하면, 여러분은 어떻게 소통하실 건가요? 눈 앞이 캄캄해지신다면 오늘 제가 공유할 인사이트가 도움이 될 거예요. 오늘 글에서는 그동안의 시행착오를 바탕으로 개발자와의 원활한 소통을 위해 꼭 지키고 있는 원칙들을 공유하려 해요. 1️⃣ 기술은 개발자에게 맡기고, 왜 이 문제를 풀어야 하..

막 PM이 되었을 때의 일입니다.기획서를 무사히 팀원들에게 전달하고, 디자인 - 개발 - 검수 까지 순차적으로 잘 진행되었다고 생각했어요.출시 후 데이터까지 열심히 분석해서 팀원들에게 공유할 겸 회고 시간을 가졌습니다. 그 회고 자리에서 팀원들의 피드백을 듣고 저는 큰 충격을 받았어요.‘사실 아직도 이 문제를 왜 풀어야 하는지 완전히 공감되지는 않았다’ 라는 이야기를 들었어요.팀원들과 분명 싱크를 잘 맞췄다고 착각했던 부분이 가장 부끄러웠고,그 다음으로는 왜 이 문제를 풀어야 하는지도 모른채 그저 팀원들을 일하게 만들어서 참 미안했습니다.의도에 공감하지 못하고 억지로 일하는 게 얼마나 힘든 일인지 아니깐요. 그래서 저는 냉정하게 제가 무엇이 부족했는지, 어떻게 개선되면 좋을지 팀원들에게 피드백을 받..

PM은 타 직군에 비해 크게 내세울 기술적 역량이 많지 않아요.(물론 요즘에는 AI를 활용할 수 있어 기술 접근성이 많이 낮춰졌지만요.)그래서 내가 잘 성장하고 있는지 의심되는 순간도 종종 있어요. 성장했음을 체감하는 다양한 방법이 있지만,성장을 위한 필수도구이자 성장을 체감할 수 있는 도구로 “회고”를 추천해요. 제가 회고를 진행하는 방법은 크게 3가지예요.1) 개인적으로 진행하는 데일리 회고,2) 스프린트가 종료되면 진행하는 팀원과의 회고,3) 사수에게 요청하여 진행하는 회고. 데일리 회고 먼저 데일리 회고는 오늘 하루 업무를 진행하면서 느낀 점을 노션으로 작성하고 있어요.(잘한 점, 부족한 점, 배운 점)으로 나눠서 작성하고 있고1줄씩 가볍게 작성해도 되고 작성할 게 없는 날에는 굳이 작성하지 않..

서비스 기획자, PM으로 직무 전환을 어떻게 할 수 있을까요? 저는 첫 회사에서 퍼포먼스 마케터로 1년가량 일하다 서비스 기획자로 직무를 전환한 경험이 있습니다. 직무 전환 계기는 제가 직접 진행한 서베이를 통해 제품 개선점을 찾고, 이를 계기로 결제 전환율을 높여본 경험이 강력한 트리거가 되었습니다.(솔직하게 고백하자면 기존에 기획팀이 풀지 못한 문제를 기획자가 아닌 제가 해결했다보니,기획자로서 나 재능이 있나본데? 이런 거만한 마음을 가지기도 했어요! ㅋㅋㅋ ) 이런 짜릿한 경험을 하면서 마케터로서 이미 잘 만들어진 제품이 필요한 사용자를 찾는 일도 재밌었지만,조금 더 앞단으로 가서 좋은 제품을 직접 만들고 싶다는 마음이 들었습니다.마케팅 업무를 하면서 유저보이스를 가장 가까이에서 듣다보니 제품..

P-S 통합 코드 이야기 설득하는 방법 실제 애플은 이렇게 프러포즈하지요 >> Why-How-What“우리가 하는 모든 일은 현실에 도전하기 위함입니다(Why).그리고 우리는 다르게 생각하기의 가치를 믿습니다(Why). 그것을 위해 우리는 모든 제품을유려한 디자인, 편리한 사용법, 사용자 친화적으로 만들죠(How).그래서 이 훌륭한 컴퓨터가 탄생했습니다(What). 한 대 사실래요?”P코드는 1) 왜 이거 해야 하지? 2) 왜 이게 문제지?설득도 Why 부터 시작해야 효과적입니다 설득은 논리와 감정의 게임이지만더 본질적인 건 논리(what/how) 이전에 감정(why)입니다.오디언스는 S코드(what/how) 보다 P코드(why)에 ‘감정적으로’ 움직입니다.기획의 해결책Solution이 무엇인지보다..

기획의 제2형식, S코드 이야기 문제 규정이 과정이라면, 해결책은 결과다 중요한 건 ‘해결점project’이 탄탄하려면 역으로‘문제점problem’이 탄탄해야 한다는 점입니다.결국은 ‘문제 규정’입니다.그만큼 기획에서 P코드problem&project가 본질적이라는 이야기입니다.따라서 좋은 아이디어가 잘 나오지 않는다면 머리를 쥐어뜯기보다근본적으로 문제 규정이 제대로 되었는지 P코드부터 재점검해보는 것이 순리입니다. 메타포로 높이 뛰어오르자‘좋은 기획 아이디어’에는 ‘은유metaphor’가 있습니다.메타포의 핵심은 '닮은꼴 찾아오기'입니다.ex. 히트텍은 제2의 피부다 ex. 우리가 사는 세상은 기차다 ex. 나이키는 운동화가 아니라 승리다 티 안 나게 훔치는 기술1. 원천 봉쇄만약 모 가구업체가이..