[북리뷰] 프로덕트 오너

https://www.yes24.com/Product/Goods/89553345

프로덕트 오너 - 예스24

 

 

PM 직무를 꿈꾸는 나이기에 PM을 꿈꾸는 사람들의 바이블이라 할 수 있는
<프로덕트 오너>를 읽어 보았다.

PM이 어떤 직무인지, 어떤 사람을 뽑고 싶어 하는지, 실무에서 활용할 팁 등을 얻을 수 있어서 유익했다.

(1) PO는 어떤 직무 인가

 

PO가 하는 업무

PO는 고객이 무엇을 필요로 하는지 끊임없이 분석 선보이려는 서비스가 사업 목표와 부합하는지 검증한다
고객이 원하는 바가 다양할때 po는 우선순위를 정한다 그리고 회사가 추구하는 사업 목적과 부합하는지도
확인하라.
원하는 바가 없을 땐 침묵속에 숨겨진 문제가 무엇인지도 찾을 수도 있다.
회사가 갑자기 중장기적 목표를 바꿀수도 있다.
결론이 내려질때까지 언제나 회사 내부에서도 귀 기울이며 모두가 동의하는 결정 내려질때까지 대화를
이어간다.
데이터를 기반한 근거을 지시하며 설득하도록 한다. 명백하게 틀릴경우 바로 수긍 한다.

 

PO는 감정을 배제하고 소통해야 한다

PO는 모두가 지켜보는 존재이다.
PO가 방어적이거나 감정적인 태도를 보이면 모두가 그것을 느낄 수 있다.
주위 사람들은 내 언행에 많은 영향을 받기 때문에 감정이 내비쳐질 단어는 애초에 배제하고 소통하자.

 

독재자형 리더는 안된다

회사내 급하게 결정된 사항을 다른 사람들에게 일정 설득해야한다. 일방적으로 통보하면 존중받기 어렵다.
왜 변경되엇는지 무엇을 이루고자 하는지 당연히 알려주어야 한다.
PO는 동료들이 직무에 집중할 수 잇도록 부수적인 일들을 도맡아 한다.
회의내용 정리, 주고받은  내용 번역, 고객과 나눈 대화 설명.

 

책임은 있지만 권한은 없다

ceo처럼 권한이 있는 것이 아니라 지시가 아니라 설득을 해야 한다.
그래서 사실을 서숧하거나 설명새주는 것이 PO의 역할이다.
실력을 끊임 없이 증명하면서 존중 받아야 한다.
부여된 책임감은 많지만 권한이 없는 PO는 언제나 겸손해야 한다.

 

고객에 집착하라

고객에게 감동을 줄 수 있도록 직접 현장에서 터득하고 동료에게 공유해 인지할수 잇도록
설명해주는 것도 PO의 몫이다.

(2) PO가 되기 위한 자질

 

학력 및 전공

컴퓨터 공학 전공
심리 경제 정치 경영 전공보다는 논리적 사고방식

 

업무 경험

개발 프로직트 처음부터 끝까지 경험
기획 디자인 개발 출시 까지(스타트업 경험)
무엇을 왜 시작, 그 과정에서 어떤 결정을 내렷고 성공여부를 어떻게 수치로 판단햇는지

어떤 업무를 맡앗고 얼마나 체계적인 사고방식으로 깊게 분석햇으며 어떤 데이터를 기반으로
이성적인 판단을 내렷는지 증명 가능
자신의 결정이 고객에게 어떤 영향을 끼쳤는지 명확하게 이해 필요

성향 및 능력

이성적으로 수치화, 웡칙에 의거해 판단할 수 잇는 논리적인 사고방식
다양한 정보를 집요하게 파고들어 인사이트를 도출해낼 수 잇는 분석 능력
우선순위를 정할 수 잇는 가시적인 시야
공통적인 목적 명시 구체적인 요구사항을 정리하는 커뮤니케이션 능력
어떤 시안이 가장 효과적인지 판단할 수 잇는 디자인적 소양도 도움된다
실패를 인정하고 빨리 포기할 수 잇는 결단력 필요
고객이 누구인지 판단하고 집착해서 최상의 경험을 제공하고자 하는 끈질김 필요

 

(3) 고객의 목소리를 어디까지 반영할 것 인가

 

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

