08. 서비스 기획 업무 A~Z 알아보기
16. MVP 이해하기
1) MVP(Minimum Viable Product) 정의
- The Lean Startup의 저자 에릭 리스에 의해 처음 사용된 개념
- 최소한의 노력으로 고객에 대한 최대의 배움을 얻을 수 있는 제품
2) MVP의 필요성
- 출시, 측정, 배움, pivot 또는 개선으로 이어지는 피드백 루프를 효율적으로 형성
- 제품 출시, 유저의 반응 측정, 비즈니스 모델 학습, 피보팅 또는 개선의 반복 과정
3) Pivot
- 기업이 기존 비즈니스 모델 또는 제품의 성공 가능성이 낮다고 판단될 때 새로운 비즈니스 모델로 전환하는 것
4) 좋은 MVP vs 나쁜 MVP
- 좋은 MVP: 기업의 비즈니스 모델에 맞춰 사용자로부터 제품 관련 인사이트를 얻기 위해 5가지 요소(기능, 신뢰도, 사용성, UX, 디자인)를 고려해야 함
- 나쁜 MVP: 제품의 핵심 기능이 누락되거나, 사용자 경험이 제품과 크게 다르거나, 제품이 사용자의 필요성을 충족시키지 못하는 경우
4-1) 자동차 제품 출시 전 MVP 체크 가정
- 나쁜 MVP 예시
- 1안: 바퀴만 제공하는 경우. 바퀴는 자동차의 핵심적인 부분이지만, 바퀴만으로는 자동차를 상상하거나 적절한 피드백을 얻는 것이 불가능하므로 미완성된 제품이 됨
- 2안: 자전거나 오토바이를 제공하는 경우. 이들은 자동차와 유사한 기능을 제공하지만, 자동차가 제공하는 경험과는 다르므로 적절한 피드백을 얻는 것이 어려움. UX가 상이함
- 좋은 MVP 예시
- 3안: 엔진이 없는 나무 자동차를 제공하는 경우. 이는 실제 자동차와 가장 비슷한 경험을 제공하며, 엔진이 달린 자동차를 상상하게 함으로써 적절한 피드백을 얻을 수 있음. 이를 통해 소비자의 인사이트를 유도할 수 있음
17. MVP 활용 사례
1) Dropbox의 MVP 활용사례
- 제품 개발 전 클라우드 서비스의 시장 니즈 파악을 위해 약 3분 가량의 영상 업로드
- 베타 서비스 신청 페이지와 영상을 업로드하여 하루 만에 75,000건의 Beta 서비스 이용 신청을 받음
- 시장의 강력한 니즈를 파악하고, 클라우드 서비스 구축에 드는 큰 비용을 미리 아낄 수 있었음
- Dropbox만의 유니크한 가치 제안이 명확하게 표현되고, 해결하려는 문제를 사용자가 이해할 수 있도록 영상 제작
- 시간과 비용 절약이라는 클라우드 성공 사례
2) Airbnb의 MVP 활용사례
- 샌프란시스코에서 열리는 디자인 컨퍼런스 참가자들에게 저렴한 숙박과 아침 식사를 제공하며 MVP를 시장에 내놓음
- 자신들이 거주하는 아파트의 사진을 웹사이트에 올려 3명의 손님을 받음
- 사람들이 낯선 이의 집에 묵고 돈을 지불할 의향이 있다는 시장의 니즈를 파악
18. PO의 MVP 활용하기
1) PO의 핵심 능력
- 새로운 기능(제품) 개발 단계에서 적절한 MVP 설정
- 리소스 낭비 최소화 및 최대의 배움 획득
2) MVP 기획 시 고려사항
- 가설 설정 및 검증을 위한 핵심 기능 확인
- 핵심 가설을 바탕으로 한 '핵심 기능'으로 MVP 제작
3) 팀원들의 다양한 욕구와 균형점 찾기
- PO: 다양한 기능 및 최신 UX 포함의 최고의 제품 기획
- 개발팀: 안정적이고 유지보수가 용이한 제품 개발
- 디자이너: 아름다운 제품 디자인
4) MVP의 지속적인 개선
- MVP는 한 번 만들고 끝나는 것이 아니라, 고객 반응을 통해 배우고 지속적으로 개선해 나가는 과정
- 최소한의 기능으로 출시 후 문제점 개선
5) MVP의 목표 인식
- '왜 MVP를 만들어야 하는지?'에 대한 기능을 항상 기억하고 유관부서에 공유
- 이후 제품의 방향성 및 개선점을 고려
19. Wireframe과 Prototype
1) Wireframe과 Prototype의 공통점
- 제품의 초기 버전, 시제품이 나오기 전 단계
- 프로덕트팀 간의 이해 차이를 줄여주는 역할
- 내부 의사결정을 위한 도구로 활용, 대부분의 경우 실제 사용자 대상 피드백 수집 용도는 아님
2) Wireframe의 특징
- 디자이너가 작업 시작을 위한 기초 역할 수행
- 세부 묘사를 최소화하고 핵심적인 요소만 추상화하여 표현
- 복잡한 디자인 아이디어나 애니메이션 효과는 지양
3) Prototype의 특징
- Wireframe보다 실제와 비슷하게 구현되며 간단한 인터렉션 포함
- 피델리티(Fidelity) 레벨에 따라 '로우 피델리티 / 미들 피델리티 / 하이 피델리티 프로토타입'으로 구분
- 하이 피델리티 프로토타입은 실제 제품과 거의 동일하게 동작하므로 미스 커뮤니케이션을 최소화하지만 제작 시간이 길어질 수 있음
4) Prototype Tool의 종류
1. usability test: 키노트(맥), 파워포인트(윈도우) / 애프터 이펙트(영상)
2. screen transition: Lucidchart, Balsamiq (로우 피델리티 툴)
3. sketch Import: Adobe XD, Axure, Atomic io ↔ 피그마(최신 툴)
4. micro interation: Invision, Silver Flows, Marvel
5-1. user input X (특정정보를 입력시 변화없음): Flinto, Principle, Origami (앱구동과 비슷) → 디자인
5-2. user input (특정정보를 입력시 변화): html, Framer(프로토타임툴), Ionic, React Natve(하이브리드 개발 언어로 한번의 코드 작성 시, 안드로이드 & IOS 직접 제작) → 개발
5) Wireframe과 Prototype의 의의(왜 사용하는가?)
5-2) Wireframe과 Prototype의 기능
- Wireframe과 Prototype은 '의사소통의 도구'로서 기획안을 이해하고 팀원들에게 제대로 설명하는 역할을 수행
- 소비자가 원하는 제품을 이끌어내는데 필요한 도구
5-2) 의사소통의 중요성
- 기획 컨셉을 디자이너와 개발자가 제대로 이해할 수 있도록, 자신이 가장 쉽고 편하게 다룰 수 있는 도구를 통해 빠르게 만드는 것이 중요
- 더 자주, 더 깊은 커뮤니케이션을 하는 것이 중요하다.
20. AB Test란?
1) AB Test 정의
- 임의로 나눈 두 집단(A/B)에 서로 다른 UI/UX 제시 후 더 높은 성과를 보이는 집단을 데이터 기반으로 정량적으로 평가하는 방식
2) AB Test 활용 사례
- 대부분의 IT 기업에서 데이터 기반 의사 결정 도구로 활용
- Google, Amazon, Facebook: 매년 약 10,000개의 실험 진행
- Bing: 매주 300개 이상의 실험 완료
- Uber, Airbnb: 상시 1,000개, 500개 이상의 실험 진행
3) AB Test 예시
- 앱 다운로드 페이지에서 상세 이미지 배치를 다르게 하여 A 이미지는 CVR 15%, B 이미지는 CVR 36%로 실험 진행
21. AB Test를 하는 이유
1) 불확실한 시장 환경
- 빠르게 변하는 시장에서 아무도 정답을 확실하게 알 수 없음
- 이런 상황에서 AB Test를 통해 효과적으로 시장 반응을 파악할 수 있음
2) 테스트의 효율성
- 쉽고 빠르게 테스트 가능한 환경에서 AB Test는 경험에 의존하는 것보다 효율적이고 위험을 줄일 수 있음
3) 수정 및 기능 추가의 용이성
- 빠르고 쉽게 수정하거나 기능을 추가한 후 배포 가능
- 예를 들어, OTT 신규컨텐츠 이미지와 각 서비스의 변화를 적용하며 베리에이션을 만들 수 있음
4) 실험 결과의 불확실성
- 최고의 인재가 모인 Google, Microsoft 등에서 진행하는 실험의 10~30%만이 긍정적인 결과를 얻는다는 사실
22. AB Test 진행 Process_ 목표 설정 및 가설 수립
1) 목표 설정
- AB 테스트 시, 테스트의 목표를 구체화
- 명확한 목표를 세운 후, 그에 맞는 지표를 설정
- 지표 설정 시, 분자와 분모를 명확히 함
2) 가설 수립
- 목표와 지표 설정 후, 해당 지표가 개선될 수 있도록 가설을 수립
- 가설 수립 전에 가설이 목표와 얼라인이 되어야 하며, 가설과 관련한 정보를 충분히 탐색하는 것이 중요
- 신입 기획자의 경우, 회사에서 진행되었던 다양한 실험을 파악해야 자원 낭비를 줄일 수 있음
- AB 테스트 진행 시, 반드시 가설과 실험을 통한 결과를 기록
2-1) 가설 수립 예시
- Netflix는 '아트웍이 유저의 CTR에 영향을 미칠 것이다'라는 가설을 세움
- 하나의 작품에 여러 가지 아트웍을 사용하여 AB 테스트를 진행
23. AB Test 진행 Process_ 실험 설계 지표
1) 지표의 종류와 이해
- 합계 지표(sum): 양을 알 수 있지만, 비율을 알 수 없음
- 평균, 중앙값(mean, median): 평균의 함정에 주의
- 중간값edian): 중간의 값
- 최빈값(mode): 자주 등장하는 답 등을 확인하여 아웃라이어 존재 여부를 파악
- 비율: '분모'에 따라 값 다름
2) 민감도 강건성
- 민감도(Sensitivity): 임의의 변화 없이 지표가 들쑥날쑥하면 실험 적절하지 않음
- 강건성(Robustness): 변화에도 지표가 크게 변하지 않으면 적절하지 않음
24. AB Test 진행 Process_ 실험 설계 Target User
1) 실험 대상 유저 설정(Target Users)
- 실험을 수행할 유저 대상 설정 필요
- 대조군(기존 타겟) vs. 실험군(개선이 이루어진 상태)으로 구분하여 A/B 테스트 진행
2) 실험군의 모수 설정
- 많은 유저가 사용하는 서비스: 실험의 부작용 최소화를 위해 5~10% 설정
- 초기 단계의 스타트업: 유의미한 실험 모수 확보를 위해 50% 가량으로 설정
25. AB Test Target_User_AB testing sample size calculator
1) 샘플 사이즈 설정(Sample Size)
- 샘플수가 많을수록 결과의 신뢰도 상승
- A/B testing sample size calculator를 이용하여 샘플 개수 확인
Ex) Optimizely A/B test sample size calculator
- 대조군의 CVR (Baseline Conversion Rate)
- 최소 측정가능효과 (Minimum Detectable Effect): The minimum relative change in conversion rate
사유) 3%→ 50% 상승보다 < 3% → 5% 상승하는 분석이 더 정밀한 실험이므로, 변화가 작을 수록 샘플 사이즈 높고 / 변화가 클수록 샘플사이즈 적음
- 통계적 유의도(Statistical Significance): 얼마나 유의미한 의미가 있는가? → 일반적으로 90% ~ 95%
- 샘플사이즈(Sample Size per Variation): 샘플 사이즈가 어느 정도 측정하면 되는지?
26. AB Test 분기단위와 분석 단위
1) 실험의 분기 설정(Unit of Diversion)
- A/B가 온전히 랜덤해야 두 그룹의 차이점이 Stimulus에 의한 변화라고 확신 가능
- Id : 데이터 베이스에 저장된 값으로, 안정성이 높음 (홀수 짝수 등)
- event : 유저가 특정 행동(event)를 했을 때 무작위로 A 혹은 B의 결과를 보여줌. → 유저 경험의 파편화 → (유저1 : 이벤트n) 가장 Randomize 된 샘플을 뽑을 수 있으나, 서비스의 일관성이 떨어질 수 있기 때문에 유저는 눈치채지 못할 변화에만 사용
2) 분석 단위 설정(Unit of Analysis)
- A/B Test에서 영향을 주고자 하는 최소 단위 설정 필요
- 보통 지표의 '분모'로 사용
- 지표가 ARPU(Average, Revenue, Per, User)로 "유저 한명당 평균 수익/매출을 얼마나 가져다 주는가?"로 (총 거래/구매액 / 회원 수)로 계산하 분석단위는 회원
- 분기 단위를 정할때는 분석 단위와 일치 시키는 것이 바람직함
Ex) 만약 분석하고 싶은 단위가 '회원' 인데, 분기단위가 '페이지뷰'로 분기되어있다면, 한명의 회원이 여러개의 페이지 뷰를 만들 수 있다. 이 경우 각 페이지뷰는 동일 회원이 만들어 내었으므로 서로 확률이 연관되어있고, 독립성이 없다. 만약 어떤 회원은 페이지뷰를 100번하고, 어떤회원은 1번 했을때 실험 데이터가 왜곡될 가능성이 커진다.
27. AB Test Duration과 Variation설정
1) 실험 기간 설정(Duration)
- 기간이 길수록 정확성 상승
- 명절과 같은 특수한 이벤트가 기간에 포함될 경우 결과 분석에 주의 필요
2) 변경 사항 설정(Variation)
- 실험군과 대조군에서 어떤 것을 다르게 보여줄 것인지 결정
- 차이가 복합적이면 결과 해석 어려움, 실험 단위를 최대한 쪼개서 통제하는 것이 좋음
- 지속적으로 데이터를 확인하면서 통계적 유의미성이 확보되었는지 확인해야 한다.
28. AB Test 실험진행과 결과분석, 주의사항
1) 실험 진행
- A/B 테스트의 분기가 제대로 이뤄지고 있는지 확인 필요
- 실험 기간이 너무 짧으면 유의미한 결과를 얻기 어려움
- 지속적으로 데이터 확인하여 통계적 유의미성을 확보했는지 확인 필요
2) 결과 검증
2-1) 통계적 유의성 확인
- 실험군, 대조군 각각의 모수와 전환 유저 값을 통해 통계적 유의미도 계산
- p-value 계산 필요 (p-value < 0.05일 경우 유의미한 결과)
- 통계적 유의미도가 확보되지 않은 상태에서 섣부른 결론 피해야 함
- https://abtestguide.com/calc
- https://vwo.com/tools/ab-test-significance-calculator
2-2) 불변지표 확인
- 실험 과정에서 변하면 안 되는 '불변지표'를 확인하여 실험 과정이 문제없었는지 점검 필요
- A/B 테스트 후 A/A테스트를 통해 결과 차이점 확인
- 정상적인 수치로는 변화가 없어야하나, 변화가 있을 경우 분기 제대로 이루어지지 않은 것으로 판단
3) A/B 테스트의 한계 인식
- A/B 테스트는 최적화 도구이지만, 전략적인 부분을 결정하는 데에는 한계가 있음
- 새로운 기능 추가나 높은 단계의 의사결정에는 효과적이지 않음
4) 가설의 실패에 대한 인식
- 대부분의 가설은 틀릴 가능성이 높음 (성공률 10~20%)
- 실험을 통해 잘못된 가설임을 증명하는 것도 큰 성과로 인식
- 데이터로 증명하고 실험에 대한 판단을 지속적으로 해야 함
5) 실험의 조기 종료 금지
- 많은 기업이 통계적 유의미성이 낮은 상황에서 실험을 조기 종료하는 경우가 많음
- 여유를 가지고 실험 결과를 기다려야 함
6) 변인의 제한
- 한 번에 너무 많은 변인을 테스트하면, 어떤 변인이 실험 결과에 영향을 미쳤는지 해석하기 어려움
- 실험을 진행할 때는 변인을 최소화해야 함
- 모르는 단어
- Pivot: 기업이 기존 비즈니스 모델 또는 제품의 성공 가능성이 낮다고 판단될 때 새로운 비즈니스 모델로 전환하는 것
- Wireframe: 웹사이트나 앱의 대략적인 구조를 보여주는 2차원 디자인
- Prototype: 실제로 동작하는 인터랙티브한 모델, 사용자 경험을 시뮬레이션 할 수 있으며, 기능과 플로우를 확인하는 데 도움(보통 wireframe을 바탕)
'PM(Product Manager) > 학습일지 3주차' 카테고리의 다른 글
| 5 day 2024.01.19. (0) | 2024.01.19 |
|---|---|
| 4 day 2024.01.18. (0) | 2024.01.18 |
| 2 day 2024.01.16. (0) | 2024.01.16 |
| 1 day 2024.01.15. (1) | 2024.01.16 |
