#왜PM을? #근거 #팀스포츠 #그럴수도있지 #커뮤니케이션 #회의
왜 PM을 하고 싶나요?
(뭉게 뭉게 떠오르는 이유들은 많은데)
한 번 쯤은 한 줄로 된 문장 진지하게 생각해보기
우아한형제들 PM의 이야기- “배민 기획자의 일” | 우아한형제들 기술블로그
PM을 한다는 것은 매년, 어쩌면 매달 바뀌어 가는 새로운 기술∙시장∙삶의 변화에 맞추어 끊임없이 서비스가 제공될 환경을 분석하고, 서비스와 함께 성장해가는 일인 것 같습니다. 한편으로는
techblog.woowahan.com
1. 내가 기획한 거, 만든 게 세상에 나오고 사람들이 쓰는 것. 긍정적인 사용자 피드백과 지표 향상.
→ 이게 제일 크지 않을까? 내가 옷을 팔 때는 제작이 아닌 이상 물론 내가 만든 건 아니었지만 어쨋든 수많은 의류 중에 내 타겟을 위해서 내가 셀렉을 해 오는 거니까. 그리고 그걸 의도에 맞는 타겟이 입어줄 때, 도움이 되었다고 할 때의 보람이 컸다. 단순히 '아무 거나 다 파는 사람'으로서는 아니다.
정확히 내 의도에 맞는 게 딱 맞아떨어져서 팔릴 때. (옷 뿐만 아니라 오겜 세트 같은 거 판 것도..)
마케팅도 어찌 보면 콘텐츠, 푸시, 팝업에서 그게 내 의도대로 조회/클릭이 올라갈 때의 희열과 비슷할 거 같다.
↔ 실제?
- 출시가 매우 오래 거리거나 아예 무산되는 경우
→ 전략적으로 나은 결정이라면 따라야지. 조직의 일원으로서, 조직의 전략에 더 나은 결정을 해야지 자아의 신화를 이루기 위한 일이 아니라고 생각함.(근데 내가 생각하는 더 나은 결정이랑 방향이 다르다면...... 힘들긴 하겠다.) - 부정적인 사용자 피드백
→ 아니 세상에 있는 모든 서비스가 어떻게 성공적이고 긍정적일 수 있나? 수 천, 수 만 가지의 서비스가 있는데.. 자연스러운 과정일 뿐이고 과정에서 배우고 다음에 적용할 수 있다.
풀어 나가기 위해?
- 문제 정의: 진짜 문제 정의
- 비즈니스: 유저 뿐만 아니라 비즈니스에도 이익인지?
- 가설 검증: 빠르게 가설 수립 - 빠르게 검증 실행
2. 새로운 것을 기획
↔ 실제?
- 내가 하고 싶고 아이디어만 있다고 다 할 수 있는 게 아니라 현실적 제약이 있음을 인지해야함
풀어 나가기 위해?
- 문제 정의: 왜 필요한가? 무엇을 해결하나?
- 데이터 기반: 정량적 근거 from. 실험/검증
- 우선순위: 수많은 제약 내에서 결정
3. 리딩
↔ 실제?
- 공식적 권한이 없음
→ 과도하게 리딩 당하는 걸 싫어하긴 하지만 그렇다고 리딩이 좋아서의 경우는 난 아닌 듯...
근데 표면적 리딩만 아닐 뿐이지 방향 제시는 굉장히 많이 하는 것 같긴 하다.
그래서 이게 맞냐? 이 순서가 맞냐? 전체 맥락과 현재 위치를 계속 파악하고 합치 시키려고 함.
차라리 그래서 공식적 권한이 없는 직책이 아닌 게 나은 걸 수도?
풀어 나가기 위해?
- 방향성 제시
- 데이터 기반: 감이 아닌 데이터
- 설득력: 각자 이해할 수 있는 언어로 설명
- 프로젝트 관리: 언제? 무엇을? 끌고 가기
4. 협업이 즐거워요
↔ 실제?
- 이해 관계 엇갈릴 때
→ 난 이것도 아닌 거 같은데..
아 근데 최근에 팀에 대해서 느낀 게 있다. 정말 정말 안 맞는 분 (예를 들면 진짜 슈퍼슈퍼EEEE 시라든가.. 전혀 찾아 보지 않고 묻어 가시려 한다든가..ㅎ) 만 아니라면, 성격이 모두 다른 사람이 마치 팀스포츠처럼 필요하다는 것이다.
스몰톡을 너무 많이 해서 시간이 길어지는 불편함이 있는 반면 조직을 좀 더 유연하게 해주고, 강력하게 의견을 내며 크게 타인의 눈치를 안 봐서 불편함이 있는 반면 앞에서 리딩을 잘 해주고.. 이런 장/단? 혹은 성격적 특성이 나 포함 누구에게나 있고 팀에는 그런 가지각색의 사람이 필요하다. 그래야 다양한 아이디어가 나온다.
(부가)
데이터 회사가 와인샵을 차린 이유
토스가 사용자 경험에 ‘집착’하는 또 하나의 방법, 유저 리서치
- 내가 사용자가 아닌 제품을 담당하면, 누구보다 사용자를 깊이 이해해야 한다.
→ 나는 사회적 민감도가 높고, 사람과 현상에 대해 탐구하는 것을 좋아한다. 근데 그저 '공감'으로만 되는 게 아니라 '경험'이 필요한 영역이기 때문에 발로 많이 뛰고 손으로 많이 찾아야 한다. 그래서 호기심이 많은 측면도 도움이 될 것 같다. 최대한 많은 영역의 사용자가 되어 보는 것일 수도? 언제나 부족하다 더 많이 많이 경험해야 하는데..! 시간과 자본과 건강이 한정적이다......ㅋ 그러니 이 역시 (기승전) 우선 순위 설정...ㅋ
+ 또는 그 사용자를 가장 자주 만나는 회사 내부 전문가에게 의견 구하기 - 회사, 팀마다 PM 역할의 범위가 천차 만별이다. 기획안과 와이어프레임의 범위.. 등이 너무 다름. 즉 팀에서 기대하는 역할이 무엇인지 잘 파악해야함
→ 이거 면접 때 역으로 물어보면 좋겠다. 내가 합류할 경우 제 역할의 범위나 주요 업무가 무엇인지?
결론

