book_030. 조직을 성공으로 이끄는 프로덕트 오너 PO가 말하는 애자일 혁신 전략

조직을 성공으로 이끄는 프로덕트 오너 PO가 말하는 애자일 혁신 전략

 

|  목차  |

추천의 글
프롤로그

1장 프로덕트 오너PO는 미니 CEO다
PO는 중심에 있다
독재자형 리더는 안 된다
책임은 있지만 권한은 없다
고객에 집착하고 또 집착하라
TIP 1 PO가 되기 위해 필요한 자질

2장 고객의 목소리를 어디까지 반영할 것인가
고객은 제품을 사지 않는다, 고용한다
서비스는 하나라도 사용자 유형은 다양하다
모든 사람을 만족시킬 수는 없다
식스 페이저로 모두의 동의를 얻어 기록하라
고객의 요청과 회사가 정한 목표가 충돌한다면
TIP 2 페르소나와 고객을 혼동하지 마라

3장 데이터 속에서 진실을 찾는 법
자신을 믿지 말고 데이터를 신뢰하라
대시보드를 통해 정기적으로 확인하라
행동을 부르지 않는 데이터는 버린다
가설을 세우고 조직의 방향성OKR까지 관리하라
리스크를 최소화하기 위한 데이터 검증법
TIP 3 데이터 대시보드도 프로덕트다

4장 효율적인 일정 관리의 비밀
스토리 티켓으로 누구에게 무엇을 알려야 하나?
PO가 해서는 안 되는 일
스크럼 회의 때 해야 할 일들
TIP 4 자신만의 백로그 관리 방법을 갖추기

5장 디자이너를 최고의 파트너로 삼는 법
디자이너는 PO의 의도를 구현해주는 최고의 파트너다
과연 편리하고 직관적인 디자인인가?
동료 직원을 대상으로 캐주얼 UT를 하라
TIP 5 의견과 요구사항은 다르다

6장 개발팀과의 협업을 성과로 이끄는 애자일 전략
확실한 프로젝트 수행법, 스프린트 플래닝
완료일을 언제로 잡는 것이 시기적절한가
모든 질문에 대답할 수 있는 소통의 기술
TIP 6 속도와 확장성 사이에서 고민하라

7장 고객 테스트 결과만큼 강력한 데이터는 없다
사용자 테스트UT로 문제점을 보완하라
빠른 피드백 공유는 동기부여가 된다
스프린트 기간 중 언제 테스트하는 것이 효과적인가
TIP 7 UT는 설문조사가 아니다

8장 프로덕트를 출시하는 최적의 시기
배포 일정을 정할 때 플랫폼을 고려하라
A/B 테스트를 활용해 트래픽을 분산하기
내부 직원도 고객이다
TIP 8 올바른 배포 문화를 만들자

9장 테스트 중 가설을 효과적으로 검증하려면
A/B 테스트와 P값을 활용한 가설 검증법
실패를 인정할 줄 알아야 더 나은 경험을 제공할 수 있다
통계적인 결과를 토대로 결정해야 진실에 가까워진다
TIP 9 검증하려는 수치는 미리 정하자

10장 론칭한 서비스의 문제를 바로잡기
업데이트 소식을 고객센터에 먼저 전달하라
프로덕트는 완벽할 리 없다
시간 낭비를 최소화하기 위한 전략
고객의 소리를 들을 수 있는 환경을 조성하라
멀티태스킹으로 문제를 해결하는 세 가지 원칙
TIP 10 5 Why 방식을 고수하자

11장 어떤 인재를 PO로 선발해야 하는가
PO 채용에 앞서 일감부터 확인하자
무한한 잠재력을 알아보는 법
능력 있는 PO로 성장하는 길
TIP 11 처음부터 PO가 아니어도 된다

 

---

프로덕트 오너를 mini ceo라고 할만큼 그 직무가 갖는 무게는 무겁다. 직접 디자인이나 코딩은 하지 않지만 프로덕트의 처음부터 끝까지 책임지는 역할을 하기 때문이다. 프로덕트 오너에게 가장 필요한 자질은 똑똑한 머리도 화려한 스팩도 아닌 맡은 제품에 대한 열정과 집착이라는 것을 책을 통해 알 수 있다. 왜냐하면 그들은 해당 프로덕트를 통해 고객에게 '감동'을 주려는 이들이기 때문이다. 이 추상적이면서도 모든것을 포괄하는 '감동' 이라는 단어를 납득가능하게 하기 위해 프로덕트 오너들은 사소한것 하나에도 고객을 담는다. 그러면서도 판단은 '데이터' 중심으로 냉철하고 현실적으로 한다. 아무나 할 수 있지만 또 아무나 할 수 없는 직무, 그러나 저자는 그 직무가 자신은 너무 재미있다고 한다. 프로덕트 오너로서 비즈니스 전략을 짜고 이행하고 팀을 결합시켜 나가는 과정을 함께 따라가보고 '가설'과 '실행'으로 짜여진 일상을 느껴보자.

