[독서 기록📚] 프로덕트 오너

1. PO는 미니 CEO다.

1. 업무 경험
   • 신입이나 직무 전환자는 개발 프로젝트를 처음부터 끝까지 경험해보는 것이 도움이 된다.
   • 간단한 아이디어로 기획, 디자인, 개발, 출시까지 해볼 수 있는 스타트업 경험도 좋다.
   • 무엇을 왜 시작했으며, 그 과정에서 어떤 결정을 내렸고, 성공 여부를 어떻게 수치로 판단했는지 대답할 수 있어야 한다.
   • 경력자는 PO로서 프로덕트를 직접 처음부터 끝까지 이행한 경력이 필수다.
   • 팀 전체가 한 프로젝트를 본인이 홀로 책임진 것처럼 포장하지는 말자.
   • 구체적으로 어떤 업무를 맡았고, 얼마나 체계적인 사고방식으로 깊게 분석했으며, 어떤 데이터를 기반으로 이성적인 판단을 내렸는지 증명할 수 있어야 한다.
   • 자신의 결정이 고객에게 어떤 영향을 끼쳤는지 명확하게 이해해야 한다.
2. 성향 및 능력
   • 이성적으로 수치화하고, 원칙에 의거해 판단할 수 있는 논리적인 사고방식은 필수다.
   • 다양한 정보를 집요하게 파고들어 인사이트를 도출해낼 수 있는 분석 능력도 필요하다.
   • 수많은 사안 중 어떤 것을 먼저 처리해야 할지, 우선순위를 정할 수 있는 거시적인 시야를 갖춰야 한다.
   • 여러 직무 집단 사이에서 공통적인 목적을 명시하고 구체적인 요구사항을 정리하는 커뮤니케이션 능력이 있어야 한다.
   • 사용자 관점에서 어떤 시안이 가장 효과적인지 판단할 수 있는 디자인적 소양도 도움이 된다.
   • 한 번 시작한 업무를 끝까지 이어갈 수 있는 추진력도 필요하지만, 실패를 인정하고 빨리 포기할 수 있는 결단력도 있어야 한다.
   • 선보이고자 하는 프로덕트의 고객이 누구인지 판단하고, 집요하게 집착해서 최상의 경험을 제공하고자 하는 끈질김이 필요하다.

2. 고객의 목소리를 어디까지 반영할 것인가 

• 고객은 제품을 사지 않는다, 고용한다 🥛 = 고객이 어떤 목적으로 제품을 고용했는가
  • 밀크셰이크 사례 🥛 
    1. 오랜 시간에 걸쳐 무료함과 허기를 달래줄 음식을 찾는 고객은 걸쭉한 농도의 밀크셰이크를 고용한다.
    2. 간단하게 간식으로 섭취할 수 있는 음식을 찾는 고객은 비교적 빨리 섭취할 수 있는 묽은 농도의 밀크셰이크를 고용한다.
  • 고용하는 이유를 찾자
    • PO는 프로덕트를 기획하거나 개발 방향을 결정할 때, 어떤 고객이 왜 해당 프로덕트를 고용할지 철저하게 고민해야 한다.
    • 고객이 제품을 어떤 이유로 고용하는지 알면 제품을 바라보는 시각이 달라진다.
      • ex. 고객이 넷플릭스를 보지 않고 미술관에 와야 하는 이유 (미술관을 고용해야 하는 이유)
• 서비스는 하나라도 사용자 유형은 다양하다 → 사용자의 유형 분류해서 의도 파악하기
  • 고객 유형에 따라 어떤 의도를 가지고 있는지 파악해서 분류해야 서비스 개선 방향성을 잡을 수 있다
  • 동일한 프로덕트를 고용하는 고객이 다양하다는 것을 명심하자!고객 유형 쿠팡 전략  

    고객 유형	쿠팡 전략
    구체적인 목적이 있는 고객	최근 구매했던 상품을 보여주기 → 상품평 보다는 빨리 가격을 보여주고 장바구니에 넣거나 구매 유도
    목적이 있지만 발견해야 하는 고객	고객이 만족할만한 상품을 최단 시간에 찾아서 구매하도록 도움 → 관련 정보를 어떻게 보여줘야 구매 결정에 도움이 될 지 늘 분석하고 경험을 개선해야 한다

