'조직을 성공으로 이끄는 프로덕트 오너' 리뷰

 

 

제품이나 서비스를 주도적으로 이끄는 PM, PO 경험을 한 사람이라면 팀 내에서 크고 작은 문제 상황을 겪어봤을 것이다. 이 책은 프로덕트 오너로서 프로덕트를 어떤 마음가짐과 태도로 어떻게 대해야 하는지에 대해 잘 알려주고 있다. 

 

 

---

 

PO는 감정을 보이지 않는다

• 프로덕트 오너는 특정 서비스에 대한 책임을 지는 자리
• PO의 언행에 영향을 받을 많은 사람들을 고려해야
• 감정과 직관에 치우치지 X ➔ 사실, 근거를 기반으로 최선의 결정을 내릴 책임

 

독재는 금물

• CEO처럼 결단을 내리는 사람이라는 착각
• 일방적 통보 X ➔ 이유(명확한 사실, 데이터) + 설득
• PO에게 주어진 권한은 전혀 없다
• 유사 과하게 미화된 스태프
• 저자세, 경청, 사실만 토대로 설득 거듭 ➔ 고독한 자리

 

책임 O, 권력 X

• PO는 지시할 수 없다 ➔ 설득의 연속
• 자신의 실력을 끊임없이 증명하며 다른 이들에게 존중받아야 한다
• 문제 발생 시 PO를 찾지만, 성공 시 함께 이룬 동료들에게 공을 돌린다

 

고객에게 집착하라

• PO는 실제 고객에 대한 이해가 풍부해야
• 도요타 프로덕션 시스템(TPS) - 현지현물現地現物: 가서 직접 봐라
• 고객이 불편하게 여기는 것, 원하는 경험 등 파악
• 고객에 집착하는 사고방식을 주변 동료들에게 전파해야 ➔ 고객 감동을 설명하는 것도 PO의 일

 

PO가 되기 위해 필요한 자질

• 학력 및 전공: 논리적 사고방식 키우기
• 업무 경험: 무엇을 왜 시작했으며, 그 과정에서 어떤 결정을 내렸고, 성공 여부를 어떻게 수치로 판단했는지 대답해야
• 성향 및 능력: 이성적 수치화, 원칙 의거 판단, 다양한 정보 ➔ 인사이트 도출, 우선순위 설정하는 거시적인 시야, 공통 목적 명시/구체적 요구사항 정리하는 커뮤니케이션 능력, 디자인적 소양, 끝까지 이어가는 추진력, 실패를 인정하고 빨리 포기하는 결단력, 고객에게 집요하게 집착하는 끈질김

 

고객은 제품을 고용한다(사는 것 X)

• 시장 분석 시 제품/서비스를 대상 고객층에 끼워 맞추지 X
• 제품이 단순히 구매된다 X ➔ 고객이 무엇을 해결하기 위해 어떤 제품을 고용했는가?
• 식스 페이저 6-Pager: 여섯 페이지 이내 해당 프로덕트에 대한 핵심 내용을 담아내는 것(목적, 과거 시도, 실패 사례, 개발 방향, 어떤 수치 활용 통한 성공 여부 파악 등)
• PO는 어떤 고객이 왜 해당 프로덕트를 고용할지 철저하게 고민해야
• 설문조사, 이미 지난 과거 데이터 통해 시장 수요 추측 X ➔ 당장 직면한 현재 고객이 어떤 제품을 고용하고, 왜 선택하는지 관점 분석

 

하나의 서비스 ➔ 다양한 사용자 유형

• 유형별 고객 ➔ 왜 서비스를 고용하는지 파악 ➔ 각 고객을 위한 경험, 정보 결정
• 만드는 사람의 관점에서 고객을 보지 X ➔ 자신이 만들고 싶은 방향으로 데이터 해석, 결정해버릴 수도
• PO는 절대 자신의 직관, 바람에 의한 결정 X 
• 자신이 직접 고객이 되어 수도 없이 많이 사용해보라
• 고객의 다양성 속 동일한 의도 찾아 고객을 분류

 

모든 사람을 만족시킬 순 없다

• 로우 행잉 프루트 Low hanging fruit: 큰 노력없이 손으로 따서 수확하면 된다
• PO는 쉽고 간단하게 고쳐서 최대한 개선된 경험을 제공해야
• PO는 한정된 자원을 어떻게 활용해야 가장 효과적일지 고민해서 우선순위를 설정해야 

 

