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

2023. 9. 8. 00:57Design/UX

예전부터 익히 이름은 들어왔지만, 이제서야 읽게된 <프로덕트 오너>.

그간 UX 이론적인 책만 읽어왔다면 이 책은 정확힌 다른 직무지만 요즘 Product Owner, Product Designer, .. 등 경계가 모호해지고 있고 밀접히 PO, 기획자와 협업하고 회사에 따라서는 어느정도 기획의 영역까지 커버하는 요즘의 '디자이너'에게도 협업+업무를 위해 꼭 읽어보면 좋은 책인듯 했다.

 

쿠팡의 프로덕트 오너에서 코빗의 프로덕트 디렉터, 그리고 사장.

현재는 쿠팡플레이의 총괄이신 김성한 작가가 전하는 '수학의 정석'의 "프로덕트 오너" ver 이라고 보면 될 듯 하다.

쿠팡에서 현재까지도 오래 일을 하신 만큼,

몇달 전 참석한 오프라인 쿠팡 디자인 행사를 포함하여 들어왔던 쿠팡의 업무 방식도 많이 녹여져 있는 책이다.

 

어떻게보면 2020년 3월, 그러니까 3년도 더 된 책인데 공식처럼 진리는 변하지 않는다 .. 느낌도 들었다.

 

 

 

PO(Product Owner)는
  • 고객과 회사가 각각 필요로 하고 추구하는 목적 사이에서 최적의 개발 방향성을 설정한다.
  • 고객을 대신해서 고민한다. : 고객이 요구하는 사항을 모두 경청하고, 그중에서 우선순위를 정한다.
  • 불확실함 속에서 진실을 간파하는 통찰력을 지녀야 한다.
  • 실제로 일어나지도 않은 변화에 대해 최대한 수월하게 대응하기 위해 신경 쓰고 미리 준비해야 한다.
  • 감정과 직관에 치우치지 않고, 사실을 기반으로 모두를 위한 최선의 우선순위와 결정을 내려야 할 책임이 있다.
  • 협업하는 다른 직무의 직원들(디자이너, 개발자..)에게 최대한 많은 맥락을 설명해줘야 한다.
  • 늘 명확한 사실과 데이터를 가지고 설득해야 한다.
  • 동료들이 자신의 직무에 집중할 수 있도록 부수적인 일들도 도맡아 한다. (회의 내용 정리, 고객과의 대화 전달, 회의실 예약 등..)
  • 늘 설득의 연속으로, ‘지시’보단 최대한 구체적인 사실을 서술하거나 설명해야 한다.
  • 끈질기게 고객에 집착해서 최고의 경험을 제공하고, 이러한 사고방식을 주변 동료들에게 전파해야 한다.
  • 단순한 구매를 떠나, ‘어떤’고객이 ‘왜’ ‘무엇을’ 해결하기 위해 어떤 제품을 ‘고용’했는지 생각해봐야 한다.
  • 최소한의 노력으로 최대한의 결과를 내기 위한 고효율 개선점을 찾는 노력을 꾸준히 해야한다.
  • 원칙을 만들면 결정을 내릴 때 언제든지 잣대로 삼을 수 있고, 협업하는 모든 이들이 프로덕트를 이해하기 수월해진다.
  • 고객과 사업이 필요로 하는 사항을 동시에 고려해야 한다.
  • 자신의 프로덕트 뿐 아니라 고객에 대한 모든 데이터를 넓고 깊게 보아 최대한 이성적인 판단을 해야한다. : 데이터의 신뢰도를 실험하고, 노이즈를 파악하는 것 역시 필수다.
  • 문제를 해결해야하는 존재이기 때문에, (검증 가능한) 가설을 설정하는데 많은 노력을 기울여야 한다.
  • 디자이너가 무엇을 달성해야 하는지 목표를 정하고 요구사항을 논의한다. (직접 와이어프레임을 작성하고 UI 사항을 제시하지는 않는다.) : 이후, 디자인 리뷰 시엔 순전히 고객이 느낄 불편함을 제거할 목적의 질문만을 한다.
  • 신규 기능 배포 후, 수많은 고객이 실제로 새로운 기능에 노출되었음에도 그 기능이 지표에 유의미한 영향을 끼치지 않았다면 그 사실을 인정하고 원인을 파악하고, 그 다음 가설을 설정해 다음 목표 달성을 위해 나아가야 한다.
  • “Hate Waste : 낭비를 증오하라” - 한정된 시간 내에 최대의 가치를 고객에게 제공해야 하기 때문에, 협업 시 조금이라도 시간을 낭비하지 않고 목표로 전진할 수 있도록 개발 자원을 효율적으로 쓰며 직무별 일정을 계획한다.
  • VOC(Voice of the Customer), 고객의 소리를 접할 수 있는 환경을 조성해야 한다.

 

 

 

 

