[북클럽] 책 Product Owner 요약

1. PO는 미니 CEO

• 많은 사람들이 볼 수 있는 이메일에서 PO가 방어적인 태도를 보이면 모두가 그것을 느낄 수 있어. 절대로 감정을 공개적으로 보이지마.
• 나의 몸과 마음이 언제나 안정적이길 바래서. 자극에 반응하지 않고 최대한 평온하게 모든 정보를 인식. 반대의견이 있어도 차분히 들은 후 설득, 언제나 긍정적인 모습을 보이려고 노력함.

• 고객과 회사 사이에서 우선순위를 결정 → 개선된 서비스가 고객에게 전해지기까지 다양한 분야의 사람들과 소통해야함 (사업적 관점에서 비용 고민도)
• PO는 최대한 많은 맥락을 설명해줘야 한다. 명확한 사실과 데이터를 가지고 설득해야한다. PO는 자신이 정한 계획을 다른 이에게 강요하는 대신, 어떻게 하면 함께 결과물을 효율적으로 도출할 수 있을지를 고민해야한다.
• 건강한 관계를 유지하기 위해서는 PO에게 권한이 없는 편이 낫다. 단기간에 마음을 얻는 것은 매우 힘들지만, 책임감 있는 모습을 보여주면서 함께 일하는 동료들과 고객이 존중하는 사람이 되려고 노력한다.

• PO의 가장 중요한 의무는 고객에게 집착하는 것. 각각 고객이 무엇을 불편하게 여기는지, 어떤 경험을 원하는지 데이터를 분석하며 팡가한다. 고객에게 감동을 줄 수 있도록 매사에 촉각을 곤두세우고 집중하자. 고객을 이해하다보면 통찰력이 생기고, 더 나은 경험을 제공할 수 있다.

• PO가 되기 위한 조건
• 학력 전공 : 컴퓨터 공학 도메인이 있으면 best.
• 업무 경험 : 개발 프로젝트를 처음부터 끝까지 경험해보는 것. 기획, 디자인, 개발, 출시까지 경험해본 스타트업 경험도 좋음. Why, 어떤 결정, 성공여부를 어떤 수치로 판단했는지 대답 가능해야함. 팀 전체가 한 프로젝트를 본인이 홀로 책임진 것처럼 포장하면 안됨.
• 성향 및 능력 : 논리적인 사고방식은 필수. 인사이트를 도출해낼 수 있는 분석 능력. 우선순위를 결정할 수 있는 거시적인 시야. 요구사항을 정리하는 커뮤니케이션 능력.

2. 고객의 목소리

• 우리는 고객을 위해 어떤 일을 하는가? : 프로덕트가 고용되는 이유를 목록 형태로 작성함. 프로덕트를 개발하기 전 고객이 어떤 일을 해결하기 위해 프로덕트를 고용하는지 PO가 먼저 완벽하게 이해하고 있어야 하기 때문. 설문조사나 지나간 과거의 데이터를 보고 시장의 수요를 추측하는 것은 PO에게 적절한 방식이 아님. 당장 직면한 현재의 고객이 어떤 제품을 고용하고 있는지, 왜 그걸 선택했는지 관점에서 분석해야함.

• 전자상거래 서비스 고용 고객 구분한다면 :
• Intent-Based Customer : 어떤 상품을 구매해야하는지 명확하게 인지하고 서비스를 고용하는 고객
• Intent-Discovery Customer : 구체적으로 어떤 상품을 구매할지는 아직 정하지 못한 고객. 여러 상품 비교 후 구매 결정내림.
• Pure-Discovery Customer : 구체적인 목적없이 들어온 고객. 다양한 상품 훑어보며 신제품이나 트렌드 파악.