식스 페이저 ➔ 모두의 동의를 얻어 기록하라

• PO의 머릿속은 늘 복잡할 수 밖에 없다
• 우선순위 설정 방법을 물을 시 최대한 논리적으로 대답해야
• 가이드 원칙: 4~6개의 원칙, 가장 중요한 원칙~부수적인 것
• 원칙을 상기하며 개발 방향 설정, 결정해야
• 매 분기별 원칙 점검 

 

고객 요청 vs 회사 목표 충돌 시

• 회사의 목표를 모두가 동일하게 이해하고 있어야
• 사업적 요구사항이 선행돼야
• 고객에게 더 나은 가치를 제공하기 위해 집착해야 하나, 회사의 방향성/목표를 잊지 말아야

 

페르소나 vs 고객

• 특정 페르소나 몇 가지가 전체 고객을 충분히 대변할 거라고 생각 x
• 페르소나를 올바르게 설정했다는 점을 증명하기 위해 UT 결과를 편파적으로 해석할 수도
• 프로덕트를 통해 어떤 가치를 얻으려는지 이해 ➔ 해당 가치를 추구하는 사용자들을 그룹화 ➔ 통합할 수 없는 단계 도달 ➔ 고려해야 할는 고객의 목록

 

자신을 믿지 X ➔ 데이터를 믿어라

• PO는 직관에 의존하지 X
• 자신의 생각이 옳다는 것을 증명하려고 데이터를 잘못 해석하면 X
• 최대한 다양한 데이터 수집
• 주어진 데이터를 그대로 받아들이면 X ➔ 긍정적인 데이터일수록 거짓이라고 가정해야
• 명확하게 어떤 데이터가 왜 필요한지 명시해서 요청
• 데이터 신뢰도 실험, 노이즈 파악, 전체적 그림 파악 필요

 

대시보드를 통한 데이터 파악

• 주요 대시보드 만들기: 매일 확인할 지표, 형태, 범위 결정 ➔ 애널리스트와 협의
• WBR(Weekly Business Review) 만들기: 주간 실적 분석 ➔ 매주 관계자와 회의 ➔ 집중 파악 부분 확인, 해결책 도출
  • 주요 요점
  • 프로덕트 목표
  • 주요 지표

 

행동을 부르지 않는 데이터 폐기

• 액셔너블 데이터: PO가 무엇을 어떻게 고쳐야 하는지 제시
• PO는 모든 자원을 효과적으로 활용해야
• 데이터 분류
  • 액셔너블 X 데이터: 섣불리 액션 X
  • 액셔너블 O 데이터: 하루 빨리 개선
  • 이미 액션 취해 대응 중인 데이터: 개발/사업적 측면에서 데이터를 지켜봐야
• 데이터를 보면서 '그래서 뭐?' ➔ 당장 액션 취할 수 없는 문제면 데이터를 무시한다

 

가설을 세우고, 조직의 방향성 OKR 관리

