프로젝트 100개를 겪고 깨달은 PM 성장의 법칙
7년 동안의 시행착오가 만들어준 나만의 기준 세 가지
안녕하세요~ :) 리뷰온리입니다!
"일 잘하는 PM이란 뭘까"라는 고민을 다들 하실텐데요,
7년 동안 수많은 프로젝트를 거치며,
저 역시 그 답을 찾으려 애썼던 것 같아요.
주니어 시절에는 일정만 잘 관리하면 된다고 믿었어요.
Jira에 태스크를 정리하고, 일정표를 맞추는 게
제 역할의 전부라고 생각했어요.
그런데 시간이 쌓이면서
PM은 사고의 구조를 설계하는 사람이라는 걸 비로소 알게 된 것 같아요.
오늘은 이런 저의 생각들을
여러분에게도 전해드리려고 해요!
할 줄 아는 PM에서 이해하는 PM으로
처음 몇 년은 "할 줄 아는 사람"이 되고 싶었죠.
요구사항을 빠르게 정리하고,
일정 지연 없이 마감하는 게 목표였어요.
그런데 어느 순간 이런 생각이 들었어요!
"왜 이 기능을 만드는 걸까?"
"이 흐름에서 사용자는 뭘 느낄까?"
그때부터 저는 툴 중심 사고에서
문제 정의 중심 사고로 옮겨가기 시작했어요.
Figma와 Jira를 넘나들며 기능과 디자인을 조합했지만,
그 뒤에 숨어있는 '의도'를 보기 시작했죠.
이전에는 Jira 이슈를 닫는 게 일의 끝이었다면,
지금은 그 이슈가 왜 열렸는가를 끝까지 추적하는 사람이 되었어요.
이 변화 이후부터 PM으로서 제 시야가 달라졌어요.
문제를 해결하는 사람에서,
문제를 해석하는 사람으로 성장했다고 느꼈어요!ㅎㅎ
중간 관리자가 아닌 해석자로
한동안 저는 개발자, 디자이너, 클라이언트 사이에서
업무를 조율하는 사람이었어요.
서로 다른 입장을 이해시키고, 문장을 다듬어 전달하는 게 제 역할이라고 생각했죠.
하지만 어느 순간 그 이상이 필요하다는 걸 깨달았어요...ㅠㅠ
단순히 중간에서 이야기를 전달하는 것 만으로는
프로젝트가 전진하지 않아요.
누가 옳은지를 정리하는 게 아니라,
무엇이 맞는 방향인지 설계하는 일이 필요했어요.
그래서 이제는 누구의 말을 옮기기보다,
그 사이에서 방향성을 제대로 잡아주는 PM이 되었어요.
회의를 설계하는 방식도 바뀌었어요.
예전엔 회의록을 꼼꼼히 정리했지만,
지금은 회의 자체를 구조화해요.
문제 정의 → 논의 포인트 → 결정 기준 → 후속 액션을 미리 설계하죠.
이 작은 변화가 협업 효율을 완전히 바꿔놓았어요!
슬랙, 노션, 피그잼 같은 협업툴은 결국 도구일 뿐이에요.
진짜 중요한 건, 그 안에서 맥락을 압축하고 방향을 제시하는 힘이에요!ㅎㅎ
사고의 단위가 달라졌다
주니어 시절엔 하루 단위로 일정을 조정했고,
미들레벨 시절엔 기능 단위로 계획을 짰어요.
하지만 7년차가 된 지금은 시스템 단위로 사고해요.
"이 기능이 다음 분기 데이터에 어떤 영향을 줄까?"
"이 구조가 팀의 생산성을 얼마나 바꿀 수 있을까?"
이런 질문을 던지며, 프로덕트의 전체 구조를 보게 되었어요.
특히 AI 도입과 UX 자동화가 본격화된 이후,
PM의 사고 단위는 훨씬 더 넓어졌어요.
업무 자동화 툴을 단순 효율 수단이 아니라
'팀의 운영 시스템'을 재설계하는 기회로 바라보게 되었죠.
예를 들어 Notion AI로 QA 로그를 자동화하고,
Jira API를 활용해 버그 리포트를 통합했어요.
이건 팀의 사고 체계를 데이터화하는 과정이었어요.
AI가 PM의 뇌 구조 자체를 확장시키고 있다고 느꼈어요ㅎㅎ
'나의 기준'이 생겼다
이제는 어떤 프로젝트를 하더라도 흔들리지 않는 기준이 생겼어요.
이 기준은 7년 동안 쌓인 시행착오의 결과물이라고 생각해요!
1. 일정보다 명확한 커뮤니케이션
일정이 틀어지는 건 괜찮아요.
대신 누구도 오해하지 않도록 커뮤니케이션을 선명히 유지해요.
2. 문서보다 공유 맥락
모든 산출물보다 중요한 건,
그 문서가 만들어진 이유를 팀 전체가 알고 있는 거예요.
3. 리스크보다 신뢰
리스크를 완전히 제거하는 건 불가능해요.
그래서 신뢰가 리스크를 흡수할 수 있는 구조를 만드는 게 더 중요해요.
이 세 가지를 중심에 두고 일하기 시작하면서,
프로젝트가 훨씬 안정적으로 굴러가기 시작했어요!ㅎㅎ
PM으로 일한다는 것의 진짜 의미
이젠 일을 완벽히 끝내는 사람보다, 더 잘 묻는 사람이 되고 싶어요.
예전에는 "이걸 언제 끝낼 수 있을까?"를 물었다면,
지금은 "이걸 왜 해야 하지?"를 더 먼저 생각하는 것 같아요!
7년 동안 배운 건 결국, 사람과 프로덕트를 동시에 설계하는 법이에요.
PM의 성장은 '관리'뿐만 아니라
'사고의 확장'에도 달려있다고 생각하거든요~
그래서 오늘도 새로운 프로젝트를 시작할 때마다
이 일을 더 잘하게 되려는 게 아니라, 더 깊이 이해하려고 노력해요.
결국 PM의 성장 곡선은,
'사고의 깊이'로 결정된다고 생각해요.
오늘의 이야기가 지금 PM으로 일하고 있거나,
일의 본질을 고민하는 분들에게 참고가 되었으면 좋겠어요 :)
오늘도 읽어주셔서 감사합니다!ㅎㅎ
