PM은 상사나 애자일 전문가가 아니다
프로덕트 매니지먼트에서 뽑은 205개의 핵심 파트 (1)
오래간만에 좋은 PM, 프로덕트 매니지먼트에 관한 책이 나왔다. 제목은 '프로덕트 매니지먼트'다. SAP의 김영욱 프로덕트 매니저가 집필한 책이다. 평소에도 이 분의 글을 브런치나 원티드에서 종종 읽어서 굉장히 기대감을 갖고 읽었다.
이번 글에서 가장 좋았던 부분은 바로 PM 역할이 아닌 것과 PM 역할인 것을 구분해 줬다는 것이다. PM은 알아야 하는 지식도 많고 챙겨야 하는 것도 많다. 그래서 흔히들 PM을 뭐든지 다 잘하는, 잘 아는 슈퍼맨으로 여기는 경향도 있는데, 이런 부분에 대해서 명확히 말해주는 부분이 좋았다. 해당 부분은 PM 뿐 아니라 PM과 일하는 개발자, 디자이너들도 꼭 한번 봐야 할 것 같다.
* 프로덕트 매니지먼트는 내돈내산은 아니다. 한빛미디어에서 리뷰 요청과 함께 책을 보내주셨다. 받은 책이라고 해서 특별히 더 좋게 쓴 부분은 없다. 이전에 쓴 여러 글처럼 좋다고 생각한 부분만을 편집하고, 요약했다.
1. 프로덕트 매니지먼트란 무엇인가
프로덕트 정의
1. 정확히 알고 싶은 것이 있다면 알고자 하는 것이 무엇인지 이해해야 한다. 설령 가정에 근거한 정의라 할지라도 가정을 검증하면서 접근한다면 가장 정확하게 이해할 수 있다. 프로덕트 매니지먼트 과정을 알고 싶은가? 먼저 프로덕트란 무엇인지 정의해야 한다.
컴포넌트와 프로덕트
2. 프로덕트 관점에서 보면 부품은 컴포넌트다. 컴포넌트는 프로덕트로 동작하지 않으며 프로덕트로 릴리스하지도 않는다. 다른 컴포넌트나 프로덕트에 의존성을 가지면서 협업을 통해 전체 프로덕트를 구성하고 동작하게 하는 데 목적이 있다.
3. 최소 단위의 구성 요소는 제품이 될 수 없다. 릴리스 되지도 않는다. 구성 요소는 상상력만 있다면 만들지 못할 것이 없는 컴포넌트 역할을 한다. 컴포넌트끼리 조합하면 형태를 가지는 ‘컴포넌트 세트'를 만들 수 있다. ‘인스턴스'라고도 하며 프로덕트로 릴리스 가능한 상태다.
4. 릴리스 가능한 상태와 프로덕트로 릴리스한다는 것은 큰 차이가 있다. 인스턴스가 프로덕트가 되려면 시장이 원하는 형태의 패키징을 해야 한다.
PM과 프로덕트
5. 유튜브의 가장 중요한 기능인 비디오 플레이는 하나의 프로덕트인 동시에 기능 컴포넌트다. 댓글을 달고 보여주는 기능 역시 단독 프로덕트이지만 단독 릴리스하지 않고 다른 기능을 하는 컴포넌트와 함께 릴리스 되는 컴포넌트다. 다양한 기능 컴포넌트로 이뤄진 프로덕트는 여러 명의 PM이나 프로그램 매니저가 각 기능을 관리하며 프로덕트 팀 또는 엔지니어링 팀의 개발자, 디자이너, 테스터, 테크니컬 라이터 등 다수가 함께 작업한다.
6. 서비스 기능으로 분류하는 것을 ‘수직적(vertical) 분류’라고 한다. 각 기술 도메인이 확실하게 나뉜다는 점에서 수직이라는 말을 쓴다.
7. PM 업무는 서비스의 기능으로만 분류하지 않는다. ‘수평적 (horizontal) 분류'도 있다. 전체 프로덕트 형태가 지원하는 플랫폼에 따라 변하지 않도록 관리하면서 서로 다른 OS 플랫폼에서도 기능이 원활하게 동작하도록 보장하는 일을 한다. 이를 해당 시스템에 포팅(porting)한다고 표현한다.
8. 프로덕트란 소비자가 보는 전체 프로덕트일 수도 있고 기능에 따라 더 작은 부분으로 나눠질 수도 있다는 사실을 이해해야 한다. 프로덕트가 만들어지고 사용자에게 전달되는 과정, 즉 프로세스 역시 프로덕트가 되고 표준화가 될 수 있다는 점을 반드시 기억하자.
9. 프로덕트를 구성하는 릴리스 노트, 온라인 헬프 같은 문서 자료도 프로덕트가 될 수 있다. 엔지니어링 팀이 공통으로 사용하는 공유 컴포넌트도 마찬가지다. 모든 것이 모여 예상하는 동작을 하도록 하려면 누군가의 시작이 필요하다. 그 역할은 바로 프로덕트 설계, 개발, 테스트, 릴리스 그리고 릴리스 후의 라이프 사이클까지 모든 프로세스에 책임을 가진 사람, 바로 PM이 한다.
PM 정의
PM 역할이 아닌 여섯 가지
10. 보고 라인에 있는 팀 상사. PM의 직함에 ‘매니저'라는 타이틀이 있어 사람을 ‘관리'하는 일이라고 생각할 수 있다. PM은 사람을 관리하지 않는다. 아무도 보고하지 않으며 그 누구의 상사도 아니다. 인사관리를 하지도 않는다.
11. PM은 강요하거나 지시하지 않고 함께 일하는 구성원을 설득하고 영감을 주는 역할을 한다. 제품이나 기능이 필요한 이유를 이해하고 사람들에게 설명해야 한다. 양보나 타협이 아닌 ‘왜'에 대한 비전을 명확하게 이해시켜 엔지니어 및 디자이너와의 협업을 이끌어내야 한다. PM은 이런 일을 하도록 의도적으로 설계된 역할이다.
12. 능숙한 기술자. PM은 개발자나 IT 담당자 같은 기술자가 아니다. 기술적인 역할보다 고객의 불편함에 공감하고 비즈니스를 파악해 제품에 반영하고 릴리스까지 책임지는 역할을 한다. 모든 기술 지식을 이해해야 하는 것은 아니다. PM 역할을 잘못 이해한 것이다. PM은 소통에 필요한 최소한의 기술만 알면 된다. 더 중요한 것은 기업이 만드는 제품을 이해하는 것과 무엇을 시장에 판매할 수 있는지 판단하는 안목이다.
13. 마케터. PM은 프로덕트가 우수한 점을 누구보다 분명하게 설명할 수 있어야 한다. 고객에게 매번 직접 설명할 필요는 없다. 마케터가 할 일이다. PM은 고객을 직접 상대하는 마케터와 세일즈 담당자가 제품의 강점을 잘 인지한 상태에서 고객의 문제에 집중하여 홍보와 판매를 하고 있는지 면밀히 모니터 하는 것이 중요하다. 그 과정에서 얻는 정보가 프로덕트 품질 향상을 위한 기회를 제공하기 때문이다.
14. 프로덕트 오너. 흔히 PM과 프로덕트 오너(PO)를 혼용하곤 한다. 애자일 방법론을 적용하는 스크럼 개발 프로세스에서 PO는 모든 백로그의 우선순위 지정에 대한 오너십을 갖는다. PM이 PO와 명확하게 다른 점은 디스커버리 프로세스에 더 많은 시간을 할애한다는 것이다. PM으로서 할 수 있는 가장 가치 있는 일은 ‘전략적 역할을 수행하기 위한 생각할 시간을 갖는 것'이라는 말이 있다. PM은 사용자가 원하는 것과 시장이 원하는 것을 파악해 전략적 계획을 세우는 사람이다.
15. 애자일 전문가. PM이 애자일 전문가처럼 애자일 방법론에 능숙해야 한다는 것은 큰 오해다. 애자일 신앙에 얽매여서는 안 된다. 다양한 주변 상황과 환경에 맞는 개발 방법을 찾아 개선해 나가는 역할을 할 뿐이다. 실제 개발 프로세스를 진행하는 역할은 PO나 스크럼 마스터가 한다.
16. 데이터 분석가나 사용자 리서처. PM은 때때로 데이터를 분석하고 다음 질문이 무엇인지 파악한 후 고객이 매력적이라고 느끼는 답변을 만들어야 한다. 하지만 린 스타트업 관점에서 프로덕트 매니지먼트 목표는 ‘최종 사용자에게 가치를 제공하지 않는 활동을 제거하는 것'이다. 최종 사용자를 위한 가치에 대해서는 리더십, 엔지니어링, 세일즈, 마케팅, 고객지원과 같은 내부 이해관계자가 프로덕트 비전과 미션을 이해하도록 한다. 그 가치에 이해하고 동의했다면 데이터를 적용하고 공유한다. 이때 데이터 수집은 사용자조사 팀이나 데이터분석 팀에 의뢰하면 된다.
PM 역할
17. 커뮤니케이션의 허브 역할. PM은 조직에서 프로덕트 관련 정보의 중심이다. 정보 양과 품질, 이해도를 끊임없이 정리한다. 즉 모든 이해관계자를 위한 커뮤니케이션 허브 역할을 한다. 경우에 따라 본인이 속한 엔지니어링 그룹을 넘어 고객과 직접 커뮤니케이션한다.
18. 우선순위 조정 역할. PM은 매일 우선순위와 다툰다. 모든 이해관계자는 본인과 관련 있는 업무가 가장 빠르게 처리되길 원한다. 고객 역시 마찬가지다. 본인의 문제가 다른 고객 문제보다 더 빨리 해결되기를 원한다. 이때 PM의 균형감이 중요하다. 합리적인 기준으로 우선순위를 조절하고 모든 이해관계자를 설득하고 합의를 이끌어내야 한다. 이는 PM의 역할이자 중요한 능력이다.
19. 프로덕트 대표이자 치어리더 역할. PM은 프로덕트를 대표하는 전체 책임자이지만, 동시에 치어리더 역할도 한다. 엔지니어와 디자이너가 어려운 기술 과제를 해결하는 데 집중하는 동안 PM은 다양한 이해관계자의 피드백과 사용 지표를 통해 어떤 것이 중요하며 다음에 무엇을 구현할 수 있는지, 어떻게 하면 시간을 잘 활용할 수 있는지 살펴보고 결정한다.
20. PM 역할을 간단하게 표현하자면 ‘프로덕트 성공에 대한 모든 책임을 지는 역할'이다. 여기서 말하는 ‘성공'은 기업 비전과 일치해야 하며 해당 엔지니어링 팀 목표와도 동일한 방향이어야 한다. 또한, 성장과 내실을 모두 가지고 고객과 사용자 만족도도 유지해야 한다.
B2B와 B2C
누구를 향하는지에 따라 구분
21. B2B 프로덕트는 다른 회사의 비즈니스를 돕고 해결하도록 설계됐다. B2B PM의 외부 이해관계자는 제품을 직접 사용하는 고객이나 고객 담당 매니저, 내부 이해관계자는 개발, 디자인, 테스트를 진행하는 프로덕트 엔지니어링 팀이다. B2B PM은 고객의 비즈니스를 이해하는 능력과 산업 및 고객별 비즈니스 흐름을 표준화하는 기술 능력이 필요하다.
22. 컨슈머 PM은 비전과 아이디어를 구현하기 위한 창의성을 갖춰야 할 뿐만 아니라 광범위하고 급변하는 기술을 빠르게 프로덕트에 적용하는 능력이 필요하다. 소비자 역할에 서서 매 순간 불확실한 상황을 모니터링하는 지표를 만드는 데에도 역량을 발휘해야 한다.
B2B와 B2C 프로덕트 매니지먼트 비교
23. B2B 프로덕트 매니저는 비즈니스 워크플로를 구축한다. 그에 반해 B2C 프로덕트 매니저는 사용자 행동을 구축한다.
24. B2B와 B2C는 프로덕트를 처음 설계하고 만드는 출발점 자체가 다르다. B2B는 고객의 비즈니스를 이해하고 기존 프로세스 내에서 어떤 시장 이점을 가져다줄 수 있는지 고민하며 고객과 ‘협업'하는 개념으로 제품화 과정을 발전시킨다. 반면 B2C는 ‘먼저 시도하고 배우기'로 고객에 접근한다. 불특정 다수를 대상으로 하므로 최적점을 찾고자 지속적으로 시도하고 배우고 실험하면서 제품 시장 적합성을 찾아가야 한다.
프로덕트 매니저, 프로젝트 매니저, 프로그램 매니저는 어떻게 다른가?
25. 각 매니저가 관리해야 할 대상을 보자. 프로덕트 매니저는 프로덕트(혹은 서비스)다. 프로젝트 매니저는 시간, 비용, 리소스다. 프로그램 매니저는 특정 기능이다.
프로덕트 매니저
26. 프로덕트 매니저는 고객과 시대가 요청하는 사항을 잘 읽어 비전화하고 솔루션을 만든 후 제품과 서비스에 포함시키며 프로덕트 라이프 사이클을 책임지는 역할을 한다.
27. 프로덕트 매니저의 주요 역할
전략적인 사업 목표/비전에 맞춰 비즈니스 목표치 정의
고객 요청을 수렴해 요청에 부합하는 솔루션 제공
고객 요청을 우선순위로 정리하고 프로덕트 라이프 사이클 정의
경쟁 프로덕트와 비교하며 프로덕트의 지속 가능한 장점 구축
해당 프로덕트의 전체 책임자 역할(디자인, 개발, 디플로이먼트, 프로덕션)
수익 모델, 홍보 마케팅은 그룹 내 판매나 마케팅을 담당하는 부서와 협의
프로젝트 매니저
28. 주로 프로젝트의 타임라인과 진행 속도를 관리하는 역할이다. 타임라인과 진행 속도에는 리소스(시간, 인원, 비용)를 어떻게 효과적으로 투입할지, 그리고 투입 결과를 분석해 예정된 시간에 계획했던 기능을 포함한 프로젝트를 마치는 것까지 모두 포함된다.
29. 프로젝트 매니저의 주요 역할
위험 관리
자원 관리
범위 관리
30. 프로젝트 매니저는 예상하지 못한 상황을 헤쳐가면서 가용 가능한 리소스로 정해진 시간에 계획된 품질을 가진 프로덕트를 출시하는 것이 목표인 역할이다. 프로젝트가 개시로 시작하고 완료인 상태로 종료하도록 하는 것이 목표다.
프로그램 매니저
31. 프로그램 매니저는 크게 두 가지 역할로 나눌 수 있다. 첫째, 테크 기업에서 프로덕트 매니저와 비슷하지만 책임의 한계에서 특정 기능을 소유한 프로덕트 오너로 사용하는 경우다. 둘째, 전체 딜리버리를 책임진다고 해서 딜리버리 매니저의 개념도 있다. 프로젝트 매니저의 상위 매니저 같은 개념으로 이해하면 쉬울 것이다.
32. 프로그램 매니저는 각 프로덕트가 한 번에 세트로 묶여 나올 때의 비즈니스 임팩트와 그를 분석해 내는 역량을 요구한다. 해당 부분은 프로덕트 매니저가 볼 수 있는 비전의 한계를 넘어서는 프로그램 매니저의 고유 영역이다.
프로덕트 리더십 팀의 역할과 책임
33. 프로덕트 리더십 팀의 구성원이 모두 회사의 보고 라인에 있을 필요는 없으나 프로덕트의 사이클을 결정하는 데 상위에 있어야 한다. 즉 프로덕트 기능을 정의하고 구현 방법을 지휘하는 PM 역할과는 다른 상위 역할을 담당한다. 또한 시장이나 고객의 니즈를 충족시키면서 경쟁 프로덕트와 확실한 차별화 방법 및 성공적인 프로덕트가 될 수 있도록 항상 고민해야 한다.
프로덕트 방향 결정
34. 프로덕트 리더십 팀의 첫 번째 역할은 프로덕트 방향을 올바르고 투명하게 결정하는 일이다. 모든 구성원이 이해할 수 있도록 해야 한다.
프로덕트 팀 구성
35. 프로덕트 리더십 팀의 두 번째 역할은 프로덕트를 만들어낼 팀을 구성하고 조직하는 일이다. 일반적으로 다음과 같은 세 가지 기준이 필요하다.
프로덕트/프로그램 매니지먼트
디자인 매니지먼트(UX, 리서치 포함)
엔지니어링 매니지먼트
출시 프로세스 만들기
36. 프로덕트 리더십 팀의 세 번째 역할은 프로덕트를 출시하는 프로세스를 만드는 일이다. 여기서 말하는 프로세스는 실제 업무를 수행하는 데 필요한 ‘운영의 우수성'을 구축하는 프로세스가 아니다. 프로덕트를 위해 많은 팀이 함께 일할 때 어떤 구조를 가질 것인지에 관한 것이다.
PM과 PO의 차이
소프트웨어 프로덕트 구체화 과정
37. 1단계: 미션. 왜에 관한 것을 답한다. 해당 프로덕트가 존재해야 하는 목적을 설명한다. 그러다 보니 프로덕트 그룹의 리더십 팀이나 그룹장이 결정하고 하위 팀으로 커뮤니케이션하게 된다.
38. 2단계: 비전. 프로덕트를 사용할 때 고객이 어떤 혜택을 볼지 기술한다. 해당 내용이 구체화돼야 프로덕트 로드맵을 작성할 수 있다. PM 역할이다.
39. 3단계: 전략. PM이 가장 중점적으로 해야 하는 과정이다. 시장을 분석하고 테마 기능별 우선순위를 정한다. 프로덕트 성공에 관한 실제적이고 구체적인 지표를 설정하는 과정이다.
40. 4단계: 전술. 실제 프로덕트를 만드는 과정이다. 프로덕트를 완성하기 위한 백로그 아이템을 만들고 기능별 릴리스 플래닝을 세우고 진행한다. PO라는 직군이 조직 내 존재한다면 전술 과정을 담당한다.
프로덕트 그룹 조직
41. PM은 전체적인 프로덕트 ‘디스커버리'를 책임지는 역할을 수행한다. 올바른 문제에 집중하고 가장 가치 있는 아이디어를 구현하는 데 집중한다. 아이디어의 우선순위를 정하고 제품 비전과 전략을 지침으로 사용하며 어떤 아이디어가 시장과 사용자에게 가장 빨리 도달할 수 있는지 ‘발견'하는 데 초점을 맞춘다.
42. PO는 프로덕트나 특정 기능의 ‘딜리버리'를 책임진다. 아이디어의 가치가 고객에게 최대한 빨리 전달되도록 하는 역할을 수행하며 논의되고 결정된 결과에 대한 구현에 책임이 있다. 아이디어를 구현할 수 있는 에픽 및 사용자 스토리를 만들고 개발 과정을 각 팀과 함께 진행한다.
2. 프로덕트 라이프 사이클, 프로세스와 프레임워크
프로덕트 라이프 사이클 4단계
43. 1단계는 도입 단계다. 기업이 처음으로 프로덕트를 시장에 출시하는 시점이다. 도입 단계에서 제품을 즉시 구매하는 사람은 얼리 어답터뿐이다.
44. 2단계는 성장 단계다. 시장에서 프로덕트 반응이 생기고 판매가 증가하기 시작한다. 일반적으로 얼리 어답터 사용자의 꼬리 끝부터 사용자가 생겨난다.
45. 3단계는 성숙 단계다. 판매는 정점에 도달한다. 경쟁자가 나타나기 시작하며 대체로 솔루션을 갖고 시장에 진입한다.
46. 4단계는 쇠퇴 단계다. 프로덕트의 판매가 감소하기 시작하는 포화지점에 도달한다.
프로덕트 개발 라이프 사이클 7단계
47. 1단계는 연구 단계다. 사용자 문제를 수집한다. 아이디어나 생각하고 있는 솔루션을 브레인스토밍하면서 어떤 프로덕트를 만들어야 하는지 알아내고자 노력하는 단계다. 만들고자 하는 것이 무엇인지 명확하게 하는 시점이기도 하다.
48. 2단계는 계획을 세우는 단계다. 해당 프로덕트로 수익을 만들 수 있을지 확인하는 과정이다. 또한 만들 수 있다고 생각하는 프로덕트가 얼마나 시간이 걸릴지, 프로덕트의 특정 기능은 어느 시점에 가져야 하는지 등 전체적인 로드맵을 작성한다.
49. 3단계는 개발 단계다. 타임라인을 만들고 프로덕트에 포함될 기능을 작성한다. 사용자 스토리와 각 동작 사양을 구체화한다. 특정한 기능을 개발하는 데 얼마나 오래 걸릴지에 대한 구체적인 세부 사항, 이를 추정하고 개발 팀을 포함한 여러 이해관계자와 활발한 커뮤니케이션을 한다. 개발을 시작하기 전까지 모든 프로덕트 요구 사항을 설정해야 한다. 개발이 완료된 프로덕트나 최소 기능 제품 사양은 검증 테스트를 받을 때까지 변경하면 안 된다.
50. 4단계는 검증 단계다. 검증 대상은 개발이 완료된 프로덕트나 새로운 프로덕트의 MVP다. 출시하기 전에 올바른 방향으로 가고 있는지 확인하는 방법이다.
51. 5단계는 프로덕트 출시 단계다. 모든 부서와 이해관계자가 현재 프로덕트 상태에 동의하면 공식적으로 출시한다.
52. 6단계는 출시 후 극대화 단계다. 상황을 유지하면서 시장 반응에 따라 제품 프로모션을 지속적으로 행하며 가치를 극대화한다.
53. 7단계는 유지 또는 종료 단계다. 결정에는 다음과 같은 질문이 도움이 된다.
얼마나 자주 소비자들이 우리 제품이나 서비스를 구매하는가?
우리는 시장의 리더 위치에 머물고 있는가?
현재 해당 프로덕트 상태로 경쟁력이 있는가?
프로세스와 프레임워크
54. 방법론의 권위가 우리의 통찰력을 방해하지 않도록 해야 한다. 이보다 더 중요한 것은 훌륭한 방법론이 가진 권위가 여러분 프로덕트의 성공을 보장하지 않는다는 점을 알아야 한다. 효율적으로 도구를 사용하려면 해당 도구가 내 몸에 익혀지는 시간이 필요하다. 내 상황에 맞도록 도구 자체를 변경하고 수정해야 하는 경우도 빈번히 생긴다. 해당 도구 프로세스의 주인이 되는 연습이 필요하다.
마법 같은 표준 프로세스는 없다
55. 훌륭한 프로세스와 방법론이라고 모든 기업의 구조에 딱 맞을 수는 없다. 원칙을 지켜 방법론의 교과서적인 해석을 이해하고 소규모로 도입해 적용하고 학습하며 바꿔가면서 최적화 경험을 찾아야 한다. 방법론 그 자체가 제품과 서비스를 성공으로 이끌어주지 않는다는 사실을 꼭 기억하자.
디자인 씽킹
56. 디자인 씽킹은 제품의 UX, UI 및 가이드라인을 책임지는 디자이너나 PM이 사용자의 현재 문제나 애로 사항을 파악하고 솔루션을 디자인하는 과정에서 사용하는 창의적인 전략이다.
린 스타트업
57. 린 스타트업은 짧은 시간 동안 제품을 만들고 성과를 측정한 후 다음 제품 개선에 반영하는 것을 반복해 성공 확률을 높이는 경영 방법론의 일종이다.
58. 좋은 PM이라면 고객이 특정 제품이나 기능을 원할 때 어떻게 행동하는지 파악해야 한다. 해당 제품이나 서비스가 프로덕트를 지속할 수 있도록 고객의 관심을 받고 주머니를 열 수 있을지 정확히 알아야 한다.
59. ‘고객 행동 경험'을 빠르게 순환시켜야 고객이 반응하는 제품을 지속적으로 릴리스할 수 있다. 그러나 많은 기업은 PM에게 성공 경험만을 요구한다. 경험의 가치는 실패했을 때와 불확실한 상황이었을 때가 훨씬 가치 있다.
애자일 개발 프로세스
60. 애자일은 소프트웨어 개발에 린 스타트업 사고방식을 적용하는 방법이다. 소프트웨어 개발을 위한 일종의 프로젝트 관리 프레임워크다. 애자일은 소프트웨어를 개발하는 반복적인 방법으로 리소스를 낭비하지 않고자 작은 배치로 그룹화하고 수행한다.
61. 스크럼 1단계는 ‘스프린트 계획 회의'를 진행한다. 작업하기로 결정했거나 작업할 수 있는 모든 항목 중 우선순위가 큰 목록인 프로덕트 백로그로 실제 사이클이 시작된다. 백로그는 프로덕트 백로그와 스프린트 백로그가 있다. 프로덕트 백로그는 프로덕트의 전체 목표를 이루고자 정리한 기능 요청 리스트다. 스프린트 백로그는 특정 스프린트의 목표에만 해당된다.
62. 2단계는 ‘프로덕트 개발을 개시'한다. 스크럼 핵심은 팀이 수행하는 작업을 스프린트라고 하는 시간 프레임으로 묶는 것이다. 2주가 끝나면 스프린트 백로그의 모든 작업을 완료해야 한다. 완료하지 못해도 다음 스프린트로 넘어간다.
63. 3단계는 ‘스탠드업 미팅이나 리뷰'를 진행한다. 스탠드업 미팅의 목표는 모든 팀 구성원이 마지막으로 작업한 애용, 현재 작업 중인 작업 및 작업 다음에 작업할 작업을 간단히 이야기하는 것이다. 누가 누구에게 보고하는 것이 아닌 상호 소통을 목표로 한다. 스탠드업 미팅 중 질문이나 도움 요청이 있다면 그에 대해 이야기하는 것이 중요하다.
64. 4단계는 회고 회의를 진행한다. 잘된 것, 개선해야 할 부분, 사람들이 궁금해하는 것 등 다음을 위한 발전의 소재를 찾아낸다.
워터폴 개발 프로세스
65. 워터폴 개발이 유용한 예는 어떤 경우일까? 프로덕트가 통째로 나와야 의미가 있는 경우다.
프로세스를 효율적으로 사용하는 아홉 가지 팁
66. 첫째, 디자인 씽킹, 린 스타트업, 애자일에서 짧고 빠른 주기로 시행착오를 경험하자. 시행착오가 큰 위험이 없으려면 작은 단위로 나누자.
67. 둘째, 반드시 팀 업무 진행 상황의 정기적인 리뷰를 하자. 해당 리뷰나 회고 미팅을 하며 발견된 개선 요청 사항은 공유해야 한다. 개선 요청 사항 중 당장 실행할 수 있는 한두 가지를 골라 다음 사이클에서는 개선할 것을 결정한다. 모든 것을 한 번에 해결할 수는 없다.
68. 셋째, 각 그룹의 책임 매니저는 각 프로세스의 진행 상황을 충실히 파악하고자 중요 미팅에 반드시 참석하자. 단 업무 결정은 팀 자체에서 할 수 있도록 팀에 권한을 부여한다.
69. 넷째, 애자일, 린 스타트업, 디자인 씽킹의 교과서적인 원론에 너무 매달리지 마라.
70. 다섯째, 팀이 테스트와 실험, 베스트 프랙티스를 통해 자율적으로 업무 결정을 할 수 있는 권한을 가질 수 있도록 하자.
71. 여섯째, 커뮤니케이션은 지극히 투명하게 하자. 새로운 계획, 변경 사항, 전략 등을 설명할 때는 왜 행해야 하고 어떻게 진행할 것인지 공유한다.
72. 일곱째, 회고 결과를 긍정적인 피드백으로 공유하고 절대 경쟁적인 요소로 사용되지 않도록 주의하자.
73. 여덟째, 팀원 모두 동의할 수 있는 투명한 진행 지표를 정하자.
74. 마지막으로 위 여덟 가지보다 더 중요한 팁이다. 고객을 항상 업무 프로세스와 프로덕트 중심에 두자.
3. 고객 개발
고객 개발이란?
75. 새로운 고객을 개발한다는 것을 의미하는 것이 아니다. 고객사에 개발해 주는 것도 아니다. PM이 고객과 시장이 원하는 제품이나 서비스를 만들고 있는지 여부를 판단하는 방법과 그 과정 전체를 말한다.
고객 개발의 4단계
76. 1단계 ‘고객 발견' 목표는 프로덕트 고객은 누구이며 해결하려는 문제가 고객에게 중요한지 여부를 결정하는 것이다. 고객 발견의 다음 단계인 ‘고객 검증'은 영업 및 마케팅 팀에서 반복할 수 있는 영업 프로세스를 구축하는 것이다. 그다음 고객 검증에서 발견한 성공을 기반으로 프로덕트 수요를 증가시키는 ‘고객 창출'이다. 마지막으로 고객 개발의 마지막 단계는 ‘구축'이다. 해당 프로세스가 더욱 공식화된 구조로 변환된다.
사용자 스토리로 문제 가설 세우기
77. 가설은 ‘사용자 스토리'를 작성한다. 사용자 스토리는 고객 입장에서 작성한다.
78. 사용자 스토리는 구축할 대상을 정의하는 프로덕트 요구 사항을 작성하는 공통 형식이다. PM 업무의 핵심이다. 사용자 스토리를 사용하지 않아도 사용자를 이해하는 방법은 여러 가지가 있지만 템플릿을 사용해 사용자를 주어로 하는 문장을 만드는 데는 다음과 같은 이점이 있다.
의식적 혹은 무의식적으로 고객/사용자 입장에서 생각하게 된다. 고객 입장을 변호하는 상황이 자연스럽게 만들어진다.
변호하는 상황에서는 지속적으로, 더 발전된 형태의 방법과 이유를 찾게 된다.
애자일 개발 환경에서 기능을 설명하는 문서의 복잡함은 줄이고 실제로 가장 필요한 것만 남길 수 있다.
고객 설문 조사
79. 좋은 설문 조사는 짧아야 한다. 긴 설문 조사는 사용자가 설문 조사가 끝날 때까지 지루함을 느낀다. 지루함은 조사 데이터의 품질을 좌우한다. 설문 조사의 모든 질문에는 특정 목적이나 통찰력이 있어야 하며, 질문을 그룹화하는 방법도 설계해야 한다.
고객 인터뷰
좋은 질문과 나쁜 질문은 어떻게 다른가?
80. 어떻게 고객에게 질문해야 할까? 몇 가지 규칙이 있다. 첫 번째 규칙은 항상 개방형 질문을 하는 것이다. 예 또는 아니오 또는 특정 정보로 대답할 수 없는 질문을 한다. 개방형 질문을 하면 고객에게 자유도와 대답할 수 있는 여지를 제공하고 자신이 적합하다고 생각하는 정보를 제공한다. 두 번째 규칙은 바이너리 질문을 하지 않는 것이다. 바이너리 질문이란 예 또는 아니오로만 대답할 수 있는 질문을 말한다. 세 번째 규칙은 가상의 질문을 하지 않는 것이다. 네 번째 규칙은 유도 질문을 하지 않는 것이다. 대답해야 하는 고객에게 편견을 심어주거나 영향을 미치는 질문이다. 다섯 번째 규칙은 고객이 거짓말할 수 있는 가능성이 있는 질문은 하지 않는 것이다.