• 가설은 PO의 생각을 증명하기 위해 꼭 필요한 수단
• 가설을 수치로 설정, 배경정보를 알려줘야
• 늘 이성적으로 문제를 바라봐야 진정으로 해결 가능
• 자신의 감정, 바람 철저 배제 ➔ 중립적인 자세로 가설 도출 ➔ 증명 방법 검토 
• OKR: Objective & Key Results(목표와 핵심 결과, 매 분기마다 회사 목표(약 3~5개) 설정 ➔ 핵심 결과 수치화
• PO는 이성적인 가설(검증 가능)을 공표해야 ➔ 일관성 있게 프로젝트 만들 수 있다

 

리스크를 최소화하는 데이터 검증법

• 가설 공표 후 수치 검증 준비 ➔ 수시 데이터 확인 가능 환경 만들어야
• 동시다발적 테스트 진행 시,
  • 테스트 일정 바꾸기, 테스트 대상 조정, 테스트 장소 한정, 상관관계 확인(p-value)
• 가설 증명 위해 데이터 추출, 실험할 환경 준비 필요

 

데이터 대시보드 = 프로덕트

•  태블로, 파워 BI 등 툴 사용 ➔ 데이터 시각화
• 주기적 업데이트 수치 기반 테이블, 트렌드 파악 그래프, 배열 데이터 다운로드 파일
• 처음 접하는 사람도 쉽게 이해할 수 있게 가독성을 개선해야

 

스토리 티켓으로 알리기

• 확장성 있는 지식 배포 형태 필요: 문서 공유로 설명
• 내용: 목적, 배경 정보, 기능별 고객 고용 이유, 원칙, 목표, 주요 지표, 개발 계획, 자주 묻는 질문
• PO가 생각하는 방향성과 개발팀이 이해하는 방향성이 일치하도록 맞춰야
• 티켓 생성 시
  • 에픽 Epic: 새로운 프로덕트, 중요한 신규 기능 개발
  • 스토리 Story: 사용자가 어떤 것을 할 수 있는지, 기능 위주(+개발 요구사항)
  • 태스크 Task: 개발자 - 기술적 요구사항 세분화
• PO가 개발자에게 존중받기 위해선 요구사항을 명확하게 전달해야

 

PO가 해선 안되는 일

• 개발 X: 매일 코드 베이스를 보지 않는 상태에서 코드를 건드는 것은 위험
• 화면 구성도 X, 와이어프레임 X: 디자이너가 고객 경험을 최적화하기 위해 효과적으로 작업해야
• PO는 자신의 존재 이유를 명확하게 알아야: R&R 구분 필요
• PO는 이것저것 다 처리해주는 직무가 X

 

스크럼 회의 때 할 일

• 변경사항 발생 시 메모 후 문서/티켓 수정 ➔ 메신저 공유 ➔ 알림 조치 ➔ 스크럼 회의 시 언급
• PO의 개발 백로그: 실행해야 할 태스크 목록화, 요청사항 전달 받음 ➔ 티켓 생성 ➔ 나중을 위해 보관

 

티켓 ➔ 스프레드 시트 공유

기능 명칭	기능 설명	요청자	요청 일자	완료 일자	우선 순위	상황	티켓
주문 수량 업데이트	주문 페이지 내 항목별 수량 자동 반영	토마스	03/28	04/15	P0	개발 중	[링크]

 

디자이너와 PO는 최고의 파트너

• PO가 의도한 바를 해석해 구현해주는 디자이너
• 디자이너에게 가이드 원칙 중심 설명
• 자신이 생각한 방식을 강요하지 X
• 디자이너가 시안을 완료하기 전 수시로 작업물을 공유받으려 하지 X
• 디자이너에게 고객 경험과 관련된 결정 권한을 위임

 

편리하고 직관적인 디자인인지 체크

• PO는 사용자가 고민하지 않고 편하게 사용할수 있는 프로덕트가 탄생하도록 질문
• 절대 디자인에 대한 시각적 코멘트 X
• 고객 입장에서 화면에 보이는 모든 것을 탐구
• 질문 O, 지시 X
• 다양한 모바일 앱, 웹사이트 사용해보며 느끼는 바를 되새겨야(1000개 이상)
• 모든 감정, 개인적인 선호도 철저하게 배제 후 고객 느낄 불편함 제거 목적 질문
• 질문 시 동료 기분이 상할 것은 크게 신경 X(우선순위: 최적의 프로덕트)

 

동료 직원 대상 캐주얼 UT

• 캐주얼 UT: 실제 고객 대상 UT 전, 내부 직원 대상 간소화된 UT
• 최대한 중립적인 입장에서 관찰
• 대상자 한 명으로부터 너무 많은 것을 얻어내기 X, 짧게 다수의 대상자 통해 진행 후 대다수 느끼는 부분 캐치

 

의견 vs 요구사항

• PO는 요구사항을 전달, 고객 중심적인 관점으로 어떤 경험 제공해야 할지 객관적 설명 필요
• 개인적인 견해를 디자이너에게 전달 X
• ex) 고객이 구매하기 전, 구매 내용을 최소 1회 확인할 수 있어야 한다. 할부 구매 방법을 인지할 수 있어야 한다.

 

스프린트 플래닝

• 스프린트 플래닝: 하나의 스프린트를 계획하는 회의
• 내용:
  • 이전 스프린트에 개발 완료한 것
  • 이전 스프린트에서 개발 완료 못한 것(스필 오버)
  • 이전 스프린트에 발생한 기술적 이슈/버그
  • 이전 스프린트에 대한 회고(잘한점/개선점)
  • 이번 분기의 OKR 달성 상황
  • 이번 스프린트에서 개발 해야 할 것
