1 day 2024.05.13.
17. 중간점검: 고객 경험을 만드는 PM 전략
1. 프로덕트를 만드는 사람들
1) Product란?
· 스마트폰에서 사용하는 앱 예시: 배달의 민족, 카카오페이, 마켓컬리
2) 구성원
· Product Owner(Mini CEO): 임원진
· Product Manager: 실현 가능한 부분 담당
· 디자이너: 디자인 담당
· 개발자: 실제 구현 및 구동 담당
· 고객 및 고객 지원, 마케팅: 최종 완료된 프로덕트를 고객에게 가장 가까운 접점에서 홍보 및 마케팅
3) 프로덕트를 만드는 사람들
· CEO: 비즈니스 기획
· 개발자: 데이터 기반으로 구현 및 시현 담당
· 디자이너: 디자인 구현
· 서비스 기획자/PM/PO: CEO, 디자이너, 개발자 사이의 원활한 커뮤니케이션을 위한 중간 역할. 비즈니스 방향성을 이해하고 서비스 기획 및 설계 담당.
- [Business-UX-Tech]
- 비지니스 이익과 어떻게 연결하면 좋은지
- 고객들에 대한 이해와 바탕이 된 서비스를 구현 하는지
- 시장환경에 대응하는 디자인&개발환경을 고려했는지
- 3가지 밸런스를 맞춰서 서비스 기획 필요!
4) 집을 짓는 '건축'과의 비교
· 서비스 기획자/PM/PO: 전체적인 설계도 작성
· 백엔드 개발자: 초반 골격 및 데이터베이스 설계 및 구현. 회원 체계, 장바구니, 데이터 저장 및 추출 담당.
· 프런트엔드 개발자: 백엔드 개발과 연동하여 실제 구동되고, 사용자가 원하는 동작을 할 수 있도록 하는 역할.
· Android/iOS 개발자: 네이티브 앱 개발 담당.
· UI개발자/퍼플리셔: 디자인한 결과물을 웹이나 앱에 구현하는 인터렉션 구현 담당.
· 디자이너: 프로덕트의 디자인 및 내부 인테리어 디자인 담당.
5) 프로덕트 진행방방식에 따라, 직군 상이
1-1. Waterfall 방식(폭포수 모델) 서비스 기획자
1) 요구사항 분석
· 비즈니스 기획/클라이언트
· 시장조사
· 수익창출 Business Model 수립
· 사업 전략
· 핵심 경쟁력
· 최종 사용자에게 줄 수 있는 가치
· UX / 서비스 기획(사용자 관점)
· 사용자 조사 설계
· 고객 관점 사용자 경험 전략 설계
2) 설계
· UX / 서비스 기획(사용자 관점)
· 요구사항 명세서, 기획서 작성
· Wireframe
· Workflow
3) 디자인
· UX/UI Design
· 고객경험 디자인(UX Design 전략 수립)
· 프로덕트 설계서
· IA 설계
· 기능정의
· Wireframe
· Workflow 설계
4) 코딩(개발)
· 기술(Tech)
· 구현
· 개발환경에 맞는 개발
5) 테스트
· 고객(사용성, 적합성, 편리성)
· 사용성 테스트
· 적합성 평가
· 편리성 검증
6) 수용(배포 후 피드백)
· Business(시장성)
· 시장 반응 분석
· 제품/서비스 개선을 위한 피드백 수집
| Waterfull(폭포수) 방식의 서비스 기획자 | |
| 비즈니스 기획 : 수익모델, 사업전략 : What, Why |
서비스 기획 : 사용자 조사, 고객 경험 설계(편리성) : How |
| (업무역할) 1) 비즈니스 기획/클라이언트 : 시장조사, 수익창출 Business Model 수립, 사업 전략, 핵심 경쟁력, 최 사용자에게 줄 수 있는 가치 2) Project Manage(개발자 관점) : 프로젝트 일정, 리소스 산정, 계약, 산출물 관리, 업무 할당 및 관리 3) UX / 서비스 기획(사용자 관점): 사용자 조사 설계, 고객 관점 사용자 경험 전략 설계, 요구사항 명세서, 기획서 작성(Wireframe, Workflow) |
|
7) 서비스 기획자의 업무 범위 및 요구되는 역량
- 커뮤니케이션 스킬
- UX/UI Design(고객경험 디자인)
- 논리적인 사고
- UX Research
- Tech(기술)에 대한 이해
- 행동경제학, 인문학, 심리학 등의 다양한 분야에 대한 이해력
8) 결과물
- UX Design 전략 수립
- 프로덕트 설계서 (IA 설계, 기능정의, Wireframe, Workflow 설계)
- Business(시장성)
- 고객(사용성, 적합성, 편리성)
- 기술(Tech, 구현, 개발환경에 맞는 개발)
1-2. Agile 방식 PM,PO
- 사업기획자: 사업측면에서의 기획, 전략을 수립하는 JD
- 프로덕트 매니저: 실제 구동이되는 프로덕트의 설계업무 요구, 트랜드&데이터분석 요구 JD
: 스타트업에서는 빠르게 업무를 추진하기 위해서 애자일방식을 차용
1) 애자일 방식의 서비스 기획자
- Waterfall 방식: Define → Design → Develop → Test → Deploy → 최종 결과물
- Agile 방식: 최소기능제품(MVP)을 빠르게 테스트하고, 고객 피드백을 바탕으로 제품을 개선/출시할 수 있는 단위로 진행. "Just in Time" 전략을 통해 한 단계씩 진행, 빠른 출시를 목표.
| · "Just in Time" 한번에 다 하려하지 말고, 빨리 출시하자 · [Define] - [Design] - [Develop] - [Test] - [Deplay] → Sprint's Outcome · 가설 수립/테스트 → 고객대상으로 [데이터분석, A/B테스트]가 진행되어 고객친화적이 & 결과치 빠른 대응 가능 · [Define] - [Design] - [Develop] - [Test] - [Deplay] → Sprint's Comulative Outcome · Define(1차 결과물을 반영하는 동안, 다음 차수의 요구사항 준비) · [Define] - [Design] - [Develop] - [Test] - [Deplay] → Sprint's Comulative Outcome |
2) 스프린트 플래닝
- 스프린트 목표를 설정하고, 2주 안에 완료할 수 있는 작업을 계획하는 회의. (한 사이클을 전략질주)
- 스프린트 플래닝의 반복: 2주 스프린트 * 2회 = 1달, 1달 * 3회 = 1분기, 1분기 * 4회 = 1년
3) 스프린트에서 공유하는 문서
- 이전 스프린트에 개발 완료한 항목
- 이전 스프린트에서 개발을 완료하지 못한 항목 (개발 완료하지 못한 것을 그 다음에 개발할지 여부)
- 이전 스프린트에 발생한 기술적 이슈 또는 버그
- 이전 스프린트에 대한 회고 (기간 내 마무리 못한 것 & 부족한 부분 등의 히스토리 기록)
- 이번 분기의 OKR(Objective Key Result)달성 상황
- 이번 스프린트에 개발을 해야 하는 것
4) 애자일 팀 구성원 예시
- 각 Product별로 PM, 디자이너, 개발자, QA가 구성되어야 함.
- 업무의 집중도를 높이고, 각 프로젝트의 빠른 의사소통 및 대응이 가능.
5) 장점과 단점
- 장점: 고객 중심적, 동시다발적인 고도화 작업 가능
- 단점: 인력 비용이 많이 들고, 협업이 잘 되어 있어야 함. 팀워크에 따라 결과가 달라질 수 있음 (케바케)
1-3. 워터폴(Waterfall) vs. 애자일(Agile) 선택 기준
1) 워터폴(Waterfall) 적용 사례
- 다양한 상황을 고려해야 할 때
- 대규모 데이터를 다루는 서비스 (예: 클라우드 서비스, 금융 서비스 등)
- 완제품으로 출시되어야 하는 경우
2) 애자일(Agile) 적용 사례
- 규모가 크지 않은 스타트업 프로젝트
- 최소한의 단위로 업무를 수행하고 빠르게 테스트할 수 있는 B2C 프로젝트
1-4. PO(Product Owner)와 PM(Product Manager)의 차이점
1) PO(Product Owner, 전략가)의 역할
· 고객을 대변하며 사업적 가치를 창출할 수 있는 가설 설정
· 가설 검증 방법 계획, 개발 및 디자인 요구사항 정의
· 성공 지표 및 세부 지표 검토, 데이터 분석
· 업무 할당, 추적, 관리를 위한 개발 티켓 생성
· UT(User Test) 후 고객 피드백 정리 및 인사이트 발굴
· 고객 및 유관부서와 소통을 통한 개발 백로그 관리
2) PM(Product Manager, 실행자)의 역할
· 개발 조직과 협의하여 개발 일정 정의
· 구체적인 개발 티켓 생성 및 정리
· 타 개발조직과 협업 시 요구사항 정리 및 회의 진행
· 상세한 테스트 방식 기획 및 테스트 진행
· 신규 기능이나 프로덕트에 대한 사용 설명서 작성 및 배포
· 고객 및 유관 부서의 상세 문의에 대한 답변
1-5. PM이 요구하는 역량
1) 고객에 대한 깊은 이해
· 사용자의 심리 이해 및 학습 필요
2) 비즈니스에 대한 깊은 이해
· 기업의 프로덕트이므로 반드시 benefit 추구
3) 개발 환경 및 기술에 대한 깊은 이해
4) 시장 및 산업에 대한 깊은 이해
· 시장 내 트랜드 이해
5) 데이터에 대한 깊은 이해
· Agile 방식 내에서, 테스트 후 결과에 대한 대응 필요
1-5. 서비스 기획자/PM/PO의 공통 역할
- 문제의 본질을 이해하고, 사용자들에게 전달할 서비스의 가치를 창출
- 고객들에게 제공할 경험 및 가치에 대한 고민
- 소통의 중심으로 의견을 경청, 취합하고 의사결정을 함으로써 서비스의 기획 목표, 일관성, 안정성 등에 영향을 미치는 요소들을 컨트롤
2. 프로덕트 목표와 지표 설정하기
1) 프로덕트 기획 단계별 산출물
① Product의 목표, 사용자 정의, 핵심지표 설정
- 목적: 프로젝트의 방향성 설정, 목표 사용자 그룹 식별
- 산출물: 목표 설정 문서, 사용자 정의 문서, 핵심 성공 지표(KPI) 설정
② 구조설계 - 인포메이션 아키텍처(IA)
- 목적: 사용자의 요구와 목표를 충족시키기 위한 정보의 구조화
- 산출물: 사이트맵, 카테고리 및 라벨링 시스템
③ 상위기획 - 요구정의서(요건 정의)
- 목적: 제품이 충족해야 할 기능적, 비기능적 요구사항 정의
- 산출물: 요구사항 명세서
④ 상세 설계 - 와이어프레임, Workflow
- 목적: 제품의 구체적인 디자인 및 사용자 경험(UX) 설계
- 산출물: 와이어프레임, 사용자 인터페이스(UI) 디자인, 사용자 경험(UX) 플로우도
2) 서비스 목표와 지표 정의
OKR(Objective and Key Results) 목표와 핵심결과
- 목적: 명확하고 측정 가능한 목표를 설정하여, 팀이나 조직의 방향성을 결정
- 산출물:
2-1. OKR
1. OKR 구성 요소
1) 목표(Objective)
- 분기 단위 목적 설정 (1~3개월)
- 특징:
2) 핵심 결과(Key Results)
- 측정 가능한 지표 설정 (3~5개)
- 특징:
3) 핵심 지표를 이루는 3가지 요소
- 달성 기간: 목표 달성을 위한 시간 설정 (예. 7/1~7/31 한달간)
- 행동 지표: 구체적인 목표 달성을 위한 행동 사항 (예. 서비스 회원 가입자수 2만명 돌파)
- 정량적 수치: 행동 지표를 수치화하여 달성 정도 파악 (예. 7/31일까지 1만 2,000명 달성)
4) MBO와 OKR의 차이점
MBO (Management by Objective, 무엇?)
- 주기: 1년
- 범위: 개인별 or 부서별
- 방식: 하향식
- 보상 연결: 보상과 연결됨 (KPI에 따라 보상연결)
- 특징: 위험 회피적
OKR (Objective and Key Result, 무엇을 어떻게?)
- 주기: 분기 or 월
- 범위: 공식적 & 투명한
- 방식: 상향식 or 수평식 (~50%) (조직원들이 같이 논의)
- 보상 연결: 대부분 보상과 관련 없음 (부서/팀마다 목표가 상이하기 때문에, 모든 일에 집중)
- 특징: 공격적 & 도전적 (상향 목적)
5) OKR을 통한 효과
- 투명성: 모호하지 않은 명확한 목표 설정
- 동기 부여: 협업으로 인한 전 부서의 동기 부여
- 협업: 모든 일정과 업무 진행 현황 예측 가능, 협업 문화 극대화
| · If you can't measure it, you can't manage it by Perter Drucker의 MBO(Management by Objective) "측정할 수 없다면, 관리할 수 없다" · (1954) Perter Drucker develops 'MBO' → MBO · (1968) Andy Grove founds Intel → OKR 개념 · (1974) John Doerr Joins Inter → 나중에는 Google에 합류하면서, OKR개념을 전수 · (1999) Jogn Doerr Invest in Goolge → Google 성공사례 · (2019) OKR is broadly adopted by large corporates (Linkedin, Facebook, Amazon, Walmart) → 스타트업에서 도입 |
2-2. OKR이지만, 피해야 하는 실수들
1) 목표 설정과 보상 분리
- 목적: 평가 관리를 위해 목표와 보상을 분리한다.
2) 목표 설정 주의사항
- 너무 쉬운 목표 피하기: 상향된 지표를 설정한다.
- 탑다운 방식 피하기: OKR은 조직 구성원이 협업하여 진행한다.
- 모호하고 주관적인 목표 피하기: 객관적이고 평가 가능한 지표가 필요하다.
- 할 일 목록으로 취급하지 않기: 목표는 달성하고자 하는 지표로 설정한다. (우리가 가고자 하는 목표/달성한 지표 (O) > 일반적으로 우리가 해야할 일 (X))
3) 예시) 목표 - 결과 - 결과에 따른 수치화(달성율)
2-3. OKR 사례
1) OKR 좋은 사례
- 고객 경험 개선
- 새로운 서비스 론칭
- 자동화를 통한 운영 비율 감소 (쿠팡 사례)
- 트럭 배송 시스템 완성 (줌피자 사례)
2) OKR 잘못된 사례
- 바이럴 마케팅
3) 지속적인 추적과 평가
- 지속적인 추적: 주 단위로 발전 상황을 점검하고, 목표를 동료들과 공유한다.
- 평가와 분석
4. AARRR 지표
- 미국 벤처 캐피탈 500 STARTUPS의 창업 기획자 '데이브 맥클루어'가 개발한 분석 프레임워크 '시장 진입 단계'에서 특정 지표를 기준으로, 서비스의 상태를 가늠할 수 있는 효율적인 지표
1) Acquistion(유입)
- 목적: 사용자가 서비스에 어떻게 도달했는지 이해하기.
- 주요 지표 및 용어
- 분석 목적
2) Activation(활성화)
- 목적: 사용자가 첫 긍정적인 경험을 어떻게 하는지 이해하기.
- 주요 지표 및 용어
- 분석 목적
3) Retention(유지/재방문)
- 목적: 사용자가 서비스를 재방문하는지 확인하기.
- 주요 지표 및 용어
- 분석 목적
4) Referral(추천)
- 목적: 사용자가 서비스를 다른 사람에게 추천하는지 확인하기.
- 주요 지표 및 용어
- 분석 목적
5) Revenue(매출)
- 목적: 서비스가 매출을 생성하는지 확인하기.
- 주요 지표 및 용어
- 분석 목적
5. AARRR 지표 분석
1) 데이터 분석 과정에서의 기본 원칙
- 문제 기반 접근: 조직의 현재 문제점을 기반으로 데이터 분석 시작
- 패턴 및 추세 분석: 숫자보다는 변화하는 패턴에서 인사이트 도출
- 가설 수립 및 검증: 문제 개선을 위한 가설 설정 및 검증 과정 필요
- 성과 평가: 개선 후 데이터를 통해 결과 평가 및 비즈니스 기여도 측정
2) 주요지표 및 용어 이해하기
- PV(Page View): 페이지가 사용자에게 노출된 횟수
- UV(Unique View): 데이터 수집 기간 동안 페이지에 방문한 중복되지 않는 순 방문자 수
- 전환율(Conversion Rate): 방문한 사용자 중 특정 행위(회원가입, 상품 구매 등)를 한 사용자의 비율
- 이탈률(Bounce Rate): 페이지와 상호작용 없이 사이트를 떠난 단일 페이지 세션의 비율
- 종료율(Exit Rate): 방문한 모든 페이지 중, 1개 이상의 페이지를 보고 화면을 종료한 방문 행동의 비율
3) 데이터 분석 목적
- 조직의 문제점 파악을 기반으로 데이터 분석
- 수치 변화의 패턴과 그로 인한 추세 변화에서 인사이트 발견
- 문제 개선을 위한 가설 수립 및 조직 내 공유와 공감대 형성
- 문제 발견 시점의 데이터를 개선 후 결과 평가의 랜드마크로 활용
- 데이터 분석을 통해 비즈니스 기여 및 성과 창출 확인