[내배캠] 프로덕트 매니지먼트 개론 | ③ 실전 PM의 커뮤니케이션

 

실무에서 PM이 겪는 문제와 해결 방법

 

 

PM의 매력

 

우아한형제들 PM의 이야기- “배민 기획자의 일”

 

https://techblog.woowahan.com/13027/

우아한형제들 PM의 이야기- “배민 기획자의 일” | 우아한형제들 기술블로그

 

내가 만든 제품이 세상에 나오는 게 좋다

 

[실제 모습]

• 디지털 프로덕트는 빠른 시간에 많은 사람에게 영향력을 끼칠 수 있음

• 다만, 여러 이유로 출시가 미뤄지거나 무산되는 경우도 있음

• 출시하더라도 기대보다 사용자 반응이 좋지 않은 경우도 있음

• 비즈니스 측면까지 고려하여 성과를 내야 함

 

[필수 역량]

‣ 문제 정의: Pain Point를 발견하고 진짜 문제를 정의할 수 있는 능력

‣ 비즈니스: 사용자에게만 좋은 것이 아니라 비즈니스에도 이익이 되는지 판단할 수 있어야 함

‣ 가설 검증: 빠르게 가설을 수립하고 검증하는 과정을 실행

 

새로운 걸 기획하는 걸 좋아한다

 

[실제 모습]

• 기획안 작성은 PM에게 가장 중요한 핵심 업무이자 전략이 담긴 중요한 문서

• 다만, 내가 하고 싶은 대로가 아니라 현실적인 상황 (ex.고객, 대표, 주변 팀의 요구사항, 일정, 개발 리소스, 정책 등)을 고려해야 함

• 현실적 제약에도 불구하고 무언가를 실제로 세상에 내놓는 사람

 

[필수 역량]

‣ 문제 정의: 새로운 기능을 만들기 전에 “왜 이게 필요한가? 어떤 문제를 해결하려는가?”를 명확히 정의할 수 있어야 함

‣ 데이터 기반 의사결정: 실험과 검증을 통해 정량적 근거가 있는 판단을 내려야 함

‣ 우선순위 설정: 일정, 리소스, 비즈니스 전략 등 수많은 제약 안에서 결정해야 함 

 

리딩하는 역할을 하고 싶다

 

[실제 모습]

• 의사결정에서 가장 중요한 문제 정의와 해결안을 포함한 방향을 제시하는 것은 PM의 중요한 역할

• 다만, PM은 공식적으로 권한이 있는 리더 직책이 아니라 역할

• 명령이 아닌 설득과 조율을 통해 자연스럽게 영향력을 확보해야 함

• 설득을 위해서는 논리적인 기획, 팀원들의 신뢰, 데이터 등이 필요함

 

[필수 역량]

‣ 방향성 제시: 팀이 혼란스러워 할 때, “무엇이 문제이고, 어디로 가야 하는지”를 명확하게 제시할 수 있어야 함

‣ 데이터 기반 의사결정: 감이 아닌  데이터로 말해야 팀이 신뢰하고 따라옴

‣ 설득력: 다양한 직군의 사람들에게 각자 이해할 수 있는 언어로 설명하고 납득시킬 수 있어야 함

‣ 프로젝트 관리: 말로만 리딩하는 게 아니라 실제로 언제까지 무엇을 완료해야 하는지 실행을 끌고 가야 함

 

다양한 사람들과 소통해서 결과물을 내는 게 즐겁다

 

[실제 모습]

• 팀 덕분에 혼자서는 낼 수 없는 성과와 영향력을 만들어가는 성취감이 있음

• 이해관계가 엇갈릴 때 그 사이에서 조율하는 것이 쉽지 않음

 

[필수 역량]

‣ 각 직무에 대한 기본적인 지식: 개발, 디자이너와 소통할수 있는 기본적인 지식 

‣ 설득력: 단순 전달이 아니라 이해시키고 공감시키고 납득시키는 커뮤니케이션이 중요

‣ 팀워크: 팀원들의 기분을 읽고 관계가 틀어지지 않게 부드럽게 리딩 

 

 

PM의 역할

 

 

 

PM의 어려움

 

누구보다 사용자를 깊이 이해해야 한다

 

[어려움]

• 제품이 속한 산업과 고객군에 대한 이해도가 매우 중요함

• 내가 겪어 보지 않은 사용자의 니즈를 상상하기 어려움

 

[해결 방안]

‣ 직접 사용자가 되어 보기

‣ UX 리서치

‣ 고객과 자주 만나는 내부 전문가에게 배우기 (ex. 세일즈팀, 운영팀 등)

‣ 온라인 SNS, 커뮤니티 분석

 

