블로그
전체 82025. 03. 31.
0
워밍업 클럽 스터디 3기(PM) - [미션 4] 기회 솔루션 트리 만들기
[미션 4] Opportunity Solution Tree 만들기 프로덕트 개요현재 사이드 프로젝트로 진행 중인 저의 프로젝트는 '사이드 프로젝트 팀 빌딩을 돕는 웹서비스'로, 핵심적인 특징은 다음과 같습니다.온보딩 및 프로필 작성가입 후 온보딩 과정을 통해 회원들은 기술 스택, 경력, 희망 포지션, 프로젝트 이력 등 자신의 역량을 구체적으로 기재할 수 있습니다.프로필의 공개 여부를 회원 스스로 선택할 수 있으며, 공개로 설정하면 사이트 메인 페이지(또는 검색 결과 등)에 노출됩니다.프로필 열람 및 채팅 기능 제공공개된 프로필을 다른 회원들이 열람함으로써, 적합한 협업 상대를 찾도록 유도합니다.컨택하고 싶은 인재를 발견하면, 자체 채팅 기능을 통해 직접 대화를 나눌 수 있습니다.Desired Outcome현재 프로덕트는 아직 출시 이전이기 때문에 최상단 목표를 설정할 때 유저의 유입/전환, Engagement, Retention에 집중하였습니다.가장 첫 번째로 "서비스 론칭 후 3개월 이내에 가입자 수 1000명 획득"을 최상단 목표로 설정하였습니다. Opportunity가장 첫 번째로 주요 기회들을 다음 세 가지로 설정해보았습니다.인지도 부족설명: 우리 서비스를 모르는 사람이 너무 많다. 존재 자체가 알려지지 않아 유입이 적다.가치 및 차별점 불분명설명: 사용자가 서비스에 들어와도 '이걸 왜 써야하지?'라는 물음에 즉각적인 답을 주지 못해 가입이나 실제 이용으로 이어지지 않는다.초기 네트워크의 부족설명: 서비스에 들어온 사람이 봤을 때, 이미 등록된 프로필이나 활동 중인 유저가 거의 없으면 '사람이 없네?' 하고 떠나버리는 악순환이 발생한다.위의 기회들을 다시 세부적인 기회들로 나누어보면 다음과 같습니다.1. 인지도 부족1-1. 프로덕트의 노출 부족타겟을 설정했지만 실제로 제품을 볼 수 있도록 하는 지속적인 노출 창구가 부족1-2. 바이럴/소개 동기의 부족기존 유저가 친구를 초대하거나 다른 사람에게 소개할 만한 동기가 부족2. 가치 및 차별점 불분명2-1. 서비스의 대략적인 개요를 보여줄 수 있는 랜딩페이지의 부재웹 사이트 방문자들을 후킹할 수 있는 랜딩 페이지가 없음2-2. 신뢰도/레퍼런스의 부족이 서비스를 통해 성공적으로 팀을 만든 사람이나 실제 사례가 없어 보인다. 따라서 사용자 입장에서 서비스가 유용할지 확신하기 어려움2-3. 차별화 포인트 부각의 부족기존에도 다른 팀 빌딩 서비스, 커뮤니티 등이 많을 텐데, 우리는 무엇이 다르며 더 좋은가?3. 초기 네트워크 부족3-1. 초기 사용자(Seed) 풀 미비실제 등록된 프로필이 너무 적거나, 특정 분야에만 치우쳐 있어서 전체적인 팀 빌딩이 어려움3-2. 빈약한 첫 인상새로 들어온 사용자가 메인 페이지에 프로필이 거의 없음을 발견하고 이탈로 이어지는 문제3-3. 활동 지속/재방문의 문제초기 사용자가 들어와도 한 번 둘러보고 '아직 사용자가 없네' 하고 재방문을 안 하는 문제Solution각각의 하위 기회들에 대한 솔루션들을 다음과 같이 생각해보았다.1-1. 프로덕트 노출의 부족SNS 계정 운영 및 정기 콘텐츠 발행서비스 관련 팁, 사이드 프로젝트 성공 사례 인터뷰, 그 외의 IT 지식 정보 등을 게시하여 자연 유입 유도1-2. 바이럴/소개 동기의 부족초대 기능 제공초대를 통한 가입 시, 프로모션 제공팀 빌딩 성공 사례 공유 이벤트"우리 서비스로 팀을 결성함"을 보여주는 후기나 SNS 게시물 작성 시 소정의 베네핏 제공2-1. 서비스의 대략적인 개요를 보여줄 수 있는 랜딩페이지의 부재서비스의 가치를 한 눈에 전달할 수 있는 랜딩페이지를 제작2-2. 신뢰도/레퍼런스 부족베타 테스터를 통한 성공 사례 만들기 + 후기 작성실제로 서비스를 이용한 사용자가 어떤 결과물을 냈는지, 그 과정은 어떠했는지 보여줄 수 있는 사례를 소개'완료된 프로젝트' 갤러리 구축MVP 또는 간단한 결과물이라도 "이 팀이 여기서 만나 이런 것을 만들었다"를 보여줄 수 있는 창구 만들기2-3. 차별화 포인트 부각의 부족UX 편의성, 온보딩, 원하는 인재 직접 컨택 등 특장점 어필3-1. 초기 사용자(Seed) 풀 부족오픈 베타를 진행하여 한정된 그룹을 단체 등록초반에 최소 50~100명 정도는 프로필이 작성되어 있어야 새로 온 사람이 “오, 여긴 사람이 있네”하고 가입 유지3-2. 빈약한 첫 인상가상/샘플 프로필(“테스트 사용자”)로 최소한의 목록 확보실제 사람처럼 보이는 건 아닌지 윤리적 문제를 고려해야 하지만, 적어도 ‘보여줄 데이터’가 전혀 없진 않게끔 조정3-3. 활동 지속/재방문의 문제알림/카카오톡 등으로 재방문 유도“당신이 찾는 포지션의 인원이 들어왔습니다” 등 가입자 풀이 조금씩 늘어날 때마다 알려주어 복귀 유도.Opportunity Solution Tree 그리기위의 내용들을 바탕으로 다음과 같은 기회 솔루션 트리를 그릴 수 있습니다.
기획 · PM· PO
2025. 03. 25.
0
워밍업 클럽 스터디 3기 (PM) 4주차 발자국
강의명: 시작하는 PM/PO들에게 알려주고 싶은, 프로덕트의 모든 것코치: 김민우링크: https://inf.run/JMgwt4주차 강의 포인트 제품 발견 (Product Discovery)어떤 제품을 만들지 결정하는 방법구시대적인 제품 개발 프로세스를 비판하기 위해 탄생 제품이 실패하는 이유제품을 잘 모르는 사람들이 아이디어를 냄제품 조직에 권한과 자율성이 없음제품 로드맵 자체의 문제검증을 마지막 단계로 넘겨서 큰 기회 비용이 유발 제품 개발에 관한 잘못된 전제들소프트웨어 제품을 만드는 일은 간단하고, Non - Technologist들이 주도할 수 있다는 전제소프트웨어 개발이 예측 가능한 프로세스라는 전제로드맵에 있는 아이템들이 사전에 예측한 만큼 임팩트와 성과를 낼 것이라는 전제 Problem / Opportunity Discovery제품 조직이 어떤 문제(기회)에 집중할 지 찾는 과정 Solution Discovery문제를 어떻게 해결할지, 또는 기회를 어떻게 잘 활용할지 찾는 과정 Product Discovery는 전체적으로 '가설(Assumption)'을 수립하고 검증하는 일련의 과정AssumptionPM에게 Assumption이란?우리가 고객이나 제품에 대해 갖고 있는 믿음이나 추측 Assumption의 유형Value(Desirability) AssumptionsUsability AssumptionsFeasibility AssumptionsViability Assumptions Assumption이 있을 때 두 가지 모드실행하기Assumption이 현실에 부합할 것이라고 믿고 실행하는 것. 기회비용의 지출을 감수하는 것.테스트하기기회비용 리스크를 줄이기 위해 현실과 부합하는지 검증 실행 vs. 테스트 판단 기준Risk : 틀리는 경우 우리는 얼마나 큰 타격을 입는가?Assumption의 위험도를 따지고 검증할지 여부를 판단 Evidence : 얼마나 탄탄한 근거를 가지고 있는가?Assumption 검증하기Assumption 검증에서의 함정'검증 = 실험 = A/B 테스트'라고 생각하는 것Assumption에 맞는 검증 방식을 사용하면 됨전형적인 방법론을 무비판적으로 사용하는 것중요한 것은 Key Assumption을 정의하고 검증하는 것 Value Assumptions 검증문제 Assumption 검증 방법심층 인터뷰간단한 설문조사시제품 반응유저 행동 데이터 분석Usability Assumptions 검증사용성 테스트 초점 있는 Product Discovery를 하려면 꼭 필요한 것지양해야 할 접근법 : 초점 없는 아이디어 난사, 즉 제대로 된 전략의 부재전략의 역할제대로 된 전략이 있으면 선택과 집중을 할 수 있음Guiding Policy(전략적 방향성)에 맞는 아이디어들은 집중적으로 실행하게 됨전략에서 중요한 것은 '뭘 하지 않을 것인가'를 정하는 것 Opportunity Solution Tree & North Star Framework우리 조직이 집중할 목표 성과 하나를 정의하고목표 달성을 위해 활용할 수 있는 다양한 기회 영역을 파악하고 정의하는 방법Opportunity Solution Tree목표 성과 정의하기기회 맵핑(Opportunity Mapping)여러 기회를 하나의 상위 기회 및에 그룹핑(Grouping) 하는 것집중할 영역 정하기기회들을 비교하여 하나의 집중할 영역을 결정솔루션 탐색기회와 솔루션 다양하게 탐색. 이때 중요한 것은,- Opportunity space를 충분히 탐색- 다양한 아이디어들의 Assumption을 점검하고, 가장 유력한 솔루션을 검증하고 실행하기기회란?고객이 느끼는 불편함, 해결이 필요한 상황 + 고객이 충족시키고 싶어하는 욕구즉, 니즈, 페인 포인트, 욕구기회는 어떻게 찾아낼 수 있을까?고객에 대한 깊은 이해가 필요어떤 기회를 선택할지 판단하기 어려운 이유서로 다른 식으로 표현됐지만, 사실 같은 기회들완전히 분리되어 있지 않고 서로 연결되어 있는(하지만 완전히 똑같지는 않은) 기회들어떤 기회는 굉장히 크고 추상적North Star Framework기회 솔루션 트리보다 조금 더 '지표'에 초점을 맞춘 방법좋은 North Star Metric제품 조직이 영향을 끼칠 수 있다고 믿어지는 레벨의 지표그 지표가 개선됐을 때 중장기적 사업 성과에 큰 도움이 될 것이라고 믿어지는 지표'고객들이 우리 제품에서 얼마만큼 가치를 얻어가고 있는가?'를 보여주는 지표North Star Framework 설계하기Output 지표(NSM) 설정Input 지표 설정Input 지표를 높이기 위한 Opportunity 정의Intervention : 기회 정의 후 솔루션 아이디어 구상Opportunity Solution Tree와 North Star Framework의 공통점'성과 내기'라는 ill-structured problem에 구조를 부여하는 행위Opportunity Space와 Solution Space를 충분히 탐색하는 것이 중요의사결정에 도움을 주는 개념적인 지도 Product GrowthGrowth Work란?기존 시장에 더 많은 유저/고객들이 우리 제품을 도입하도록 하고, 더 활발히 사용하게 만듦으로써 가치를 창출하는 일제품이 크게, 빠르게 성장하려면?많은 사람들이 원하는 것을 만들기 = PMF그들에게 도달하고, 그들이 제품을 이용하도록 만들기 = Growth그로스 레버 (Growth Lever)고객 여정에 변화를 줌으로써 우리 사업의 성장에 영향을 끼치는 방법들 첫 번째 그로스 레버, AcquisitionAcquisition에서 제품의 역할사용자들이 다른 사용자를 초대하게 만들기 (Referral)레퍼럴이 잘 작동하려면고객이 제품에 만족해야 함고객이 제품의 가치를 금방 느낄 수 있어야 함 (Quick time-to-value)많은 사람에게 어필할 수 있는 제품이어야 함 (Broad value proposition)제품이 광고판 역할을 하게 하기UGC(User-Generated Content)로 사용자 유입시키기유저 획득 2가지 방법사용자들의 UGC 공유검색 엔진에 UGC의 노출다른 제품과의 연동을 통한 획득 두 번째 그로스 레버, Retention리텐션은 그로스에서 가장 중요한 지표 리텐션의 인풋 - 아웃풋 관계다음 요소들이 리텐션의 증가로 이어짐고객이 제품을 이용해서 문제를 해결하는 것그로 인해 가치를 느끼는 것계속해서 문제를 해결하기 위해 이용하고자 하는 것리텐션의 주요 레버 두 가지 Activation, EngagementActivationActivation의 3단계Setup - Aha - Habit유저 온보딩신규 유저가 제품에 안착하기까지, 즉 Habit Moment에 도달하기까지 일련의 과정Setup Moment의 증가를 위한 행동사용자 데이터 수집연결 관계 만들기유저 맥락에 맞는 설명Aha Moment의 증가를 위한 행동제품의 가치를 빠르게 경험할 수 있도록 온보딩을 구성Habit Moment의 증가를 위한 행동Hook ModelTrigger : 사용자에게 자극이 주어지는 것External Trigger : 사용자 행동을 촉발하기 위한 외부 자극Internal Trigger : 사용자의 마음 속에서 저절로 일어나는 트리거Action : 사용자가 행동을 하는 것구체적인 행동을 유도 해야 함.Reward : 행동에 대한 보상이 주어지는 것물질적인 보상보다는 심리적인 보상이 습관을 형성하는데에 더 강력한 역할Investment : 시간과 노력을 투자하는 것제품에 투자할수록 사용자가 인지하는 제품의 가치가 높아짐 EngagementEngagement 레벨을 높이는 세 가지 요소DepthFrequencyEfficiencyBJ Fogg의 Behavior ModelBehavior = Motivation x Ability x PromptMotivation : 동기가 충분히 클 때Ability : 능력을 충분히 가지고 있을 때, 즉 행동을 하기가 얼마나 쉬운가/어려운가Prompt : 트리거가 적당히 주어질 때 세 번째 그로스 레버, MonetizationMonetization에 관한 기본 질문누구에게 돈을 받을 것인가?우리 제품이 얼마나 많은 사용자를 모을 수 있는가사용자를 많이 모으는 것이 우리 제품에 얼마나 중요한가위의 기준을 통해 "누가 돈을 낼 의지와 능력이 있는지" 판별무엇을 대가로 돈을 받을 것인가?Value Unit : 판매가자 구매자에게 제품을 제공할 때, 구매자에게 제공되는 가치의 단위. 이는 곧 과금 단위가 됨.예시) Usage-Based Pricing = 사용량에 비례하여 과금Incentive Alignment : 고객의 이익과 우리의 이익이 최대한 합치되어야 한다.얼마를 받을 것인가?Cost : 제품을 고객에게 제공하기 위해 비용이 얼마나 드는가?가격은 비용을 커버할 수 있어야 함.소프트웨어 제품은 CAC(고객 획득 비용)를 고려해야 함.Competition : 경쟁사는 얼마를 받는가?Value : 고객은 우리 제품이 얼만큼 가치가 있다고 생각하는가?우리 제품의 가치를 고객에게 어떻게 인지 시킬 것인지 생각해야 함.Value PropositionPositioning'우리 제품에 대한 고객의 Perceived Value에 따라 우리가 받을 수 있는 가격이 달라질 수 있다. 고객의 인식에 어떻게 영향을 끼칠 수 있을까?' 라는 식으로 접근어떻게 수익을 극대화 할 수 있을까?가격 높이기판매 수량 늘리기 Growth Model, 우리의 제품 성장 메커니즘 도식화 하기Growth Model우리 제품의 성장에 영향을 끼치는 중요한 요소들을 도식화 한 것.우리 프로덕트가 성장하는 메커니즘을 이해할 수 있음.각 요소들이 어떤 역할을 하는지 이해하면, 그 요소들에 영향을 끼쳐서 성장을 만들 방법을 알 수 있음.정성적 그로스 모델Acquisition, Retention, Monetization, 이렇게 세 가지 그로스 레버를 고려하여 모델링 하기.4주차 회고이번 주 강의는 PM으로써 제품을 찾는 단계부터 그 제품을 성장시키는 단계까지에 대한 내용을 알 수 있는 강의였다.처음 강의를 듣게 된 계기는 PM이 어떤 일을 해야 하는지, 어떤 역량이 필요한지에 대한 보다 객관적인 정보를 얻고 싶은 마음이었다. 4주차까지 강의를 듣고 난 후, 나의 의문이 다소 우문이었다는 생각을 하게 되었다. 어쩌면 PM이라는 직무는 객관적일 수 없는 직무인데, 그 곳에서 객관성을 찾고 있었던 나를 알 수 있었다. 다만 PM이 어떤 태도를 가지고 과업에 임해야 하는지, 어떤 지식들이 PM에게 도움이 될 수 있는지에 대해 잘 알 수 있는 강의였던 것 같다. PM이라는 직무는 지식을 쌓는 것보다도 경험이 가장 중요한 직무인 것 같다. 앞으로 더욱 다양한 경험을 통해 나의 실력을 향상시키고자 한다.
기획 · PM· PO
2025. 03. 24.
0
워밍업 클럽 스터디 3기(PM) - [미션 3] 프로덕트 지표 설정하기
미션 3. 프로덕트 지표 설정하기여러분이 맡은 프로덕트에서 어떤 지표들을 측정할지 설정해보세요.단, 프로덕트 지표 프레임워크 강의에서 소개한 지표들은 제외합니다.맡고 있는 프로덕트가 없는 경우, 프로덕트를 하나 정해서 해 보세요.지표의 이름을 정하고, 지표의 계산식을 정의해보세요.그 지표를 측정해야 하는 이유는 무엇인지, 지표의 변동에 따라 어떤 의사결정 또는 후속 조치를 해야 하는지 작성해보세요.프로덕트 : 사이드 프로젝트 팀 빌딩 플랫폼프로덕트 소개 요약사이드 프로젝트 팀 빌딩을 지원해주는 서비스.유저가 자신의 프로필을 작성 후 게시할 수 있음.프로젝트 팀 빌더는 게시되어 있는 다양한 프로필을 열람하고 자신이 원하는 인재를 찾아 컨택할 수 있는 환경 제공. 프로덕트가 "잘 운영되고 있음"의 근거가 될 수 있는 액션들회원이 프로필을 충실히 작성하는 행동프로필 공개 설정 비율타인의 프로필을 열람하는 행동타인의 공개 프로필을 보고 직접 컨택(채팅)을 거는 행동채팅을 통한 의미 있는 커뮤니케이션 발생외부 툴 정보 교환팀 결성(프로젝트 참여) 선언재사용(재방문) 행동지표 1. 프로필 완성도(%)정의: 가입 중 온보딩 과정에서 프로필 작성 시, 프로필의 핵심 항목 기재 비율프로필 핵심 항목 예시경력 사항희망 포지션세부 포지션보유 기술 스택프로젝트 이력계산식: (작성 된 필드 수 / 전체 필수 필드 수) * 100활용: 온보딩 완료율 확인, 서비스 참여 의지 확인 지표 2. 유저 완성 프로필 비율(%)정의: 전체 유저 중 프로필 완성도(지표 1)가 일정 수치 이상인 유저의 비율계산식: (프로필 완성도 >= 80%인 유저 수 / 전체 유저 수) * 100활용: 온보딩 완료율 확인, 서비스 참여 의지 확인 지표 3. 공개 프로필 비율(%)정의: 전체 유저 중 자신의 프로필을 공개 상태로 등록한 유저의 비율계산식: (공개 프로필 유저 수 / 전체 유저 수) * 100활용: 유저들이 실제로 프로젝트 팀 빌딩을 위해 자신을 노출할 의향이 얼마나 높은지 파악 지표 4. 1인당 프로필 평균 조회수정의: 일정 기간 내 활성 사용자들의 프로필 조회 수의 평균계산식: (일정 기간 내 총 프로필 조회 수) / (일정 기간 내 활성 사용자 수)활용: 유저가 적극적으로 서비스를 이용하고 있는지, 매칭 시도를 위한 탐색 행동이 활발한지 파악 지표 5. 신규 채팅 개시율(%)정의: 일정 기간동안의 프로필 조회 수 대비 새롭게 생성된 채팅방의 총 건수(신규 채팅 세션 수)계산식: (일정 기간 내 생성된 신규 채팅 세션 수 / 일정 기간 내 전체 프로필 조회 수) * 100활용: 프로필 열람에서 그치지 않고 실제로 채팅을 통한 매칭 시도가 있었는지 여부를 파악 지표 6. 깊이 있는 대화 세션 비율 (Deep Conversation Rate)(%)정의:실제 채팅을 통해 유의미한 결과로 이어지는 대화를 진행한 채팅방의 비율해당 프로덕트는 1:1 채팅만을 지원, 대화의 왕복이 약 5회 이상 진행되어야 의미 있는 대화라고 간주채팅방의 전체 누적이 아닌 일정 기간 내로 한정하여 설정계산식: 일정 기간 내 (채팅의 왕복이 5회 이상인 채팅방의 수 / 전체 신규 채팅방의 수) * 100활용: 채팅을 통해 실제 유의미한 단계까지 도달하는지 여부를 파악 지표 7. 외부 툴 정보 교환 채팅방 비율(%)정의:해당 서비스의 채팅 메세지에서 슬랙/디스코드/카카오톡 등 외부 툴로 이동하기 위한 링크/아이디 공유한 건수본격적인 프로젝트를 진행하기로 결정하면 자사의 서비스가 아닌 대중적인 툴로 이동할 경향성이 높다고 가정계산식: (외부 툴 정보가 오간 채팅방 수 / 전체 깊이 있는 대화(Deep Conversation) 채팅방 수) * 100활용: 외부 툴 정보가 교환된 경우, 함께 프로젝트를 진행하고자 결정했다고 간주. 즉, 팀 결성 완료 단계라고 볼 수 있음.위의 지표들로 어떤 의사결정을 할 수 있을까?프로필 완성도, 유저 프로필 완성 비율 (지표1, 2)유저들이 가입 중 온보딩 과정을 충실히 수행하였는지 알 수 있음수치가 낮다면?온보딩 과정 자체에서 피로를 느낄 수 있음'완성 프로필'의 기준을 예상보다 높게 설정한 경우일 수 있음공개 프로필 비율수치가 높을수록 가입한 유저 중 프로필을 공개로 설정한 유저가 많다는 것을 의미기존의 팀 빌딩 방식이 불편하다는 나의 가정을 뒷받침 하는 근거가 될 수 있음사람들이 직접 팀을 찾는 수고를 덜고 싶다는 니즈가 있다고 판단할 수 있음수치가 낮다면?가정부터 오류가 있다고 판단하고 수정1인당 프로필 평균 조회 수서비스가 활발히 이용되고 있는지 판단할 수 있는 가장 객관적이고 간단한 지표수치가 낮다면?프로필을 하나하나 열람하는 과정에 피로감을 느낀다고 판단할 수 있음유저들이 직접 탐색을 하는 행위를 비효율적이라고 생각하였다고 판단할 수 있음신규 채팅 개시율유저들이 서비스의 핵심 가치를 체감하기 시작했음을 판단할 수 있는 지표수치가 낮다면?유저들이 자신이 원하는 팀원을 찾지 못했다고 판단할 수 있음깊이 있는 대화 세션 비율 (Deep Conversation Rate), 외부 툴 정보 교환 채팅방 비율서비스가 제공하고자 하는 본질을 모두 경험하였다고 판단할 수 있는 지표수치가 낮다면?대화 후 유저 간의 니즈가 맞지 않아서 성사되지 않았다고 판단할 수 있음외부 다른 툴로 이동해야 한다는 점에서 불편함을 느꼈다고 판단할 수 있음
기획 · PM· PO
2025. 03. 18.
0
워밍업 클럽 스터디 3기 (PM) 3주차 발자국
강의명: 시작하는 PM/PO들에게 알려주고 싶은, 프로덕트의 모든 것코치: 김민우링크: https://www.inflearn.com/course/%EC%8B%9C%EC%9E%91%ED%95%98%EB%8A%94-pmpo-%EB%AA%A8%EB%93%A0%EA%B2%83/dashboard3주차 강의 포인트 지표(Metric)란?우리 사업, 제품의 현황과 성과를 측정해서 정량화 한 것Acquisition, Activation, Engagement, Retention, Monetization 등의 지표를 상시로 모니터링 하면우리 제품의 현황이 어떠한지, 어떤 추이로 변화하고 있는지 알 수 있고,지표를 토대로 의사결정을 하고 과업을 수행할 수 있음.Proxy 지표가정이 많이 들어간, 간접적인 지표.즉, 어떠한 값을 측정하고 싶은데 해당 값이 정량적이지 않아 직접 측정이 어려울 때, 가정을 포함하여 설정한 대체 지표.Proxy 지표는 완벽하지 않을 수 있지만, 설정했다는 것 자체만으로 의미가 있음. 모든 프로덕트에 적용할 수 있는 대표적인 지표 5가지Acquisition질문 1. 우리는 충분히 많은 신규 유저/고객을 획득하고 있는가?질문 2. 신규 유저/고객을 비용 효율적으로 획득하고 있는가?CAC (고객 획득 비용)Customer Lifetime Value (고객 생애 가치)Payback Period (비용 회수 기간)Activation신규 획득한 사용자들이 프로덕트의 핵심 가치를 경험하는 습관을 형성하는 것Activation은 Retention에 영향을 주는 핵심 요소 중 하나임.Activation 3단계Step Moment사용자가 제품의 핵심 가치를 경험하기 위한 '준비'를 마친 순간Aha Moment사용자가 '처음으로' 제품의 핵심 가치를 경험한 순간Habit Moment사용자가 제품의 핵심 가치를 경험하는 '습관'을 형성한 순간Engagement사용자들이 프로덕트에 관심을 갖고, 이용하고, 관계를 맺는 것얼마나 많은 유저들이 이용하는가 (Breadth)제품을 얼마나 깊이 있게 이용하는가 (Depth)얼마나 자주 이용하는가 (Frequency)성공적으로 과업을 완수하는가 (Efficiency)Retention고객(사용자)들이 제품을 계속해서 이용하는 것Retention Rate특정 기간 동안 고객(사용자)들이 유지되는 비율리텐션율을 이야기할 때는 항상 기간과 분자, 분모를 정의해야 함.Retention 측정/관찰 방식Cohort Retention (코호트 리텐션)특정 cohort user들이 시간이 경과함에 따라 유지되는 비율Retention CurveDay N RetentionN일째 유지된 사용자의 비율Bracket(Bounded) Retention어떤 기간 내에 유지된 사용자 비율Unbounded(On and After) Retention Monetization대표적인 Monetization의 지표들매출기간별 매출 성장률Paying User 수인당 매출(객단가) 지표Net Revenue Retention Metric Hierarchy, Input/Output 지표Metric Hierarchy : 지표의 위계 구조하나의 output 지표에는 다양한 input 지표들이 작용한 결과.수식으로 명확하게 표현되지 않는 지표 간의 관계도 존재.이는 프로덕트에 대해 많은 고민과 리서치를 하고 여러 케이스에 대한 실험으로 알아내는 수 밖에 없음. Product Analytics의 주요 개념들데이터는 투자가 필요한 자원이다.어떤 데이터를 축적할 것인지, 어떤 형태로 어디에 데이터를 기록할 것인지 정의가 필요.Product Analytic의 주요 개념들Event-Based Analytics이벤트를 기반으로 하는 데이터 분석Event유저와 제품 사이에 일어나는 상호작용Event Property이벤트에 수반되는 상세 정보User Property유저에 대한 정보Date TypeClient-side/Server-side Tracking어디에서 데이터를 트래킹할 것인지에 대한 기준 Event Taxonomy Event Taxonomy 설계란?어떤 event, 어떤 property를 트래킹할 것인지 구체적으로 정의하는 작업 두 가지 접근 방식Top-Down 접근데이터를 활용하는 '목적'에서부터 정의하는 것Bottom-Up 접근'우리 제품의 주요 이벤트는 무엇인가?'에서 시작 Naming Convention다음 요소들을 고려해야 함.일관성이벤트 이름을 설정할 때 일관성을 지켜야 함명확성부여한 이름이 무엇을 뜻하는지 명확하게 설정해야 함이벤트를 얼마나 잘게 쪼갤 것인가?각 행동이 '구분되는 서로 다른 종류의 행동'인지, 아니면 '본질적으로 같은 행동'인지 판단해서 설정하기 Event Taxonomy 문서를 만들 시 꼭 포함시켜야 하는 정보Naming Convention이벤트 정보이번트 프로퍼티 정보유저 프로퍼티 정보3주차 회고 이번 주차 강의는 최근 데이터 분석을 공부하고자 마음을 먹은 나에게 많은 도움을 주는 강의였다. 데이터 분석을 공부하고 있지만 어떤 지표를 기준으로 데이터를 수집하여 분석을 해야 하는지 감이 잡히지 않는 상황에서 이번 내용들은 길잡이가 되어 주었다. 하지만 Proxy 지표와 같은 가정을 필요로 하는 데이터들을 다루는 것에 대해서는 여전히 걱정이 많다. 객관적이고 명확한 정보에서 편안함을 느끼는 나의 경우, 반대의 성향을 지닌 정보들에서는 불안함이 수반되는 것 같은 느낌을 받는다. PM에 대해 공부할수록 PM이라는 직무가 굉장히 추상적인 것 같다는 인상을 계속해서 받게 된다. 이걸 해결하기 위한 방법은 아무래도 경험뿐이라는 생각이 드는데, 이런 모호함을 떨쳐내는 것이 나의 숙제이지 않을까 싶다.
기획 · PM· PO
2025. 03. 17.
0
워밍업 클럽 스터디 3기(PM) - [미션 2] 고객 조사 설계하기
프로덕트 배경최근 IT 직무에 대한 인기가 점점 높아지고 있으며, 비전공자들 또한 IT 직무로 전환을 희망하는 경우가 증가하고 있음.이러한 비전공자들의 경우 IT 직무에 대한 경험을 쌓는 가장 좋은 방법은 사이드 프로젝트에 참여하여 개발 사이클을 경험해 보는 것임.현재 대다수의 팀 빌딩 방식은 다음과 같음.팀을 모집하고자 하는 주체가 모집글을 작성하고 다양한 플랫폼에 게시참여를 희망하는 불특정 다수는 모집글을 보고 지원지원자를 받고 선별하여 팀을 확정기존의 팀 빌딩 방식이 다소 불편하다고 생각하여 다른 방식을 도입하고자 하는 것이 목적.프로덕트 개요IT 직무 희망자 및 현업 종사자에게 자신의 경력과 보유 기술을 간편하게 보여줄 수 있는 플랫폼을 제공프로젝트 팀 빌더에게는 원하는 팀원을 직접 컨택할 수 있도록 하여, 맞춤형 팀 빌딩을 실현할 수 있는 가치를 제공고객 조사 계획1. 조사 주제기존 사이드 프로젝트 팀 빌딩 방식의 불편함이 실제로 존재하는가?불편함이 실제로 존재한다면 나의 가설과 일치하는가존재하지만 내가 생각한 것과는 다른 불편함인가2. 조사 대상자 선정IT 직군 취업 준비생IT 직군으로 전환을 희망하는 비전공자IT 직군과 관련된 전공을 수료 중인 대학생사이드 프로젝트 경험이 있는 사람3. 조사 방법1 대 1 심층 인터뷰정성 데이터 획득을 위한 수단구글 폼을 이용한 간단한 설문조사정량 데이터 획득을 위한 수단4. 인터뷰 질문 설계기존 방식의 이용 경험 파악그동안 사이드 프로젝트 팀원을 구하거나 합류하기 위해 어떤 과정을 거치셨나요?이 과정에서 어려움을 느꼈던 적이 있다면 구체적으로 어떤 부분이 가장 힘드셨나요?팀을 꾸릴 때 사람들이 지원을 해도 실제로 프로젝트로 연결이 잘 되지 않았던 이유가 있나요?이미 프로젝트가 구성된 팀에 합류해본 경험이 있으시다면, 지원 과정을 통해 느낀 불편함도 있나요?구체적인 불편함 & 이유 탐색불편함을 느꼈던 이유가 무엇이라고 생각하시나요?이런 불편함이나 문제 때문에 프로젝트 자체를 포기하거나, 사람을 구하는 걸 중단한 적도 있으신가요?불편함을 해소하기 위해 직접 시도했던 방법이나 우회로가 있으신가요?기존 방식에 대한 생각 & 대안지금 사용하시는 방식이 만족스럽지 않았다면, 가장 큰 이유는 무엇인가요?기존 방식이 불편함에도 불구하고 어쩔 수 없이 쓰게 되는 이유가 있다면 무엇일까요?인터뷰 질문지 설계인터뷰 목적기존 방식(모집글을 올리고 사람들이 지원하는 방식)의 실제 이용 경험을 듣고,그 과정에서 느낀 불편함, 어려움, 불만족을 구체적으로 파악하기 위함.인터뷰 질문 내용소개 및 아이스브레이킹자기소개 관련 질문(이름/나이/직업 등)사이드 프로젝트를 진행해본 경험이 있으신가요?팀 빌딩 시 주로 어떤 플랫폼이나 방법을 사용하셨나요?기존 방식 이용 경험 파악그동안 사이드 프로젝트 팀원을 구하거나 합류하기 위해 어떤 과정을 거치셨나요?이 과정에서 어려움을 느꼈던 적이 있다면 구체적으로 어떤 부분이 가장 힘드셨나요?팀을 꾸릴 때 사람들이 지원을 해도 실제로 프로젝트로 연결이 잘 되지 않았던 이유가 있나요?이미 프로젝트가 구성된 팀에 합류해본 경험이 있으시다면, 지원 과정을 통해 느낀 불편함도 있나요?구체적인 불편함 & 이유 탐색불편함을 느꼈던 이유가 무엇이라고 생각하시나요?이런 불편함이나 문제 때문에 프로젝트 자체를 포기하거나, 사람을 구하는 걸 중단한 적도 있으신가요?불편함을 해소하기 위해 직접 시도했던 방법이나 우회로가 있으신가요?기존 방식에 대한 생각 & 대안지금 사용하시는 방식이 만족스럽지 않았다면, 가장 큰 이유는 무엇인가요?기존 방식이 불편함에도 불구하고 어쩔 수 없이 쓰게 되는 이유가 있다면 무엇일까요?마무리또다른 경험 or 불편함에 대한 질문기타 개선 희망 사항에 대한 질문감사 인사
기획 · PM· PO
2025. 03. 16.
0
워밍업 클럽 스터디 3기 (PM) 2주차 발자국
강의명: 시작하는 PM/PO들에게 알려주고 싶은, 프로덕트의 모든 것코치: 김민우링크: https://www.inflearn.com/course/%EC%8B%9C%EC%9E%91%ED%95%98%EB%8A%94-pmpo-%EB%AA%A8%EB%93%A0%EA%B2%83/dashboard2주차 강의 포인트PM에게 있어 가장 중요한 부분은 "고객에 대한 전문가가 되는 것"따라서 PM은 중간에 누군가를 끼지 않고, 직접 고객을 만나서 이야기를 나누고 관찰해야 함. 고객을 직접 만나면 얻을 수 있는 것들고객의 경험, 생각, 감정을 생생하게 이해우리가 고객을 얼마나 몰랐는지 알 수 있음고객에 대한 더욱 정확한 Mental Model다양한 아이디어재미와 보람PM에 대한 전문성PM이 알아야 하는 고객 정성 조사 방법 2가지일대일 심층 인터뷰사용성 테스트PM이 고객 리서치를 하는 명확한 목적 설정 필요. 그래야 더 나은 의사결정으로 이어질 수 있음. 일대일 심층 인터뷰를 통해 고객의 동기, 경험 등 다양한 정성적인 정보들을 수집할 수 있음.사업적인 질문에서 리서치 질문으로, 다시 인터뷰 질문으로 단계를 거쳐 가며 질문을 구체화 해야 고객 인터뷰를 통해 양질의 정보를 얻을 수 있음. 사용성 테스트는 다음과 같은 정보들을 얻기 위함임.유저가 우리 제품을 사용할 수 있는가유저가 우리 제품을 이해할 수 있는가유저가 우리 제품의 기능을 발견할 수 있는가 PM에게 있어서 데이터 활용 능력은 중요하다.데이터를 통해 사용자들의 패턴을 알 수 있고, 이를 통해 그 다음을 예측할 수 있다.데이터를 잘 활용하는 PM이 되기 위해서는 다음 2가지 역량이 필요하다.데이터 축적 관련 역량데이터 활용 역량PM은 특정한 의도(어떤 데이터를 축적할 것인지, 어떤 형태/이름으로 축적할 것인지)를 가지고 데이터를 축적해야 함.지표 이해, 데이터 분석, 툴 사용 등의 역량을 길러야 함.2주차 회고2주차 강의는 내가 해야 할 것을 조금 더 명확하게 알도록 해줬고, 또한 나의 이전 과업에 대해 돌아보도록 해주었다.일을 하면서 우리 회사가 타겟으로 생각하는 고객들을 대상으로 수차례 인터뷰를 진행한 적이 있었다. 당시에 몸으로 직접 부딪혀 가며 인터뷰 스킬을 늘릴 수 있었지만, 스스로 인터뷰의 목적에 대해 뚜렷하지 못한 상태였던 것 같다. 우리가 알고자 하는 것이 무엇인지, 그것을 알기 위해서는 어떤 질문을 했어야 좋았는지 조금 더 치밀하게 준비했다면 더 좋았을 것 같다는 생각이 들었다.최근 PM 직무에 대한 공부를 시작하면서 데이터 분석에도 관심을 가지게 되었는데, 마침 데이터 분석 측면에서 PM이 가져야 하는 역량에 대한 강의를 듣게 되어 어떤 부분을 더 공부하면 좋을지 알게 되었다. 현재는 파이썬 언어를 기반으로 한 데이터 분석을 공부 중이지만 해당 학습을 마치고 나면 데이터 분석 툴, SQL 등 추가적인 공부를 해봐야겠다.
기획 · PM· PO