• 각 항목에 포함된 티켓 미리 생성, ETA 조정, 우선순위 설정
• 매 스프린트마다 충분히 준비해야 최대한 많은 결과를 얻을 수 있다

 

완료일 설정 방법

• ETA 강요 X, ETA 역으로 산정 X
• 고객에게 선보일 일정, 사업적 목표, 개발 조직 여건 등 고려 후 최적 완료 일정 설정

 

모든 질문에 대답하는 소통의 기술

• 개발자, 디자이너가 본연의 업무에 집중할 수 있도록 PO가 소통 책임
• 개발자, 디자이너가 어떤 질문이든 편하게 물어볼 수 있는 환경 조성
• PO가 병목이 되어서는 안된다
• PO는 늘 다른 팀원보다 조금 더 멀리 내다보고 있어야 한다
• 개발자, 디자이너가 궁금해하기 전에 미리 정의를 다하고 제공해야 한다

 

속도 vs 확장성

• 현재 상황만을 감안하지 않고, 수십배까지 급속도로 성장할 것을 전제해보라
• 레이턴시(로딩 시간) 고려
• 개발팀과 확장성, 속도, 안정성 등 함께 논의

 

사용자 테스트 UT로 문제점 보완

• 새로운 프로덕트 or 신규 기능 추가 시 반드시 UT 거치기
• 최소 세 명 이상 대상자 선정 ➔ 검증 사항 결정 
• 대면 진행 or 유선 원격 진행
• 목적: 대상자가 처음 접하는 기능/디자인을 어떻게 사용하는지 관찰
• 최대한 힌트를 주지 X, 질문 통해 특정 행동/답변 유도 X

 

빠른 피드백 공유 = 동기부여

• 대상자별 화면, 관찰 노트, 수정사항 정리 ➔ 개발팀 공유

 

스프린트 기간 중 테스트  일자

• 디자이너 UT 피드백 반영할 때까지는 백엔드 작업만 진행
• UT: 스프린트 중간 진행 ➔ 결과 정리/공유 ➔ 디자이너 최종본 작업 ➔ 새로운 스프린트 플래닝
• UT 결과 부정적일 경우, 개발 매니저와 일정 변경 논의
• 근본적인 흐름/로직 변경 시 2차 UT 계획

 

UT vs 설문조사

• 사용자 테스트 UT는 다수의 의견을 묻는 것 X
• UT: 1:1 환경에서 한명의 고객이 프로덕트를 사용하는 모습을 보고 떠오르는 생각을 직접 접하며 인사이트 도출
• 고객 서베이: 특정/불특정 다수 인원에게 질문 ➔답변 받음, 실제 톤/뉘앙스 파악 X
• 포커스 그룹: 6~8명 인원을 모아 사회자가 질문 ➔ 다수의 의견을 한 번에 받는 형태, 순간의 생각을 알기 X, 답변 순도 낮음
• 고객이 실제로 프로덕트를 사용하는 모습을 지켜보기 중요

 

배포 일정 정할 시 플랫폼 고려

• 배포: 개발 완료 ➔ QA 테스트 ➔ 고객 사용할 수 있도록 적용
• 아무때나 배포하는 것은 위험(여러 팀 배포 시 기술적 문제, 버전 관리, 고객 경험 일관성 유지X)
• 배포 주기 정하기: 스프린트 끝나기 전 많은 개발 시간 확보 필요
• 핫픽스 Hot Fix: 급하게 수정해 안정화된 버전을 배포하는 것
• OS별 상황 고려: 안드로이드 상대적 자유로움, iOS 보수적 ➔ 앱 스토어 검토 기간 감안 필요
• 저녁 늦게, 금요일, 사용률/매출 급증 시기 배포 X  

 

A/B 테스트 활용 트래픽 분산

• A그룹: 신규 디자인/기능 노출 X 이용자
• B그룹: 신규 디자인/기능 노출 O 이용자
• 보통 A, B 그룹 무작위 분류
• 새로운 디자인/기능 배포 후 점차 노출 빈도 높이기(시스템/회사 악영향 가능)
• PO는 언제든 롤백할 태세를 취해야
• A/B 테스트 플랫폼 활용

 

내부 직원 = 고객

