프로덕트 매니지먼트도 종합 예술

프로덕트 매니지먼트

프로덕트를 이해하는 자가 프로덕트를 지배한다

저자: 김영욱 / 한빛미디어 / 2023/06/08

https://www.hanbit.co.kr/store/books/look.php?p_code=B8246471071

 

프로젝트 관리(Project Management)는 친숙한 업무이지만, 프로덕트 관리(Product Management)는 다소 생소합니다. 국내 IT 업계에서 외산 솔루션은 흔해도 국산 솔루션은 드문 편입니다. SI(System Integration, 시스템 통합) 프로젝트로 개발한 시스템에 비해 국산 솔루션은 참 적습니다. 그렇다 보니 프로덕트로서의 소프트웨어 솔루션을 개발하고 운영하는 업무는 특이할 게 없는 듯하면서도 막상 하려고 들면 백지 상태인 부분이 많을 겁니다. 국산 솔루션이 이미 많다는 반론이 있을 수도 있습니다. 만약 솔루션 개발사가 고객사마다 커스터마이징하여 고객 별로 버전 관리를 하고 있다면 그건 솔루션이 아닙니다. 그냥 SI로 만든 겁니다. 제니퍼 소프트(https://jennifersoft.com/ko/product/)처럼 해야 전세계 어디에서든 솔루션이라 할 만하지 템플릿 수준의 코드 덩어리는 솔루션이 아닙니다. 다시 말해 개발사가 관리해야 할 프로덕트가 아닙니다.

 

제품이 생명을 다할 때까지 기능 로드맵을 수립하고 버전을 관리하며 개발과 출시를 반복하는 프로덕트 관리 업무는 종합 예술입니다. 마케팅(홍보 말고), 프로젝트 관리, 애자일 개발, 고객 관리 등 상당히 많은 일을 합니다. 조직 규모에 따라 맡은 업무 가지수가 더 늘어나기도 하고 의사결정 상당 부분에서 따르기만 하기도 합니다. 현장에서 떠난 적 없을 저자는 이 책에서 프로덕트 관리에서 보편적인 부분과 전반적인 부분을 다룹니다. 10년차 정도 필드에서 구른 사람이라면 이 책이 다루는 이야기 태반은 낯설지 않습니다. 그래도 프로덕트 관리 업무를 처음 맡게 된다면 기술적인 사안보다는 소통과 조율에 해당하는 업무로 크게 어려움을 겪을 텐데, 이 책이 체크리스트로서 효용을 발휘할 거라고 기대합니다.

---

반응형

Chapter 1 프로덕트 매니지먼트란 무엇인가?

1.1 프로덕트 정의

1.2 PM 정의

1.3 B2B와 B2C

1.4 프로덕트 매니저, 프로젝트 매니저, 프로그램 매니저는 어떻게 다른가?

1.5 글로벌 기술 기업의 조직 구조 이해하기

1.6 프로덕트 리더십 팀의 역할과 책임

1.7 PM과 PO의 차이

 

Chapter 2 프로덕트 라이프 사이클, 프로세스와 프레임워크

2.1 프로덕트 라이프 사이클 4단계

2.2 프로덕트 개발 라이프 사이클 7단계

2.3 프로세스와 프레임워크

(1) 짧고 빠른 주기에 작은 단위로 시행착오를 경험해야 큰 사고를 치지 않는다.

(2) 반드시 팀 업무 진행 상황의 정기적인 리뷰를 하자.

(3) 각 그룹의 책임 매니저는 중요 미팅에 반드시 참석하여 진행상황을 충실히 파악하되, 업무 결정은 팀이 하도록 권한을 부여하며 성과가 좋은 프로세스는 공유하여 조직 역량을 끌어 올린다.

(4) 애자일, 린 스타트업, 디자인 씽킹의 교과서적 원론에 매달리지 말라.

(5) 팀이 테스트, 시도, 베스트 프랙티스를 통해 자율적으로 업무 결정을 하도록 권한을 부여한다.

(6) 커뮤니케이션은 투명하게 하자.

(7) 회고 결과는 긍정적으로 피드백하고, 절대 경쟁적인 요소로 사용되지 않게 한다.

(8) 팀원 전원이 동의하는 진행 지표를 정하자.

(9) 고객을 업무 프로세스와 프로덕트 중심에 두자. 팀은 고객의 필요사항과 애로사항을 해결하는 데에 집중하며 서로 경험을 공유하고 협업한다.

 

Chapter 3 고객 개발

3.1 고객 개발이란? 

3.2 사용자 스토리로 문제 가설 세우기 

3.3 고객 설문 조사 116

3.4 순고객추천지수 조사 118

3.5 고객 인터뷰

 고객 개발의 4단계: 발견(discovery), 검증(validation, 사업 가능성 증명), 창출(creation, 제품 수요 증가), 구축(building, 조직으로서 사업 수행) - 제품수명주기(PLC) 모든 단계에서 동시에 진행해야 한다.

 사용자 스토리: 매니저, 사용자, 영업대표로서 작성해본다.

 

Chapter 4 프로덕트 전략과 로드맵

4.1 사용자 필요성 

4.2 경쟁 

4.3 경쟁자 평가를 위한 다섯 가지 방법 

4.4 이기는 전략

4.5 전략 만들기 

4.6 엘리베이터 피치 프레임워크 

4.7 로드맵

 아이디어는 EMUC로부터: Employee, Metrics, Users, Customers(B2B, B2C)

 하향식 시장규모 정하기: 전체 시장 크기를 초깃값으로 설정하고 내 제품의 점유율을 추정하는 낙관적 접근법

 상향식 시장규모 정하기: 유사 상품의 현재 매출 기반 및 청구 가능한 판매 금액을 추정하는 보수적 접근법

 Guesstimation: 논리적 사고를 통한 추산

 전략이란: 기능 리스트가 아니다. 비밀문서가 아니다.

 프로덕트 전략이 갖출 선택사항: 개발할 프로덕트, 시장 부문 및 카테고리, 차별화 방법, 가격 정책, 포지셔닝과 커뮤니케이션

 엘리베이터 피치 프레임워크: [문제]를 가진 [고객]을 위한 [제품]은 [특장점, 가치]를 가진 [카테고리, 분류]다. [경쟁제품]과는 달리 [차별점]을 지녔다. (AWS 및 Netflix의 elevator pitch 참고)

 

Chapter 5 PM의 일상 업무

5.1 와이어프레임, 프로토타입, 목업 

5.2 프로덕트 백로그, 에픽, 사용자 스토리 

5.3 속도와 번 다운 차트 

5.4 우선순위 정하기

5.5 MVP

 워킹 스켈레톤: 실제로 실행 가능한 최소화 프로덕트. end2end를 개발해야 하므로 초기 개발에 시간 소요.

 RICE: Reach(직접적인 사용자 수), Impact(영향도), Confidence(PM이 추정하는 혜택에 대한 신뢰도), Effort(팀원이 들여야 할 공수)

 MVP: 고객과 시장이 가정한 대로 실제로 행동하는 알아내고자 사용하는 실험 도구.

 

Chapter 6 능력 있는 PM 되기

6.1 제품 시장 적합성 

6.2 지표 

6.3 OKR과 KPI 

6.4 주의해야 할 네 가지 편향적 의사결정

6.5 좋은 PM에게 협업이란 

6.6 PM/PO가 되고 싶다면?

 PMF(Product Market Fit, 제품 시장 적합성) 달성: 처음부터 시장의 요구를 검증하고, 고객과 자주 대화하며, 초기부터 딜리버리 채널을 확보한다.

 PMF framework: (1) 비즈니스 모델링  (2) 시장 검증  (3) 고객 인터뷰  (4) 제품 개발 및 고객 확보  (5) 제품 분석(고객은 정말 우리 제품을 사용하는가?) ← 반복

 AARRR framework: 획득(Aquisition, 사용자 확보 지표), 활동(Activation, 사용자 경험도), 유지(Retention, 고객 충성도), 매출(Revenue, 고객의 비용지불 여부 확인), 추천(Refferral, 고객이 다른 고객에게 소개할 것이 정도 평가)

 굿하트의 법칙(Goodhart's law): 측정치가 목표치가 되는 즉시 그 측정치는 지표로서의 가치를 잃는다.

 좋은 지표의 조건: 이해할 수 있고, 비율로 표현 가능하고, 상관관계가 있으며, 변경 가능하다. (소셜미디어 팔로워 수보다는 참여율, 이메일 구독자 수보다는 구독 신청률 등)

 HEART framwork: Happiness(행복, 사용자 행복도), Engagement(참여, 사용자 참여도), Adoption(도입, 얼마나 많은 사용자가 제품을 사용했는가?), Retention(유지, 사용자가 재방문하는가?), Task success(작업 성공, 사용자가 제품으로 하는 가장 중요한 일은 무엇이며, 실제로 작동하는가?) ← 실제 실행은 ATERH 순

 OKR(목표 및 핵심결과)의 특성: 항상 수량화/정량화가 가능하고, 0/1 상태 혹은 0~100 같은 척도로 점수 부여가 가능하며, 명확한 타임과인과 매우 공격적인 달성 목표를 설정해야 한다.

 You are not your user. 사용자는 너처럼 생각하거나 사용하지 않는다.

 PM은 답할 줄 알아야 한다: 해결하려는 진짜 문제는? 고객과 비즈니스에 왜 중요한지? 진행 중인 다른 모든 중요한 작업과 비교하면 어떤 차이가 있는지? 이것의 우선순위가 높다면 다른 어떤 것의 우선순위를 낮게 조정할지? 작업이 성공했는지 어떻게 아는지? 이 기능을 출시하지 못할 때 생기는 최악의 상황은? (이 기능을 미뤄도 되는지?) 이것을 릴리즈하려면 구체적으로 무엇을 어떻게 해야 하는지?

 PM이 마감일을 언급해야 할 때: 쉬운 일이라고 하지 말고, 견적 범위를 검토하고 조정할 시간과 권한을 부여하며, 작업예상치가 높으면 업무범위를 합리적으로 줄일 방법을 찾는다.

 PM의 덕목: 사용자/고객/비즈니스 이해(프로덕트 직접 사용/테스트), 프로덕트를 함께 만드는 관계자와 비전 공유, 유용성을 부단하게 탐구, 전략적 사고(차선책, 전문가/담당자 의견 청취), 업무 우선순위 설정(보수적 결정, 위험 관리)