훌륭한 제품팀에서는 어떻게 일하고 있을까?
인스파이어드 (마티 케이건)
훌륭한 제품팀에서는 어떻게 일하고 있을까? 스타트업이든 대기업이든 훌륭한 제품팀에서 발견한 특징은 ‘비즈니스 성과’를 달성하기 위해 소통하고 노력하며, 작고 빠른 단위로 실행에 옮겨 보고, 이 과정을 무수히 반복한다는 것. 이 과정에서 용병이 아닌 미션팀으로 움직이고 있다는 점이었다. 작가가 말하는 미션팀이 되기 위해 갖춰야 할 사람, 제품, 프로세스, 문화에 대해 알아보자.
1장) 최고의 기술 기업에서 배운 것
최고의 기술 기업에는 아래 7가지 요소가 포함되어 있다고 한다.
①훌륭한 제품을 이끄는 사람
②기술 중심의 제품과 서비스
③스타트업 : 제품과 시장 궁합 찾기
—> 그로스 해킹에서 읽었던 PMF가 맞는 제품인지 꼭 검증하고 시작하라는 내용이 생각났다.
④성장 단계의 회사 : 성공을 위한 확장
⑤대기업 : 끊임없는 제품 혁신
⑥실패한 제품의 근본 원인 중 나에게 가장 와닿았던 부분을 추려보았다.(워터폴 프로세스의 문제점)
1) 아이디어의 출처: 판매 확대를 위한 기능이나 이해관계자 위주로 제품이 끌러가게 된다. 외부 용병처럼 그저 열심히 실행하는 것이 되어 버린다.
2) 엔지니어들이 너무 늦게 참여한다. 그럼 코드를 짜는 일만 하는데 불과하다.
3) 프로젝트 중심적이다. 프로젝트는 ‘기능을 만드는 결과물‘에 대한 것이고, 제품은 ’그 기능으로 어떤 문제점과 지표를 개선했는지 비즈니스 성과‘에 대한 것이다.
⑦ 린과 애자일을 넘어서
1) 위험은 마지막보다는 초기에 대응한다.
2) 제품은 순차적인 방식보다는 함께 협업하며 정의되고 설계한다.
3) 기능을 구현하는 것이 아니라 문제를 해결한다.
2장) 사람
[제품팀]
1) 우리가 원하는 것은 용병팀이 아닌 미션팀이다.
2) 제품 관리자: 고객/데이터/비즈니스/시장과 산업에 대한 깊은 이해가 필요하다.
3) 컴퓨터 프로그래밍 개론, 회계/재무
4) 제인 매닝(구글) : 구글 애드워즈
[사람의 확장]
1) 제품 총괄의 역할: 팀 개발 / 제품 비전과 전략 / 실행 / 제품 문화
2) 기술 총괄
3) 제품 실행 관리자 (=스크럼 마스터): 따로 없는 경우, 제품 관리자나 엔지니어 관리자의 책임이 된다.
- 사례: 레아 힉맨(어도비)
3장) 제품
1)제품 로드맵의 문제점과 대안
전통적인 로드맵은 제품을 출시하는데 초점을 맞추었는데, ‘출시’에 초점을 맞춰 로드맵을 작성하면 안된다. 해결해야 할 문제 위주의 ‘성과 중심의 로드맵’을 작성해야 한다. (OKR)
제품의 비전과 전력, 사업 목표를 녹여 로드맵을 작성하는 것이 하나의 방법이다. 성과 중심으로 작성하는 중에 Task들의 일정이 로드맵에 녹여지게 될 때도 있다. 이것은 꼭 일정을 지켜야한다는 걸 의미하는 건 아니다. (높은 신뢰 수준의 약속으로 목표일을 지키는 것도 필요하다) 중요한 것은 성과 지표 달성이다.
제품의 비전과 전략 : 전체 조직이 무엇을 달성하기 위해 노력하는지, 그 비전을 달성하기 위한 계획은 무엇인지에 대한 큰 그림을 설명한다.
사업 목표 : 각 제품팀에 대한 구체적이고 우선순위가 명확한 사업 목표를 설명한다. (팀이 달성하기 원하는 것과 그 성과가 어떻게 측정될지 말해준다)
2) 제품 비전과 제품 전략
제품 비전은 영감을 줄 수 있는 (도전적인) 내용이어야 하며, 제품 전략은 분명한 초점이 있어 목표한 곳으로 이끄는데 도움을 줄 수 있어야 한다.
제품 비전이 당신이 만들고자 하는 미래에 대한 설명이라면, 제품 전략은 그 비전을 달성하는 길을 말해준다. 여기서 제품 원칙이란 당신이 만들고자 하는 제품의 특성을 말한다.
제품 비전 : 솔루션이 아니라 문제와 사랑에 빠져라, 도전적으로, 현재를 파괴해서 잡아라, 집요하게 비전을 전파하라
제품 전략 : 한 번에 한가지 시장/고객에 집중하라, 사업 전략과 연계되어야 한다, 영업 및 시장 진출 전략과 연계되어야 한다, 경쟁사가 아닌 고객에 집착하라
제품 원칙 : 만들고자 하는 제품의 특성
3) 제품 목표
OKR 기법 : 목표는 정성적, 핵심 성과는 정량적 (ex. 고객이 원하는 상품을 더 쉽게 찾을 수 있도록 한다. / PV수 증대, 고객 인당 PV수 증대)
제품 조직에서 OKR을 적용할 때는 OKR을 제품팀 레벨로 초점을 맞추는 것이 핵심이다. (기능 조직의 목표가 있다면, 다른 사업 목표들과 연계해서 리더십 레벨에서 먼저 우선순위가 논의되어야 한다)
4) 제품의 확장
회사 목표 —> 조직 전체 레벨의 목표를 분명하게 이해 —> 각 상호 지원이 필요한 경우가 생기는데, 의존성과 관계성을 잘 조율해야한다 —> 리더십에서 조정의 단계를 거친다. —> 투명하게 공유하고, 적극적으로 관리하고 추적한다.
리더십과 경영진은 조직이 실제로 긴밀히 연계되도록 더 많은 노력이 필요하다. 각 제품팀은 그들이 기여하는 것이 무엇이고, 그들이 전체의 범주에 어떻게 들어가 있는지 이해해야 한다.
제품 에반젤리즘 : 꿈을 파는 것, 영감을 불어넣는 것
4장) 프로세스
제품이 만들어지는 프로세스를 요약하면 아래와 같다.
1) 제품의 발견 (아래에 대응하는 것이다)
고객이 이 제품을 사용할 것인가? (가치 위험)
사용자가 이 제품의 사용 방법을 이해할 수 있는가? (사용성 위험)
우리가 만들 수 있는 것인가? (실현 가능성 위험)
우리 사업에 효과가 있는 솔루션인가? (사업 유효성 위험)
2) 제품 발견 구조화 기법
- 기회 평가 기법
- 거꾸로 일하기 : 언론 홍보를 가정하는 것에서부터 제품 업무를 시작하는 것.제품팀이 만들기로 한 모든 기능에 대해 즉각적으로 빠져들도록 매료시킨다. 여기서 제품의 가치를 느끼지 못한다면 재검토를 해보아야 한다.
- 고객 편지 기법 : 홍보 기사의 형식으로 고객의 효익을 전달하는 것 대신 명확히 정의된 하나의 사용자 또는 고객 페르소나가 가상의 관점으로 작성한 고객 편지 형식
- 스타트업 캔버스 기법
3) 제품 발견 계획 기법
참조 고객(=실제 제품을 돈을 주고 사용하는 고객으로, 당신의 제품을 얼마나 사랑하는지 다른 사람들에게 이야기할 의사가 있는 사람들)이 중요하다.
4) 아이디어 발상 기법
- 사용자 테스트, 안내인 테스트
- 고객 일탈 행동의 힘: 당신의 고객이 예측하지 못한 방법으로 당신의 제품을 사용하고 있다면, 이는 잠재적으로 매우 소중한 정보가 된다.
5) 프로토타이핑 기법
형태에는 실현 가능성, 사용자, 라이브 데이터, 혼합 프로토타이핑이 있다.
어떤 형태의 프로토타입이건 가장 중요한 목적은 실제 제품을 만드는 것보다 시간과 노력의 측면에서 훨씬 더 적은 비용으로 학습하는 것이다.
6) 제품 발견 테스트 기법
정성적인 가치 테스트: 인터뷰, 사용성 테스트
정량적인 가치 테스트: A/B test, 초대 테스트, 고객 발견 프로그램
실현 가능성과 사업 유효성까지 살펴보아야 한다.
사용자 테스트 vs 제품 데모 vs 워크스루(=이해관계자에게 프로토파입을 보여줄 때 그들이 잘 이해하는지 분명히 하고, 우려가 될 수 있는 모든 사항을 기록하는 것이다)
7) 변화 기법
제품 발견 스프린트: 1주 단위(time box)로 제품 발견 업무를 진행하는 것으로서 제품팀이 당면한 중요한 문제나 위험을 처리하기 위해 설계되었다.
로드맵 끊기 : 특정 날짜에 출시하는 구체적인 기능에서 비즈니스 성과로 조직의 초점이 변하는 것을 목표로 한다.
8) 프로세스의 확장
이해관계자를 잘 관리하는 것도 중요하다. 신뢰를 주어야 한다.
높은 위치의 관리자를 뽑을 때, 기존의 혁신을 경험하고 정체된 회사에서 데려오는 경우가 많다. 회사가 풀고 싶은 문제점이 무엇인지 확실히 공유하고 이에 맞는 사람을 뽑는 과정이 필요하다.
5장) 문화
혁신을 잃는 10가지 이유 (다음을 잘 지키고 있는지 확인 할 것) :
고객 중심의 문화, 강렬한 제품 비전, 제품 전략의 초점, 제품 마인드, 자율성, 혁신의 속도
속도를 잃는 10가지 이유: 기술 부채, 뛰어난 제품 관리자의 부재, 우선순위의 변경, 합의의 문화
PM의 바이블이다, 읽으면 좋다는 얘기를 많이 들어 읽기 시작한 책이었지만
지금보다는 시니어 혹은 관리자 단계에서 다시 읽어본다면 더 좋을 책이라는 생각이 들었다.
읽으면서 내 회사는 어떤 팀에 용병팀인가 미션팀인가 비교하면서 읽게 되었는데, 초반에는 스프린트도 진행하면서 미션팀에 가깝다는 생각을 했었는데 최근에는 아이디어의 출처가 이해관계자에 더 가깝게 작용하게 되면서 그리고 제품을 출시하기에 바쁜 느낌이 드는 좋지 않은 형태의 제품팀이 되어가는 것 같았다.
그런 와중에 내가 PM으로서 작게나마 실행할 수 있는 것은 무엇일까?
(1) 항상 사용자 관점에서 문제점을 생각하고, 문제점을 해결하기 위한 솔루션을 잘 고민해보는 것
(2) 과제를 진행할 때, 개발자와 디자이너에게도 의견을 많이 들어가면서 "애자일"하게 일하도록 노력하는 것
(3) 내가 맡은 제품의 가치와 회사의 비전에 대해 꾸준히 인지하는 것
나도 사람들에게 사랑받는 제품을 만들고 관리하고 싶다.