하버드 클레이튼 크리스텐슨 교수:  신제품 실패이유는 잘못된 시장분석 때문
고객은 해결해야할 일이 생길 때 그것에 도움을 주는 제품을 고용한다.
어떤일을 고객을 위해 해줘야 하는지 알아야 한다.
박물관을 넷플릭스가 대체하듯이 책임지고 잇는 프로덕트의 고객이 대체물로 고용할 수 잇는 그 모든 것을
고려하도록 하자.
바로 눈앞에 보이는 누구나 다 알고 있는 경쟁자가 전부가 아닐 수도 잇기 때문이다.
PO는 고객이 흔쾌히 고용할 프로덕트를 만들고 꾸준히 개선해야 한다.

 

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

PO가 범하기 쉬운 실수 중 하나는 프로덕트를 만드는 사람의 관점에서 고객을 바라보는 것이다.
그렇게 하면 무의식적으로 PO자신이 만들고 싶어 하는 방향으로 데이터를 해석하고 결정해버릴 수 있다.

PO는 절대 자신의 직관이나 바람에 의한 결정을 내려서는 안된다.
직접 프로덕트를 사용해보는 것보다 고객 분류 세분화에 좋은 것은 없다.
다양성 속에서 동일한 의도를 찾아 고객을 분류
프로덕트를 고용하는 이유 파악 후, 프로덕트를 개선

모든 사람을 만족 시킬 수는 없다.

PO는 쉽고 간단하게 고쳐서 최대한 개선된 경험을 제공할 수 있도록 늘 살펴야 한다
자원은 한정적이기 때문에 모든 고객의 의견을 다 들어줄 수는 없다.
얼마나 많은 고객에게 영향을 끼치는지 확인이 필요하다.
강박적으로 정보를 요구하고 직접 그 수치를 검증하지 않으면 불필요한 곳에 자원을 투자하는 실수를
범할 수 있다.
언제나 우선순위를 정해야한다. 한정된 자원을 가장 효과적으로 활용할지 고민 필요

식스페이저로 모두의 동의를 얻어 기록하자 (원칙 정하기)

결정을 내릴 때 잣대로 삼을 수 잇는 원칙이 잇으면 도움이 된다
토론하다 주장 뒷받침할 때 등

식스 페이저 문서 작성 시 가이드 원칙 목록화
개발 운영시 지켜야 할 법이다

다른 PO가 프로덕트 넘겨받더라도 원칙을 따를 경우 문제없이 개발이 이어지도록 정확해야 한다.
원칙을 정하면 결정 내릴 때 도움이 됨

시간 투자해 최대한 많은 부분에 대해 고민한 후에 원칙을 정해야 한다.
나중에 방향성을 바꿔야 할 수도 있기 때문이다.
매 분기별로 원칙 점검 추천
원칙이 잘 유지되면 동료들이 프로덕트를 이해하기 수월해진다.

 

고객의 요청과 회사가 정한 목표가 충돌한다면

회사가 건강하게 성장해야 고객에게 더 훌륭한 경험을 제공할 기회가 많아진다.
고객과 사업이 필요로 하는 사항을 동시에 고려해야 한다.
회사의 목표가 뚜렷하지 않다면 목표를 설정하는 책임자에게 과감하게 질문을 던져야 한다
그래야 하나의 집단으로 전진할 수 잇다
추진하고 싶은 프로덕트가 있는 경우 회사에 끼치는 영향을 두루 설명해야 한다.
논의 끝에 회사에서 반대할 경우 PO는 바로 수긍해야 한다.
po는 회사 성장 전략과 비용 관리등을 하는
역할이 아니기 때문이다.

 

페르소나와 고객 혼동하지 마라

특정 페르소나 몇가지가 전체 고객을 충분히 대변할 거라는 착각을 할 수 있다
페르소나 설정 타당성 검증을 위해 ut를 편파적으로 해석할 수 있다.
서로 다르게 주관적으로 해석할 수 잇다

 

(4) 데이터 속에서 진실을 찾는 법

 

자신을 믿지 말고 데이터를 신뢰하라

매 결정이 상당히 큰 영향을 끼치므로 직관에 의존하지 말고 이성적으로 판단하도록 데이터에 기반한
사고방식을 갖추도록 한다.
의도적이던 아니던 정보를 자신의 주장을 뒷받침하는 방향으로 다루지 않도록 하자
주어진 데이터를 그대로 받아들이지 말고 거짓이라고 가정해본 후 철저하게 파고들어야 한다

 

대시보드를 통해 정기적으로 확인하라

프로덕트의 효율적 검토를 위해
1. 주요 대시보드 만들기
자주 확인해야만 하는 지표를 정하고 그걸 졸 수잇는 대시보드 생성
직접 추출보다 애널리스트에게 도움 요청

 