• 불필요한 디자이너 자원 사용 X
• 내부 고객용 프로덕트 업데이트 시 안내 메일 발송
  • 기능 명칭, 개발 이유, 배포 예정 일시, 사용 안내서, 문제 대처 방법

 

올바른 배포 문화

• PO는 하루 빨리 고객에게 새로운 기능을 선보이고 싶어한다
• 메이커는 보다 완성도 높은 개발물을 선보이길 바란다
• 개발 조직 특성
  • 스피드 추구형 개발 조직: 빨리 배포하려는 개발 조직, 장기적 지속 가능 X, 충분한 질문(가능 여부) 필요
  • 안정성 추구형 개발 조직: 배포 일정 연기 부추기는 개발 조직, 장기적 지속 가능 X, 협의한 일정=약속 강조

 

A/B 테스트 & P값 활용 가설 검증법

• p값:p-value, 결과가 우연히 나타난 것인지 아닌지 판단할 때 사용
• p값 < 0.01 까지 결과 신뢰X

 

실패를 인정하라

• PO는 가설을 세울 때마다 신중해야 
• PO는 이성적으로 판단해야 ➔ 원칙, 성공 지표, 근거 되새겨볼 것 ➔ 고객에게 어떤 경험을 제공하려 했는지 스스로 상기
• A/B 테스트 결과가 설정한 지표를 달성할 수 없을 것 같다면 포기
• 개발 조직과 디자이너에게 심적인 미안함 때문에 테스트 결과를 왜곡된 시각으로 해석하면 X
• 통계적 실패를 인정할 줄 알고 재빨리 목표 달성을 위해 나아가야

 

통계적인 결과를 토대로 결정해야

• 직관 X, 통계적 결과 토대 O
• 최대한 이성적으로 판단하려면, 직감을 의식적으로 무시하고 배제해야

 

검증하려는 수치는 미리 정하라

• A/B 테스트 전 어떤 수치를 검증할 지 미리 결정해야
• 다른 부수적인 수치가 긍정적/부정적이더라도, 가장 주된 수치가 무엇인지 확실히 인지해야(주의 분산X)

 

업데이트 소식 ➔ 고객센터에 먼저 전달

• 고객센터에서 변경 사실을 모르면 회사와 프로덕트에 대한 신뢰가 떨어짐
• 내부 고객이 사용하는 프로덕트가 업데이트돼도 동일하게 안내해야
• 법적 의무로 인한 공지 필요 시, 전체 적용 직전 재공지

 

프로덕트는 완벽할 리 없다

• PO는 새로운 기능이 적용되는 날 문제가 생긴다면, 
  • 심각하다면 당장 이전 버전 롤백
  • 금방 고쳐진다면 잠시 기다려달라고 안내
  • 금방 고쳐질 줄 알았지만 시간 지체 시 롤백 or 차선책 대응
• 초조/창피하지 말고 고객에게 끼칠 영향을 고려하며 최적의 결정을 내려야
• 무조건 일관성 있게 집행해야

 

시간 낭비를 최소화하는 전략

• Hate Waste
• PO가 거쳐야 하는 주요 과정 이해 + 직무별 다른 이의 결과물 기다리는 동안 시간 낭비 X 계획

 

고객의 소리를 듣는 환경 조성

• VOC: Voice of Customer
• VOC 리포트: 사용자 ID, 고객 분류, 문의사항/의견, 문의 분류, 접속 경로, 기기 종류, 앱 버전 정보, OS 정보, 브라우저 정보, 최초 가입일자, 최근 30일/90일/1년간 거래량, 최근 30일/1년간 접수되는 VOC 수
• PO는 매일 VOC 리포트 읽어야
• 하루 정도 날을 잡아 콜센터 상담원 옆에 앉아 실제 고객의 의견을 전해듣기

 

멀티태스킹으로 문제 해결하는 3 원칙

1. 꼼꼼해야 한다: 관계자들은 자신에게 가장 중요한 요청을 딱 한 번 전달 ➔ 요약해 기록해두어야 한다
2. 우선순위를 이성적으로 정해야 한다: 개인적 감정을 모두 배제하고 가장 중요한 것을 알아내야
3. 커뮤니케이션을 잘해야 한다: 올바른 기대치를 형성하게 해야

 

5 Why 방식을 고수하자