고객과 원인에 집착하여 프로덕트를 개선해야 한다.
고객이 무엇을 불편하게 여기는지, 어떤 경험을 원하는지 등을 데이터를 분석하며 파악한다.

 

제품 생산 과정에서 낭비를 제거하는 방식으로 유명한 다이치 오노&에이지 도요타가 정의한 “도요타 프로덕션 시스템(TPS)”의 14가지 원칙 중 12번째로 소개된 ‘현지현물’ 즉 “가서 직접 봐라”라는 원칙은 어떤 현상을 이해하기 위해 직접 현장에 가서 관찰할 것을 제안한다.

미국 실리콘밸리의 넷플릭스에서도 고객 관련 데이터를 집요하게 분석하고 결론을 내리는 것으로 유명한데, CEO리드 역시 ‘고객과학 (Customer Science)’을 강조한다.

아마존도 고객의 목소리를 경청하고, 각 고객이 원하는 제품을 어떻게 만들어야 할지 고민하는 것이 성공으로 이어지는 원칙이라고 밝히며, 고객에 집착하듯이 집중하는 것을 중요시 말하곤 했다.

 

식스 페이저 (6-Pager / 아마존, 쿠팡) : 여섯 페이지 이내에 해당 프로덕트에 대한 핵심 내용을 담아내는 것

“우리는 고객을 위해 어떤 일을 하는가?”

프로덕트의 목적이 무엇인지
과거에 어떤 관련된 시도를 했는지
어떤 실패 사례가 있었는지
앞으로 어떤 방향으로 개발할 건지
어떤 수치를 활용해서 성공 여부를 확인할 것인지

 

  1. 목적 (Objective) : 최대 2~3문장 이내로 이 문서의 목적이 무엇이며, 어떤 내용을 다룰 것인지
  2. 배경 정보 (Background) : 약 2~3문단에서 길게는 반 장 정도로 왜 이 신규 기능이 필요한지
  3. 고객을 위해 어떤 일을 하는가? (What job are you doing for the Customer?) : 각 고객이 왜 해당 기능을 ‘고용’할지에 대해 중요도에 따라 나열
  4. 원칙 (Guiding Principles) : 꼭 따라야 하는 주요 원칙만 선정하고, 어떤 기능이 불필요하여 배제할지 명시
  5. 목표 (Goals) : 새로운 기능을 선보였을 경우, 어떤 목표를 달성할지 수치를 통해 설명
  6. 주요 지표 (Key Metrics) : 목표에 사용되는 지표를 포함하여, 기능이 고객을 위해 제대로 된 목적을 수행하고 있는지 나타낼 수 있는 지표 3~4가지 선정
  7. 개발 계획 (Roadmap) : 각 단계별로 나열. 개발 계획 색션은 완료 예정 시간(ETA)를 명시
  8. 자주 묻는 질문 (FAQ) : 효율적인 시간 활용을 위한 협업 인원 및 유관 부서들의 예상 질문 예측 및 답변 작성

 

 

