[제로베이스 PM스쿨 18기 학습일지 #21] Ch 17.중간점검:고객경험을 만드는 PM 전략 - 프로덕트를 만드는 사람들, 프로덕트 목표와 지표 설정, 프로덕트 관리 및 산출물, 휴리스틱
PM 학습 일지
✅ 프로덕트
핸드폰에서 구동하고 있는 모든 어플리케이션들
🫂 프로덕트를 만드는 사람들
- CEO
비지니스 기획 - 비지니스적 관점, 기업의 이익과 어떻게 연결 될 지 고민 - 개발자
개발 기술 - 기술 변화에 예의 주시, 트렌드를 따라가야 함 - 디자이너
UX/UI 디자인 - 사용자의 고객 경험, 고객에 대한 이해 필요
⇨ 중간 관리자 : 서비스 기획자/PM/PO
📌 서비스 기획자/PM/PO를 나누는 관점 : 프로덕트의 진행 방식 차이
🌊 Waterfall(폭포수) 방식 - 서비스 기획자
[업무 역할]
- 비지니스 기획 / 클라이언트
시장 조사, 수익 창출 Business Model 수립, 사업 전략, 핵심 경쟁력, 최종 사용자들에게 줄 수 있는 가치- Project Manager
프로젝트 일정, 리소스 산정, 계약, 산출물 관리, 업무 할당 및 관리- UX 기획, 서비스 기획
사용자 조사 설계, 고객 관점 사용자 경험 전략 설걔, 요구사항 명세서, 기획서(wireframe, Workflow) 작성[업무 범위 및 요구되는 역량]
- 커뮤니케이션 스킬
- UI / UX Design(고객 경험 디자인), 논리적 사고, UX Research
- Tech(기술)에 대한 이해, 행동 경제학, 인문학, 심리학
[결과물]
- UX Design 전략 수립, 프로덕트 설계(IA 설계, 기능 정의, Wireframe, Workflow 설계)
🧸 Agile(애자일) 방식 - PM / PO
- 최소 기능 제품(MVP : Minimum Variable Product) 빠르게 테스트하고
고객 피드백 바탕으로 제품 개선, 출시할 수 있는 단위- 데이터 분석에 대한 역략 요구
- 가설 수립 / 테스트 : 데이터 분석, A/B Test
⇨ 고객 친화적 방식
[스플린트 플래닝] : 스프린트를 계획하는 회의, 2주 안에 끝낼 수 있는 목표
- 애자일 방식으로 2주간 집중 개발, 스프린트 플래닝의 반복
- 2주 스프린트 x 2회 = 1달
1달 x 3회 = 1분기
1분기 x 4회 = 1년[스플린트에서 공유하는 문서]
- 이전 스프린트 개발 완료한 것
- 이전 스프린트에서 개발을 완료하지 못한 것
(개발 완료 곳한 것을 그 다음 스프린트에 이어서 개발할 지)- 이전 스프린트에 발생한 기술적 이유 또는 버그
- 이전 스프린트에 대한 회고
- 이번 분기의 OKR 달성 상황
- 이번 스프린트에 개발해야 하는 것
[장점]
- 고객 중심적
- 동시다발적인 고도화가 가능
[단점]
- 인력 비용이 많이 든다
- 협업이 잘 되어야 한다 ⇨ 팀워크 중요
✨ Waterfall(폭포수) vs Agile(애자일)
⇨ 프로젝트 특성과 규모에 따라서 다르게 적용
워터폴
- 다양한 케이스를 고려해야 되는 경우
- 대규모 데이터가 접목되어야 하는 경우
ex)클라우드 서비스, 금융서비스, 완제품으로 출시되어야 하는 경우
애자일
- 규모가 크지 않은 스타트업 프로젝트
- B2C 프로젝트로 최소한의 단위로 업무 수행하고 빠르게 테스트할 수 있는 경우
PO / PM의 차이
✅ (C)PO (Product Owner - 전략가 / 상위 기획)
- 많은 의사결정권의 권한, 중요한 역한 전담
- 고객을 대변하면서 사업적인 가치를 창출할 수있는 가설 설정
- 가설을 검증할 방법을 계획하고 개발 및 디자인 요구사항 정의
- 성공지표, 세부지표 등을 검토하고 데이터 분석 진행
- 업무 할당, 추적, 관리하는 개발 티켓 생성
- UT 진행 후 고객 피드백을 정리하고 인사이트 발굴
- 고객 및 유관 부서와의 소통울 통해 개발 백로그 관리
⇨ PO에게 전적인 오너십을 줄 수 있어야 한다
⇨ PO가 협업할 수 있는 전담 개발 조직이 있어야 한다
✅ PM (Product Manager - 실행자)
- 실무에 가까운 위치
- 개발 조직과 협의하여 개발 일정 정의
- 구체적인 개발 티켓 생성 및 정리
- 타개발 조직과 협업해야 할 경우, 요구사항 정리 및 회의 진행
- 상세한 테스트 방식 기획 후 테스트 진행
- 신규 기능 또는 프로덕트에 대한 사용 설명서 작성 및 배포
- 고객 및 유관 부서의 상세 문의에 대한 답변
💪🏻 [PM에게 요구되는 역량] ⇨ 미드필더
- 고객에 대한 깊은 이해
- 비즈니스에 대한 깊은 이해
- 개발 환경 기술에 대한깊은이해
- 시장과 산업에 대한 깊은 이해
- 데이터에 대한 깊은 이해
⇨ 소통의 중심
- 의견을 경청,취합하고 의사결정 한다
- 서비스의 기획 목표, 일관성, 안정성 등에 영향을 미칠 수 있는 요소들을 컨트롤한다.
🌟 서비스 기획자/PM/PO 는
문제의 본질을 이해하고,
사용자들에게 전달할 서비스의 가치를 만들어 나가는 미드필더 역할
프로덕트 목표와 지표 설정하기
프로덕트 기획 단계별 산출물
서비스 목표와 지표 정의
🗝️ OKR (Object and Key Results - 목표와 핵심 결과)
목표(Object)를 설정하고 그 결과(Key Results)를 측정하는 목표 관리 프레임워크
IF YOU CAN'T MEASURE IT, YOU CAN'T MANAGE IT" 측정할 수 없다면 관리할 수 없다 "
Peter Drucker의 MBO(Management by Objective) 철학
[OKR 구성]
⇨ Objective (분기 단위로 목적 설정) & Key Result (측정 가능한 지표 3~5개)
목표를 달성했는 지 확인하기 위해 핵심 결과를 수치화
목표 (Objective)
- 명확한 목적
- 공격적인 달성 목표 제시
- 조직에 맞는 주기로 설정
(조직의 목표는 1년, 팀의 목표는 분기마다)- 목표는 최대 1-3개 정도 설정
- 목표 진척 사항을 매주 ~ 2주 단위로 측정
핵심 결과 (Kev Results)
- 정량적이고 측정 가능
(측정 가능한 수치화된 지표 포함)- 비교 가능하도록 기준점(Benchmark)이 되는 수치 기록
- key results 달성하기 위한 구체적인 milestone/action plan 있어야 함
📌 핵심 지표를 이루는 세 가지 요소
- 달성 기간 : 들어가도 되고, 안 들어가도 됨
목표로 정한 행동 지표와 정량적 수치를 언제까지 달성해야 할 지
ex) 7/1 ~ 12/31 까지 6개월 간- 행동지표(How to)
목표를 달성하기 위해 행동해야 할 매우 구체직인 내용
ex) 서비스 회원 가입자 수 2만명 돌파- 정량적 수치
행동 지표를 정량적 수치로 표기하여 달성 정도를 파악할 수 있어야 함
ex) 7/1 ~ 12/31 까지 현재 1만 2000명 달성
🌟 MBO와 OKR의 차이
🪄 OKR을 통한 효과
- 투명함 : 의구심이 들지 않음
- 동기부여 : 공개적인 목표, 진행 상황 공개
- 협업 : 다른 팀과 협업
[ 피해야 하는 실수들 ]
- 평가 관리하기 위한 목적 X ⇨ 협업이 건전하게 이루어 지지 못함
- 너무 쉬운 목표 X ⇨ 공격적으로 가야 함
- 탑다운 방식 (강제적인 할당 방식)
- 모호하고 주관적인 목표
- 할 일 목록 X ⇨ 서비스가 가고자 하는 방향에 대한 지표 달성 도구
🏃🏻♂️ OKR : 동기부여 & 지속적인 추적 필요
⇨ 주 단위 발전 상황을 지속적으로 점검
⇨ 목표를 동료들과 공유하고 발전 상황을 지속적으로 검토해야지만 가능성 높아짐😊 마무리 OKR : 평가와 분석
🐣 OKR 사례
- 매주, 2주 단위로 작성 / 수치화 해서 표기
- 목표#2 - 핵심 결과 #3은 적합하지 못한 OKR ⇨ 수치화 할 수 없음
- 수치화된 자세한 결과 ⇨ 좋은 OKR
[잘못된 OKR 사례]
- 수치화되지 못하고 두리뭉실 방법(To-do List 아님)
🪅 AARRR 지표
미국 벤처 캐피탈 500 Startup 창업 기획자 데이브 맥클루어가 개발한 분석 프레임워크
시장 진입 단계에 맞는 특정 지표를 기준으로 서비스의 상태를 가늠할 수 있는 효율적인 지표
📝 주요 지표 및 용어 이해하기
- PV(Page View, 페이지 뷰)
페이지가 사용자에게 노출된 지표- UV(Unique View, 순 방문자)
데이터 수집 기간 동안 페이지에 방문한 전체 사용자 중 중복되지 않은 순 방문자
⇨ PV와 UV 데이터는 특정 기간의 추세를 살펴보거나 증감이 눈에 띄게 큰 날을 찾아 인사이트 발견
⇨ 수치 변화의 패턴에 집중을 하고 왜 변화하였는 지 분석하고 인사이트 발굴하는 것이 중요 : 지표를 보는 목적
- 전환율 (Conversion rate)
방문한 사용자 중 특정 행위를 한 방문자의 비율
ex ) 회원 가입, 상품 구매, 파일 다운로드, 동영상 재생- 의탈률 (Bounce rate)
페이지와 상호작용하지 않고 사이트를 떠난 단일 페이지 세션의 비율- 종료율(Exit rate)
방문한 모든 페이지를 대상으로 1개 이상의 페이지를 보고 화면을 종료한 방문(세션)행동 비율
📈 AARRR 단계별 분석 지표
🌟 데이터 분석 목적 : 문제 진단, 정의, 개션
- 데이터 분석을 할 때 항상 조직의 이슈를 기반으로 생각
- 데이터는 숫자나 수치보다 패턴에서 발견되는 변화/추세 중요
(급격한 추세의 변화에서 인사이트 발견 가능) - 문제를 개선하기 위한 가설을 수립하고, 조직에 공유하고 공감대 형성
- 문제 발견한 시점의 데이터는 개선 후 결과 평가할 때 랜드마크로 활용
- 최종적인 목적은 데이터를 분석하여 비즈니스에 기여하고 성과 창출하는 것
⇨ 문제점이 발생한 지표에 대한 기록 중요
프로덕트 관리 및 산출물
🎞️ 프로젝트 프로세스
⇨ 요건 정의가 작성 되었을 때 개발 담당자들과 협의해서 목표 일정 수립
⇨ 정해진 목표 일자가 있다면, 업무의 우선 순위 선정하기
📆 일정 관리
⇨ 전체 일정 진행 상황 파악, 업무 할당 및 진척도 확인
⇨ WBS (Work Breakdown Structure - 엑셀 형식, 업데이트 기간 소요 - 실시간 X)
⇨ Jira (칸반보드 제공, 전체 일정 & 실시간 상태 진척 관리/확인)
⚠️ 프로덕트 배포할 때 유의 사항
- 배포 일정은 개발 조직이 정한 배포 일정이나 절차가 있는 지 확인
- 미리 배포 일정과 변경사항을 협업팀(법무팀, 마케팅팀, 고객센터)과 공유 협의
- 저녁 늦게 또는 금요일에는 배포 XXX
배포 후 이슈를 대응하기 위해 누군가는 늦게까지 자리를 지켜야 함 - 사용률이나 매출이 급증하는 기간에는 배포 지양
- 배포 일정을 정할 때 플랫폼 고려
ios와 안드로이드는 특정 기관의 검토/승인 필요
ios : 새로운 버전을 배포하려면 애플 입스토어의 승인을 받아야 다운로드 업데이트 가능
안드로이드 : 구글의 승인을 받아야 되지만 상대적으로 덜 보수적 - 플랫폼 배포 순서와 일정을 다르게 진행
국내에서는 안드로이드 앱 을 먼저 업데이트한 후 몇 주 후에 ios 앱 업데이트
🤔 배포 주기를 정해서 업데이트해야 되는 이유
- 여러 팀에서 동시 다발적으로 배포 시도할 경우 기술적인 문제가 발생할 가능성 증가
⇨ 서비스의 안전성, 신뢰도에 영향 - 버전 관리의 어려움 발생
- 수시로 업데이트 될 경우, 고객 경험의 일관성을 유지하기 어려움
📜 산출물 : RFP (Request for Proposal)
- 발주자가 특정 과제의 수행에 필요한 요구사항을 체계적으로 정리하여 제시함으로써 제안자가 제안서를 작성하는데 도움을 주기 위한 문서
- 외주 협력사가 있을 시 작성하는 문서
- 인하우스에 디자이너나 개발자 없을 경우 제안요청서 작성
🤔 RFP는 언제, 왜 필요할까?
- 가장 적합한 파트너사를 선정하기 위해 정해진 일자까지 제안서 제출 요청
- 제안사가 제안서를 기준으로 질문, 테스트, 검증하는 미팅 진행
- 원활하고 의미있는 미팅을 위해 자신의 기획 의도, 사업 방향성을 분명히 인지하고 이를 아웃소싱 개발 업체에 전달할 내용을 RFP에 포함
⇨ 목표에 맞는 제안서를 받았을 때 제대로 된 평가 가능
✒️ RFP 내용 작성
- 개요
- Project 개요 : 프로젝트 소개, 목적, 서비스 컨셉 정의, 대상 국가, 타겟 유저
- 업무내용 : 개발 범위, 리서치 포함 여부, 프로젝트 요건, 운영 기획안, 산출물
- 일정
- 개발 일정 : 예상 일정, F/U 기간 명시
3. 제안서 내용- 유사 서비스 작업 경험 포폴, 과제 수형 계획, 산출물 리스트, 대략적인 배포 일정, 역량/ 강점, 투입 인력 프로필(맨먼스), 견적서
- 제안서 작성 방법 : 파일 타입, 표준 문서 있을 시 명시
4.제안 평가 기준- 제안서 제출 : 응답 시한, 제안서 제출 시한, 제출 방법, 제출처, Contact Point 명시
- 평가 형식 : 제안서로만 평가 or 제안서 발표 평가(발표 날짜), 평가 절차 단계
- 결과 발표
- 결과 통보 방식, 통보 기한 명시
📬 제안서 양식
🧩 구조 설계 - 산출물 : 메뉴 구조도
Main structure를 파악할 수 있는 계층적 구조 ⇨ Depth 구조 & 뼈대 파악
웹/앱 서비스가 어떻게 구성되어있는 지 보여주는 도구
🧩 구조 설계 - 산출물 : I.A.(Information Architecture)
정보 구조 설계, 어떤 기능을 하는 화면들이 어떤 뎁스
모든 페이지, 기능 정의
- 메뉴 구조도보다 더 자세히 작성, 넘버링 중요
- 개발자들과 가장 많이 소통하며 활용하는 문서 중 하나
- 다양한 문서의 기준 문서가 됨
예시 - 웹어벤져스 홈페이지 제작 샘플
🖼️ 상세 설계 - 산출물 : Wireframe
화면 단위 구조(레이아웃)을 설계하는 작업
- 이해관게자들과 빠르게 레이아웃, 기능, 콘텐츠들을 협의하기 위해 설계
- 설계된 정보 구조를 기반으로 화면 구성
- 빠른 구성요소, 구조 검토와 의사결정을 위한 도구
[작성 tip]
- 페이지 목적에 집중
- 요소만 정의 (디자인은 디자이너에게)
- Text는 텍스트 속성으로 작성하거나
- 하나만 예시로 작성해도 됨
ex) 날짜: YYYY. MM.DD 시간: HH:MM
🖼️ 상세 설계 - 산출물 : UserFlow
실제 사용자들이 구체적으로 이용하는 순서에 따라 화면들이 전개되는 지 정의
[User Flow의 활용 목적]
- 앱의 실행부터, 기능이 동작하는 순서, 화면 간 흐름을 제공
- 일관된 사용자 경험을 제공
- 복잡한 흐름을 쉽게 파악
- 발생할 수 있는 모든 case와 error 체크
[U1 디자인 digital tool]
- Sketch
- AXURE
- InVision
- Figma
- Adobe XD
🖼️ 상세 설계 - 산출물 : UI Workflow
🪀 산출물 : Prototype을 활용한 Small test
처음 접하는 기능 또는 디자인을 어떻게 사용하는 지 관찰하는 목적
Agile 방식 )
중간 테스트 과정을 통해 작은 스몰 테스트를 하여 고객 반응 확인, A/B Test를 통해 유입률을 더 높일 수 있는 요소 파악
[준비]
- 조건을 명확하게 정의한 후, 테스트 대상자를 섭외
- 테스트 도중 검증해야 할 사항들을 미리 정리
- 참여자는 5명 이상
[장점]
- 고객의 의견을 빠르게 확인 가능
- PO나 디자이너가 간과했던 사실들을 효과적으로 확인 가능
- 사용자가 불편함을 느끼거나 예상치 못한 돌발행동을 하는 곳에서 개선사항 발견 가능
☑️ 휴리스틱
🐣 오늘자 일기
안녕?! 오랜만에 돌아온 주인장!!
무슨 일이 있어서 오랜만에 돌아온 건 아니고,, 공부 권태기가 왔달까,,ㅎㅎ
모두 다 하기싫어병에 걸려서 고작 LMS 과제만 하고 다른 스터디들 아예 안해보림,,,
그래도 해야지!! 맞잖아? 누가 내 인생을 책임져? 아무도 안책임져!
나 혼자 스스로 책임져!! 왜냐! 난 다 큰 성인이니까!! 왕멋진사람!!!
방황해도 돼!! 그래도 그 행동을 뒤돌아보고 다시 책임질 수 있으면 돼!!!
포기하지 않고 끝까지 해내면 돼!! 맞지?!! 난 자취도 하는 멋진 어른이니까!! 헿
이번주 2배로 고생해서 남들 끝낸 것들 다 해내기!! 땅땅!!!! 나 강조이 할 수 있따!
나중에 공부하면서 적은 일기들 보면 재밌겠다 ㅎㅎㅎ 나의 사소한 방황일기를 읽을 수 있는 거 꽤나 짜릿할지도,,ㅎㅎ 이렇게 내 맘을 자세하게 적는 이유는 내 블로그는 꽤나 사람들이 안 봄,,ㅎㅎ SQL 관련된 거랑 개발관련 된 것만 보고 PM관련은 잘 안보더라구,,,ㅎ 헿 다 나름 데이터 기반으로 해서 적는 거란 말이오! 엣헴 ㅎㅎ
자자자자자!!! 달려보쟈구~~~!