• 모든 사람을 만족시킬 수는 없다 → input 대비 output 비중을 고려하여 우선순위 설정
  • 얼만큼의 공수를 투입하여 얼만큼의 임팩트를 낼 수 있는지 논리적으로 따져보고 최적의 결정을 내리기
• 식스 페이저로 모두의 동의를 얻어 기록하라 → 의사결정에 도움을 줄 6원칙
• 고객의 요청과 회사가 정한 목표가 충돌한다면 → 회사의 상황을 고려하여 제품의 성장을 고민하자
  • 극단적으로 선택한다면 ‘사업적인 요구사항’이다.
    • 프로덕트도 회사 전체에서 어떤 역할을 맡고 있는지에 대해 명확하게 자리를 잡아야 하기 떄문이다.
    • 회사가 생존하지 못하면 결국 고객에게 최상의 경험을 제공할 수 없기 때문이다.
  • PO가 하고싶은 일이라고 하더라도, 회사의 성장 전략 및 비용에 의해서 반대된다면 수긍해야 한다.
    • 어디까지나 PO는 주어진 자원을 활용해서 프로덕트를 개선해야 하기 때문이다.

• 고객이 누구인지 파악하는 방법 → 데이터와 사용 패턴 등을 감안하여 포괄적으로 접근하라
  • 이 프로덕트를 사용하는 사람은 누구인가?
  • 개개인이 아닌 법인이나 단체가 이 프로덕트를 사용하는 경우도 있나?
  • 사용자는 어떤 가치를 얻으려고 하는가?
  • 프로덕트가 그 가치를 직접적으로 제공해줄 수 있나?
  • 성공적으로 제공했다는 사실을 데이터로 증명 가능한가?
  • 동일한 가치를 추구하는 사용자 집단을 묶을 수 있나?
  프로덕트를 사용해서 어떤 가치를 얻으려고 하는지 이해한다면, 역으로 그 가치를 각각 추구하는 사용자들을 하나씩 그룹화할 수 있다

 

3. 데이터 속에서 진실을 찾는 법

• 자신을 믿지 말고 데이터를 신뢰하라 → 데이터를 어떻게 축적할지 고민하는 것도 PO의 역할
  • 배달앱에서 치킨 주문 카테고리를 올려서 치킨 주문량이 늘었을 때 함께 살펴봐야 할 데이터
    • 마케팅 부서에서 치킨 주문 관련 프로모션을 진행하지 않았나?
    • 영업 부서에서 치킨 판매처를 추가하지 않았나?
    • 초복이나 중복 같은 복날이 지난주에 있었나?
    • 고객 수가 증가하지 않았나?
  • 프로덕트를 론칭하고 개선하는 것만큼 데이터를 축적하는 방식을 마련하는 것도 중요
    • 고객 행동을 트래킹할 수 있도록 로그를 다 심어두죠 ❌
    • 고객 행동을 트래킹하기 위해 가장 중요한 데이터가 무엇인지 판단 후, 데이터를 심죠 ⭕
• 대시보드를 통해 정기적으로 확인하라 → 어떤 데이터를 봐야할까? ⭐
  • 예를 들어 영화 관람평 서비스라고 한다면
    1. 주간 대시보드
       • 관람평 수 : 일별, 주별, 월별, 누적치, 전주 대비 변화%, 당월 합계
       • 관람평 길이: 일별, 주별, 월별, 누적치, 전주 대비 변화%, 당월 합계
       • 관람객 대비 작성자 비율(참여도) : 일별/주별/월별 작성자 수, 일별/주별/월별 관람객 / 작성자 비율
       • 악용건수
    2. WBR(주간 실적 분석) : 현재 집중할 부분을 파악해 해결책을 도출하는데 도움을 주는 문서 (메이커들과 주간 회의할 때 사용하는 문서) 
       • 주요 요점
       • 프로덕트 목표 (OKR)
       • 주요 지표
