제품관리자의 역할은 무엇인가? PM과 서비스기획자는 무엇이 다른가?

이번 글은 '제품관리자는 어떤 일을 어떻게 하는지'에 대한 내용을 다루었습니다
(제가 내린 개인의 결론이긴 하지만) PM과 서비스기획자의 차이가 궁금하셨던 분은 글의 마지막으로 가시면 빠르게 이해하실 수 있을 것 같습니다.
 

---

※ 중요 : 아래 내용은 패스트캠퍼스의 "PM/PO 실무 완전 정복 초격차 패키지 Online "강의 내용을 정리한 것으로, 강의 내용 중 일부를 캡처한 이미지는 저작권에 문제가 있는 경우 삭제될 예정입니다.
 

I. 제품 관리자란

제품관리자는 회사 별로 업무가 다르기 때문에 논란의 주제이지만, 시끄러움 속에서 질서를 만들어내는 직무라고 본다.
제품관리자는 올라운드 플레이어여야 한다.
 

제품관리자 능력 = 제품기획 + 프로젝트관리 + 커뮤니케이션

 
 
[제품기획의 역할 변화]
1. As-is 런칭에 집중하는 제품기획자에서
- 서비스기획자 : 10년 이상의 경력자들은 대부분 이렇게 시작하였을것
- 프로젝트 매니저 : '관리'에 집중. 서비스기획을 안하는 경우도 있음. 창의성 < 적시대응.
※ 개발자가 잘 이해할 수 있도록 상세하게 기획하는 것과 런칭되는 것을 잘 관리할 수 있도록 하는 것에 집중하였다
2. To-be 런칭보다 런칭 후가 더 중요한 제품기획자로
- 프로덕트 매니저 : 상품의 전략을 결정 (PO 상위에 존재)
- 프로젝트 오너 : 우선순위를 결정
※ 목표 달성여부를 확인하기 위해 다양한 가설을 검증해나가는 것에 집중. 정성/정략적 목표 수립.
 
→ STUDY : 나는 어떤 단계에 있는가? 내가 재직하고 있는 회사는 담당하는 product별 PM과 서비스기획자를 구분하는 방식을 취하고 있다. 앞으로는 모두가 PM/PO 방식으로 변경될 것이라고 하지만, 내가 관리하는 product는 Platform&BO라서 나는 '서비스기획자, 프로젝트 관리자'로 불리고 있다. 
 

📍강사의 조언
"제품관리자는 남을 통해 성과를 만들어내는 사람이다"
"아래의 질문들에 잘 답변하는 사람이 좋은 제품관리자이다. "짐이 태양이다", "내가 짱이다"라는 사람들은 성과를 못내는 경우가 많다"
"일이 막막하고 재미없을 때 아래의 질문에 답변을 해보아라. 답변이 애매하다 싶으면 누군가와 소통해서 답변을 찾아내라. 위의 질문들에 답변을 못한다면 '시키니까 하는 일'을 하는 것 뿐이다"

→ STUDY : 나의 답변은 무엇인가? 나는 현재까지는 송금과 매출정산에 대한 정책을 기획했는데, 2023 우선순위를 고려하여 '권한'을 최우선순위로 기획하기로 하였다. 위의 질문에 대한 답변은 '권한정책'에 focus하여 답을 해보았다.