• → 이전 면접에서 앱의 홈화면을 1분 간 탐색해보고, 개선 아이디어를 말해보라고 해주셨는데, 홈화면 = 대부분의 사용자가 반드시 거쳐가는 공간 = 사용자 퍼널을 단축시켜주는/전환율 상승 전략이 필요. 이렇게 Rough하게 접근했었음. 고객 Segment를 나눠서 홈화면의 개선전략을 답변했다면 더 좋은 답변이 됬을 것 같은데, 아쉽다. 프로덕트를 바라볼 때 현재의 프로덕트 화면에 갇힌 대답이 아니라, 고객 관점에서 바라보는 게 무척 중요하겠다: 무슨 지표를 개선하기 위함인지?

• PO가 범하기 쉬운 실수 : 프로덕트를 만드는 사람 관점에서 고객을 바라보는 것. 자기가 만들고 싶은 방향대로 데이터를 해석하고 결정함.

• 개발 리소스가 한정적인 상황에서 2가지의 개발 방향성을 두고 고민했음.
• 비교적 적은 자산으로 거래하는 리테일 거래자를 위한 경험 개선
• 많은 자산으로 빠른 거래를 지향하는 우량 거래자를 위한 속도 개선.
• 어느 쪽을 선택해야할까? 리테일 거래자 쪽을 먼저 개선함. 질문 “머릿속으로 어느 한 부류가 사라졌을 때 프로덕트에 끼치는 영향을 강제적으로 상상해보자!”
• 우량 거래자가 사용 불가능한 상황이 아니다.
• 속도를 개선하면 도움이 되지만, 아직 거래가 가능하다.
• 리테일 거래자를 모두 확보하는 건 어려운 일이다. 떠나면 다시 되돌리는 비용이 더 들 것.
• 리테일 거래자가 아예 없으면, 우량 거래자는 단숨에 거래소를 떠난다.

• → PM면접 단골질문. (어떤 기능을 먼저 개선하는게 좋을지에 대한) 우선순위 어떻게 결정해요? 투입되는 리소스 대비 (비즈니스)임팩트에 따라 우선순위를 결정하려고 합니다. estimation의 정확성을 높이기 위해 데이터에 기반해서 설득한다. 다만 B2B의 경우, 정말 중요한 고객의 Voice가 전체 제품의 로드맵보다 우선시 되야하는 경우도 있는 것 같다. 정도로 답변했는데,(B2B SaaS의 경우 어필어필) 여기에 극단적으로 한 쪽의 Customer가 사라졌을 때의 경우 Simulation을 해보는 경우도 더하면 더 좋은 답변이 될 것 같다.

• 6-Pager 작성시, 고객 분류 다음으로 공을 들여야하는 것. 가이드 원칙. (프로덕트를 개발하거나 운영할 때 꼭 지켜야하는 법)
• ex 영화 감상 서비스 개편
실제 관람 고객이 생성한 콘텐츠의 진위와 신뢰성 신성시 → 오용 부정작성 방지, 의심콘텐츠는 감시 및 제거
• 감상평은 실제로 관람한 고객만 작성가능
• 상영종료 후 작성 가능
• 이미 작성한 영화의 감상평을 남길 땐, 기존 글에 수정 또는 추가하도록 유도
• 비정상적 예매 빈도 고객의 감상평은 노출하지 않음
• 상영 종료 후 20분내 장문 감상평 고객의 감상평은 별도 검토
• 특정 제작사의 영화에만 감상평을 남기는 고객은 별도 분류하여 콘텐츠 검토
• 일반적이지 않은 콘텐츠 감지시 노출을 중단할 수 있도록 함
• 관람객의 상세한 감상평을 소중히 여긴다. 좋은 콘텐츠 우선 노출 시스템 개발
• 자립가능한 커뮤니티를 구축한다.
• 생성된 감상평은 고유의 데이터. 콘텐츠에 대한 접속과 기여를 규제한다.