• 행동을 부르지 않는 데이터는 버린다 → 액셔너블한 데이터가 아니면 무시하기
  • 액셔너블하지 않은 데이터 그 어떤 노력으로도 효과적으로 고칠 수 없는 이슈 (ex. 추석 연휴에 택시 매출 하락) 

    액셔너블하지 않은 데이터	그 어떤 노력으로도 효과적으로 고칠 수 없는 이슈 (ex. 추석 연휴에 택시 매출 하락)
    액셔너블한 데이터	원인을 파악할 수 있는 이슈
    이미 액션을 취해 대응하고 있는 데이터	참조용

• 가설을 세우고 조직의 방향성 (OKR)까지 관리하라 ⭐
  • 동일 상품 페이지에 최소 3번 이상 방문하면서 최소 5분 이상 체류하다 세션을 종료하는 고객층이 지난 30일간 2만 3천 명 있습니다. 그리고 그들 중 25.8%는 곧바로 검색 사이트로 옮겨가는 것으로 보아, 구매 결정에 필요한 추가 정보를 원하는 것으로 생각됩니다. 그들에게 실제 여행지에서 계절마다 360도로 촬영한 자체 콘텐츠를 제공하면 구매를 망설이게 하는 불확실성을 줄여줄 것이며, 상품 구매율이 8% 증가할 거라 예상합니다.
  • 이 가설을 증명하기 위해, 최근 30일 내 동일 상품 페이지를 3번 이상 방문한 고객을 두 그룹으로 나눠, 한쪽에만 새로운 기능을 제공할 예정입니다. 이 테스트는 50% 대 50% 비율로 총 7일간 진행할 예정이며, 검증에 사용될 주요 지표는 상품 구매 전환율, 매출 기여도, 360도 촬영 콘텐츠 소비율 등입니다.
• 리스크를 최소화하기 위한 데이터 검증법
  • 로그
    • 웹사이트나 모바일 앱을 개발할 때 사용자가 어떤 선택을 하는지, 어떤 텍스트를 입력했는지, 한 페이지에 얼마나 체류했는지 등을 알 수 있도록 심어두는 기록용 코드다.
  • PO는 자신의 가설이 맞는지 증명하기 위해 준비를 철저히 하도록 한다. 실험을 꼼꼼하게 계획하는 것도 중요하지만, 만약 데이터를 추출하거나 실험을 제대로 진행할 환경이 준비되어 있지 않다면 개발팀과 함께 논의하자. 당장 출시해야 하는 기능 때문에 이런 준비를 하기 버거울 수 있겠지만, 로그를 심고, 데이터 마트를 만들고, 태블로를 구축하고, A/B 테스트 플랫폼까지 연동해놓는 것은 장기적으로 빼놓을 수 없는 투자다. 고객에게 더 나은 경험을 제공하기 위해 필수적인 요소이다

4. 효율적인 일정 관리의 비밀

• 스토리 티켓으로 누구에게 무엇을 알려야 하나? → PO가 개발자에게 존중받는 가장 확실한 방식은 요구사항을 명확하게 전달하는 것
  • 문서 목적
  • 배경 정보: 신규 기능 필요한 이유
  • 고객을 위해 어떤 일을 하는가?
  • 원칙: 우선순위 결정 원칙
  • 목표
  • 주요 지표: 목표를 달성하고 있는지를 트래킹할 수 있는 지표
  • 개발 계획
  • 자주 묻는 질문
• PO가 해서는 안 되는 일
  • PO는 디자이너가 무엇을 달성해야 하는지 목표를 정하고 요구사항을 논의하는 직무이지, 직접 와이어 프레임을 작성하면서 화면상 버튼을 어디에 놓아야 하는지 제시하는 사람이 아니다. 그건 UXUser Experience(사용자 경험)나 UIUser Interface(사용자 인터페이스) 디자이너가 고객 경험을 최적화하기 위해 훨씬 효과적으로 작업할 수 있는 영역이다.

5. 디자이너를 최고의 파트너로 삼는 법

• 디자이너는 PO의 의도를 구현해주는 최고의 파트너다
  • 어찌 되었건 1차 시안이 완료될 때까지 PO는 디자이너를 믿고 기다리도록 한다.
  • 가장 중요한 건, 디자이너가 동일한 목적 의식을 갖고 작업할 수 있도록 도움을 주는 것이다.
    • 스크럼 회의 등을 통해 어떤 지표를 달성해야 하는지, 그렇게 달성할 경우 고객과 회사에 끼치는 영향이 무엇인지 등을 추가적으로 설명해줘도 된다.