• Q1 : BackOffice와 Dashboard에 접속하는 계정에게 역할을 부여하여 그 역할 별 권한을 설정할 수 있는 제품을 만들어야 합니다. 
• Q2 : 이 제품이 성공적으로 만들어진다면, 개인정보노출 Risk가 감소하고 정보보안성이 증가할 뿐만 아니라 제품을 관리하지 않았을 때 발생할 수 있는 법적 이슈들을 방어할 수 있습니다.
• Q3 : 이제 막 정책을 기획하는 단계이기 때문에 유관부서(개발, 운영자)과 함께 '역할기반 권한관리 시스템(RBAC)' 구조에 대한 논의가 필요하고, 그 결과에 따라 권한정책을 작성해야합니다.
• Q4 : 제품의 주요사용자는 내부관리자 및 고객사의 담당자가 될텐데, 내부관리자는 사업운영담당자(B2B Growth)가 주사용자이며 고객사의 담당자는 월렛충전 및 송금을 요청하는 실무자가 주 사용자가 될 것입니다.
• Q5 : 이 제품의 핵심지표로는 (1)역할 별 권한에 따른 기능제한(쓰기,조회,다운로드)이 잘 작동되는가?, (2)해당 계정이 조회가능한 정보만을 잘 노출하는가?(개인정보, 조회가능 거래)로 볼 수 있습니다.
• Q6 : 이 제품을 개발하기 위해서는 기획+개발+보안담당+실운영자(내부,고객사)의 리소스가 필요합니다.
• Q7 : 이 제품은 2023 말 ~ 2024년 초에 런칭을 목표로하고 있고 기획을 시작하는 현 시점은 8월 1일 이므로 [ (1)8월 중순까지 정책 완성 → (2)8월 말가지 개발리뷰 종료 → (3)9월부터 백엔드 개발 시작 및 간단기능 화면기획→ (4)9월 중 화면기획 완료 및 프론트개발시작 → (5)11월 1차 개발완료 및 QA진행 → (6)제품 오픈 ] 하는 것을 초기 일정으로 잡아보았습니다.
   

II. 조직이 기대하는 제품관리자란?

 
1. 경영
- 사업전략을 -> 제품전략으로 전환해서 실행하고 목표를 달성해주는 사람
- 제품을 통한 비즈니스 성공을 하게 해주는 사람
→ STUDY : 나는 기대를 충족하는가? 사실 요즘은 잘 모르겠다. 2023년 나의 주목표는 '장기적으로는 송금 기능 통합하고, 2023년은 연내에 5개 업체를 온보딩을 할 수 있도록 프로덕트 및 프로젝트를 관리하는 것'이었지만, 최근 겪는 일련의 과정을 통해 '나는 2023년 회사의 목표와 얼라인이 잘 되어 있지 않았나?'라는 의심이 마구 들고 있다.
 
2. 사업
- 사업과 제품이 따로 놀지 않고, 제품에 회사의 목표를 녹여주는 사람 
- "안돼요!"가 아니라 가능하게 하는 다른 대안을 찾아주는 사람
※ 제품관리자는 자기 제품, 유저가치 중심으로 생각하기 때문에, 사업과 회사의 목표를 무시하는 경우가 많다.
 

옛날에는 만들면 누군가 쓸것이다라는
막연한 확신으로 개발했지만,
지금은 무엇을 위해 개발을 시작했는지를
검증해야한다.

→ STUDY : 나는 기대를 충족하는가? 제품을 기획할 때 유저의 스토리와 니즈를 충분히 반영하기 위해 노력했다고 생각한다. 다만, 송금 통합이라는 큰 목표가 아니라 2023년 목표만을 본다면  유저가 필요하지 않는 기능 또는 복잡한 기능들이 많이 들어가지 않았는지 점검해 볼 필요가 있다.
 
3. 개발
- 앞에서 운전대를 잡는 사람
- 정확한 기획을 해주는 사람 < 이해관계자들과 얼라인을 잘 시켜줘서 하나의 방향을 바라볼 수 있도록 해주는 사람
- 일정에 대한 관리를 해주는 사람 
※ 일정이 계속 늘어지고, 딜레이되고 스트레스를 받으면 그때 과감하게 스펙아웃하거나, 목표를 상기시키는 등의 여러 장치를 제공하는 것이 중요하다. 여러 시도를 했음에도 성과가 나지 않는다면 개발자 역량 문제일수 있지만, 환경을 같이 만들어 나가는 역할을 해줘야한다
💌Tip. 자기가 만든 제품이 실제 시장에서 어떤 반응을 보여주고 있는지를 개발자들에게 보여주게 되면 동기부여가 된다
→ STUDY : 나는 기대를 충족하는가? 현재까지는 개발자 <-> 타부서와의 얼라인을 해야하는 기회가 없었지만 이번 조직개편으로 인해 내가 내 프로덕트에 한하여 직접 얼라인하게 될 것으로 보인다. 개발자에게 동기부여를 주는 PM이 되도록, 혹시 "시켜서 하는거에요"라는 인상이 뿜어져나오지 않게 정신차려야 겠다.
 