2. WBR 만들기
주간 실적 보고
변동사항, 현재 문제점 파악

3. OKR 달성여부 파악
주요지표 보여주기
집중해서 파악해야할 부분 확인 및 해결책 도출 도움

행동을 부르지 않는 데이터는 버린다

데이터 분석 결과는 참조 할 수 잇는것
어떤 행동으로 옮겨 무언가를 바꿀 수 있게 해주는것
무엇을 고칠 수 있는지 확인이 안된다면 데이터 과감히 무시

PO는 데이터를 단면적으로 보아서는 안된다.
쓸데없는 이슈를 파악하는 데 시간낭비 하지 않도록 액셔너블한지 아닌지 재빨리 알아내야 한다.

 

가설을 세우고 조직의 방향성까지 관리하라

개인의 감정, 자신의 바람 등을 철저하게 배제하고 중립적인 자세로 가설을 도출하라.
명확한 결과를 얻기 위해 치밀하게 검증하길 바란다.
가설을 기반으로 OKR설정

리스크를 최소화 하기 위한 데이터 검증법

가설 공표 후 수치를 검증할 준비
테스트하는 도중 수시로 데이터를 확인할 수 잇는 환경 만들도록 한다.

어떤 데이터가 축적되고 잇는지 명확하게 알아야 한다.
필요한 데이터가 쌓일 수 잇는 구조로 개선 요구
a/b테스트가 가장 널리 이용됨

 

<<효율적인 일덩 관리의 비밀>>
<스토리 티켓으로 누구에게 무엇을 알려야 하나>
기능 개발 전 문서 작성 후 개발자에게 공유
회의전 읽어와달라 부탁 후 구두로 설명 질문받음
바로 답변하거나 최대한 빨리 답변드리겟다고 함

서로 이해가 맞아떨어지지 않을 경우 프로덕트가 제대로 완성이 되지 않는다.
시간 또는 기회 낭비를 방지하고자 최선을 다해 문서를 작성한다

po가 존중받는 확실한 방식은 요구사항 명확히 전달하는 것

<po가 해서는 안 되는 일>
po가 코딩 잘못해 버그 생기면 고객 경험에 악영향 끼치기 때문에 코딩 참여x
디자인도 마찬가지
po는 방향성 제시하는데 집중
본연 업무에 투자하디 못한 시간은 회사와 고객에게 낭비로 남게 된다
R&R구분 필요
고객에게 가장 큰 영향을 끼치는 업무인지 자문할 것

<<고객 테스트 결과 만큼 강력한 데이터는 없다>>
<사용자 테스트 ut로 문제점을 보완하라>
고객으로부터 직접 듣지 않으면 놓치는 점도 많다
ut로 효과적으로 확인 가능

사전에 무엇을 하고자 하는지 정리해놓으면 도움됨

po는 촤대한 힌트를 주지 않도록 한다
질문을 통해 행동이나 답변 유도하지 말고 의도파악만 할 것

<빠른 피드백 공유는 동기부여가 된다>
ut결과 빠르게 공유해서 일정차질 없도록 한다
어떤 수정사항 발생할지 알리기

기록된 피드백을 찾아 왜 특정 방식으로 결정햇는지 설명 가능하다

<<어떤 인재를 po로 채용해야 하는가>>
기업이 po를 고용할 최소 조건
1. 전적인 오너십
데이터를 보고 고객의 소리를 듣고 가설을 설정하지 못한다면 po필요 없다

2. po가 협업할 수 잇는 전담 개발 조직 필요
개발조직 없이 가설 설정, 보고서 작성만 한다면 필요없음
외주 업체 이용한다면 자체 pm이 잇는 경우가 많음

<무한한 잠재력을 알아보는 법>
어떤 학교를 나왓는지 등은 중요하지 않고
현재의 사고방식을 이해하는데 시간을 투자하고 싶다.
여러가지 결정을 왜 어떻게 내렸는지 이해하시 위해서 깊은 질문을 던진다
그리고 자신이 맡은 프로덕트가 회사 전체의 목표에 어떤 역할을 하고 잇는지 알고 잇어야 한다

예상질문
1. 책임진 프로덕트의 고객은 누구인가
2. 과연 그 고객 뿐인가
고객을 세분화해서 분석해본 경험이 없기 때문
3. 만약 두가지 고객 중 하나만 택해야 한다면 누구에게 집중할 것인가
우선순위를 어떤 기준으로 내리는지 파악하도록 한다
청소 요청자와 청소제공자 어느쪽 기능을 개선할지 등

