프로덕트 오너 (김성한 저) 리뷰

 

랜선 사수로부터 일하는 방식 배우기

현업에 있는 업계 선배한테 업무 조언을 받은 기분이다.

어떻게 일하는지, 어떻게 하면 좋은지 본인이 경험하고 생각한 걸 공유해주는 선배를 만난 기분.

마치 선배가 일하는 거 지켜보면서 나도 어떻게 일하면 좋을지 생각해 볼 수 있는 기회였다.

물론 쿠팡과 내 스타트업은 규모나 일하는 방식이 다를 수 밖에 없다. 그냥 큰 곳은 이렇게 일하는 구나 싶었다.

 

---

기억하고 싶은 부분

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

(1) 고객은 제품을 사지 않는다, 고용한다

🛒 고객은 해결해야 할 일이 생길 때, 그것에 도움을 주는 제품을 ‘고용(구매)’한다.

• 모든 제품과 서비스를 고용의 대상으로 바라보면, 각각 어떤 일을 고객을 위해 해줘야 하는지 알 수 있다 → 그것이 고객에게 전달되는 실제 가치
• 식스 페이저 기법 활용
• “우리는 고객을 위해 어떤 일을 하는가?”가 중요

[적용]

고객의 해결해야 할 일은?

(따로 노션에 정리함)

“내 서비스”가 고용되는 이유는? (무엇을 위해? / 내 서비스가 고객을 위해 어떤 일을 하는가? / 3~5가지)

(따로 노션에 정리함)

 

(2) 서비스는 하나라도 사용자 유형은 다양하다

• 프로덕트가 최대로 고용되기 위해서는 고객이 모두 똑같지 않다는 사실을 받아들여야 한다
• 고객을 성별, 나이, 방문 횟수 등 표면적인 정보로 구분하는 것은 왜 서비스를 고용하는지 이해하는 데 도움이 되지 않는다
  • 수많은 고객의 통일된 의견을 파악하려면, 먼저 고객의 관점에서 바라봐야 한다
• 아마존 사례 참고하기! → 고객이 가진 본질적 의도를 분석하고 유형별로 서비스에서 제공하는 것 달라짐
• 실제 고객 경험을 토대로 고객 분류를 한 다음, 그들이 어떤 일을 해결하기 위해 서비스를 고용하는지 생각해보면 경험을 보다 수월하게 개선할 수 있다 (본질적 의도 중요!)
• 고객 분류 잘하면 절반은 성공.

 

(3) 모든 사람을 만족시킬 수는 없다

• CS 들어왔을 때, 몇 명의 고객이 불편을 토로했는지, 불편을 토로한 고객이 어떤 고객인지 먼저 확인

[적용]

설문조사나 들어온 피드백, CS 빈도 파악하기

(따로 노션에 정리함)

 

(4) 식스 페이저로 모두의 동의를 얻어 기록하라

• 식스 페이저 문서 작성시, 고객 분류와 더불어 공을 제일 많이 들이는 부분 → 가이드 원칙
  • 4~6개의 원칙 목록화
  • 해당 프로덕트 개발 및 운영 시 꼭 지켜야 하는 법
  • 1번이 가장 중요한 원칙, 중요한 순으로 작성
  • 모두 검토하고 동의해야함.
  • 원칙 분기별로 검토 필요

 

(5) 고객의 요청과 회사가 정한 목표가 충돌한다면

• 회사 목표가 무엇인지 질문 받았을 때, 모든 직원과 대표가 같은 답을 해야 함.
• 프로덕트가 회사 전체 내에서 어떤 역할을 맡고 있는지가 중요
  • 회사 전체에 대한 유기적인 고려 없이 독단적으로 고객을 위한다는 취지로 방향성을 잡는 건 옳지 않다

 

+) 페르소나와 실제 고객을 혼동하지 마라

고객이 누구인지 파악할 때는, 데이터나 사용 패턴 등을 감안하여 최대한 포괄적으로 접근해야 함

• 이 프로덕트를 사용하는 사람은 누구인가?
• 개개인이 아닌 법인이나 단체가 이 프로덕트를 사용하는 경우도 있나?
• 사용자는 어떤 가치를 얻으려고 하는가?
• 프로덕트가 그 가치를 직접적으로 제공해줄 수 있나?
• 성공적으로 제공했다는 사실을 데이터로 증명 가능한가?
• 동일한 가치를 추구하는 사용자 집단을 묶을 수 있나?
• → 프로덕트를 사용해서 어떤 가치를 얻으려고 하는지 이해한다면, 역으로 그 가치를 각각 추구하는 사용자들을 하나씩 그룹화할 수 있다. 더 이상 통합할 수 없는 단계까지 도달하면, 그게 PO가 고려해야 하는 고객의 목록이 된다

---

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

• “고객 행동을 트래킹할 수 있도록 로그를 다 심어두죠” = PO가 어떤 데이터가 중요한지 모른다는 뜻
• 주별로 WBR 공유하자! → 어디에 집중해야 하는지 파악 가능 / not only 현재 상태 파악, but also 어디에 집중해야 할지 그리고 해결책 도출 도움
  • 주요 요점
  • 프로덕트 목표
  • 주요 지표

 

(3) 행동을 부르지 않는 데이터는 버린다

• 모든 데이터 분석의 결과는 “액셔너블” 해야 함
• 도움이 되는 데이터 분석은, 데이터를 통해 얻은 인사이트를 토대로 그다음 어떤 행동으로 옮겨야 하는지 명확하게 제시해야 함
• 액셔너블하지 않은 데이터 → 어떤 노력으로도 효과적으로 고칠 수 없는 이슈. 섣불리 액션 취하면 안됨. 과감히 무시!
  • 예) 시즌이나 외부 이벤트 등에 의해 일시적으로 영향받은 데이터
• 액셔너블한 데이터
• 이미 액션을 취해 대응하고 있는 데이터 → 참조만.
• 데이터 볼 때 “그래서 뭐?” → 당장 액션을 취할 수 없는 문제라면 데이터를 무시하는 결단.

 

---

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

• UI/UX 전문가는 디자이너. PO는 디자인 관련 의견내지 말 것.
• 객관적인 요구사항만 전달하기(의견 X) → PO가 의견 강조하면 고객을 위한 디자인이 아니라 PO를 위한 디자인 함