• 문제 발생 원인을 파악 ➔ 적절한 해결책 마련 ➔ 재발 방지
• 넓은 시각 접근 ➔ 후속 질문 이어나갈수록 깊게 파고들어야

 

PO 채용 전 일감 확인 필요

• PO에게 오너십은 필수
• PO에게 전적인 오너십을 줄 수 있고, 전담 개발 조직이 있어야

PO (전략가)	- 고객 대변, 사업적 가치 창출 가설 설정 - 가설 검증 계획, 개발/디자인 요구사항 정의 - 성공지표/세부지표 검토 및 데이터 분석 - 에픽/스토리 등 개발 티켓 생성 - UT 진행 후 고객 피드백 정리/공유  - 고객/유관부서와 소통 ➔개발 백로그 관리
PM/TPM (실행자)	- 개발 조직 협의 ➔개발일정 정의 - 구체적 개발 티켓 생성/정리 - 타 개발 조직과 협력 경우, 요구사항 정리/회의 진행 - 상세 테스트 방식 기획 후, 테스트 진행 - 신규 기능/프로덕트 사용 설명서 작성/배포 - 고객/유관 부서 상세 문의 답변

 

무한한 잠재력을 알아보는 법

• 단순히 경영진이 시켰기 때문에 진행했다는 대답 X - PO 적합X
• 회사 전체에 대한 넓은 시각, 고객 중심적 사고방식 ➔ 성공 지표 설정 경험
• 질문
  • 책임진 프로덕트의 고객은 누구인가?: 내/외부 고객 유형 인지/분류 ➔각각을 위한 가치 제공
  • 과연 그 고객뿐인가?: 자신의 프로덕트가 훨씬 더 다양한 고객에게 가치를 제공했다는 것 알아야
  • 만약 그 두 가지 고객 중 하나만 우선적으로 택해야 한다면 누구에게 집중?: 우선순위 결정 기준
  • 설명한 방식을 더 간소하게 구현하려면 어떻게?: 기술적 구현 방식 간소화 가능성 파악(회사 내부 시스템 간 관계, 데이터 축적 방식, 자동화 가능성 등 이해 정도 검증)
  • 특정 상황 가정: 어떤 관점 접근 문제 푸는지 확인
    • 질문: 가장 최근 전자상거래 앱 통해 물건 구매? 어떤 고객이 '장난감' 단어만 검색창 입력 가정 ➔ 검색 담당 PO로서 특정고객이 가장 만족할 장난감 제품을 맨 상단 노출 원함. 어떻게 구현?('만족' 키워드)
    • 답변: 고객 이해 후, 그에 맞는 상품 제시. 각 데이터를 어떤 구조로 나눠서 활용할 지 구현 방법 ➔ 성공 검증 방법 제시(자발적으로 자신의 방식을 검증하는 프로세스 설명 필요)
• 문제 제대로 파악 ➔ 주어진 자원 고민 ➔ 로직 짜기 ➔ 프로덕트 구현 방식 설명 ➔ 검증 절차 고려
• 질문 기회: 면접관/동료 PO가 직면하는 문제, 목표/고객 등에 대한 질문

 

능력 있는 PO로 성장하는 법

• PO는 오너십이 제일 중요: 자신 프로덕트에 대한 직접적인 가설 설정/요구사항 정의해야
• 프로덕트에 대한 이해를 쌓아야: 다른 시스템들과 어떻게 유동적인 관계를 맺고 있는지 파악
• 딥다이빙하는 습관: 모든 상황에서 반문

 

처음부터 PO가 아니어도 된다

 

PO의 자질

• PO는 본질이 무엇인지 파악할 수 있어야: 문제 발생/성공 시, 원인을 찾아야
• 고객입장에서 공감하고 생각할 수 있어야, 고객 인지 전 알고 있어야
• 최적의 경험을 제공하려고 무언가를 만들어야 한다는 마음가짐
• 프로덕트를 하루 빨리 선보이려고 하는 행동력: 고객이 오래 기다리면 안된다는 압박감을 스스로 줘야
• PO는 이타적이어야:자신의 개인적 성과/성취 X, 고객 감동을 통해 세상을 조금 더 발전시켰다는 사실에 만족해야

 

출처 | 김성한, 조직을 성공으로 이끄는 프로덕트 오너, 세종서적(주), 2020년