4. 설명한 방법을 더 간소하게 구현하려면 어떻게 할 수 있을까
기술적 구현 방식을 보다 더 간소화 할수없는지 물어보면 얼마나 이해하고 있는지 알 수 있다
데이터 축적 방식, 자동화 가능성등을 이해하고 있는지 검증해본다

5. 케이스 제시
문제를 처음 부터 끝까지 풀어보는 과정을 확인

어떤 고객이 장난감을 검색했을 때 어떻게 가장 만족할 만한 장난감 제품을 결과 맨 상단에 노출할것인지 어떻게 구현할 건지
1)요구되는 상황을 정확하게 파악햇는지 확인

만족이라는 단어때문에 단순히 베스트셀링 상품 노출이 아닌 개인화 영역까지 포함된다

2) 활용 가능한 데이터가 뭔지 파악해보는게 중요

수많은 데이터 중 무엇을 중요하게 고려해야 하는지 고민해보아야 한다
고객과 상품 각각에 대한 데이터를 어떤 구조로 나눠서 활용할지 고민

3)구현방법 설명 후 절차가 성공적인지 검증하는 방법까지 제시

자발적으로 자신의 방식을 검증하는 프로세스까지 설명한다면 매우 훌륭한 po지원자이다

<능력잇는 po로 성장하는 길>
유관부서원들과 안면을 트거 관계를 형성해야 한다 직접 만나며 자시자신을 소개하는 과정이 중요하다

작은 것 부터 책임질 수 잇게 하라

상사가 시켯어가 아닌 주도적으로 결정하도록 질문을 던진다

<po로서 갖추어야 할 가장 중요한 자질>
체계적으로 생각하기와 깊게 파고들기
원칙을 주입시키기보다는 여러가지 케이스를 해결해보며 분석하는 능력을 키워야 한다

본질이 무엇인지 파악할 수 잇어야 한다
문제가 생기면 그 원인이 뭔지 찾아내야 한다
그래야 똑같은 실수를 반복하지 않는다

성공햇더라도 그 원인 분석 필요

고객 입장에서 공감하고 생각할 수 있는 능력
무엇을 필요로하는지 만족하는지 무엇을 불편해하는지

추진력
실행에 옮기고 걸림돌이 되는 것들을 지체없이 제거 조금이라도 더 신속하게 검증된 프로덕트를 선보여야 한다

이타적이어야 한다
개인적 성과나 성취가 아닌 고객의 감동을 통해 세상을 조금 더 발전시켯다는 사실을 확인하며 만족할 수 잇어야 한다

<스크럼 회의 때 해야 할 일들>
시시각각 변하는 상황을 인지하지 못하고 잇거나 개발조직에 제대로 전달하지 못한 경우 병목될 수 잇어 파악할 프로덕트 필요

자신만의 백로그 관리 방법이 필요하다

<디자이너와 소통>
요구가 아닌 질문하기

<<테스트 중 효과적 가설 검증>>
<ab 테스트와 p값을 활용한 가설 검증법>
유의 확률을 뜻하는 p값
실험의 결과가 우연히 나타난 것인지 아닌지 판단할 때 사용되는 수치
0에 수렴해 유의도가 100퍼에 가까워야 한다

테스트플랫폼이 계산해주기 때문에 해석만 잘하면 된다

0.01 나올때까지 테스트 신뢰하지 않음
테스트 시 어떤 수치를 봐야 할지 결정해야 한다

버튼 사용 평균 횟수
메모기능 사용 빈도
추천 버튼 누른 횟수

1인당 주문 횟수
1인당 동영상 시청 횟수
1인당 이미지 업로드 횟수

<실패를 인정할 줄 알아야 더 나은 경험을 제공할 수 잇다>
po는 가설 테스트 위해서 많은 사람들의 도움을 얻어야 한다. 그말은 많은 투자를 받앗다는 것을 의미
그러니 신중리 가설 세워야 함

그러니 테스크 결과가 유의미 하지 않다면 미안함을 느낌
그러나 이성적으로 원칙을 다시 찾아보고 성공지펴도 찾아보고 이유를 되새겨봄

유의미하지 않은 결과 이성적으로 인정하기
다음 가설 설정하기

<통계적인 결과를 토대로 결정해야 진실에 가까워진다>
테스트 일정을 정해놧다면 이성적으로 서두르지말고 유의미라뉴결과가 도출될수 잇도록 기다리기