독서노트 : [커리어] 조직을 성공으로 이끄는 프로덕트 오너 - 김성한

📌 고객을 이해하고 분류하기

• 고객은 왜 우리를 고용하는가? 해결해야 할 일이 있기 때문이다.
  • 서비스 정의 : 우리는 고객을 위해 어떤 일을 하는가?
  • 고객 이해 : 어떤 고객이 왜 고용하는가?
  • 경쟁자, 차별점 : 우리 대신에 누구를 고용할 수 있는가? 대신 우리를 고용해야할 이유는?
• 고객을 분류하기 위한 질문들 : 고객 경험을 토대로 고객의 목적에 따라 분류한다.
  • 사용자는 누구인가?
  • 어떤 일을 하기 위해 고용하는가? 어떤 가치를 얻으려고 하나?
  • 동일 가치를 추구하는 집단을 묶을 수 있나?
  • 프로덕트가 직접 그 가치를 제공해줄 수 있나?
  • 개인 아닌 법인, 단체도 있나?
  • 성공적으로 제공했다는 사실을 어떻게 데이터로 증명하나?
• 고객의 마음을 알아내는 습관
  • 일반 사용자로서 다양한 앱, 플랫폼 써보기, 우리 프로덕트를 고객보다 많이 써보기
  • 편리 or 불편했다면 기억했다가 원점으로 돌아가 써보기, 왜 그렇게 느꼈는지 문구, 배치, 색상 등의 요소 관찰하기

 

 

📌  목표와 가설 세우기

• 목표의 요소
  • 단-중-장기 목표
  • 검증할 목표 수치
  • 타당성

모든 프로젝트 구성원이 동일하게 이해할 수 있도록 전달하고 일관성을 유지한다.
PO는 회사와 고객의 중간입장, 회사의 입장에서도 이 목표의 비용, 방향성, 영향이 타당해야한다.
상위 조직의 목표 세분화 > 하위 조직의 목표 설정

 

 

• 가설의 형식
  • ~하면 ~가 ~만큼 증가할 것이다
  • 테스트는 ~을 대상으로 ~동안 ~방법을 통해 한다. 불확실성은 ~해서 제거한다.

PO는 매우 정교한 가설을 세워야한다.
핵심 결과는 수치로 검증할 수 있어야 한다. (OKR)
다양한 관점 + 데이터 = 검증 가능한 가설 

 

 

• 우선순위 정하기 : 고효율 개선점을 찾기
  • 얼마나 많은 고객에게 영향을 주는가?
  • 2개 집단의 고객 중 우선순위를 정해야 한다면, 던져 볼 질문 : 어느 쪽이 아예 없어진다면? 영향이 더 큰 쪽은?
    ex. 저관여 다수 vs 고관여 소수 : 저관여 다수가 없다면 고관여 소수는 빠르게 사라질 것

 

 

📌  가이드 원칙 정하기

• 프로젝트를 진행하면서 룰이 되는 4-6개의 절대 원칙
  • 누가, 무엇이 제일 중요한가? 무엇은 안 중요한가?
  • 장기적으로 무엇을 구축할 것인가?
  • 규제할 것은 무엇인가?
  • 제공할 프로세스는 어떠한가?
  • 이를 위해 우리는 어떠한 자세로 무엇을 할 것인가?

모두가 합의해야 하고, 개발 방향성을 정의하는 중요한 요소
분기별 점검이 필요하며, 회사의 목표와 어떻게 얼라인하는지 명시

 

 

 

📌  데이터로 검증하기

• 데이터를 신뢰하고 데이터로부터 판단한다.
  • 노이즈 : 프로모션, 영업 상 판매처 증가, 시즌(연말, 명절), 고객 전체 수, 회사 매출 변화, 타 서비스 오픈 등
  • '시점'의 노이즈 제거 방법 : 동일 시점의 A/B테스트, 테스트 일정이나 대상 그룹 조정 등
• 데이터는 Actionable 해야한다 : 그래서 뭐?
  • 목표를 바탕으로 단계를 세분화 할 수 있는 데이터 - 그래서 우리가 뭘 할 수 있지? 에 대한 답을 주는 데이터여야 한다.
    ex. 추석이라 매출이 떨어졌다? 그래서 할 수 있는 일이 없기 때문에 무의미
• 필요한 데이터, 분석 환경 만들기
  • PO가 구축해야할 분석 환경 : 로그 > 데이터마트 > 대시보드(태블로) > A/B테스트 플랫폼 연동
  • 명확한 데이터 분석을 위해, 어떤 데이터가 왜 필요한지를 명시해 요청

• 대시보드 만들기
  • 매일, 수시로 볼 지표 정의하기 : 월, 일, 주? 어디까지?
• WBR 주간 실적 분석
  • 최근 변동사항 > 문제점 파악 > 해결책 도출을 위한 정기적 공유
  • 주요 요점, 프로덕트 목표 (분기, OKR), 주요 지표

 

 

📌  쿠팡의 6-pager