• 사업 방향성에 대한 질문 : 회사의 최종 의사결정 담당자가 그리는 프로덕트는? 사업적으로 분석한 시장 상황, 경쟁사의 추세, 회사의 성장전략. 단기, 중기, 장기 목표가 무엇인지 검증할 목표 수치. 모두가 사업 방향성을 이해하고 있어야 하나의 집단으로 전진할 수 있음. 고객의 요청vs사업적인 요구사항…이라면 후자. 회사가 생존하지 못하면 고객에게 최상의 경험을 제공할 수 없다. PO는 고객과 회사 모두가 필요로 하는 제대로 된 프로덕트를 책임지는 사람이다.

• 페르소나에 매몰되면 안됨. 데이터와 사용패턴을 감안하여 포괄적으로 접근해야한다.
• 이 프로덕트를 사용하는 사람은 누군가? 법인이나 단체도 있나?
• 사용자는 어떤 가치를 얻으려고 하나?
• 이 가치를 프로덕트가 직접 제공해줄 수 있나?
• 성공적으로 제공했다는 사실을 데이터로 증명할 수 있나?

3. 데이터

• 나의 일은 모든 걸 자동화해서 내 존재의 필요성 자체를 없애는거라고 생각해. 프로덕트에 관한 데이터를 효율적으로 검토하기 위해서는 :
• 주요 대시보드 만들기
• WBR만들기 : 다른 유관부서와 함께 특이사항, 트렌드 공유하기 위해 관계자들과 30min~1hr 회의를 진행함. 현재 문제점 파악을 하기 위해. 특이사항에 대해 서로 질의 응답.
• Key Call-Outs (주요 사안 명시)
• Product Goals (OKR 기입)
• Key Metrics

• Actionable한 데이터 : 데이터를 단면적으로 바라보면, 모든이들이 쓸데없는 이슈를 파악하는데 리소스를 낭비할 수 있음. 그래서 뭐? 당장 액션을 취할 수 없는 문제라면 데이터를 무시하는 결단을 내리자.

OKR은 핵심 결과가 하나하나 매우 정교한 가설이어야한다. PO는 어떤 가설을 설정했고, 그걸 왜, 그리고 어떻게 증명해야하는지 명확하게 알아야한다.

4. 일정관리

• Scalable Knowledge Transfer : Objective, Background(진행상황, 문제, 방향성을 이해할 수 있어야함), JTBD, Guiding Principles(결정을 내릴 때 잣대로 삼을 원칙 나열), Goals, Key Metrics, Roadmap, FAQ

• 신규 개발을 위해 티켓을 생성할 때
• 에픽 : 새로운 프로덕트를 만들거나 중요한 신규 기능을 개발할 때 활용 (목적, 개발 타당성, 목표, 주요 수치 포함)
• 스토리 : 사용자가 어떤 것을 할 수 있는지 설명 (ex. 지도상 실시간 배달원 위치 표기) (개발 요구사항을 가장 중요하게 다룸)
• 태스크 : 하나의 스토리가 완료되기 위해 개발되어야하는 것들 (ex 네이버 지도 API 연동) → 주로 개발팀 관리자가 직접 작성

• R&R

• 백로그 관리
• 요청일자, 요청자, 요청사항, 간략한 설명, 우선순위, 티켓 링크, ETA, 개발상황, 기타로 작성

5. 디자이너

• PO가 의도한 바를 해석하여 구현해주는 최고의 파트너, Product Designer

• 디자이너와의 협업 프로세스
• 개발 문서와 티켓 공유
• 문서 기반으로 목적, 원칙, 목표, 주요 지표, 테스트 방식, 일정 설명
• 1차 시안 리뷰 피드백
• 캐주얼 UT 진행
• 2차 시안
• 실제 고객 UT
• 최종 시안

• 디자인 리뷰의 원칙
• PO는 고객을 대변하는 입장이어야 한다.
• 디자이너에게는 질문 형태로만 의견을 피력한다.
• 질문한 후에는 디자이너의 의견을 경청한다. 모든 시안은 고심의 결정이다.