• 과연 편리하고 직관적인 디자인인가?
  • PO는 사용자가 고민하지 않고 편하게 사용할 수 있는 프로덕트가 탄생하도록 질문해야 한다. 나는 절대로 디자인에 대한 시각적 코멘트를 하지 않는다. 오로지 고객이 사용할 때 어떤 느낌이 들지 가정해보며, 조금이라도 모호한 점들을 찾아내려고 노력할 뿐이다.
    1. PO는 오로지 고객을 대변하는 입장이어야 한다. 감정, 관계 등을 일체 배제한다.
    2. 이런 과정을 거칠 때, 처음에는 무조건 아무런 생각 없이 접해야 한다. 비판적인 시각으로 다가가지 않고, 머릿속을 비운 채 그냥 사용해본다. 대다수의 사용자는 PO가 아니라서, 별 생각 없이 설치하고 이용하기 때문이다. 일반적인 사용자의 관점에서 바라보는 것을 연습해보는 것이 중요하다.
    3. 개발하고자 하는 기능에 대해 정한 원칙에 기반하여 판단한다.
    4. 디자이너에게는 질문의 형태로만 의견을 피력한다. 절대로 지시하지 않는다.
    5. 질문한 후에는 디자이너의 의견을 경청한다. 모든 시안은 고심의 결정체다.
    6. 구두로 거론된 내용을 회의 직후 기록하여 전달한다. 디자이너가 선호하는 방식을 따른다.
  • 만약 자신의 프로덕트가 이미 있다면, 그것을 고객보다 많이 사용해보는 것이 무엇보다 중요하다.
• 동료 직원을 대상으로 캐주얼 UT를 하라

6. 개발팀과의 협업을 성과로 이끄는 애자일 전략

• 확실한 프로젝트 수행법, 스프린트 플래닝
  • 다시 한 번 강조하지만, 2주짜리 스프린트가 모여서 한 달, 한 분기, 한 해의 방향성과 결과물이 결정된다. PO는 개발자 및 디자이너 리소스 등을 감안하여, 최적의 우선순위를 짜도록 한다. 한정된 자원과 시간을 활용하여 고객에게 가장 많은 가치를 선보이고, 회사의 발전에도 기여해야 하기 때문이다. 매 스프린트마다 충분히 준비해야 최대한 많은 결과를 얻을 수 있다는 점을 늘 명심하라.
• 완료일을 언제로 잡는 것이 시기적절한가 → 디자이너와 개발 매니저의 의견을 참고하되, 회사의 달성 목표를 위해 일정을 조율하자
  • 공수 산정
    • 개발에 필요한 공수 산정은 개발자와 개발 매니저에게 맡겨라.
    • 디자인 시안에 필요한 공수 산정 또한 디자이너에게 맡긴다.
• 하지만 무조건 그들의 의견에 귀 기울여 개발 완료 일자를 정해서는 안 된다. 존중하고 참고하되, PO는 고객에 선보여야 하거나 회사가 꼭 달성해야 하는 목표를 위해 일정을 최종적으로 조율해야 한다.
• 적절하게 반문하며 왜 일정을 맞출 수 없는지 충분히 파악하도록 하자. 만약 특정 기능을 하나 제거하거나, 그다음 버전에 적용하기로 잠시 미룰 경우 기존 ETA를 맞출 수도 있기 때문이다. 아니면 우선순위 조정을 통해 불필요한 개발물 하나를 다음으로 미루고, 몇 명의 개발자를 다른 업무에 투입시킬 수도 있다. 혹은 디자이너에 할당된 업무 중 하나를 미룰 경우, 더 중요한 프로젝트 완료에 집중할 수도 있다. 이렇게 PO는 수많은 가능성을 열어두고 검토한 다음, 개발 조직 및 디자이너와 솔직하게 의논하며 최적의 일정을 산정해야 한다.

7. 고객 테스트 결과만큼 강력한 데이터는 없다

• 사용자 테스트(UT)로 문제점을 보완하라
• 빠른 피드백 공유는 동기부여가 된다
• 스프린트 기간 중 언제 테스트하는 것이 효과적인가? → 다음 스프린트에 차질이 없도록 월 / 금요일

