사람들이 싫어하는 네 가지 PM 유형
프로덕트 매니지먼트에서 뽑은 205개의 핵심 파트 (2)
앞선 글에 이은 프로덕트 매니지먼트 핵심 파트 요약 두 번째 글이다. 후반부를 요약한 글인데, 해당 부분에서는 PM이 협업할 때 피해야 할 주의 사항 4가지 부분이 가장 핵심적으로 다가왔다. 실제로 PM을 하면서 내가 의식적으로든, 무의식적으로든 해당 유형의 행동을 했는지를 돌이켜보면서 읽을 수 있었다.
책에서도 말하는 것이지만, PM에 관한 지식을 익힌다고 해서 PM을 바로 잘할 수는 없다. 매일매일 우선순위와 사람들과의 커뮤니케이션과 전문 지식 사이에서 이리저리 치이면서 몸으로 겪어야 조금이라도 잘할 가능성이 생긴다.
실제로 PM을 하고 있지만, PM은 취업 광고에서 말하는 것처럼 멋있고 연봉 높은 직무가 아니다. 오히려 많은 사람들과 함께 많은 일을 해야 하는, 매일매일이 어렵고 힘든 직무다. 그 어렵고 힘든 길을 걷고 이렇게 좋은 책을 쓴 저자에게 감사와 응원의 박수를 보낸다. 이런 선구자들이 있었기에 후배 PM들이 조금이나마 시행착오를 덜 겪을 수 있지 않을까 생각한다.
* 프로덕트 매니지먼트는 내돈내산은 아니다. 한빛미디어에서 리뷰 요청과 함께 책을 보내주셨다. 받은 책이라고 해서 특별히 더 좋게 쓴 부분은 없다. 이전에 쓴 여러 글처럼 좋다고 생각한 부분만을 편집하고, 요약했다.
4. 프로덕트 전략과 로드맵
사용자 필요성
유효한 아이디어인지 검증하기
1. PM이 된다는 것은 처음에 생각했던 아이디어의 문제를 찾는 것이 아니라 문제에 대한 솔루션을 찾는 것이다. 어떤 요청이나 기능 아이디어가 주어지면 가장 먼저 세 가지 질문으로 검증해야 한다.
실제 문제를 해결하고 있는가?
기능을 구현하고 구조를 변경하는 데 부작용은 없는가?
요청의 핵심 문제에 도달하고 실제 문제가 무엇인지 이유를 세 번 이상 물어보고 고민했는가?
2. PM 역할은 아이디어가 주는 요청을 듣는 것뿐만 아니라 요청 뒤에 숨겨진 진정한 고통을 찾는 것, 요구하는 진짜 이유가 무엇인지 찾는 것이다. 가장 쉬운 방법은 겸손한 태도를 유지하며 계속 이유를 묻는 방법이다.
경쟁
3. 시장 규모를 추정하는 방법은 여러 가지다. 가장 중요한 첫 번째 단계는 시장을 정의하는 것이다. 시장을 정의하는 기준이 되는 변수는 다음의 세 가지다.
목표 사용자
구매자
시장 범위
4. PM이 각 이해관계자와 일할 때 가장 큰 자산은 신뢰감이다. 제품이나 서비스가 속한 거대한 시장이 아니라 내 제품의 시장에 초점을 맞추는 것이 중요하다.
시장 규모 정하기
5. TAM(전체 시장)은 제품과 서비스의 총 시장 규모를 말한다. SAM(유효 시장)은 TAM의 하위 세그먼트다. SAM은 제품이 실제 판매 가능한 시장이어야 한다. SOM(수익 시장)은 실제 수익을 만들 수 있는 가장 보수적인 크기의 시장이다. SOM은 얼마나 많은 수익을 창출할 수 있는지에 대한 매우 현실적인 평가 수치다.
6. 하향식 접근 방법. 더 큰 시장에서 찾을 수 있는 모든 데이터로 시작해 하위 세그먼트로 내려간다. 하향식 방식은 전체 시장의 크기를 초기치로 잡고 아래로 계산해 나가는 방법이다. 전체 시장 크기에서 우리 제품이 얼마나 차지하는지 계산하면 규모를 추정할 수 있다. 매우 낙관적인 접근법이다. 제품 가격에 근거한 방법이 아니며 전체 시장 가격부터 시작하기 때문이다.
7. 상향식 접근 방법. 하향식 방식에 반해 상향식 방식은 최종 단가부터 계산해 전체 시장 크기를 계산하는 방법이다. 비슷한 프로덕트의 현재 영업 상황을 기초로 가격과 시장 크기를 계산한다. 그 후에 얼마나 해당 시장이 매력적인지 다가가는 보수적인 접근법이다. 계산하는 방식에서 하향식 방식보다 노력과 시간이 좀 더 걸리지만 더 정확한 계산이 가능하다는 장점이 있다. 상향식 방식은 소규모의 전문화된 고객층에게 판매할 때 가장 효과적이다.
네 가지 유형의 경쟁자
8. 첫째, ‘직접 경쟁자'다. 동일한 대상의 고객 그룹을 추구할 뿐만 아니라 해결하고자 하는 동일한 문제의 해결 방법을 갖고 제품과 서비스를 출하하는 경쟁자다. 둘째, ‘간접 경쟁자'다. 해결하고자 하는 동일한 문제를 다른 방식으로 대상 사용자 그룹에 제공하는 경쟁자다. 셋째, ‘잠재 경쟁자'다. 동일한 목표 대상 사용자 그룹 또는 유사한 대상 사용자 그룹에 해결책을 제공하지만 우리가 제공하는 것과 같은 동일한 문제를 해결하지 않는 경쟁자다. 넷째, ‘대체 경쟁자'다. 우리가 제공하는 해결 솔루션과 같은 문제를 해결한 제품이지만 동일한 고객층을 대상으로 하지 않는 경쟁자 유형이다.
경쟁자 평가를 위한 다섯 가지 방법
9. PM으로 성공하는 데 가장 큰 부분을 차지하는 것은 경쟁 업체를 주시하고 무엇을 할 것인지를 알아내 경쟁에서 앞서는 방법을 찾는 것이다.
10. 경쟁 업체를 이해하는 데 절대적으로 중요한 다섯 가지 기준을 알아보자. 첫 번째는 ‘프로덕트 핵심’이다. 프로덕트 핵심은 프로덕트팀을 의미한다. ‘누가 그 프로덕트를 만들고 있는가'다. 어떤 레벨 어느 정도의 엔지니어인지 알아내는 것이 첫 번째 평가 기준이 된다.
11. 두 번째 기준은 경쟁 프로덕트의 사용자 규모를 아는 것이다. 대규모 사용자 기반이 있다고 반드시 더 나은 프로덕트를 더 빨리 구축할 수 있다는 의미는 아니다. 하지만 꽤 중요한 경쟁 포인트다. 사용자 기반이 크면 새로운 제품/기능을 출시하거나 새로운 시장에 진출할 때 기존의 사용자 기반으로 많은 사람을 쉽게 끌어들일 수 있어 시장을 지배할 가능성이 높다.
12. 세 번째 기준은 브랜드다. 추상적인 것으로 생각할 수 있지만 실제 효과는 굉장하다. 사람들이 가진 브랜드와 판매하는 프로덕트 이미지가 미래에 무엇을 할 수 있는지 결정할 수 있다. 강력한 브랜드는 훨씬 더 높은 수준의 고객 충성도를 요구한다. 충성도는 새로운 시장이나 새로운 계획에 착수할 때 많은 고객이 함께하도록 할 수 있다.
13. 네 번째 기준은 디자인이다. 미학적으로 아름다운 프로덕트를 만드는 능력을 의미한다. 많은 사람이 잘 설계된 프로덕트를 좋아하는 경향이 있다.
14. 마지막 기준은 속도다. 새로운 프로덕트나 기능을 작업할 때 경쟁자보다 얼마나 더 빨리 제품을 출시할 수 있는지에 관한 것이다. 빠른 결정을 내리는 것이 아닌 올바른 결정을 빠르게 진행하자는 것이 목적이다. 그렇게 할 수 있는 능력을 가진 팀이 경쟁에서 우위를 점한다.
이기는 전략
전략이란
15. 전략이란 프로덕트 기능 세트, 즉 프로덕트에 들어가는 기능의 집합이 아니다. 전략은 여러 개의 옵션 중에서 비즈니스 목표를 달성하기 위해 ‘선택'을 하는 것이다.
16. 전략이나 로드맵은 각 이해관계자 의견과 요청, 요구, 불만 사항을 정렬하고 커뮤니케이션하는 것이 핵심 원칙이다. 전략은 의견 및 불만 사항 등을 전달했을 대 조직 구성원들의 행동과 업무에 변화가 일어날 때만 유효하다.
17. 전략이 제대로 동작하려면 조직에 속한 사람들의 행동에 변화가 생겨야 한다. 내가 무엇을 위해 어떤 것을 해야 하며 동료와 함께 어떻게 이뤄내야 하는지 생각해야 한다. 전략은 우리가 원하는 비즈니스 목표나 성과에 도달하고자 방법을 찾는 창의적인 연습이다. 그 과정에서 여러 가지 옵션이 있을 수 있다. 어떤 것을 선택하든 목표에 일관성을 가져야 한다.
프로덕트 전략의 다섯 가지 요소
18. 프로덕트 전략은 기업이 해당 제품을 통해 설정한 목표를 달성하는 선택 과정이다.
19. PM처럼 생각의 중심에 전략이 있는 사람들은 조직 내에서 해당 프로덕트 전략의 중심축 역할을 한다. PM만 전략을 만든다는 의미는 아니다. 오히려 많은 사람이 전략에 참여할 수 있어야 하며 독려해야 한다.
20. PM은 실제 전략이 만들어질 때까지 이해관계자 의견을 정렬하고 균형 잡힌 결과물이 나와 이해도 높은 문서의 형식으로 커뮤니케이션 되기까지 모든 과정을 책임지고 이끄는 역할을 한다. 주요 이해관계자가 전략이 의미하는 바를 이해하고 실현할 때 자신의 역할을 할 준비가 됐는지 정기적으로 확인해야 한다. 잘 동작하지 않을 때 다시 원점으로 가져와야 하는 사람이 바로 PM이다. 모든 과정이 PM을 전략의 중심축이라고 이야기한다. 힘든 작업이지만 결정적으로 중요한 역할을 한다.
21. 프로덕트 전략에서 꼭 갖춰야 할 다섯 가지 선택 사항이 있다.
개발할 프로덕트
시장 부문 및 카테고리
차별화 방법
가격 정책
포지셔닝과 커뮤니케이션
22. 명확한 전략을 세우고 열정적으로 지키는 것만으로는 기업과 프로덕트가 성공할 수 없지만 좋은 일이 생기기 시작할 가능성은 훨씬 더 높아진다. 먼저 목표를 이해해야 전략을 세우고 파악할 수 있다. 일단 이 과정이 끝나면 실행에 집중하고 모든 일이 이뤄지도록 조직을 배치해야 한다.
전략 만들기
23. 전략을 정의하고 일관되게 따를 수 있도록 하는 방법에는 두 가지가 있어야 한다. 강한 신념과 매니지먼트 기술이다. 일관성 있고 효과적인 프로덕트 전략을 명확히 하는 데 필요한 기술은 비즈니스, 운영 및 마케팅에 이르기까지 다양한 분야에 걸쳐 있다. 시장 역학을 이해하며 다양한 플레이어가 제공하는 프로덕트와 서비스를 계획하고 어떤 기술이 가능하게 하는지 이해해야 한다. 또한, 재정적 요인을 분석하고 릴리스 방식을 정의하며 우선순위를 지정하고 선택 사항을 그룹 내 조직원에게 명확하게 커뮤니케이션할 수 있어야 한다.
24. 적절한 기술을 보유하는 것만으로는 일관되게 전략을 추구할 수 없다. 명확한 경로를 계획하는 것은 중요하지만 시간이 지나면 유지하는 것은 완전히 다른 도전이 된다. 현실은 계획된 경로에서 쉽게 벗어날 수 있는 압력과 유혹, 주의를 산만하게 하는 뉴스로 가득하다. 장기적으로 가치 창출을 하는 제품을 만들려면 전략의 중요성과 힘에 대한 확고한 신념이 있어야 한다. 전략을 개발하는 데 필요한 기술과 적극적으로 추구하려는 신념을 함께 갖춘 PM 역할이 절대적으로 필요하다.
25. 좋은 프로덕트 전략은 일곱 가지 조건이 있다.
목표를 달성하는 방법을 보여준다.
성공하는 데 필요한 것을 설명한다. 여러 선택 사항 중 비즈니스 목표를 달성하고자 어떤 최선의 선택을 해야 하는지 알려준다.
성공에 영향을 미치는 요소를 고려한다. 시장 동향, 경쟁자와의 역학 관계 및 성공 가능성에 영향을 줄 수 있는 기타 요소도 모두 고려한다.
경쟁 우위를 설명한다. 사용자나 고객이 다른 대안보다 우리 프로덕트를 선택해야 하는 이유를 설명한다.
결정을 내리는 데 도움이 된다. 앞으로 만나게 될 어려움을 이겨내고 제품이 성공할 수 있는 이유도 설득력 있게 주장한다.
무엇을 할지 하지 않을지 결정하는 데 도움이 된다. 어떤 선택이 올바른 방향으로 이끄는지에 대한 투명한 관점을 제공한다.
이해관계자들과 합의를 이룬다.
26. 신뢰감 있는 전략은 진행 상황을 정확하게 측정할 수 있어야 한다는 점이다. 비즈니스 목표에 대한 진행 상황을 나타내는 지표를 정하고 면밀히 모니터링한다. 좋은 전략은 비생산적인 논쟁을 피하고 마찰을 줄인다. 이를 달성하려면 모든 이해관계자가 전략을 이해하고 동의해야 한다. 이해관계자를 설득하고 정렬시켜 한 방향을 보게 만드는 것은 PM의 중요한 역할이다.
엘리베이터 피치 프레임워크
27. 전략을 명확히 하는 유일하고 올바른 방향은 없다. 대신 전략의 세부 사항을 구체화해 고려할 사항이 모두 포함됐는지 확인하는 것이 중요하다.
28. 전략을 문서화하는 방법에 관계없이 전략 자체는 간결하고 명확하게 핵심만 한두 문장으로 요약해 설명할 수 있어야 한다. 그렇게 할 수 없다면 중요한 사항을 파악하지 못했거나 주요 선택을 피하고 있다는 의미다.
29. 대상 사용자는 전략을 정당하게 만드는 EPF의 첫 번째 공백이다. 다른 모든 것은 첫 번째 선택에 따라 달라질 수 있다. 가장 중요한 첫 번째 열쇠다. 누구를 위해 프로덕트를 구축하느냐만큼 중요한 전략적 결정은 없다.
30. 고객 요구는 매우 실제적이고 구체적이어야 하며 프로덕트는 고객 요구를 해결해야 한다. 고객이 가진 문제는 엄청난 기회 가치가 된다. 결국 제품 솔루션은 실제 문제를 해결하거나 요구 사항을 충족해야 한다.
31. 고객의 요청 사항은 제품 기능과 다르다. 제품 기능은 제품이 할 수 있는 일, 즉 제품 사양이다. 고객의 요청 사항이나 문제점은 제품이 사용자를 위해 만든 기능으로 요청 사항을 해결하는 것을 의미한다. 고객은 프로덕트 ‘기능'을 구매하는 것이 아니다. 기능을 통해 얻을 수 있는 ‘이점’을 구매하는 것이다. 기능을 설계하고 개발하기 전에 프로덕트가 만들어낼 수 있는 이점을 명확히 해야 한다.
로드맵
로드맵은 왜 필요한가?
32. 프로덕트 로드맵은 비즈니스 목표와 프로덕트 전략을 지원하고 프로덕트 개발을 가시화한다. 실행 결정을 내리고 중요한 질문에 답하는 핵심 요소가 된다.
33. 경험할 수 있는 가장 큰 혼란 중 하나는 프로덕트 로드맵을 개발 팀에서 사용하는 릴리스 플랜과 헷갈린다는 점이다. 릴리스 플랜은 프로덕트 로드맵 안의 한 부분일 수는 있지만 전체 로드맵을 말할 수는 없다.
34. 프로덕트 로드맵은 프로덕트와 관련된 모든 이해관계자가 업무 계획을 조정하는 데 필요한 정보를 제공하는 장기 프로덕트 개발 계획이다. 프로덕트의 모든 이해관계자가 자신의 미래 업무 활동을 계획하고 조정할 수 있다는 것은 기업에서 매우 중요한 일이다. 이는 프로덕트 로드맵이 프로덕트 개발 프로세스에 예측 가능성을 제공해 조직을 정렬시킨다는 것을 의미한다.
프로덕트 이해관계자
35. 프로덕트 개발의 영향을 받게 될 조직 내부 및 외부의 다양한 프로덕트 이해관계자는 누구일까? 첫째, 무엇보다 중요한 고객(사용자)이다. 둘째, 영업, 마케팅, 고객 지원이나 GTM 같은 고객 대면 그룹이다. 셋째, 프로덕트 로드맵으로 미래 수익 및 비용을 추정하고 재정 투자, 고용 계획을 포함해 팀에 할당할 리소스 수준을 결정하는 투자자, 이사회 또는 경영진이 될 수 있다. 넷째, 프로덕트 개발 팀에 있는 아키텍트, 엔지니어 및 디자이너다.
로드맵 템플릿
36. 주요 이해관계자에게 승인받고 지원을 약속받는 것보다 중요한 문서 형식은 없다. 세상에서 가장 아름다운 프로덕트 로드맵도 이해관계자가 동의하지 않는다면 가치 없는 것이 된다. 로드맵 목적은 고객을 포함한 각 프로덕트 이해관계자가 해당 프로덕트 개발 계획을 중심으로 업무를 조정할 수 있도록 ‘정렬'하게 하는 것이다. 각 마일스톤은 비즈니스에 상당한 영향을 미칠 의미 있는 새로운 기능 세트가 포함된 패키지 형태여야 한다.
프로덕트 로드맵 vs. 프로덕트 백로그
37. 프로덕트 백로그는 제품 개발 작업의 우선순위를 정해놓은 리스트 집합이다. 프로덕트 로드맵은 프로덕트 이해관계자가 자체 계획을 조정하는 데 필요한 정보를 제공한다는 점이다. 프로덕트 백로그는 개발 프로세스에 초점을 맞췄을 뿐이다.
38. 고객, 마케팅 그룹, 재무 그룹 같은 이해관계자는 새로운 고객, 새로운 마케팅 활동 또는 새로운 수익을 가져올 마일스톤에 관심이 있다. 마일스톤은 로드맵에서 고객에게 제공하는 제품의 출시 시기를 말한다. 반면 제품 백로그는 사용자 스토리나 버그 같은 작업으로 가득 차 있다. 백로그는 개발 프로세스 내에서 예상 릴리스 날짜를 제공하기 위한 것이다. 또한, 백로그는 버그, 제품 유지 관리 작업, 엔지니어링 중심 작업 등 다양한 유형의 항목이 포함되지만 프로덕트 로드맵에는 새로운 기능만 포함된다.
로드맵 목적과 성공 및 실패 이유
39. PM으로서 제품을 성공시키려면 협상과 정렬은 가장 중요한 덕목 중 하나다. 이해관계자와의 정렬 자체가 실제 로드맵 목표라는 사실을 잊지 말자.
40. 프로덕트 로드맵이 성공하려면 다음의 세 가지 요소가 반드시 필요하다.
건전하고 성취 가능한 비즈니스 목표와 프로덕트 전략을 기반으로 해야 한다.
현실적이어야 한다.
주요 프로덕트 이해관계자가 지원해야 한다.
41. 훌륭한 PM을 꿈꾼다면 리더의 직관이 좋더라도 로드맵 변경을 지시하지 않도록 하는 것이 매우 중요하다. 이를 해결하는 세 가지 방법이 있다. 첫째, 리더의 에너지를 성공적인 로드맵으로 변환시킬 수 있는 프로세스에 집중한다. 리더 의견이나 제안이 통과하고 승인받을 수 있는 프로세스를 만들어야 한다. 둘째, 리더의 직관이 잘못됐을 수 있다는 가정과 의심을 멈추지 않는다. 셋째, 리더와 시간을 보내고 아이디어를 묻고 의견을 말한다.
마일스톤 만들기
42. 로드맵에서 가장 큰 영향력을 가지는 것은 개발 능력이다. 해당 수치에 따라 모든 이해관계자의 일정이 조정되고 정렬된다. 첫 번째로 할 일은 프로덕트 개발 리더와 협업하는 것이다. 팀의 개발 능력에 대한 현실적인 추정이 필요하다. 일반적으로 개발자 시간 단위로 측정한다.
43. 다음으로 프로덕트 개발 리더와 해야 할 일은 각 마일스톤에 소요될 개발 시간을 추정하는 것이다. 스프레드시트에 해당 정보를 기록하는 것이 좋다. 마일스톤은 일반적인 백로그 작업보다 훨씬 더 크고 복잡하다. 프로덕트 개발 리더가 가장 먼저 범위를 추정하는 것이 상당히 어렵다. 시도하는 것을 꺼릴 수도 있다. PM은 개발 리더에게 추정치를 약속받는 것이 아니라 최선의 추측을 요청하고 있다는 점을 주지 시킨다. 혹은 문서 상단의 숫자는 시간 추정치일 뿐이며 변경될 수 있다는 사실을 공유하는 모든 이해관계자에게 상기시키는 것이 좋다.
44. 범위를 지정한 후 일부 마일스톤이 너무 작으면 개별적으로 로드맵에 나열하기보다 전략의 일부 요소를 지원하는 더 큰 마일스톤으로 함께 그룹화한다. 반대로 마일스톤이 너무 길어지면 독립성을 가진 작은 마일스톤으로 분해할 수 있는 방법이 있는지 확인한다. 이 단계를 마치면 현실적인 마일스톤이 포함된 프로덕트 로드맵을 구축하는 첫 번째 단계가 완성된다.
로드맵 만들기
45. 첫 번째로 할 일은 프로덕트 전략을 지원하는 가치가 높은 패키지 순서대로 마일스톤 순서를 지정하는 것이다. 한 번에 하나씩 살펴보고 각각의 전략적 근거를 기억하면서 우선순위를 지정한다. 다음 단계는 마일스톤을 로드맵에 등록한다. 로드맵이 확정되지 않은 상태이므로 ‘예약한다'라는 표현을 사용한다.
46. 다음으로 우선순위가 두 번째로 높은 마일스톤을 선택한다. 첫 번째 마일스톤이 정시에 완료된다고 가정한 상태에서 같은 방식으로 일정을 잡는다. 실제 개발 팀 프로젝트는 훨씬 더 복잡하다. 대규모 제품 개발 조직에서는 많은 개발 팀이 연관성 있는 제품을 동시에 작업한다. 제품을 중심으로 구성된 경우 각 팀에 별도의 마일스톤이 있을 수 있으며 별도로 일정을 잡아야 한다.
47. 팀이 기능적으로 구성돼 각 팀이 프론트엔드 팀과 백엔드 팀처럼 서로 다른 시스템 구성요소를 소유하게 되면 의존관계를 확인해야 한다. 일정을 잡는 것이 더 어려워진다. 이 경우 각 팀에 필요한 DC(개발 능력)와 LOE(level of effort)를 별도로 파악해 각 팀이 정해진 기간 동안 각 마일스톤을 완료할 수 있도록 가능한 업무량을 배정하고 예약해야 한다.
프로덕트 로드맵 미팅
48. 로드맵을 만들고 난 후에는 모든 이해관계자와 로드맵 미팅을 한다. 미팅을 시작하기 전 반드시 체크해야 할 두 가지 포인트가 있다. 첫째, ‘로드맵이 정해진 제품 전략을 구현하는 데 충분한가'를 체크해야 한다. 의문이 생긴다면 이해관계자 정렬은 매우 힘들어진다. 다시 처음으로 돌아가 로드맵을 작성한다. 둘째, ‘현재 가진 DC가 바르게 적용된 것인가'를 체크해야 한다. 모든 로드맵의 기초는 개발 팀의 생산 능력에 기반을 둔다. 기본이 잘못되면 모든 일정과 로드맵은 의미 없어진다.
49. 프로덕트 로드맵의 목적은 문서 자체가 아니라 로드맵이 나타내는 개발 계획을 중심으로 다양한 제품 이해관계자를 정렬하는 것이라는 사실을 기억하자. 회의 진행은 PM 역할이다. 회의를 시작할 때 모든 이해관계자가 제품과 로드맵을 완전히 지원한다는 목표를 명확히 설명한다.
50. 첫 번째 의제로 이미 결정된 제품 전략을 빠르게 리뷰한다. 제품 전략은 모든 로드맵의 기본이며 설계 전략을 구현하는 데 반드시 필요하다는 것을 설명한다. 이때 다시 한번 이해관계자가 정렬됐는지 확인하는 것이 중요하다. 팀이 전략에 맞춰져 있지 않다면 로드맵을 논의하는 것은 무의미하다.
51. 두 번째 의제로 팀의 개발 역량을 리뷰한다. 개발 리더에게 팀의 DC를 설명하고 버그 수정 및 엔지니어링 주도 프로젝트 같은 신제품 개발 외 일에는 시간을 어떻게 사용할지 설명을 요구한다.
52. 세 번째 의제로 초기 버전의 로드맵을 리뷰한다. 각 마일스톤을 한 번에 하나씩 제시하고 각각 어떤 전략적 목표와 연결됐는지 설명한다. 각 마일스톤에는 관련된 개발 시간 추정치가 있으며 로드맵 릴리스는 현재 허용된 리소스에 맞춰 설계됐음을 주지 시킨다.
53. 네 번째 의제는 중간 체크포인트다. 이 시점까지 모두 동의하는지 혹은 이해했던 바와 달라진 점이 있는지 확인한다. 이 단계에서는 로드맵에 대한 다양한 의견을 듣는 것이 중요하다. 모든 이해관계자를 존중한다는 것과 이해관계자가 생각하는 중요한 문제를 표면화하는 방법이다. 수정이 필요하다고 판단되는 중요 문제는 모든 이해관계자가 볼 수 있도록 회의에서 직접 로드맵을 수정해 오해를 줄이고 수정된 로드맵에 합의하도록 한다. 이때 각 이해관계자에게는 한 팀으로서 제품 성공을 가장 최우선에 둬야 한다는 것을 다시 한번 강조한다.
5. PM의 일상 업무
와이어프레임, 프로토타입, 목업
54. 훌륭한 프로덕트를 만들고 싶다면 먼저 개념화해야 한다. 훌륭한 모든 프로덕트는 오랜 시간을 들여 개발 및 유지 보수, 개선 과정을 거친 결과물이다. 어떤 프로덕트도 첫 버전으로 성공할 수는 없다.
55. 와이어프레임은 기본적으로 레이아웃을 구성하는 웹사이트, 웹 애플리케이션 또는 모바일 애플리케이션에 대한 시각적 가이드다. 프로덕트 아이디어를 개념화하거나 전달하려고 할 때 가장 먼저 하는 작업이다.
56. PM으로서 가장 중요한 것은 복잡한 기능이 포함된 프로덕트 아이디어를 더욱 효과적으로 전달하는 방법을 알아야 하며 가장 대중적인 방법이 와이어프레임이지만 UX 전문가가 될 필요는 없다는 점이다.
57. 중요한 프로덕트 아이디어를 개념화하는 일은 디자이너가 아닌 PM의 고유 영역이다.
프로덕트 백로그, 에픽, 사용자 스토리
58. PM이 성공적으로 제품을 시장에 출시하려면 계획 및 목표를 업무의 태스크 단위로 세분화한다. 이것이 백로그라는 이름으로 만들어진다. 팀을 위해 실행할 수 있는 항목의 우선순위 목록도 제공한다.
59. 프로덕트 백로그는 프로덕트 릴리스 플랜을 지원하는 데 필요한 작업 목록이다. 프로덕트 백로그에는 제품을 완성하는 데 고려하는 모든 잠재적 항목이 포함된다. 사소한 수정부터 주요 기능 추가까지 모든 영역을 포함한다. 일부 백로그 항목은 다음 스프린트에 선택돼 스프린트 백로그로 들어가며 티켓으로 관리된다. 혹은 에픽 형태로 선택된 후 다시 스프린트에 선택될 수도 있다. 이 밖의 것들은 우선순위가 할당돼 선택될 때까지 대기열에 남게 된다. 범용 저장소인 프로덕트 백로그는 미래에 제품이 무엇을 추가하거나 변경할 수 있는지에 대한 모든 가능성을 담고 있다. 새로운 백로그는 경쟁자 움직임, 사용자 요청, 시장 피드백으로 계속 추가되고 스프린트로 옮겨진다.
60. 결정된 여러 기능 테마를 묶어 사용자에게 특정 날짜나 특정 기간에 배포하는 과정이 릴리스다. 릴리스에는 각 기능 테마가 존재하는데 프로덕트 매니지먼트 세계에서는 에픽이라고 한다. 즉 에픽은 만들고자 하는 하나 이상의 프로덕트 기능을 포함한 그룹이다.
61. 기능이 아닌 에픽이라고 표현하는 이유는 프로덕트 팀에서 실행하는 모든 일이 사용자에게 새로운 기능을 제공하는 것은 아니기 때문이다.
62. 에픽은 구축하는 데 한 번의 스프린트보다 더 오래 걸리는 작업이다. 구축하고 싶은 작은 것이 있고 한 번의 스프린트에서 끝날 수 있다면 에픽이 필요하지 않다. ‘사용자 스토리'만 있으면 된다. 에픽은 사용자 스토리보다 상위 개념으로 그 안에 여러 기능 요청 사항과 사용자 스토리가 포함됐다. 사용자 스토리는 구축하려는 기능을 최종 사용자에게 설명하는 방법이다.
63. 사용자 스토리는 ‘[고객/사용자] 입장에서 나는 이러한 [필요, 욕구, 이익]을 위해서 [행동, 행위]하기를 원합니다'라는 형식을 따른다. 사용자 스토리는 항상 해당 형식을 따른다. PM은 ‘무엇'과 ‘왜'를 책임지고 엔지니어와 디자이너는 ‘어떻게'를 책임진다는 설명을 기억하는가? 바로 질문의 답이다.
64. 사용자 스토리를 사용하는 이유는 무엇일까?
(무) 의식적으로 ‘고객/사용자' 입장에서 생각하게 된다.
지속적으로 더 ‘발전된 형태'의 방법과 이유를 찾게 된다.
복잡함은 줄이고 실제 ‘필요함'만 남기게 된다.
65. PM이 사용자 스토리를 작성하면 기술 수준에서 어떻게 해야 하는지 말하지 않아도 된다. 이 형식으로 작성한다는 것은 엔지니어에게 작업 수행 방법을 알려주는 것이 아니라 사용자로서 기능적으로 어떻게 수행돼야 하는지 알려준다는 의미다.
66. PM은 사용자 스토리가 완성됐다고 말하기 전에 기능이 의도한 대로 작동하는지 확인해야 한다. 여기에서 판정 기준 혹은 허용 기준, 승인 기준이 필요하다. 판정 기준은 해당 기능이 완전하게 만들어진 것으로 간주되기 위해 충족해야 하는 일련의 조건이다. 기능이 어떻게 작동해야 하는지 매우 구체적으로 설명하는 것이 목적이다.
속도와 번 다운 차트
67. 스크럼과 칸반의 가장 큰 차이점은 정해놓은 기간을 타임박스로 관리하는지 여부였다. 속도가 나오려면 시간 기반이 돼야 하며 스크럼의 스프린트와 연결된다. 예를 들어 하나의 스프린트가 있고 스프린트에 다섯 개의 백로그가 할당됐다면 이번 스프린트에서 특정 에픽의 일부인 다섯 개 사용자 스토리를 수행한다.
68. 문제는 시간이 얼마나 걸릴지 묻는다면 그 값은 부정확하다는 점이다. 좀 더 정확히 시간을 추정하는 방법이 있다. ‘이것을 하는 것이 얼마나 어려운가?’라는 등급을 만들어 표현하는 것이다. 즉 얼마나 어려운지 숫자로 수량화하는 방법이다. 이를 ‘스토리 포인트'라고 한다.
69. 벨로시티는 팀 능력이나 성능을 평가하는 핵심 성과 지표가 아니라 오직 작업을 마치는 시기를 예측하기 위한 도구라는 점이다. 벨로시티 추적의 핵심은 팀이 얼마나 많은 작업을 일관되고 안정적으로 수행할 수 있는지 추정하는 능력을 향상하는 데 있다.
우선순위 정하기
70. 프로덕트 백로그는 프로덕트에 필요한 것으로 수집된 모든 항목 리스트다. 리스트에 포함되지 않으면 프로덕트에 절대 반영될 수 없다고 할 만큼 모든 요청 사항을 모아놓은 것이다.
71. 좋은 제품과 서비스를 만들려면 리스트 안에서 가장 큰 가치를 제공하거나 합리적으로 보이는 작업을 먼저 완료할 수 있도록 우선순위를 매겨야 한다. 백로그에서 작업의 우선순위를 정하는 것은 PM과 PO의 가장 중요한 업무 중 하나다.
72. 가장 단순하면서 명료한 원칙이 있다. ‘가장 중요한 일을 가장 먼저 하는 것'이다. 이때 진정한 PM의 독립성과 창의성이 필요하다. PM은 사용자 스토리부터 에픽처럼 더 큰 주제에 이르기까지 모든 것의 우선순위를 매기는 일을 담당한다. 단순히 프로덕트만 보는 것은 아니다. 마케팅의 우선순위를 정하는 데 도움을 주는 제품 출시 기반의 브랜딩 캠페인도 우선순위에 영향을 끼친다. 기존 고객의 불만 사항 해결이 우선인지 혹은 신규 고객 창출이 우선인지도 고민해야 한다. 경쟁 제품의 포지셔닝에 따라서도 우선순위가 바뀔 수 있다.
모스코 우선순위 정하기
73. 어떤 것이 ‘머스트 해브'가 될 자격이 있는지 알아보는 가장 쉬운 방법은 그것을 포함하지 않는 최악의 시나리오와 최선의 경우를 생각해 보는 것이다. 만약 그것 없이 프로덕트의 성공을 상상할 수 없다면 그것은 ‘머스트 해브', 즉 프로덕트의 필수품이다.
워킹 스켈레톤 우선순위 정하기
74. 워킹 스켈레톤은 기본 아키텍처의 기술 검증 버전이다. 일반적으로 PoC는 단일 기능에 초점을 맞추지만 워킹 스켈레톤은 최소화된 프로덕트의 엔드 투 엔드를 구현한다. 즉 개념의 윤곽 정도가 아니고 실제로 실행할 수 있어야 하며 테스트도 함께 가능해야 한다. MVP 기능의 우선순위를 정하는 데 자주 사용되며 그중 무엇이 프로덕트가 작동하는 데 절대적으로 중요한지 정의한다.
75. 특징: 사용자 스토리에 초점을 맞춰 우선순위를 정한다. 먼저 필요한 사용자 스토리에 순위를 매긴다. 필수 기능의 구현에 중점을 둬 주요 기능이 완전하게 동작하는 프로덕트의 형태를 갖고 있어야 한다. 또한, 비즈니스 가치를 충분히 보여주는 형태여야 한다. 여러 가지 기술 제한이 있는 상태에서도 핵심 시스템 요소를 표시하기 위해 스토리 맵을 잘 정리한다. 워킹 스켈레톤은 딜리버리와 배포까지의 모든 과정을 포함하기 때문에 프로덕트 기능 테스트도 과정에 포함한다.
76. 장점: 첫째, 핵심 기능의 우선순위를 정의하는 데 많은 시간이 걸리지 않는다. 둘째, 출시할 프로덕트나 서비스의 비즈니스 가치를 추정할 때 가능한 많은 기능을 포괄적으로 가진 프로덕트를 만들고자 하는 유혹이 강하게 생긴다. 이 때문에 핵심 필수 기능에만 초점을 맞추는 것이 어려울 때가 많다. 워킹 스켈레톤은 실제 동작하는 MVP를 목적으로 하기에 이런 상황을 피할 수 있다. 셋째, 사용자에게 우선순위 결정에 대한 피드백을 빠르게 받을 수 있다. 전체 프로덕트 팀은 프로덕트 시장 적합성과 비즈니스 아이디어를 전체적으로 평가할 수 있게 된다.
77. 단점: 첫째, 주요 기능이 동작하는 프레임워크의 형태를 띠고는 있지만 여전히 중요한 다른 기능을 포함하고 있지 않을 수도 있다. 둘째, 빠른 우선순위 설정 테크닉이지만 주요 기능이 동작하는 프레임워크가 완성돼야 하기에 첫 릴리스까지는 시간이 걸린다. 셋째, 프로덕트의 첫 릴리스를 하려고 할 때 리더십 팀에서는 출시를 가속화하고자 주요 기능의 우선순위를 조정하려고 할 수 있다. 이렇게 되면 최초의 실행 가능한 프로덕트 버전은 시장에 출시할 준비가 되지 않은 프로토타입으로 나올 위험이 있다.
우선순위 정하기 방법 정리
78. 프로덕트 백로그는 소프트웨어 개발 및 애자일 기반 프레임워크에서 사용되는 가장 중요한 데이터다. 다음 스프린트에서 완료해야 할 스토리 포인트뿐만 아니라 프로덕트를 구성하는 중요항 요소가 된다. 프로덕트 백로그에서 작업의 우선순위를 정하는 것은 PM이나 PO의 중요한 책임 중 하나다. 직감에 의존하는 우선순위 접근 방법은 프로젝트와 프로덕트를 위험에 빠뜨린다.
MVP
MVP 목적
79. MVP는 해결할 가치가 있는 문제를 찾았는지 알아내는 방법이다. 출시 실패의 위험을 줄이고 가장 중요한 가정을 빠르게 테스트하고 사용자들로부터 피드백을 받는 것이 목적이다. MVP 제품에 넣은 아이디어가 고객에게 관심받지 못할 것이라고 판단되면 신속한 방향 전환이 필요하다. MVP를 만드는 유일무이한 목적은 고객과 시장을 빨리 이해하기 위해서다. MVP를 만드는 이유와 필요한 이유는 다섯 가지로 정리할 수 있다.
빠른 시간 안에 최소 비용으로 프로덕트를 내놓고 실험한다.
대상 사용자와 타깃 시장을 찾아내는 연습을 한다.
프로덕트가 제공할 기능과 고객 요구 사항의 밸런스를 찾아 시장에서 생존할 가능성을 높인다.
대상 사용자에게 품질이 좋은 피드백을 받아 고객과 시장을 더 잘 이해한다.
중대한 문제점을 걸러내 메인 릴리스에 반영한다.
MVP 핵심 개념
80. minimum의 의미를 ‘최소한의 기능 세트'로 이해한다. minimum은 ‘핵심 가치'를 의미한다. viable은 학습 목적으로만 ‘실행 가능', ‘생존 가능'이라고 사용한다. MVP의 목적은 미리 정해놓은 비즈니스 모델을 테스트하는 것이 아니라 프로덕트의 가치를 제안하고 확인하는 과정에서 탄력적으로 비즈니스 모델을 함께 수정하는 것이다. ‘product’는 ‘제품/서비스'를 의미하는 것이 아닐 수 있다.
81. MVP는 제품이라고 부르기보다는 ‘실험 또는 경험'이라고 부르는 것이 맞다. 실제로 MVP는 확인하는 과정의 산물이지 반드시 최종물의 작은 버전이 아니다.
6. 능력 있는 PM 되기
제품 시장 적합성
82. MVP를 딜리버리 하는 시점은 지금 이야기하는 PMF가 검증된 후다. 즉 시장이 검증되고 사용자가 진정으로 원하는 것이 무엇인지 파악한 후 MVP를 출시한다. 이런 이유로 MVP는 PMFT 다이어그램의 최고 상위 단계인 ‘UX’와 ‘기능'에 해당한다.
83. PMF를 알고 싶다면 반드시 ‘가치 가설'을 먼저 이해해야 한다. 가치 가설이란 고객이 우리 제품을 사용할 가능성이 높은 이유가 될 주요 가정을 명확히 하는 과정이다. 가치 가설은 다음의 세 가지를 만족해야 한다.
구축해야 하는 기능
관심을 가질만한 잠재 고객
고객이 제품을 구매하도록 유도하는 데 필요한 비즈니스 모델
가치 제안
84. 가치 제안은 우리 제품이 대안이나 경쟁 제품보다 고객 요구를 더 잘 해결할 수 있다고 사용자에게 설명하고 약속하는 과정이다. 이 과정에서 가설을 세우는 기본 질문은 다음과 같다.
고객의 모든 잠재적 요구 중 우리 제품이 해결할 수 있는 가장 중요한 것은 무엇인가?
어떤 것이 가장 큰 영향을 미치며 어느 정도의 시간과 노력이 필요한가?
85. 이를 알려면 가설에 세 가지 요소가 필요하다.
무엇: 만들고 있는 제품
대상: 해당 제품이 절실히 필요한 사용자
방법: 제품 제공에 사용하는 비즈니스 모델, 성장을 이끄는 마케팅 전략
지표
허세 지표란
86. 허세 지표는 ‘데이터를 얻는 데 큰 노력이 필요 없으며 보는 이의 기분을 좋게 할 수는 있지만 무엇을 하면 되는지 프로젝트/비즈니스 인사이트를 제공하지 못하는 지표'로 정의할 수 있다.
87. 누적 지표가 나쁜 이유는 ‘분석 노력 없이 쉽게 얻어지는 것'과 ‘지표의 명확성 부족' 때문이다. 숫자 자체의 표현 외에는 분석 백그라운드를 제공하지 않는다. 지표가 좋으면 모두 내 덕이며 지표가 나쁘면 네 탓이라고 생각하게 되는 나쁜 문화를 생성하기도 한다.
좋은 지표의 조건
88. 좋은 지표, 즉 실행 가능한 지표는 다음과 같은 네 가지 조건을 만족해야 한다.
이해할 수 있어야 한다.
비율로 표현할 수 있어야 한다.
상관관계가 있어야 한다.
변경할 수 있어야 한다.
OKR과 KPI
89. OKR 특징은 다음과 같다.
상위 목표를 달성하기 위한 구체적 계획을 하위 목표로 두고 계층화해 성능을 추적하는 방법이다.
위에서 지시하는 목표가 아닌 직원이 직접 중요 목표와 결과를 설정한다.
중요 목표와 결과는 매우 도전적으로 설정해야 한다.
OKR
90. OKR 특성은 다음과 같다.
항상 수량화/정량화가 가능해야 한다.
0 또는 1의 바이너리 상태(성공/실패, 달성/미달성, 활성/비활성)나 0~10, 0~100의 척도를 갖고 점수를 부여할 수 있어야 한다.
명확한 타임라인과 매우 공격적인 달성 목표가 설정돼야 한다.
91. OKR은 성장이라는 큰 틀의 목표 위에 구축되므로 직원과 조직을 매우 도전적이고 공격적인 ‘거의 불가능에 가까운’ 선까지 밀어붙인다.
92. 모든 비즈니스의 성공은 방법론 자체가 만들어주는 것이 아니다. 각 조직원이 새로운 프로세스와 방법론을 적극적으로 받아들이고 행동으로 보여주느냐에 달려있다.
주의해야 할 네 가지 편향적 의사결정
확증 편향
93. 확증 편향은 자신이 옳다고 생각하는 정보만 받아들이고 신념과 일치하지 않는 정보는 무시하는, 보고 싶은 것만 보고 듣고 싶은 것만 듣는 경향을 말한다.
94. 확증 편향의 가장 큰 폐해는 ‘당신의 의견이 틀렸다'는 반대 의견을 무시하기 쉽다는 점이다. 이미 전문가 위치에 있는 상황에서 반대 의견을 받아들이지 않는다는 점보다 더 심각한 점은 편향이 지속적으로 프로덕트를 만드는 프로세스에 영향을 미친다는 점이다.
95. 개발자를 포함한 엔지니어는 다른 직군보다 낙관적 편향에 더 많이 빠졌다. 해야 할 작업이 추상적인 경우 낙관적 확증 편향이 더 쉽게 드러난다. 낙관적 확증 편향의 나쁜 점은 작업을 추정하는 것과 작업 요구 사항을 철저하게 이해하는 데 방해가 된다는 점이다.
96. 정상적인 경로만 테스트하는 것은 매우 위험하다. 사용자의 제품 사용 프로세스와 환경은 상상할 수 없을 정도로 많은 조합이 있다. 모든 조합을 테스트할 수는 없지만 정의된 ‘행복한 경로 테스팅'에만 머물러서는 안 된다.
이케아 효과/편향
97. ‘사람들은 본인이 직접 만든 제품은 실제보다 더욱 큰 가치를 부여한다'는 심리 효과다. 이케아 효과로 부풀려진 본인의 노력이 궁극적으로 제품 경쟁력과 마켓 셰어보다 중요할 수는 없다.
오류 합의 편향
98. 오류 합의 편향은 내가 생각하고 행동하는 것처럼 다른 사람도 분명 그럴 것이라고 ‘오류 합의'를 하는 일종의 확증 편향이다. 쉽게 생각하면 ‘자기중심적 사고의 편향'이라고 해석할 수 있다.
99. PM은 쉽지 않은 일이다. 여러 팀과 이해관계자 사이에서 프로세스와 정보 흐름의 중심적 허브 역할을 한다. 엔지니어링의 기술 언어를 구사해야 할 뿐만 아니라 다른 쪽의 비즈니스와 고객을 이해해야 한다. 회사 내부, 고객, 시장의 요청과 경쟁 제품의 분석에 따라 수많은 요구 사항을 파악해 엔지니어링이 이해하는 언어로 커뮤니케이션하고 진행한다. 이 같은 업무 환경에서, 매 순간 다가오는 결정에서 PM은 편향을 피할 수 있는 자신만의 노하우를 연습하고 체득해야 한다. 편향을 공부하고 이해했다고 행동할 수 있는 것이 아니다. 최소한 뇌와 습관이 이성을 속이려 한다는 것을 안다면 경계하고 조심하면서 명확한 사고와 좀 더 나은 의사결정을 하기 위한 연습을 할 필요가 있다.
좋은 PM에게 협업이란
사람들이 싫어하는 네 가지 PM 유형
100. 첫째, 업무 범위가 모호한 PM이다. 개발하려는 기능의 범위 지정과 요청 사항을 매우 불확실하고 애매하게 설정하는 PM이 해당한다. 개발자와 디자이너는 투명하고 확실한 사양을 원한다. 모호함은 오해를 만들어 다른 해석으로 이어지기 쉽다. 개발 단계뿐만 아니라 테스트를 할 때도 큰 혼란을 야기하며 내부 이해관계자와 소통할 때도 문제가 된다. 이를 해결하려면 다음과 같은 질문에 명확한 답을 할 수 있어야 한다.
해결하려는 진짜 문제는 무엇인가?
고객과 비즈니스에 왜 중요한가?
진행 중인 다른 모든 중요한 작업과 비교하면 어떤 차이가 있는가?
이것의 우선순위가 높다면 어떤 것의 우선순위를 낮게 조정해야 하는가?
작업이 성공했는지 어떻게 알 수 있는가?
101. 둘째, 업무 영역을 넘나드는 PM이다. 업무 영역의 선을 지키지 않고 넘나드는 PM이 해당한다. 일당백 역할이 필요한 작은 스타트업에서는 강점이 될 수 있지만 회사가 성장함에 따라 전문성을 확보해야 하는 경우 충돌로 이어지기 쉽다. PM은 전문 업무와 관련해 지시나 조언하기보다는 제안하는 방법을 배워야 한다. 유일하게 집중할 가치가 있는 것은 프로덕트 성공에 매우 중요하고 PM으로서 강하게 확신하는 것에 대해서일뿐이다. 다른 모든 것은 작업을 수행하는 도메인 전문가가 결정하는 것이 좋다.
102. 셋째, 일을 복잡하게 만드는 PM이다. 애매한 업무 지정을 하는 것만큼 나쁜 것은 일을 점점 더 복잡하게 만드는 PM이다. 가장 대표적인 예가 이미 백로그가 확정된 상황에서 기능 사양을 추가하는 경우다. 이를 해결하려면 다음과 같이 새로운 체크리스트를 접할 때마다 매번 스스로 질문해 보는 것이다.
이 기능을 출시하지 못할 때 생기는 최악의 상황은 무엇인가? (영향이 제한적이라면 다음으로 미루자.)
이것을 릴리스하려면 구체적으로 무엇을 어떻게 해야 하는가?
103. 넷째, 마감일만 외치는 PM이다. “이건 쉬운 일인데 내일까지 할 수 있죠?”라고 말할 수 있는 PM은 극단적으로 두 가지 유형밖에 없다. 해당 업무의 경력이 있어 잘 안다고 자신하는 타입과 해당 업무를 전혀 모르는 타입니다. 엔지니어가 가장 싫어하는 유형의 PM이다. 다음과 같은 연습이 필요하다.
본인이 그 일을 직접 하는 사람이 아닌 한 어떤 것도 ‘쉬운'이라고 하지 않는다.
견적을 요청하기 전에 사람들이 범위를 검토하고 조정할 시간과 권한을 준다.
작업 예상치가 높으면 업무 범위를 합리적으로 줄이는 방법을 찾는다.
개발자, 디자이너와 즐겁게 협업하는 방법
104. 개발자나 디자이너들이 신뢰하는 사람은 본인과 같은 업무를 하는 엔지니어다.
105. 초기에 프로덕트를 기획하는 일은 개발자나 디자이너 손에서 이뤄지지 않는다. 프로덕트 리더십이 설정한 비전과 전략에 따라서 PM의 손을 거쳐 전략과 로드맵을 짜고 세부 기능 분류와 우선순위에 따른 릴리스 플래닝이 마련된다. 시작이 이렇기 때문에 엔지니어와 PM 관계는 한쪽은 드라이브를 하고 한쪽은 그에 맞춰야 하는 입장을 해석하면 갈등의 원인이 된다.
106. 내가 그 역할이 아닐 때 이해할 수 없었던 것은 해당 역할을 맡게 되면 이해가 되는 경우가 많다.
107. 문제점, 개선점, 고객의 애로 사항만 설명하고 해결책은 이야기하지 않는다. PM은 프로덕트 내 ‘무엇을', ‘왜'에 집중하고 설명하는 일을 한다. 엔지니어는 그것을 실제로 ‘어떻게' 풀어내는 PM의 유일한 파트너라는 사실을 항상 명심해야 한다.
108. 프로젝트의 초기 단계부터 프로세스에 엔지니어를 포함시킨다. 무작위로 참여시키는 것이 아니라 대표 자격을 가진 각 부문 엔지니어링 프로덕트 코어 팀을 구성하는 것이 좋다.
109. 무엇이 어떻게 어렵고 힘든 부분인지 적극적으로 듣고 이해하고 공감을 표현하는 것만으로도 엔지니어링 팀에게 신뢰를 얻을 수 있다. 신뢰감을 느낀 엔지니어의 업무 성과는 좋을 수밖에 없다. PM은 엔지니어와 소통하면서 프로덕트의 기술 흐름과 설계 구조 같은 깊은 지식을 이해할 수 있다.
110. 데이터를 기반으로 결정하고 투명한 커뮤니케이션 과정을 갖는다. 사용자 조사나 핵심 고객이 보낸 공식 요청서 등 데이터와 우선순위에 근거해 명확한 고객/시장 요구 사항 리스트 및 사용자 스토리를 작성하고 소통한다. 테크니컬 업무 정의는 엔지니어링 팀의 고유 권한으로 남겨 놓는다. 업무 회의 후에는 명확하게 책임 한계를 기술한 회의록을 참석자와 관계자에게 배포해 항상 같은 수준으로 이해할 수 있도록 한다. 엔지니어가 PM에게 ‘기습당했다'라는 느낌은 갖지 않도록 투명한 커뮤니케이션에 집중한다.
111. 실수를 인정한다. 프로젝트를 진행하면서 우선순위가 바뀌거나 지원 기능이 변경되는 일은 빈번하다. 그 상황을 엔지니어링 팀에 설명하고 유감을 표현하는 것, 때에 따라서 실수를 인정하는 것 역시 PM의 역할이다. 이를 주저하거나 두려워할 필요는 없다. PM의 목표는 오직 사용자가 원하는 성공적인 프로덕트를 릴리스하는 것이다. 오류를 바로 잡거나 실수라는 것을 이야기한다고 해서 엔지니어가 PM의 개인적인 실수로 생각하거나 결정된 결과에 크게 분노 및 좌절, 실망하지 않는다. 오히려 투명하게 전달해 주는 PM에게 신뢰감을 느끼고 다음 솔루션 찾기에 최선을 다한다.
다양한 성향의 팀원과 일하는 다섯 가지 방법
112. 회의 시간 전에 의제를 보낸다. 내향적인 엔지니어들은 누구의 간섭도 없이 업무를 독립적으로 처리할 수 있을 때 가장 기여도와 품질이 좋다고 생각한다. 내향적인 팀 구성원에게는 회의 전에 다루게 될 정보를 미리 검토할 기회를 제공한다.
113. 본인의 성향을 편안히 이야기할 수 있는 분위기를 만든다. PM 팀워크를 만들어내는 퍼실리테이터 역할을 할 때 할 수 있는 일이다. 팀 구성원들이 가장 잘 일하는 방식을 인식하고 지원하는 것은 이기는 제품을 만들기 위한 PM의 가장 강한 목표이자 자원이다.
114. 다양한 형식의 커뮤니케이션 협업 방법을 제공한다. PM은 다양한 커뮤니케이션 방법을 모두 잘 동작하게 해야 한다. 특정 커뮤니케이션 방법이 협업 프로세스를 지배하지 않도록 하는 것이 중요하다. 팀 구성원이 다양한 커뮤니케이션 방법으로 기여할 수 있다고 느끼는 환경을 만들어야 한다.
115. 성격 유형을 미리 가정해 선을 긋지 않는다. 모든 팀원이 분석적이면서 친화적이고 공감 및 소통 능력, 긍정성을 가졌다면 더없이 이상적이다. 아쉽게도 존재하지 않는다. 각 장점을 가진 사람들이 모이면 슈퍼맨 같은 일을 하는 강한 조직이 될 수 있다. PM은 완벽한 구성원은 아무도 없다는 점을 강조한다. 함께 모인 다양성의 가치를 반복적으로 고취시켜 여러 성격 유형이 견제나 갈등으로 커져 팀 발전을 저해하는 요소가 되지 않도록 한다.
116. PM은 회의 목표가 합의가 아니라는 점을 강조한다. 회의 목표가 현재 수준에서 보장할 수 있는 최저치에 대한 합의가 돼서는 절대 안 된다는 의미다. 대신 ‘더 나은', ‘더 빠른', ‘더 훌륭한’ 방법을 찾아낼 수 있는 방법을 찾아낼 수 있는 환경을 만드는 것이 목표가 될 수 있다.
117. 좋은 PM은 모든 사람이 동의한다고 생각되는 합의를 위해 노력하는 것이 아니라 서로 다른 관점이 새로운 솔루션을 만드는 원재료가 돼 가져오는 상승효과를 위해 노력해야 한다.
118. PM은 더 나은 품질의 프로덕트를 만들어내고자 팀 멤버의 능력과 경험에 집중해야 한다. 구성원을 잘 알면 자신의 행동과 반응, 업무 방법을 동적으로 빠르게 전환할 수 있다.
PM/PO가 되고 싶다면?
이미 가진 다섯 가지 장점을 강점으로 만들기
119. ‘어떻게든 되겠지'가 아닌 ‘어떻게 해서든 해결해야지'라는 덕목은 PM에게 어떤 상황에서도 프로덕트를 꼭 딜리버리 해야 한다는 에너지로 동작하고 에너지는 모든 이해관계자에게 신뢰감을 준다.
120. PM은 오케스트라의 지휘자처럼 각 전문가가 놓치는 부분의 디테일을 찾을 수 있어야 한다. 각 악기를 연주하는 최고의 예술가가 모였을 때 소리 강약과 잡음을 모아 하모니를 만들어내는 지휘자 역량이 필요하다.
PM의 필수 덕목 다섯 가지를 추가하기
121. PM이 된다는 것은 매 순간 고객이 원하는 프로덕트를 만들지 못하면 시장에서 선택되지 않는다는 사실을 깨달아야 하는 일이다. 고객의 비즈니스를 이해하는 것은 프로덕트 매뉴얼이 돼야 한다.
122. 프로덕트를 함께 만드는 관계자와 비전을 공유해야 한다. PM은 혼자서 할 수 있는 것이 거의 없다. 철저하게 각 부문 전문가의 브릿지가 돼야 한다. 통합하고 프로덕트 비전을 끊임없이 불어넣는 역할을 해야 한다. 매번 전문 지식이 필요한 엔지니어링, UX, 데브옵스뿐만 아니라 서비스 운영, 마케팅, 법무팀 등 수많은 담당자와 함께 하모니를 만들어내는 오케스트라 지휘자가 돼야 한다. 적절한 외교력과 협상력, 커뮤니케이션 같은 소프트 스킬도 필수다.
123. 엔지니어의 업무 난이도에 따른 우선순위가 아니라 고객과 시장이 요구하는 우선순위와 함께 방향성도 함께 부여해야 한다. 소수의 고객이 아닌 모든 고객의 유용성을 확보하는 것이 중요하다.
124. PM은 모든 면에서 생각과 귀를 활짝 열어둬야 한다. 여기에서 그치지 않고 차선책도 준비해야 한다. 순차적 사고 방법을 전략적 사고라고 한다. 이런 전략적 접근법이 유연하게 활성화되려면 열린 마음으로 전문가나 업무 담당자의 의견 및 지혜를 들어야 한다.
125. 업무 우선순위를 정해야 한다. PM은 훨씬 더 보수적으로 결정해야 한다. 업무의 우선순위를 정할 때 위험도를 얼마나 잘 관리할 수 있느냐를 최우선에 둬야 한다.
