PM의 핵심 역할은 "무엇을 만들고, 왜 만드는가"를 결정하는 일이다. 하지만 '무엇을'과 '왜'를 결정할 때, 단순한 감이나 개인적 경험에 의존한다면 의사결정은 쉽게 왜곡된다.
"사용자는 늘 변하고, 시장은 복잡하며, 팀 내 의견도 제각각이다."
많은 사람들로 구성된 한 팀에서 의견을 좁히는 것이란 쉽지 않다.
그렇기 때문에 PM에게 데이터란 나침반이자 언어이다.
데이터는 제품의 현 상태를 객관적으로 보여주고, 논의를 감정이 아닌 사실(fact) 중심으로 이끌어준다.
PM은 늘 불확실한 선택의 연속 속에 있다. "이 기능을 출시해야 할까?", "이 온보딩 플로우가 더 나을까?"와 같은 고민의 연속이다.
이때 데이터 기반 접근은 가설-실험-검증의 사이클을 가능하게 한다. A/B 테스트나 코호트 분석 같은 방법을 통해, 감이 아닌 판단을 검증 가능한 실험으로 바꿀 수 있게 해준다.
🔹데이터 기반 의사결정의 개요
🔻데이터, 지표, 가설의 관계
PM이 데이터를 바라보는 기본 프레임은 세 가지 축으로 나뉜다.
데이터(Data), 지표(Metric), 그리고 가설(Hypothesis)
이 세 가지는 분리된 개념이 아니라 하나의 순환 구조를 이룬다.
✔️ 데이터 (Data)
- 제품 안에서 발생하는 모든 행동과 사건의 기록이다.
예) 신규 가입자 수, 버튼 클릭 횟수, 세션 유지시간, 전환율, 피드백 응답 등- 데이터를 수집하는 목적은 "사실(fact)"을 확보하기 위함이다. 감이나 경험은 주관적이지만, 데이터는 객관적 근거를 제공한다.
✔️ 지표 (Metric)
- 수많은 데이터 중 의미 있는 패턴을 정리한 숫자다.
예) '가입자 수'는 단순 데이터지만, '신규 가입 전환율(가입자 수 % 방문자 수)'는 지표이다.- 지표는 단순한 숫자가 아니라 의사결정을 이끈다.
✔️ 가설 (Hypothesis)
- 데이터를 해석하고 실행으로 옮기기 위한 "검증 가능한 주장"이다.
예) "온보딩 과정을 단순화하면 신규 사용자 7일차 리텐션이 높아질 것이다."- 가설이 있어야 데이터를 통해 무엇을 알고자 하는지 명확해진다.
이 세 요소는 순환한다. 데이터를 기반으로 현재 상태를 파악하고, 지표로 성과를 정의하며, 가설로 변화를 제안한다.
🔻Metric vs KPI vs OKR의 차이와 의미
PM이 데이터를 다루기 위해 Metric, KPI, OKR의 개념에 대해 확실히 알아야 한다. 모두 수치를 다루지만 역할이 다르다.
✔️ Metric (일반 지표)
- 단순히 활동이나 결과를 측정하는 모든 수치형 데이터다.
예) 일일 방문자 수(DAU), 클릭 수, 페이지 체류시간 등- Metric은 제품의 다양한 면을 관찰할 수 있게 하지만,
전략적 방향성을 직접적으로 보여주진 않는다. 따라서 PM은 수많은 Metric 중에서 진짜 의미 있는 지표를 선별해야 한다.
✔️ KPI (핵심 성과 지표)
- Key Performance Indicator의 약자이며, 조직 또는 제품의 목표 달성 정도를 평가하는 핵심 지표다.
예) 구독 서비스 → “월간 유료 전환율” / 커머스 → “재구매율” / B2B SaaS → “활성 계정당 주간 사용시간”- 좋은 KPI는 성과를 직접적으로 설명하며, 팀 전체가 같은 목표를 바라보게 한다. 따라서 KPI는 전략적으로 가장 중요한 지표이다.
✔️ OKR (목표와 핵심 결과)
- Objective & Key Results의 약자이며, 조직이 달성하고자 하는 목표(Objective)와 그 목표를 수치로 검증할 핵심 결과(Key Results)의 조합이다.
- OKR은 KPI보다 더 도전적이고, 변화 지향적인 프레임워크다.
예)
Objective: 신규 사용자 경험 개선으로 리텐션 강화
Key Results:
신규 사용자 7일차 리텐션 +10%p
온보딩 완료율 85% 달성
피드백 만족도 4.5점 이상 유지- OKR은 단기적 지표 관리가 아니라, 제품 성장의 방향성을 제시한다.
좋은 PM이 되기 위해서는 이 세 단계를 유기적으로 연결해 생각해야 한다. Metric으로 제품의 현재 상태를 진단하고, 그중 KPI를 통해 핵심 성과를 관리하며, OKR을 통해 더 큰 목표와 변화의 방향을 설계해야 한다.
🔹제품 지표 설계 방법
PM에게 올바른 지표를 세우는 일 역시도 요구되는 역량 중 하나이다. 좋은 지표 설계는 '우리가 어떤 가치를 만들어내고 있는가'를 정량적으로 보여준다.
해당 부분에서는 PM이 지표를 설계할 때 반드시 알아야 하는 네 가지 핵심 단계에 대해 알아보도록 하자.
🔻북극성 지표(NSM) 설계
북극성 지표(North Star Metric)는 제품의 핵심 가치를 한 문장(혹은 한 숫자)으로 표현하는 지표이다.
"이 숫자가 오르면, 우리 제품이 성장하고 있다고 말할 수 있는가?"
이와 같은 질문에 답할 수 있어야 한다. 이해하기 쉽게 다른 예시를 들어보자.
- 에어비앤비 - 1분기 안에 예약한 숙박의 개수
- 페이스북 - 10일 안에 7명과 친구를 맺는 사용자의 수
- 넷플릭스 - 유료 사용자가 콘텐츠를 스트리밍 하는 총 시간
- 스포티파이 - 음악을 스트리밍 하는 총 시간
예시와 같이 '고객이 우리 제품을 통해 얻게 되는 핵심가치'를 정확하게 측정하는 지표를 말한다.
⚒️ 북극성 지표의 조건
- 고객 가치(Customer Value)를 직접적으로 반영해야 한다.
→ 사용자가 제품을 통해 얻는 이익 또는 만족을 나타내는가?- 비지니스 성과(Business Growth)와 연결되어야 한다.
→ 지표가 상승할 때 매출, 리텐션, 시장 점유율 등 실질적 성장이 일어나는가?- 팀 정렬(Alignment)이 가능해야 한다.
→ 모든 부서가 같은 방향으로 의사결정을 내릴 수 있는 공통 언어인가?
⚙️ 설계 팁
- “매출”이나 “방문자 수”처럼 결과만 나타내는 래깅 (Lagging) 지표보다는, 사용자 경험에 선행하는 리딩(Leading) 지표를 선택하는 것이 좋다.
- 하나의 완벽한 지표를 찾으려 하지 말고, 팀이 의사결정을 내릴 수 있는 핵심 방향 신호에 집중하는 것이 좋다.
🔻KPI 설정 원칙
북극성 지표가 “방향”을 제시한다면, KPI(Key Performance Indicator)는 그 방향으로 나아가고 있는지를 측정하는 “속도계”다.
⚒️ KPI의 5가지 설계 원칙 - SMART
- S(Specific): 구체적이고 명확해야 한다.
ex) “리텐션 향상” → “신규 사용자 7일차 리텐션 +5%p”
* M(Measurable): 측정 가능한 수치여야 한다.
ex) KPI 수집 방식: SQL / GA 이벤트 / 로그 기반- A(Achievable): 현실적으로 달성 가능한 목표
ex) 과거 성장률·자원 대비 설정- R(Relevant): 제품의 핵심 가치와 직접 연관
ex) 단순 클릭수 ↑보다는 전환율 ↑- T(Time-bound): 기간이 명확해야 한다.
ex) “분기 내 +5%p 개선”
좋은 KPI는 팀이 주간·월간 단위로 진척도를 추적할 수 있게 하고, 성과를 객관적으로 평가할 수 있는 기준을 제공한다.
🔻지표 계층 설계
모든 지표는 동일한 수준의 중요도를 가지지 않기 때문에, PM은 목표를 달성하기 위해 지표 간의 계층(hierarchy) 을 설계해야 한다.
⚒️ 지표의 세 단계 구조
✔️ 상위 지표 (Top-level KPI): 제품이나 비즈니스의 최종 성과를 나타내는 지표
ex) 월간 활성 사용자 수(MAU), 전환율, 구독 유지율
✔️ 중간 지표 (Intermediate KPI): 상위 KPI에 영향을 미치는 중간 단계의 행동 지표
ex) 온보딩 완료율, 첫 구매율, 재방문률
✔️ 실행 지표 (Execution Metric): 실제 실행 단계에서 관리되는 구체적 지표
ex) 알림 클릭률, 추천 상품 노출수, CTA 버튼 클릭률
예시를 들어보자.
커머스 서비스에는 다음과 같은 지표 계층 설계를 수행할 수 있다.
- 상위 KPI: 재구매율 ↑
- 중간 지표: 장바구니 상품 유지율, 추천상품 클릭률
- 실행 지표: 추천 알고리즘 노출 정확도, 푸시 알림 클릭률
이처럼, 실행(하위) 지표가 중간 지표를 견인하고, 중간 지표가 상위 KPI를 견인하며, 결국 전체가 북극성 지표(NSM)로 수렴되는 구조를 만드는 것이 핵심이다. 단, 계층 구조는 고정된 것이 아니기 때문에 제품 단계에 따라 주기적으로 업데이트 되어야 한다.
🔹분석/실험 설계와 실행
문제를 정의하고 데이터를 수집했다면, PM은 가설을 검증하고 의사결정으로 연결하는 단계로 넘어간다.
여기서 핵심은 "분석을 통해 학습하고, 학습을 통해 개선한다"는 루프를 만드는 것이 중요하다.
분석 설계
- 분석 목적 명확화: "지표의 추세를 보기 위함인가?", "원인을 규명하기 위함인가?"
- 세그먼트 기준: 신규 vs 기존, 지역별, 디바이스별 등으로 나누어 비교
- 분석 기법 예시
- 코호트 분석(Cohort Analysis): 가입 시점별 리텐션 비교
- 퍼널 분석(Funnel Analysis): 전환 과정 단계별 이탈률 파악
- 상관,인과 분석(Correlation vs Causation): 단순 패턴이 아닌 원인 탐색
-
코호트 분석
코호트 분석은 사용자를 특정 시점이나 속성(코호트)으로 나누어, 시간이 지나면서 그들의 행동 패턴이 어떻게 변화하는지를 추적하는 방법이다. 즉, "언제 들어온 사용자가, 얼마나 오래 남아 있는가?"를 보는 분석이다.
코호트 분석은 '평균 리텐션'보다 훨씬 더 유용하다. 같은 시기에 유입된 사용자 집단은 비슷한 맥락을 공유하기 때문에 코호트 분석을 이용하면 제품의 변화 효과나 정책의 영향을 정밀하게 분리할 수 있다.
-
퍼널 분석
퍼널 분석은 사용자의 전환 여정(conversion path)을 단계별로 분해해, 각 단계에서 얼마나 많은 사용자가 이탈하는지를 시각적으로 파악하는 방법이다.
즉, "고객이 목표 행동(구매, 가입 등)에 도달하기까지 어디에서 떨어지는가?"를 보는 것이다.
이는 여정의 병목지점을 찾아내 전환율을 최적화 하는 데 핵심적인 역할을 한다. -
상관/인과 분석
상관관계(Correlation)는 두 변수 간의 동시 움직임을 의미한다.
인과관계(Causation)는 한 변수가 다른 변수를 직접적으로 변화시킨다는 의미다.
이 세 가지 분석을 종합적으로 사용하면, PM은 "무슨 일이 일어났는가(코호트)", "어디서 문제가 생겼는가(퍼널)", "왜 그런가(상관/인과)"를 단계적으로 이해할 수 있다.
🔹데이터 기반 의사결정
지금까지 살펴본 '데이터 → 지표 → 가설 → 분석/실험 설계'의 흐름은 PM이 데이터를 실제 의사 결정에 연결하기 위한 핵심 구조이다.
PM에게 데이터는 제품의 상태를 진단하는 근거이자, 의사결정의 언어이다. 데이터를 통해 문제를 관찰하고, 지표로 목표를 구체화하며, 가설을 세워 실험을 설계하고, 그 결과로 학습하는 일련의 과정을 통해 PM은 제품과 사용자에 대한 '사실 기반의 이해'를 확장시킨다.
👀 My thoughts
- PM이라는 직무에 관심을 가지게 되면서, PM에게 요구되는 역량 중 그나마 가장 많이 공부해왔던 부분이 어떻게 보면 데이터를 다루는 역량인 것 같다는 생각이 들었다.
제품의 상태를 분석하여 의사결정을 하는 것은 지금까지 내가 했던 분석과 비슷하지만, 그 데이터를 통해 모두가 공통의 이해를 갖도록 만드는 것이 중요하다는 것을 새롭게 알게 된 것 같다.- 또한 통계학과 수업을 들으며 가설을 세우고 검증하는 과정을 많이 배웠다. 이 부분은 PM으로서 데이터를 근거로 판단하고 실험을 설계하는 역량으로 이어질 수 있다고 느꼈다. 또한, 해당 역량이 나의 가장 큰 강점이 될 수 있겠다는 생각이 들었고 더 노력해야겠다는 생각이 들었다.