데이터 회사가 와인샵을 차린 이유

 

https://koreacreditdata.medium.com/데이터-회사가-와인샵을-차린-이유-c60909c9e865

데이터 회사가 와인샵을 차린 이유

 

토스가 사용자 경험에 ‘집착’하는 또 하나의 방법, 유저 리서치

 

https://toss.im/tossfeed/article/user-research-team-interview

UX 리서처 인터뷰 - 토스가 '사용자 경험' 에 '집착'하는 방법은? - 금융이 알고 싶을 때, 토스피드

 

PM 역할의 범위가 조직마다 조금씩 다르다

 

[어려움]

• 회사가 작을수록 다양한 업무를, 회사가 클수록 좁은 범위의 업무를 담당함

• 팀에서 기대하는 역할과 어긋나면 실망으로 이어질 수 있음

 

[해결 방안]

‣ 내가 담당한 제품 혹은 팀에서 어떤 역할 범위를 가져갈지를 스스로 잘 정의해야 함 (ex. 기획안 범위, 와이어프레임 등)

 

수시로 변하는 시장 상황과 회사 상황에 빠르게 적응해 우선순위를 정해야 한다

 

[어려움]

• 시장상황이 바뀌면서 최상위 목표가 수시로 바뀌기도 함 

• 직무별로 우선시하는 우선순위의 기준이 다를 수 있음 (ex. 일정 VS 완성도)

 

[해결 방안]

‣ 제품의 방향성을 기반으로 우선순위 기준에 대해서 팀 내 합의하기 

‣ 기획을 짧은 사이클로 쪼개서 민첩하게 움직이기 (애자일) 

‣ 심리적으로 ‘계속 바뀌는 게 당연하다’는 마인드 세팅

 

 

 

비즈니스 커뮤니케이션의 기본

 

PM 커뮤니케이션의 특징

 

팔로워지만 여러 이해관계자를 리딩해서 성과를 내야 함

Q. 커뮤니케이션 오류는 왜 생길까?
A. 각자 알고 있는 정보 혹은 각자 원하는 목표가 다름

 

 

PM 커뮤니케이션의 원칙

 

1. 상대방의 니즈 파악

 

✔︎ 상대방의 입장에서 상대방이 중요하게 여기는 기준을 파악하기

‣ 개발자는 어떤 기준으로 우선순위를 정할까?

‣ 나한테 이 업무를 왜 줬을까? 어떤 걸 원할까?

‣ 경영진이 원하는 건 매출 증가인데, 이걸 어떻게 연결할 수 있을까?

 

✔︎ 상대방이 듣고 싶은 방식으로 이야기하기

‣ 팀장님이 매일 바쁘시던데, 결론부터 알고 싶지 않을까?

‣ 디자이너랑 개발자도 시키는 업무보다는 제안을 하고 싶지 않을까?

 

✔︎ 상대방의 언어로 말하기

‣ 회의에 처음 참석하는 사람도 이해하기 쉽게 말하기

 

2. 빌드업

 

✔︎ 상대방이 이해하고 납득할 수 있는 논리적 근거 제공

‣ 이 디자인 수정해주세요 (X)

‣ 사용자 테스트에서 이 버튼이 잘 보이지 않는다는 피드백이 나왔어요 (O)

 

✔︎ 갑작스러운 통보가 아니라 사전에 과정을 공유하기

‣ 아직 확정은 아닌데 이런 과제를 할 수도 있을 것 같아요.

‣ 다음 주에 그 과제에 대해서 진행 여부를 논의할 것 같아요.

 

✔︎ 적극적인 협업을 위해 사람들에게 참여했다는 느낌을 줄 수 있도록 하기

‣ 지난번에 이야기했던 내용 기반으로 정리해 봤는데, 이 방향 괜찮을까요?

‣ 혹시 그 과제에 대해서 사전에 공유주실 의견 있으실까요?

 

3. 크로스체크

 

✔︎ 구두 합의 직후 체크

‣ 말씀해주신 내용을 저는 [이해한 내용] 이렇게 이해했는데 맞을까요?

 

✔︎ 업무 지시 혹은 요청 후 체크

‣ 지금 이해한 대로 설명해줄 수 있을까요?

 

✔︎ 중요한 정보 공유 후 체크

‣ 다시 한번 정리해서 문서로 공유하기

 

 

PM이 자주 마주치는 커뮤니케이션 상황

 

1. 보고 (공유)

 

• 적절한 시점에 적절한 사람에게 진행 상황 공유

• 내가 말하고 싶은 것보다 상대방이 듣고 싶어 하거나 필요로 하는 정보 위주로 공유

• 중간 단계 없는 최종 보고는 금물

• 상대방이 정확히 이해했는지 크로스체크