• 프로덕트의 목적
• 과거의 시도
• 실패 사례
• 앞으로의 개발 방향
• 어떤 수치로 성공 여부를 확인할지

프로젝트를 시작하기 전에, 6페이지의 문서 작성
핵심 내용 작성 > 공유 & 검토 > 피드백 & 개선 > 확정 및 개발

 

 

📌  개발을 위한 2-pager

1. 문서의 목적 (2~3 문장)
2. 신규 기능이 필요한 이유 (1/2장) : 진행 상황, 문제, 방향성
3. 고객의 정의 & 우리가 각 고객을 위해 하는 일 : 각 고객이 왜 해당 기능을 고용하는지 (고객 분류는 간소해야함)
4. 가이드 원칙 (4~6개)
5. 수치화 된 목표 (2~3개)
6. 주요 지표 (3~4개) : 목표에 사용하는 것 포함, 현재도 수집하고 있다면 현재 수준
7. 로드맵 (개발 계획) : 1(MVP)>2>3 or 단(1m)>중(3m)>장(6m) - 개발팀과 확인해 ETA & 진행 상태 표기
8. FAQ : 시간을 아끼기 위한 유관부서, 메이커의 예상 질문

 

 

📌  스프린트 플래닝

1. 이전 스프린트에 개발 완료한 것 : 각 과제 설명, 지표 공유(고객, 회사에 기여한 것)
2. 이전 스프린트에 개발 완료 못한 것 : 사유, 이어서 할지 여부
3. 이전 스프린트 기술 이슈, 버그 : 인시던트 리뷰 요약, 원인, 대응 방식, 개선책
4. 이전 스프린트 회고 : 각자 준비해오고 공유하기 - 잘한점, 개선할점 (자기, 조직, 타인)
5. 이전 스프린트 플래닝 자료 보기 : 매주 개선사항을 트래킹
6. 이번 분기 OKR 상황 : 수치, 얼마나 왔는지, 달성이 어렵다면 어떻게 해야할지
7. ⚠️ 이번 스프린트에서 개발할 것 : 제목, 티켓, 담당자, ETA

고객, OKR에 기반한 우선순위 공유
스프린트 플래닝이 모여 한 달, 일 년이 된다

 

 

 

📌  프로젝트 진행하기

• Hate waste : 직무 별 일정표

  • PO	요구사항		시안 검토		UT	요구사항		시안 검토		UT	요구사항
    디자이너		1차 시안		2차 시안		최종 시안	1차 시안		2차 시안		최종 시안
    백엔드		개발 시작		개발			기타 개발		QA		개발 시작
    프론트엔드		기타 개발		개발 시작		개발			QA		버그 수정

1차 시안 > 내부UT, 피드백 > 2차 시안 > 고객UT, 피드백 > 최종 반영 & 가이드(5일) 
고객 UT와 최종 반영 사이 기간에 백엔드 개발은 시작

 

 

• Jira 발급 형식
  • Epic : 프로젝트 주제, 핵심 내용
  • Story : 상세 기능 + UX 흐름 문서, 디자인 시안
  • Task : 세부 개발 요소 (개발PM이 작성)

 

 

 

📌  소통하기

• PO의 지상 목적 : 프로젝트가 정체되지 않고, 팀원이 집중해 일하게 한다.
  • 최대한 빨리 답하고, 해결하고, 뭐든지 물을 수 있게 하라.
  • 물어보기 전에 최대한 정의하라, 모든 것에 미리 대답하라.
  • 속도(빨리 뭔가 하기) - 확장성(더 커질수 있는 준비, 효율적 아키텍쳐) - 성장(진짜 가치 획득)를 조율한다.
• 요청 대시보드 만들기 : 유관 부서 요청사항을 효율적으로 관리하기
  

  • 요청자						PO
    요청일자	이름	소속 팀	요구 사항	기능	설명	우선순위	티켓 링크	ETA	진행 상태	기타

  • 모든 요건 취합 > 우선순위 정하기 > 우선순위의 사유에 대해 잘 소통한다. 요청자의 올바른 기대 수준을 형성한다.
• 나만의 백로그 만들기 : 나의 TO DO와 우선순위 관리

  • 기능 명칭

    설명

    요청자

    요청일자

    완료일자

    우선순위

    진행 상태

    티켓 링크

• 디자인 피드백 하기
  • PO는 디자이너에게 목표 & 지켜야할 사항을 알려주는 역할
  • 원칙에 기반해 판단하되, 결정권한은 위임한다.
  • 시각적 코멘트, 감정, 개인 선호는 배제한다. 질문의 형태로만 의견을 내고 디자이너의 의도를 경청한다.
  • 오로지 고객을 대변한다 : 고객이 고민하지 않고 편하게 사용할 수 있는가?
  • 회의 직후 오간 의견을 기록해 전달한다.
• 개발과 소통하기
  • 개발자의 존중은 명확한 요구사항 정의로부터 나온다.
  • ETA에 반문하고 점검하기 : 병목이 있는지? 특정 기능을 제거하면? 우선순위 조정할 요소가 있는지?