4. 디자이너
- 기획서 쓰는 능력 < 제품의 방향성과 우선순위를 명확하게 알려주는 사람
※ 예전에는 기획자가 기획한 것을 디자인산출만 했지만, 지금은 프로덕 디자인이 설계까지 하는 구조로 변경되고 있기 때문에 와이어프레임은 디자이너가 하고 방향성을 제품관리가 설계해준다.
ㄴ 제품관리자 : 제품전략, 문제정의, 제품지표, 제품 정책 설계
ㄴ 디자이너 : 제품 세부기획, 디자인 산출물 작업
💌 Tip. 유저 시나리오를 명확하게 정의해주고, 이 제품이 비즈니스에 어떻게 기여되는지(되어야하는지)를 설명해주는 것이 도움이 된다
→ STUDY : 나는 기대를 충족하는가? 작업 우선 순위 별로 화면을 기획하고 comm하였지만, 제품의 방향성은 충분히 설명하였는지 고민해볼 필요가 있다. 내가 관리하는 product는 디자이너가 딱 디자인만 해주고 있기 때문에 제품의 방향성에 대한 고민을 하지 않아도 되어서 설명해주지 않았었다.
 
5. 데이터 분석
- Objective (정성적인 목표)와 Key Result (정량적인 목표)를 수립해주는 사람
※ 제품관리자는 OKR를 명확하게 정의할줄 알아야한다
→ STUDY : 나는 기대를 충족하는가? 아직 일 안 해봤다!
 
6. 프로젝트 관리 (=TPM)
- 제품 지표를 정확하게 전달해줌으로써 프로젝트관리자가 우선순위를 결정할 수 있게 해주는 사람
※ 프로젝트 관리자는 제품에 대한 이해도가 낮기 때문에 제품관리자가 제품의 방향성과 지표를 전달해야한다
→ STUDY : 나는 기대를 충족하는가? 우리 회사는 프로젝트 관리를 PM과 PO가 함께 하는데, 우선순위 결정은 PO가 해줄 것으로 보인다. 나는 내 프로덕의 지표와 일정을 PO에게 공유하고 내 product의 우선순위를 다시 조정받아야 겠다.
 

III. 제품관리자의 역할 및 역량

ⓐ제품목표에 기반한 ⓑ과업의 우선순의를 결정하여, ⓒ부여된 제품개발 리소스를 활용하여, ⓓ제품기반의 비즈니스 성과를 낼 수 있는 사람

 
[제품관리자의 역할]
구분 1. 제품개발 프로세스에 따른 구분
문제정의 → 가설수립 → 가설검증 방식수립 → 유저스토리 작성 → 기능정의서 작성

제품개발 프로세스 상세

→ STUDY : 나는 역할을 수행하고 있는가? 가설수립과 검증에 대한 단계가 빠져있다. Platform & BackOffice를 기획하고 있어 놓친 부분이 있었던 것 같다. 가설을 세워 검증하는 프로세스를 '권한'과 '매출정산'에 꼭 반영해야겠다.
 
구분 2. 제품특성 - 의존성에 따른 구분
단일 도메인 : 해당 그룹 내에서 모든 문제를 해결할 수 있다
의존성이 걸리는 경우 : 도메인 간 연결이 되어 있기 때문에 제품기능 수정 시 사전 협의가 필요하다. 정치를 한다거나 감정적으로 대응하기 보다는 Dry한 방식으로 정량/정성적인 지표들에 집중해서 더 나은 선택을 하는 것이 필요하다

 
→ STUDY : 나는 어떤 구분인가? 그 구분에 맞는 역할을 수행하고 있는가? 나는 Case B에 해당한다. 의존성이 매우 높은 영역이라 PO의 역할이 매우 중요하다.
 