• 의견과 요구사항은 다르다
• 의견 : 젊은 여성고객이 선호하는 디자인으로 해주세요~ 버튼을 누르면 팝업은 여기에 떴으면 좋겠어요~
• 요구사항 : 고객이 구매하기 전, 구매 내용은 최소 1회 확인할 수 있어야 합니다. 고객이 결제할 때, 할부 구매 방법을 인지할 수 있어야 합니다.
• → PO는 디자이너가 아니고, 객관적인 요구사항만을 전해야한다. 디자이너에게 개인적 의견을 강조하면, 프로덕트는 고객을 위한 것이 아니라 PO를 위한 것이 되어버리기 쉽다.

6. 개발자

• 스프린트 플래닝을 너무 엄격하게 진행해요. 당신의 영향력을 더 넓히기 위해, 자신의 완벽주의적 방식을 확장성있게 변화시켜야 할거예요. 그렇지만, 나는 아직도 팀운영을 타이트하게 운영한다! 2주마다 성과 측정하고, 그 다음 2주 계획. 같이 어떤 목표를 달성해야하는지, 왜 어떤 것이 우선적으로 개발되어야하는지를 설명하며 설득하는 것이 PO의 역할이라고 믿기 때문이다.

• 개발 조직과 공유하는 것
• 이전 스프린트에 개발 완료한 것 : 2주간 개발을 완료했거나 배포까지 해서 고객에게 선보인 기능들을 목록화하여 보여줌. 임팩트가 컸던 것부터 우선적으로 나열함. 고객과 회사에 끼친 영향을 설명하고 주요 지표를 공유한다. 개발자와 디자이너가 자신이 기여한 바가 무엇인지를 명확하게 이해해야하기 때문이다.
• 이전 스프린트에서 개발 완료 못한 것 : 개발 계획이 취소된 것과 완료가 늦춰져서 다음 스프린트로이어갈 케이스(Spillover) 공유
• 이전 스프린트에 발생한 기술적 이슈와 버그 : 고객에게 직간접 영향을 끼친 버그는 Incident Review 진행 (원인, 대응방식, 개선책 심도 깊게 논의)
• 이전 스프린트 회고 : 잘한 점, 개선할 점 목록 작성. 누군가를 비판하는게 아니라 조직이 발전하기 위해, 궁극적으로 고객에게 더 나은 프로덕트를 선보이기 위해 짚고 넘어가야한다는 점을 인지한다.
• OKR 달성 현황
• 이번 스프린트 개발해야하는 것

• 속도와 확장성 사이의 고민 : 적절한 시기에 대규모 투자를 할 수 있도록 백로그 관리를 잘해야한다.

7. 프로덕트 출시

• 핫픽스 : 급하게 수정하여 안정화된 버전을 배포하는 것

• 되도록 점진적 배포 권장 (A/B 테스트로 트레픽 분산)

• 배포 예정일자에 맞춰 업데이트 안내 메일 발송하기
• 기능 명챙, 개발 이유, 배포 예정 일시, 사용 안내서, 문제 대처 방법

• PO와 메이커의 입장은 다를 수 있다. 메이커는 보다 완성도 높은 개발물을 선보이길 바라기 때문.
• 스피드 추구형 개발 조직 : 빨리 배포하려는 개발 조직은 겉으로 보기엔 좋아보여도 장기적으로 지속 가능하지 않다.
• 안정성 추구형 개발 조직 : 서로 협의한 배포 일정은 약속이다. 약속을 어기는 경우는 부득이한 상황이어야 한다. 왜 일정을 연기해야하는지 끊임없이 물어야 한다.

8. 가설검정

• P-value : 실험 결과가 우연히 나타난 것인지 판단하는 지표. 귀무가설(null hypothesis)이 참이라고 가정했을 때, 관찰된 결과나 그보다 더 극단적인 결과가 우연히 발생할 확률을 나타내는 값