한정된 시간 내 최대한 많은 가치를 구현하는 것을 목표한다.
설득을 위해 상위의 권위를 빌려오는 것은 (ex. 상급자가 하래) PO의 권위를 박탈하는 일

 

 

 

📌  UT 하기

• 캐주얼 UT
  • 프로토타입으로 내부 인원 중 짧게 다수에게
  • 일단 지켜보기 + 머물거나, 예상치못한 경우만 질문 (답정너 질문X ex. 버튼 발견도 못했는데 그 버튼 누르면 뭐가 될까요?)
  • 한번 완료하면 재시도 요청 + 이 때, 왜 그랬나? 라는 질문으로 의도 확인
• 고객 UT
  • 대상군 정의, 최소 3명 이상의 다양성 확보
  • 테스트 중 '검증할 상황'을 미리 정의 : 각 화면에서 ~을 이해한다, ~을 할 수 있다.
  • 힌트 X, 망설이거나 예기치못한 행동을 했을때만 묻기
  • 인사이트를 얻기 위한 추가 질문 : 만약 여기서 방금한걸 취소하고 싶다면? 방금 한 행동의 기대결과가 뭐였나?
  • 정의 문서 기반으로 관찰 노트 작성 & 수정사항 도출 : 추후 타당성의 논거가 됨

 

 

📌  A/B테스트와 배포하기

• 검증할 수치는 미리 정의
• A/B테스트 프로세스 : B그룹(신규 기능) 적용율을 천천히 증가, 5단계 약 2주
  • 1일(5%) > 2일(20%) > 3일(50%-7일간 유지해 통계 분석) > 4(80%-3일) >  5(100%)
• 결과 보기
  • 2개의 지표로 결과 보기 : 특정 기능에 관한 수치 (ex. 추천 버튼 클릭수) vs : 프로덕트 전반의 수치 (ex. 1인당 주문수)
    ex. 버튼을 변경 했는데, 버튼 클릭수는 늘었지만 주문수가 감소했다면?
  • 적용 대상이 증가해 신뢰도(p)가 0.01이하가 될 때 까지 대기
  • 안 낮아진다면? : 테스트 지속 or 중단 or 유의미하지는 않지만 악영향은 아니므로 B그룹(신규 기능)이 이겼다고 판단
  • 실패한것 같다면? : 다시 최초의 문서로 돌아가 왜?를 생각한다. 테스트결과에 승복하고, 그 다음 가설을 설정한다.
• 내부 고객 대응
  • 배포 전 사용 안내 : 기능, 개발사유, 배포예정일시, 사용안내서, 문제 발생시 대처 방안(연락처)
  • 고객센터에 배포 시점 마다 전달 : VOC 리포트는 정기적으로 받고, 매일 읽기
• 배포 후 이슈 대응 : 문제 발생은 당연하다
  • 대응책 기정사실화 : 롤백하기 or 고칠 수 있다면, 기다려달라고하기 or 그래도 안 고쳐지면 롤백하고 차선책 찾기

 

 

📌  PO와 PM

• PO : 계획하는 사람, 전략가
  
  • 고객을 대변하고, 사업적 가치를 창출하는 가설 설정
  • 가설을 검증할 방법을 계획, 개발/디자인 요구사항 정의
  • 성공 지표, 세부 지표를 검토하고 데이터 분석
  • 에픽, 스토리 티켓 생성
  • UT 진행 후 고객 피드백 정리, 공유
  • 고객 및 유관부서와 소통해 개발 백로그 관리

PO는 "고객에게 가장 큰 영향을 주기 위해 해야할 일"을 한다. 메이킹은 전문가가 한다.
고객의 필요성과 회사의 방향성 사이에서 해결책(목표)을 도출하고, 가설을 세워, 구현하고, 검증한다.
신속하고, 정확하게 이해하고, 꼼꼼해야한다.
오너십과 전담 개발 조직을 가지고, 그들이 할 일을 찾고 정의한다.

PO에 대한 평가 : 회사 전체의 시각 + 고객 중심 사고방식 + 성공 지표의 설정 여부
- 회사, 프로덕트의 목적과 달성 여부
- 어떤 고객을 위해 무슨 가치를 구현했는가?
- 고객은누구? 그 고객뿐인가? 둘중 우선순위는?
- 더 간소하게 구현하려면? (개발이해도)
- Case. ~ 고객이 서비스에 왔을때 ~ 물건을 사게 하려면? : 문제 파악, 자원 파악(데이터), 로직, 프로덕트 구현방법, 검증 절차

 

 

• PM : 계획을 실행하는 사람
  • 개발과 구체적 일정을 정의
  • 구체적인 개발 티켓 생성, 정리
  • 유관 부서와 협력 시 요구사항 정리, 회의 진행
  • 테스트 방식 상세 기획, 테스트 진행
  • 신규 기능, 프로덕트에 대한 사용설명서 작성 배포
  • 고객 및 유관부서 문의 대응