구분 3. 제품특성 - 고객군에 따른 구분
c2c : 데이터 분석, 가설설정 -> 검증 능력 필요. 매출담당자가 없기 때문에 제품관리자가 집객전략과 매출전략에 대한 고민이 필요하다
b2b :  b2b 서비스는 세일즈조직이 매출을 일으키기 때문에, 세일즈와 제품관리자가 떨어질래야 떨어질수없다. 그렇기 때문에 데이터만 보고 결정할수는 없다. 제품관리자도 세일즈를 통해 매출을 일으킬 수 있기 때문에 세일즈와의 네고 능력이 매우 중요하다.
amdin : 프로세스혁신이 필요하기 때문에 즉, 비즈니스 임팩트에 영향이 직접적으로 가지 않기 때문에 우선순위에 밀리는 경우가 많다. 제품관리자는 이 제품을 통해 어떤 효율이 발생했는지 지표로 설명하고 논리를 만드는 능력이 필요하다. 내부효율이 비즈니스 임팩트를 개선할 수 있다는 것을 증명할 수 있어야한다

→ STUDY : 나는 어떤 구분인가? 그 구분에 맞는 역할을 수행하고 있는가? 내 product는 내부고객이 유저이므로 '운영효율'에 집중되어야 하고, 개발 중요성을 강조하기 위해 전사가치에 어떤 임팩트를 미칠지를 증명함으로써 내 유저가 빠르게 product를 사용할 수 있도록 해줘야겠다.
 
구분 4. 제품특성 - 도메인에 따른 구분
서비스 : 유저, 시장을 잘 알아야함
코어 : 스펙 관리. 꼼꼼함. 데이터 신뢰성. 영향도 파악능력.

→ STUDY : 나는 어떤 구분인가? 그 구분에 맞는 역할을 수행하고 있는가? 나는 코어 시스템을 기획하고 있다. 데이터 기반의 정책을 기획하고 있고, 한 필드가 변경됨으로써 어떤 영향을 미칠지 꼼꼼하게 검토하고 있다. 즉, 잘 수행하고 있다.
 
[제품관리자의 필요역량]

 
 
[제품관리자가 겪는 애로사항]
1. 제품과업에 대한 자유도 (전달자 역할만 한다고 느껴짐)
 - "위에서 하래요. 나도 이거 왜하는지 모르겠어요" 이런말 하면 내 말에 힘이 안 실린다. 즉, 제품관리자의 역할이 축소된다.
- 경영자는 목표만 주고, 그걸 제품관리자가 재해석해서 Task를 만들어내야하는데 경영자가 Task까지 주면 제품관리자는 전달자가 되는것이다.
 
2. 제품설계에 대한 오너십
- "유저스토리 구상을 누가 하는가? 디자이너? 나?", "데이터 흐름까지 내가 짜? 개발자가 해줘야해?"
- 킥오프 같은 단계에서 업무 방식을 정교하게 잘 정리하고 얼굴을 붉히더라도 R/R 명확하게 해야함. 그때 안하면 나중에 개발하다가 사람들 다 나감
 
3. 모두 관여해야함
- 매뉴얼, 이미지, 등 이것저것 다 해야하는 상황 발생. 예, 다른 팀에서 제품의 스펙을 제대로 모르니까 그걸 나한테 다 해달라고 하는 상황
- 처음에는 어쩔 수 없지만, .. 개발 배포 전에 데모데이 같은걸 하면서 이해관계자들이 제품을 이해할수있도록 하는 장치가 필요하다
- 문제가 발생했을 때 에스컬레이션하는 방법과 익숙해질때까지 내가 양보해서 해주는 방법이 있다
 
4. 사업부서 담당자와 R&R 모호
- '시키는대로 만들기만 하는 사람이야?'라는 고민 생김
- 매출과 직접적으로 연계되는 제품은 사업의 영향이 클 수 밖에 없다
- 양쪽의 입종 이해가 필요하다
- 제품 관리자는 사업과 개발 사이에서 둘과 커뮤니케이션한다. 이 말은 제품관리자는 제품의 공정을 잘 알고 있기 때문에 사업에는 사업이 이해할 수 있는 용어로 설명할 수 있고, 개발자들에게는  개발이 이해할 수 있는 방식으로 잘 설명하는 것이 능력이다.
 
5. 논리 구성이 어려움
- "이래이래서 개발해야해요". 라는 논리를 증명할 수 있는 정량적인 지표가 없는 경우도 있음
 
