김성한님은 쿠팡에서 PO이다. (PRODUCT OWNER)
Product Owner, 그게 뭘까?
미니 CEO 라고도 한다. 항상 근거를 세우고 커뮤니케이션+설득을 해야하는 직종이다.
크게 보면 고객과 회사의 중심에 있는 존재라고 할 수 있다.
고객의 의견을 대변해야하며 반영될 수 있도록 디자이너 기획자 개발자 대표 등을 설득해야한다.
프로덕트에 대한 시장조사, 방향성, 기능 및 고객 요구사항을 반영하여 운영을 해야한다.
어떻게 보면 실질적인 프로덕트의 최고 관리자라고 할 수 있겠다.
고객과 사업이 요구하는 것들을 종합하여 원칙을 재정비하면 명확한 방향성을 잡을 수 있다.
(실제적인 회사의 방향성을 잡는다라 하기보단 프로덕트의 방향성을 제시할 수 있는 역할이라 할 수 있다.)
(PO가 문서를 작성할 때 신경쓸 것)
식스페이저
6쪽 자리 문서 (아마존에서는 6pager라고 불린다.)
자세하게 공부하기 위해서는 '순서파괴'라는 책을 읽어봐야겠다.
식스페이저:
아이디어나 주제를 깊이 있고 주도면밀하게 설명한 완전한 문장 형식의 문서.
만들어야하는 이유가 있다면?
완벽한 기획안을 만들 수 있기 때문이다.
작성해야할 것
- 문제의 배경 및 의문
- 의문에 답하기 위한 접근 방식 (누가 어떻게 그리고 예상되는 결과)
- 접근 방식 간의 비교
- 앞으로 취할 행동, 그리고 그 결과가 어떻게 고객과 회사에 혁신을 가져올 것인지에 대한 설명
고객의 요청과 회사가 정한 목표가 충돌하면?
먼저 PO는 회사의 목표에 대해서 정말 잘 알고 있어야한다. 대표의 방향성 그리고 디자이너 개발자 기획자 등등의 방향성과 목표가 일치하는지 등을 검토해야한다. 그래야 하나의 집단으로 전진할 수 있다.
고객에게 더 나은 가치를 제공하기 위해 집착하는 PO지만 회사가 정한 방향성과 목표를 잊어서는 안된다.
페르소나와 고객을 혼동하지 마라
해당 프로덕트를 구매하는 고객을 예상해 페르소나를 설정하는 경우가 있다.
페르소나는
- 실제 사용할 거라고 가정하고 만든 프로필
- 이름 성별 나이 집업 등을 구체적으로 정할 수 있다
- 페르소나에 맞춰 기획 및 디자인을 한다.
하지만 충분하지 않다
BECAUSE
- 특정 페르소나 몇가지가 전체 고객을 충분히 대변할 거라는 착각을 할 수 있다,
- 페르소나를 올바르게 설정했다는 점을 의식적 혹은 무의식적으로 증명하기 위해 사용자 테스트 결과를 편파적으로 해석할 수 있다.
그렇다면 이를 해결하기 위해서는 이런 문제를 던져보면 된다
- 이 프로덕트를 사용하는 사람은 누구인가
- 개개인이 아닌 법인이나 단체가 사용하나?
- 사용자는 어떤 가치를 얻고자 하나
- 성공적으로 제공했다는 사실을 데이터로 증명가능한가
항상 데이터를 조심해라
설령 배달앱의 상위 노출항목으로 ab 테스트를 해본다고 하자
상위에 치킨을 올렸을 때 치킨 매출이 늘었다고 증명하고 싶다.
하지만 다음과 같은 사항을 고려했는지 확인해야한다
- 마케팅 부서에서 치킨 주문관련 프로모션을 했나?
- 영업 부서에서 치킨 판매처를 추가했나?
- 초복 중복 복날인가?
- 고객 수가 그냥 증가한건가?
따라서 데이터가 유효한지 검증할 필요가 있다.
긍정적으로 보이는 데이터일수록 거짓이라 가정해본 뒤 파고들어야한다
WBR
weekly business review → 매주 관계자들을 모아 30분 정도 회의를 한다
담고 있는 내용
- 주요 요점 Key Call Outs 지난 WBR회의 후 일어난 주요 사안만 몇가지명시한다
- 프로덕트 목표 Product Goals 프로덕트를 통해 분기 또한 연간 달성하고자 하는 목표를 적는다. (OKR)
- 주요 지표 Key Metrics 대시보드의 데이터 중 몇가지 중요한 것들만 선별하여 보여준다
EG. 아사나,지라에 에픽을 열 때
문서 작성 방법
-
목적 :
최대 2~3 문장. 어떤 내용을 담을 것인지 명확하게 밝힌다 -
배경정보 :
2~3문단. 신규 기능이 왜 필요한지 등에 대해 설명,누가와서 읽어도 풀고자하는 문제를 알 수 있도록 -
고객을 위해 어떤 일을 하는가 :
목록형태로 작성한다. 각 고객이 왜 해당 기능을 ‘고용’할지에 대해 명확하게 명시한다. -
원칙 :
원칙을 나열한다. 주요 원칙만 선정해서 적는다 eg) 불필요한 기능은 추가하지 않고 개선바람 -
목표 :
새로운 기능을 보였을 경우 어떤 목표를 달성한건지 무조건 수치화될 수 있도록 작성한다. 가설을 증명하기 위해 사용되는 수치가 그대로 기입될 수 있다. -
주요 지표 :
목표에 사용되는 지표를 포함하여 기능이 고객을 위해 제대로 된 목적을 수행하고 있는지 나타낼 수 있는 지표를 3~4개 설정한다. (고객 컴플레인이 1/2 줄어들었다 -
개발 계획 roadmap 단계별로 작성.
ETA(estimated time of arrival) 개발 완료 예정 시간 상태를 표기한다, (먼데이랑 비슷하다) 가능성 있는 순으로 그린 옐로우 레드… -
자주 묻는 질문
PO가 개발자에게 존중받는 가장 확실한 방식은 요구사항을 명확하게 전달하는 것이다.
자신의 백로그를 관리하는 방법
엑셀로 정리하는 것을 추천 (이건 나도 적용해볼만한 것 같다)
CUT (casual user testing ):
실제 고객 테스트 전에 내부 직원을 대상으로 하는 사용자 테스트)
- 대상자가 사용하는 모습을 지켜본다
- 한곳에 오래 머물거나 예상치 못한 행동을 할 경우 질문으로 의도를 확인한다
- 일단 흐름을 최대한 끊지 않고 사용하는 모습을 지켜보도록한다
- 한번 완료하면 다시 재시도를 요청한다
- 대상자가 느끼는 점을 메모한다.
- 마지막에는 대상자에게 질문할 기회를 주고 설명할 수 있는 것들은 설명해준다
고객 테스트 만큼 경력한 데이터는 없다
- UT 를 모더레이팅할 PO필요, 지켜볼 디자이너 그리고 확인할 수 있도록 문서화
- 검증해야할 사항은 미리 적어간다
- 질문을 통해서 특정 행동이나 답변을 유도해서는 안된다
PM / PO
PO:
- 고객을 대변하면서 사업적인 가치를 창출할 수 있는 가설 설정
- 가설을 검증할 방법을 계획하고 개발 및 디자인 요구사항 정의
- 성공지표 세부지표 등을 검토하고 데이터 분석 진행
- 에픽 스토리 등의 개발 티켓 생성
- UT 진행 후 고객 피드백을 정리하고 공유
- 고객 및 유관부서와의 소통을 통해 개발 백로그 관리
PM :
- 개발 조직과 협의하여 개발 일정 정의
- 구체적인 개발 티켓 생성 및 정리
- 타 개발 조직과 협력해야할 경우 요구사항 정이 및 회의 진행
- 상세한 테스트 방식 기획 수 테스트 진행
- 신규 기능 또는 프로덕트에 대한 사용 설명서 작성 및 배포
- 고객 및 유관부서의 상세 문의에 대한 답변