• PO는 자신이 선정한 가설을 테스트하기 위해 많은 지원을 받는다. = 상당 기간 회사의 자원을 투자받았다는 것을 의미함. 가설을 세울 때마다 신중해야한다. 새로운 가설을 세우고 2~3 스프린트를 할애했는데 결과가 예상과 다르면 머리가 복잡해질 수 있음..

• 그렇지만, 개발 조직과 디자이너에게 심적 미안함 때문에 테스트 결과를 왜곡한 시각으로 해석하려고 하면 안된다. 인지적 편향의 영향을.. 이겨내라!

9. 론칭 서비스의 문제 찾기

• Hate Waste : 매우 빠른 속도로 발전하는 업계의 PO와 개발조직의 시간은 귀하다. 그들의 시간이 자원이자 비용. 시간을 효율적으로 활용해야 고객에게 더 나은 경험을 계속해서 선보일 수 있다.

• VOC리포트 : 사용자 ID, 고객분류, 문의사항/의견, 사용자 정보(접속 경로, 기기 종류, 최초 가입일자, ..)

• 멀티테스킹을 잘하려면 : 꼼꼼해야한다. (그 자리에서 내용 요약. 모든 요청사항 취합은 기본) 우선순위를 이성적으로 정한다. 커뮤니케이션을 잘해라. (기대치 관리, 각 요청사항이 어느 정도의 우선순위인지 상대방에게 알려준다. 서로 간 올바른 기대치가 형성되면 실망은 안한다.)

10. PO에 맞는 인재

• PO 딥다이빙 Questions
• 책임진 프로덕트의 고객은 누군가요? 내 외부 고객 유형을 충분히 인지하고 있는지 확인
• 고객이 그 뿐인가요? 고객 세분화를 해본 경험이 충분히 없는 경우가 많음.
• 만약 그 두가지 고객 중 하나만 우선적으로 선택해야한다면, 누구에게 집중하실 건가요? 전략적, 거시적 사고를 하는지 확인함.
• 설명하신 방식을 더 간소하게 구현라면 어떻게 할 수 있을까요?

• Case 예시
• 가장 최근에 전자상거래 앱을 통해 물건을 구매하신 적있나요? 어떤 고객이 장난감이라는 단어만 검색창에 입력했을 때, 검색을 담당하는 PO로서 그 특정 고객이 가장 만족할만한 장난감 제품을 결과 맨 상단에 노출하려면 어떻게 구현하실건가요?
• → ‘만족’이라는 단어를 포착. 활용가능한 데이터가 뭔지 파악해봐야함. 고객에 대한 데이터, 상품에 대한 데이터로 구분. 구현 방법을 설명하고, 모든 절차가 정말 성공적인지 검증하는 방법까지 제시하면 이상적.
• → 문제를 제대로 파악하고, 주어진 자원이 무엇인지 고민해보고, 로직을 짜고, 프로덕트를 어떻게 구현할지 설명하고, 검증하는 절차까지 고려해야한다.

• PO로서 가장 갖춰야할 자질?
• Thinking Systematically & Dive Deep → 올바른 프로덕트를 만들기 위해서.
• 고객 입장에서 공감하고 생각할 수 있는 능력. 고객이 무엇을 필요로 하는지, 무엇을 만족하는지, 무엇을 불편해하는지 진정으로 고객의 입장이 되어 공감할 수 있어야 한다.
• 발상에서 끝나는게 아니라 행동력이 뒷받침되어야 한다. 더 신속하게 검증된 프로덕트를 선보여야 한다.
• 고객과 진정으로 공감하고, 더 나은 경험을 선사하고 싶다는 진심이 있고, 올바른 프로덕트로 만들어 하루 빨리 제공하고자하는 절박감이 있다면 분명 좋은 PO가 될 수 있다.
• PO는 이타적이어야한다. 개인의 성과나 성취가 아니라 고객의 감동을 통해 세상을 조금 더 발전시켰다는 사실을 확인하며 만족할 수 있어야 한다.