→ STUDY : 내가 겪어본 애로사항이 있는가? 나는 어떻게 해결했는가? 2번, 3번, 5번의 문제가 있다. 2번은 부서 대 부서로 정리가 얼추되고 있는 상황이며 상위 레벨에서는 동의가 끝난것으로 보인다. 3번은 2번으로부터 파생되는 문제라 2번이 해결되면 자연스레 해소되지 않을까 한다. 또, 나는 내부 운영효율을 돕는 Product을 기획하고 있는데 내부 운영효율을 높이는 것을 증명하는 것은 쉽지 않다. 그럼에도 5번의 경우 법적인 이슈 방어가 가능하고 향후 데이터 분석을 해야할 때 꼬임없이 세세한 정보를 줌으로써 명확한 분석이 가능하도록 한다는 점을 강조해야겠다.
 

III. 제품이해관계자의 이해

제품이해관계자의 역할을 왜 이해해야하는가?
제품 관리자는 결국 다른 사람을 통해 성과를 내는 사람이므로 알아야한다.
 
[제품조직 내 이해관계자]
디자이너 : 제품을 기획하는 것 자체에 대한 협업을 한다. 예전에는 제품관리자가 다 했지만, 이제는 디자이너가 제품기획까지 함께 한다
개발자 : 중요한 역할을 하는 사람들이다. 샤이한 사람들이 많고 소통하는 것보다는 서류/문서로 업무하는 것을 좋아하기 때문에, 정리를 잘해주는 것이 필요하다. ※ QA와 개발자가 싸울때 중간에서 해결해주는것도 제품관리자의 역할이다
QA : 기획의도를 모르는 경우 단순히 오류만 발견하려고 할 수 있기 때문에, 최초 설계 단계에 QA와 함께 협업하면 좋다
데이터 분석가 : 기획의도를 정략적인 지표로 만드는것까지가 제품관리자의 역할이다. 제품관리자가 그 지표를 줘야 데이터 분석가가 그 기준에 따른 모니터링, 의사결정체계 수립을 할 수 있다

→ STUDY : 나는 어떤 관계자들과 협업해보았는가? 나는 현재까지는 디자이너와 개발자와만 협업을 해보았다.
 
 
[제품조직 외 이해관계자]
사업 : 사업은 유저&매출 중심이기 때문에, 제품관리자는 이 제품이 "유저의 어떤 문제를 해결하는지"를 정의해주는 것이 필요하다.
💌 Tip. 고객의 지불의지를 끌어내는 기능은 BD와 협업해야 수월하다
영업 : 무기가 될 수 있는 기능을 잘 전달하는 것이 중요하다. 한 영업팀 안에서도 고객사의 우선순위가 다를 수 있기 때문에 우선순위를 세워서 제품관리자에게 전달해달라고 해야한다. 
마케터 : 성장(growth)시키는 것이 목표인 관계자들이기 때문에 마케팅관련 기능을 개발해달라고 하는 경우가 많다. 물러서지 않는 경우가 많은데, 유저에게 먹힐만한 스토리를 기반으로 어떤 가치를 만들어낼수 있는지에 집중해서 협업하는것이 필요하다
운영&CS : 제품관리자는 '긍정적'인 유저스토리를 집중하는 반면 운영자는 VOC를 많이 듣기 때문에 '부정적'인 유저스토리에 집중한다. 이 중간을 잘 맞춰서 협업하는것이 중요하다. 
Tip. 운영&CS와 comm할때는 "당신들의 업무가 비즈니스를 이렇게 개선할 수 있어요"라는 것을 보여주는 것이 좋다
 

→ STUDY : 나는 어떤 관계자들과 협업해보았는가? 나는 사업개발, 세일즈, 오퍼레이터와 협업해보았다.
 
 
Self 결론

• 여러 자료에서는 서비스기획자와 PM의 차이를 조직의 형태(목적,기능)에 따라 구분하기도 하지만 패스트캠퍼스 강사의 내용과 배민PM 자료들을 보고 드는 생각은 '아 PM은 사업기획의 업무 일부와 + 서비스 기획 업무의 일부가 합쳐진 포지션을 뜻하는구나?' 라는 결론을 스스로 내려봤습니다.