제품을 구매할 때 작용되는 간단한 원리는 고객의 '오, 해결해야 할 일이 있어 ' 라는 생각. 그것에 도움을 주는 제품을 고용하는 것.
밀크셰이크 사례로 알 수 있듯이, 고객이 동일한 제품을 고용하는 이유는 한 가지가 아닌 경우가 다반사다. 그래서 고용되는 이유를 나열하는 목록은 주로 세가지에서 다섯가지 정도로 정리하는 편이다. 가장 처음에 내세우는 항목이 물론 제일 중요한 고용 이유이고, 아래 목록으로 내려갈수록 부수적인 것들로 채워진다.
어떤 고객이 왜 해당 프로덕트를 고용할지 철저하게 고민
설문 조사나 이미 지나간 과거의 데이터를 보고 시장의 수요를 추측하는 것은 PO에게 적절한 방식이 아니다. 당장 직면한 현재의 고객이 어떤 제품을 고용하고 있는지, 그리고 왜 그걸 선택하는지에 대한 관섬으로 분석.
분명 선보인 서비스는 하나라도, 그것을 고용하는 고객의 유형은 다양하다. 고객이 모두 똑같지 않다라는 사실을 받아들여라.
월간 방문 횟수 등의 수치로 왜 이 서비스를 고용하는지 이해하는데 도움이 되지 않는다. 오히려 왜 그 모바일 앱에 들어가는 것일까 고객의 관점에서 바라봐야 한다.
예 1. 구체적인 목적이 있는 고객 2. 목적이 있지만 발견해야 하는 고객 3. 발견을 원하는 고객.
관련 정보를 어떻게 보여줘야 구매 결정에 도움이 될 지 PO는 늘 분석하고 경험을 개선해야 한다.
본질적으로 고객이 각각 어떤 의도를 가졌는지 파악해서 분류해야 서비스 개선 방향성을 잡을 수 있으며, 평균 구매액 등은 부수적으로 활용하면 된다. 직접 고객ㅇ 되어 프로덕트를 사용해보는 것보다 더 나은 방법은 없다.
동일 사안에 대해 몇명의 고객이 불편을 토로했는지 추가적으로 알려주기. 불편 접수 메일 매일 오전 자동으로 추출해서 검토.
우선순위를 정해라. 그 하나만 택해야 할 때 버려지고 얻는 것들을 계산해라.
가이드 원칙 필요.
예:
1.
실제 관람한 고객이 생성한 콘텐츠의 진위와 신뢰성은 신성시되어야 한다. 우리는 콘텐츠가 노출되기 전 오용과 부정 작성을 방지하고, 게시된 후에도 의심되는 콘텐츠를 감지해서 제거한다.
→ 개발 방향성: 감상평은 실제로 관람한 고객만 작성 가능하다. 사영 종료 후 작성할 수 있다. 이미 작성한 영화에 대한 감성평을 남기려고 할 경우, 기존 글에 수정 또는 추가하도록 유도한다, 비정상적인 예매 빈도를 보이는 고객의 감상평은 노출하지 않는다. 상영 종류 후 20분 내에 장문의 감상편을 남기는 고개그이 감상평은 별도 검토한다.
고객이 누구인지 파악할 때는, 데이터와 사용 패턴 등을 감안하여 최대한 포괄적으로 접근해야 한다.
•
이 프로덕트를 사용하는 사람은 누구인가
•
개개인이 아닌 법인이나 단체가 이 프로덕트를 사용하는 경우도 있나?
•
사용자는 어떤 가치를 얻으려고 하는가
•
프로덕트가 그 가치를 직접적으로 제공해줄 수 있나
•
성공적으로 제공했다는 사실을 데이터로 증명 가능한가
•
동일한 가치를 추구하는 사용자 집단을 묶을 수 있나?
→ 이 가치를 각각 추구하는 사용자들을 하나씩 사용자 그룹화 가능.
반드시 봐야 하는 데이터들을 정리해야 한다.
대시보드를 통해 정기적으로 확인
→ 주기적으로 검토하는 데이터는 일별, 주별, 월별로 집계되어 주로 매일 일 회씩 자동 업데이트되어 화면에 노출되면 도움이 된다.
1. 주요 대시보드 만들기
매일 수시로 확인해야만 하는 지표를 정하고, 그걸 볼 수 있는 댓보드를 생성하라. PO 는 추출된 데이터를 가지고 분석한 다음, 결정을 내리는 것에 자신의 자원을 투자해야.
매일 확인해야 하는 지표 결정, 일별로 확인해야하는지 주, 또는 월 단위로 보여
양(월경 타입검사, 방문, 리뷰 수)
•
일별
•
주별
•
월별
•
누적치
•
전주 대비 변화율
•
전달 대비 변화율
•
당월 합계 MTD
퀄리티(평균 리뷰 길이, 체류 시간, 채비키트 만족도)
•
일별
•
주별
•
월별
•
전주 대비 변화율
•
전달 대비 변화율
•
당월 합계 MTD
참여도 (구매 수, 매출, 개별평균구매액)
•
일별
•
주별
•
월별
•
일별 구매자/방문자 비율
•
주별 구매자/방문자 비율
•
월별 구매자/작성자 비율
락인(N회이상 재방문, N회이상 재구매, 구독신청고객, )
•
일별 락인드고객 수
•
주별 락인드고객 수
•
월별 락인드고객 수
•
일별 락인드고객/신규고객 비율
•
주별 락인드고객/신규고객 비율
•
월별 락인드고객/신규고객 비율
이탈
•
1번 - 일별 주별 월별 이탈률
•
2번 - 일별 주별 월별 이탈률
•
3번 - 일별 주별 월별 이탈률
•
4번 - 일별 주별 월별 이탈률
•
5번 - 일별 주별 월별 이탈률
•
6번 - 일별 주별 월별 이탈률
•
일별 주별 월별 이탈률 순위
WBR
매주 관계자들을 모아 30분에서 한시간 정도 회의. 주간실적 분석. 두장 이하
신속하게 문제점을 공유하고 대응 방안 도출하기 위해.
•
주요 요점: 지난 WBR 회의 후에일어난 주요 사안만 몇가지 명시한다.
•
프로덕트 목표 : 해당 분기의 OKR.상기.
•
주요 지표 : 대시보드에서 넘처나는 데이터 중 꼭 중요한 것들만 선별한다. 일별 데이터는 보여주지 않고, 주별 데이터도 최근 3주치 정도면 보여준다. 한눈에 어느 영역에 문제가 있느지, 어느 부분이 잘되고 있는지.
1.
액셔너블하지 않은 데이터
2.
액셔너블한 데이터 → 데이터를 보고 시스템 구조를 변경하거나 고객 경험을 개선할 방안을 찾는 것은 액션이다.
3.
이미 액션을 취해 대응하고 있는 데이터.
데이터의 노이즈를 제거하는 방식으로 테스트를 고안해내야 한다. 론칭 전과 후를 비교하기 보다는, 고객군을 최소 두개로 나눈 후 동일한 기간 동안 한쪽에만 기능을 제공해서 각각의 상품구매율을 비교해보는 것도 하나의 방법이다.
가설을 공표한 후에 PO는 수치를 검증할 준비를 한다. (프로토타입→AB테스트UT)
한가지 수치에 연계된 테스트가 동시다발적으로 진행될 수밖에 없다면, 몇가지 그룹으로 분류할 수도 있고, 교집합이 있으면 안된다.
이렇게 테스트를 진행라기 어렵다면 전체에 테스트를 진행한 후 데이터 분석을 통해 상관 관계를 확인한다.
자체적으로 대상 고객을 선정하여 랜덤으로 어떤 고객은 A그룹, 또 다른 고객은 B그룹에게만 혀용된 기능을 사용할 수 있게 관리 가능하다. 매순간 몇명이 무엇을 햇고, 매출 등에 영향을 끼쳤는지 확인할 수 있도록 수십 가지 이상의 수치를 시시때떄로 확인할 수도 있다.
→ 구글 옵디마이즈, 옵티마이즐리같은 A/B 테스트 서비스 연동.
→ Tableau, Power BI 등의 툴을 이용하여
주기적으로 업데이트되는 수치 기반 테이블,
트랜드를 한눈에 파악할 수 있는 그래프
배열된 데이터를 다운로드해서 볼 수 있는 파일
대시보드의 타이틀은 주제를 명확하게 알려줘야한다. 각 테이블의 명칭도 정확하게 쓰여 있어야 한다.
InVision인비전 혹은 Plinto플린토 등의 프로토타이핑 툴로 만든 시안 프로토타입 파일이 설치죈 스마트폰→ 프로토타입을 통한 캐주얼 UT
→ 최대한 프레임을 씌우지 말고대상자가 느끼는 점만 물어보는 것.
의견과 요구사항은 다르다.
의견: 이 버튼을 누르면 팝업이 여기에 떴으면 좋겠습니다. 문구 크기는 최대한 키웠으면 합니다.
요구사항: 고객이 구매하기 전, 구매 내용을 최소 1회 확인할 수 있어야 합니다. 고객이 결제할 때, 할부 구매 방법을 인지할 수 있어야 합니다. 고객에게 궁금증이 있을 경우, 곧바로 고객센터에 연락할 수 있도록 안내해야 합니다.
디자이너에게 개인적인 의견을 강조 절대X 객관적인 요구사항만을 전해야 한다.
새로운 프로덕트를 만들거나 신규 기능을 추가할 떄, 반드시 UT를 거쳐라.
하는 방법→ PO의 요구사항에 맞춰 디자이너가 1차,2차 시안 등을 완성한 후 내부 검토와 캐주얼 UT를 통해 얻은 피드백까지 반영한다. 거의 최종에 가까운 이시안을 기반으로 프로토타입을 만든다. 캐주얼 UT때 사용되는 것과 비슷하게 인비전 또는 플린터같은 툴로 디자이너가 완성한다.
프로토타입이 완성되는 동안, PO는 UT를 준비한다.
일단, 대상군을 정의하여 최소 3명 이상의 대상자를 선정한다. 조건을 명확하게 정의한 후, 대상자를 섭외해야 한다.
그 후 테스트 도중 검증해야 할 사항들을 미리 정리해좋는다. UT를 직접 모더레이팅 할 PO는 물론, 다른 모든 이들이 확인할 수 있도록 문서화한다.
예시: 홈 화면
•
사용자가 홈 화면에서 음식을 선택하는 방식을 이해한다.
•
사용자가 홈 화면에서 특정 음식을 검색할 수 있다.
•
사용자가 홈 화면에서 이전에 주문했던 음식을 불러올 수 있다.
UT 후 노트 예시)
1.
홈 화면
관찰 노트 : - 홈 화면에 노출된 배너 때문에 헷갈려 함 / - 타코를 주문하고 싶어 하는데, 카테고리 확인에 시간이 걸림
수정 사항 : 배너 크게 수정 / 카테고리 아이콘
UT는 설문조사가 아니다
다수의 의견을 붇는 것이 아니라 한 명의 고객이 프로덕트를 사용하는 모습을 보고 떠오르는 생각을 직접 접하면서 인사이트를 도출해내는 절차다.
고객 서베이: 주로 몇가지의 옵션을 주고 그중 다수가 어떤 것을 선호하는지 파악하려면 유용하다.
포커스 그룹:
테스트를 통해 가설을 효과적으로 검증하는 방법
1.
A/B 테스트와 P 값을 활용한 가설 검증법
PO는 고객 경험을 개선하기 위한 여러가지 방법 중 최적인 것을 가설로 선택한 후, 검증을 거쳐 선보인다. 이중A/B테스트가 제일.
새로 개발된 기능을 배포한 후, 신규 디자인 또는 기능에 노출되지 않는 이용자 A그룹과 노출되는 이용자 B그룹을 나누어
ABC 테스트에서는 A,C 그룹이 동일하게 새로운 기능에 노출되지 않음.
이를 대체할 수 있는 것이 테스트 결과의 P 값.
P값이 0.01 보다 낮을 때까지 테스트를 신뢰하지 않는다
결론:
1.
기반 원칙 세우기 → 성공 지표 만들기
2.
대시보드에서 데이터 뽑아내기 → 기반으로 PO는 가설 세우기
3.
가설을 검증하기(프로토타입→ UT)