계속 바뀌는 게 당연하다~
역시 '그럴 수도 있지' 마인드네...
커뮤니케이션 오류를 방지하기 위해
- 각자 알고 있는 정보(경험)가 다르다는 것을 인지
- 각자 원하는 목표(동기부여)가 다르다는 것을 인지
커뮤니케이션의 원칙
1. 상대방 니즈 파악 (역지사지)
→ 상대방이 중요하게 여기는 기준 (우선순위, 효과)
→ 상대방이 듣고 싶은 방식 (명확, 결론, 의견수렴)
→ 상대방의 언어 (이해하기 쉽게)
2. 빌드업
→ 결정 통보가 아니라 과정의 점진적 공유로 자연스러운 동의 얻어내기 + 논리적 근거 제공
(반발심 감소, 준비 시간, 피드백 반영, 참여했다는 느낌)
3. 크로스 체크 (이거 내가 꼭 하는 것)
→ 말씀해주신 내용을 저는 ~ 이렇게 이해했는데, 맞을까요?
→ 지금 이해한 대로 설명해 주실 수 있을까요?
(ㄴ 근데 이건 상사에게는 비추천일 듯. '혹시 ㅇㅇㅇㅇ 이라는 단어를 어떤 의미로 생각하시는지 여쭤볼 수 있을까요? 의견 합치를 위해서 여쭤보려고 합니다.' 정도가 실제로 내가 쓰는 것이기도 함)
→ 다시 한 번 정리해서 문서로 공유할게요!
보고(공유)
1. 상대방이 필요로 하는 정보
2. 중간 단계 보고 필수 (개요라도 작성해서 팀장님께 여쭤보자)
3. 이해도에 대한 크로스체크
요청하기
1. 여유를 두고 빌드업
2. (빌드업 못 했을 때도)왜 이걸 요청하는지 맥락 설명
3. 상대방의 언어
4. 요청 내용에 대한 크로스체크
요청받기
1. 요청의 맥락 파악
2. 우선순위 판단
3. 요청 내용에 대한 크로스 체크
4. 거절 시에는 대안/이유 제시
설득(협상)
1. 상대방의 목표, 우선순위, 걱정을 이해
2. 상대방이 이득을 본다고 느끼게
3. 갑자기가 아니라 단계적 공감대 형성
회의 종류
전제: 준비한 건 없지만 일단 모여서 얘기하자 x 아젠다 필수 공유
정보 공유 회의 - 핵심만 공유
아이디어 회의 - 일단 편하게 많이
의사 결정 회의 - 사전 자료 & 결론 도출
문제 해결 회의 - 문제 정의 & 해결 방안 차근 차근 정리
피드백/회고 회의 - 안전하고 솔직한 환경에서 '다음에 더 나아질 수 있겠다'는 관점
지금 하는 회의의 목적이 뭔지 이런 식으로 정해 봐야겠다.
회의 운영
회의 진행 여부 판단
- 회의는 팀의 시간을 소비 → 가치 있는지 먼저 확인
- 단순 전달은 메신저/문서로 대체
- 아젠다·목적 모호하면 회의 연기·보완
- 정기회의도 목적 사라지면 포맷 변경·축소·폐지 검토
회의 전 준비
- 목적에 맞는 참석자 선정 (특히 의사결정권자 포함)
- 역할 분담: 진행자 / 발표자 / 서기 / 참석자
- 회의 목적 명확히 정의
- 자료·아젠다 사전 공유
- 회의 시간은 미리 잡고, 가능하면 1시간 이내
회의 중 핵심 원칙
- 목적·아젠다·예상 아웃풋을 회의 시작 시 공유
- 논의가 산만해지지 않도록 흐름 통제
- 중간중간 크로스체크로 이해 정렬
- 참석자 모두 발언할 기회 제공
- 안건별 시간 관리
- 필요하면 논의 시각화
- 마무리: 누가·무엇을·언제까지(Who/What/When) 명확히 결정
회의 종료 후
- 빠르게 회의록 배포
- 결정사항·액션아이템 재확인
- 담당자와 기한 리마인드
zoom/구글밋 회의록 작성 or 요약 기능 알아보기!
'스파르타 내일배움캠프 PM 5기 > 프로덕트매니지먼트 개론' 카테고리의 다른 글
| [강의] 프로덕트 매니지먼트 개론 - 프로덕트 개발 (0) | 2025.12.06 |
|---|