각 고객을 위해 어떤 경험을 제공하고, 무슨 정보를 더 명확하게 노출해야 하는지 결정할 수 있어야 한다.

  1. 구체적인 목적이 있는 고객 (Intent-Based-Customer) : 어떤 상품을 구매해야 하는지 명확하게 인지하고 서비스를 고용하는 고객
  2. 목적이 있지만 발견해야 하는 고객 (Intent-Discovery-Customer) : 대략 어떤 상품군을 구매해야 하는지는 알지만, 구체적인 상품을 아직 정하지 못한 고객. 여러 가지 상품을 비교해보고 구매 결정을 내림.
  3. 발견을 원하는 고객 (Pure-Discovery-Customer) : 구체적인 목적 없이 들어온 고객. 둘러보다 마음에 드는 게 있으면 구매하기도 함

 

 

대시보드를 만들어 주기적으로 꼭 데이터를 확인하여 이성적인 판단을 해야 한다.

 

주기적인 트렌드를 확인하고 각 항목별로 세부사항을 정의하며 추가 데이터를 추적하면 좋다.

“주간 실적 분석 (WBR, Weekly Business Review)”을 만들고 매주 리뷰하며 해결책을 도출한다. 그러나, 곧바로 어떤 행동으로 옮겨 무언가를 바꿀 수 있는 ‘액셔너블’한 데이터에 더욱 집중해야 한다.

 

 

 

스프린트 플래닝을 위해 문서를 작성하고, 해당 조직과 공유한다.

  1. 이전 스프린트에 개발 완료한 것 : 주요 지표와 각자의 기여사항
  2. 이전 스프린트에서 개발을 완료하지 못한 것 : 취소된 것이 있다면 사유 설명, 그다음 스프린트에 이어서 할 지 여부 안내
  3. 이전 스프린트에 발생한 기술적 이슈 또는 버그 : 특히 고객에게 직,간접적 영향을 끼쳤을 경우에는 반드시 이를 기록하고 논의하는 ‘인시던트 리뷰 (Incident Review)’를 진행하여 원인, 대응 방식, 개선책 등을 심도 깊게 논의
  4. 이전 스프린트에 대한 회고 : 각자 느낀 좋은 점과 개선해야 할 점을 기록하고 공유
  5. 이번 분기의 OKR 달성 상황 : OKR 달성이 가능할지 아닌지 2주마다 가늠해보고, 어려워보인다면 남은 시간 동안 어떤 노력을 해야 할지 논의
  6. 이번 스프린트에 개발해야 하는 것 : 가장 중요한 것부터 나열

 

 

때로는 고객으로부터 직접 듣지 않으면 놓치는 점들도 많다.

새로운 프로덕트를 만들거나 신규 기능을 추가할 때는 내부 직원을 대상으로 간소화된 절차로 진행하는 캐주얼 UT를 통해서라도 UT(User Test)를 진행하는 것이 좋다.

디자이너가 1차, 2차 시안 등을 완성한 후 내부 검토와 캐주얼 UT를 통해 얻은 피드백까지 반영 후에, 3명 이상의 대상자를 선정하고 테스트 도중 검증해야 할 사항들을 미리 정리해 놓은 후, 대면 혹은 유선으로 UT를 진행한다.

관찰 시에는 그 어떠한 힌트 없이 최대한 중립적인 입장에서 관찰해야 한다.

 

 

 

배포 일정은 무작위로 정하지 않고 미리 정해두며,
다른 팀과의 협의도 충분히 하고 가급적 저녁 늦게나 금요일에는 배포하지 않는다.

새로운 디자인이나 기능을 배포할 땐 점차적으로 노출 빈도를 높이는 것이 좋다. 소수에게 먼저 보여준 다음, 시스템 또는 회사 매출 등의 데이터를 보면서 악영향을 끼치지 않는지 검증할 수 있기 때문이다.

점진적으로 노출 빈도를 늘려가면서 여러 수치를 확인하고, 안정적으로 적용하는 것이 좋다.