• 예시

    - 디자이너에게 현재까지 정리된 기획안 공유

    - 팀 리더에게 업무 진행상황 공유하기

    - 데일리 스크럼, 프로젝트 정기 회의

 

2. 요청하기

 

• 언제쯤 요청이 들어갈 것 같다는 것을 미리 공유 (빌드업)

• 요청의 맥락을 설명하기

• 각 직군의 언어로 이해할 수 있게 말하기

• 요청 내용을 정확히 이해했는지 크로스체크

• 예시

    - 개발자에게 새로운 기능 개발 요청

    - 마케팅 부서에 서비스 오픈일 공유하기

 

3. 요청받기

 

• 요청 자체보다 왜 이 요청이 나왔는지를 파악 (근본적인 문제나 목표 파악)

• 해당 요청이 얼마나 긴급한지 파악하고 수락

• 요청 내용과 내가 이해한 게 맞는지 크로스체크

• 바로 거절하기보다는 대안이나 이유를 함께 제시

• 예시

    - 운영자의 요청으로 어드민에 기능을 개선할 때

    - CS팀이 자주 들어오는 문의를 줄이기 위한 개선 요청

 

4. 설득 (협상)

 

• 상대방의 목표, 우선순위, 걱정하는 부분을 먼저 이해

• 상대방이 이득을 본다고 느끼게 만들어야 함

• 설득은 갑자기 하는 것이 아니라 단계적으로 공감대를 형성해야 함

• 예시

    - 개발자, 디자이너와 과제 우선순위 및 일정에 대한 협상

    - 개발자, 디자이너와 과제의 구현 방식에 대한 협상

    - 디자이너에게 유저 피드백을 반영한 다른 방향 제안

 

 

회의 진행

 

피해야 하는 회의 유형

 

‣ 목표 / 준비 / 집중 / 결론 없는 회의

 

회의 종류

 

• 정보 공유 회의: 발표자가 핵심만 정리해서 공유하고 참석자는 궁금한 점을 질문하는 것이 좋음

• 아이디어 회의: 아이디어의 수준을 따지지 말고 편안한 분위기에서 일단 많이 내는 것이 좋음

• 의사결정 회의: 사전에 자료가 충분히 준비되어야 하고 반드시 결론이 나와야 함

• 문제 해결 회의: 문제를 제대로 정의하고 왜 문제가 생겼는지, 어떻게 해결할지를 정리해야 함

• 피드백/회고 회의: 서로 공격하는 것이 아니라 더 나아지기 위한 건설적인 관점이 중요함

 

회의 진행 과정별 업무

 

1. 회의 진행 여부 검토

- 회의가 이만한 가치가 있는가를 먼저 고려해야 함

- 단순 정보 전달이라면 이메일이나 메신저, 논의 안건이 모호하거나 부족하다면 회의 연기 혹은 자료 보완, 습관성 회의가 반복된다면 구조화된 목적 설정으로 대체

- 정기 회의더라도 회의 목적이 분명해야 함

 

2. 회의 전

- 회의 목적에 맞는 적절한 참가자 구성, 너무 많거나 적어도 비효율적임

- 의사결정이 필요한 회의라면 최종 결정을 내릴 수 있는 권한을 가진 사람을 반드시 포함

- 회의를 통해 무엇을 얻고자 하는지(의사결정, 문제 해결, 아이디어 도출 등)를 명확히 정의

- 참석자들이 회의 전 충분히 숙지하고 올 수 있도록 안건과 필요한 정보를 미리 공유, 회의 중 자료 설명에 시간을 낭비하지 않기

- 회의 시간 선정: 일정은 미리 잡을 것, 회의 시간은 최대 1시간으로 잡는 것이 효율적

 

3. 회의 중

- 회의 시작 때 진행자가 전반적인 내용 공유: 참여자들이 동일한 아젠다를 인지했는지 확인, 목적・진행순서・아웃풋 정리

- 논의가 논점에서 벗어나지 않도록 흐름 유지

- 크로스체크를 통해 오해 없이 중간 정리 (용어가 동일한지 재정의)

- 모든 참석자의 참여 유도

- 시간 관리: 각 안건별 소요 시간을 염두에 두고 시간을 초과하지 않도록 조절

- 필요하다면 논의 내용 시각화

- 회의 결론 정리: 누가 무엇을 언제까지 할 건지 명확하게 결정

 

4. 회의 종료

- 회의 직후 빠른 시간 내에 회의록을 작성하여 배포: 특히 결정사항과 액션 아이템은 명확히 작성

- 참석자들에게 피드백을 요청하여 최종본 확정

- 해야 하는 업무 인지시키기: 담당자와 기한을 리마인드