8. 프로덕트를 출시하는 최적의 시기

• 배포 일정을 정할 때 플랫폼을 고려하라
  • iOS: 앱스토어 검토 기간을 감안하여 배포
  • AOS: 정기 배포 일자에 맞춰 배포
  • 가급적이면 저녁 늦게 또는 금요일에는 배포 X
  • 회사에 따라 사용률이나 매출이 급증하는 기간에는 배포 X
• A/B 테스트를 활용해 트래픽을 분산하기 → 점진적 배포의 중요성

9. 테스트 중 가설을 효과적으로 검증하려면

• A/B 테스트와 P값을 활용한 가설 검증법 ⭐

  A 그룹: 신규 디자인 또는 기능에 노출되지 않은 이용자

  B 그룹: 신규 디자인 또는 기능에 노출되는 이용자

  • 통계적 유의도가 100%에 가까워야 신뢰할 수 있다
    • 산출 공식: 1에서 P값을 빼면 된다 (p값이 0.02라면, 98%의 통계적 유의도를 가졌다는 뜻)
      • p값(유의확률, P-Value) : 실험의 결과가 우연히 나타난 것인지 아닌지 판단할 때 사용
  • P값을 보며 테스트 결과를 판단해야 한다
    • p값이 0으로 수렴할수록 A/B 테스트의 통계적 유의도는 100%에 가까워진다
    • 보통 쿠팡에서는 0.01보다 낮은 수치가 나올 때까지 지켜본다
  • 살펴보면 좋을 지표
    • 각 수치마다 p값을 보고 유의미한지 판단해야 한다
    • 2가지 지표를 모두 보고 A/B 테스트를 진행해야 프로덕트에 유의미한 결정을 내릴 수 있다
      • 특정 기능과 직결된 수치
        • 동영상의 볼륨 조절 버튼을 사용한 평균 횟수
        • 주문 화면의 메모 기능을 사용한 빈도
        • 코멘트의 추천 버튼을 누른 횟수
      • 프로덕트 전반의 수치 
        • 고객 1인당 주문 횟수
        • 고객 1인당 동영상 시청 횟수
        • 고객 1인당 이미지 업로드 횟수
  • 만약 p값이 낮아지지 않아 유의미한 결과를 얻을 수 없다면?
    • 더 많은 고객에게 노출될 때까지 테스트를 며칠 더 진행한다
    • 테스트를 중단한 후 신규 디자인 혹은 기능이 의미없다고 판단한다
    • 유의미한 결과가 없었으나, 프로덕트 전체에 악영향을 끼치지 않아 B그룹이 이겼다고 판정한다
• 실패를 인정할 줄 알아야 더 나은 경험을 제공할 수 있다
  • 아무리 자신과 팀원들이 많은 노력을 했어도, 결과가 유의미하지 않으면 납득하고 그다음 가설을 설정해야 한다. PO가 결정을 확실하게 내려야 개발 조직과 디자이너도 시간을 허비하지 않고 다른 목표 달성에 집중할 수 있기 때문이다.
  • A/B 테스트 결과가 늘 예상했던 것처럼 나올 수는 없다. 우연의 일치도 자주 발생하고, PO가 실제 고객의 행동을 잘 예측하지 못하는 경우도 있다. 어찌 되었건, 테스트 결과가 자신이 바라던 바와 다르다고 낙심하거나 팀원에게 미안해하는 데 시간을 너무 할애하지 않도록 한다. 사실을 재빨리 인지하고, 원인을 명확하게 파악한 후, 그다음 목표 달성을 위해 나아가는 것이 PO의 미덕이다. 때로는 통계적인 실패를 인정할 줄 알아야 고객에게 더 나은 경험을 제공할 수 있다.
• 통계적인 결과를 토대로 결정해야 진실에 가까워진다

 

PO의 역량
결국 PO는 이타적이어야 한다. 자신의 개인적인 성과나 성취가 아니라, 고객의 감동을 통해 세상을 조금 더 발전시켰다는 사실을 확인하며 만족할 수 있어야 한다.

1. 체계적으로 생각하기
2. 깊게 파고들기(Deep Dive)
3. 고객 입장에서 공감하고 생각하기 ⭐
4. 그 프로덕트를 하루 빨리 선보이려고 하는 행동력