---

 

---

1장 프로덕트 오너PO는 미니 CEO다

| 고객에게 집착하고 또 집착하라

- 넷플릭스 CEO : '스피브 잡스 같은 리더는 고객이 뭘 원하는지 아는 센스가 있는데, 나는 그게 없다. 우리는 고객에게 과학적인 접근을 할 필요가 있다. _p47

- PO는 고객에 집착해서 최고의 경험을 제공해야 한다. 또한 이에 머물지 않고, 고객에 집착하는 사고방식을 주변 동료들에게 전파해야 한다. 단순히 개발을 하거나 디자인 시안을 만드는 것이 아니라, 그것이 고객에게 얼마나 큰 감동을 줄 수 있는지 각자 충분히 인지할 수 있도록 설명해주는 것도 PO의 몫이다. 모두가 고객에 집착할 때까지 PO에게는 직접 현장에서 터득하고 정보를 공유해야 하는 책임이 있다. _p52

 

| PO가 되기 위해 필요한 자질

---

2장 고객의 목소리를 어디까지 반영할 것인가

| 고객은 제품을 사지 않는다, 고용한다

- "하버드 비즈니스 스쿨" 인터뷰 : 고객은 해결해야 할 일이 생길 때, 그것에 도움을 주는 제품을 '고용(구매)' 한다. 제품이 단순히 구매된다는 관점에서 벗어나, 고객이 무엇을 해결하기 위해 어떤 제품을 고용했는지 생각해봐야 한다. 모든 제품과 서비스를 고용의 대상으로 바라보면, 각각 어떤 일을 고객을 위해 해줘야 하는지 알 수 있다. 그게 고객에게 전달되는 실제 가치다._p60

 

| 식스 페이저(6-Pager)

프로덕트를 만들기 전이나, 혹은 매 분기별로 문서를 하나 작성한다. 여섯 페이지 이내에 해당 프로덕트에 대한 핵심 내용을 담아 내는 것이다. 이 문서는 개발팀은 물론 임원진, 다른 유관 부서 등에 언제든지 공유할 수 있도록 준비해둔다. 임원진의 검토를 받고, 피드백을 통해 문서를 개선하고, 확정된 뒤에야 개발에 착수한다. 

1) 프로덕트의 목적이 무엇인지 (=우리는 고객을 위해 어떤 일을 하는가?)

2) 과거에 어떤 관련된 시도를 했는지

3) 어떤 실패 사례가 있었는지

4) 앞으로 어떤 방향으로 개발할 건지

5) 어떤 수치를 활용해서 성공 여부를 확인할 것인지

 

| 서비스는 하나라도 사용자 유형은 다양하다

- PO라면 동일한 프로덕트를 고용하는 고객이 다양하다는 점을 명심해야 한다. 다양성 속에서 동일한 의도를 찾아 고객을 분류하자. 각각 프로덕트를 고용하는 이유를 파악한 후, 그것에 맞춰 프로덕트를 개선해야 한다. PO가 고객 분류만 잘해도 절반은 성공적으로 완수했다고 본다. 모든 고객에 대한 이해가 이뤄져야 분류 자체를 온전히 할수 있기 때문이다. 그 이후는 프로덕트를 어떻게 잘 개선해야 하는지에만 집중하면 된다._p73

 

| 식스 페이저 문서 작성

- 가이드원칙 이라고 부르는 이 부분에는 주로 4~6개 원칙 목록화한다. 1번이 가장 중요한 원칙이고, 내려갈수록 부수적인 것들로 채운다. 이 원칙은 허투루 작성해서는 안된다. 너무 길어서도 안되고 명확한 단어들로 구성한다. 동료, 상사, 경영진 등의 검토를 거치며 보완하고 최종적으로 모두 동의하는 원칙이 정해졌을때, 개발에 착수한다._p82

 

| 고객 요청과 회사거 정한 목표 충돌

- 언제나 회사의 목표를 모두가 동일하게 이해하고 있는지 확인. 모두가 사업 방향성을 이해하고 있어야 한다고 믿는다.

- 논의 끝에 회사가 반대할 경우, PO는 바로 수긍해야 한다. PO는 회사의 성장 전략과 비용 관리 등을 하는 역할이 아니기 때문이다. 전문가의 판단하에 특정 프로덕트에 대한 투자를 단행할 수 없다고 결정되면, PO는 그 방법을 제외하도록 한다. 어디까지나 PO는 주어진 자원을 활용해서 프로덕트를 개선해야 하는 책임이 있기 때문이다. _p91