• 서비스 기획 숙련 주차 퀴즈 ▼
• 오늘의 인사이트 + KPT 회고 ▼
데이터 기반 문제 정의 + 경쟁 서비스 분석
1. 데이터 기반 문제 정의
2. 문제 정의 단계에서 가장 먼저 해야 하는 것(우선순위)
3. 경쟁 서비스 분석 - 기능 분석
4. 경쟁 서비스 분석 - UX 분석
5. 경쟁 서비스 분석 - 포지셔닝 분석
활동 내역(6/7 휴일 작업 포함)
- 서비스 기획 숙련 강의 정리
- 아티클 보기(1~15화)
- 출처 : 기획하는 프로이직러의 취업과 이직
- 아티클 카타
- 정보처리기사 실기 공부(D+40)
오늘의 퀴즈 정리
-
데이터 기반 문제 정의 + 경쟁 서비스 분석
1. 데이터 기반 문제 정의
- 문제를 정의할 때는 단순히 '사용자가 많이 이탈하는 것 같다'처럼 감으로 이야기하면 안 된다(설득력 ↓).
- 문제가 실제로 존재하는지, 얼마나 심각한지, 어디에서 발생하는지를 데이터로 설명할 수 있어야 한다.
◾GOOD 문제 정의 예시
| 항목 | 내용 |
| 지표 | 신규 가입자 7일 내 이탈률 |
| 현재 수치 | 45% |
| 비교 기준 | 업계 평균 25% |
| 차이 | +20%p |
| → 문제를 수치화해야 개선 목표도 설정할 수 있다. | |
- GOOD 지표의 조건
- 구체적(Specific) / 측정 가능(Measurable) / 비교 가능(Benchmark)
ex. 사용자 이탈률 X, 신규 가입 후 7일 내 이탈률 O
→ 실제 개선 액션으로 이어질 수 있는 지표 설정
- 구체적(Specific) / 측정 가능(Measurable) / 비교 가능(Benchmark)
2. 문제 정의 단계에서 가장 먼저 해야 하는 것(우선순위)
- 전환율이 낮다고 가정했을 때, 많은 사람들이 '경쟁사 분석 / 사용자 인터뷰 / 해결책 탐색'부터 떠올린다.
but, 먼저 해야 하는 것은 문제가 어디서 발생하는지 파악하는 것이다.
ex 1. [퍼널 단계] 방문 → 회원가입 | [전환율] 70%
ex 2. [퍼널 단계] 회원가입 → 상품 조회 | [전환율] 80%
ex 3. [퍼널 단계] 상품 조회 → 구매 | [전환율] 25%
⤷ 이 경우 진짜 문제는 상품 조회 → 구매 구간일 가능성이 높다.
즉, 문제 위치 파악 → 원인 분석 → 해결책 검토 순서로 진행해야 한다.
3. 경쟁 서비스 분석 - 기능 분석
- 기능 분석은 '경쟁 서비스가 사용자에게 무엇을 제공하는가'를 확인하는 과정이다.
배달앱 ex. '실시간 배달 추적 / 배달 예상 시간 / AI 메뉴 추천' 등을 비교할 수 있다.
↔ '직원 수 / 조직 규모 / 인력 규모' 등은 기능 분석 대상이 아니다(내부 운영 영역).
◾주요 확인 항목
| 분석 항목 | 핵심 기능 | 기능 완성도 | 사용성 | 차별화 기능 |
| 예시 | 결제, 검색, 추천 | 구현 수준 | 사용하기 쉬운가 | 경쟁사만의 강점 |
4. 경쟁 서비스 분석 - UX 분석
- UX 분석은 '사용자가 서비스를 얼마나 쉽고 편하게 사용하는가'를 보는 과정이다.
◾ex. 배달앱을 분석한다면, 주요 확인 항목
| 확인 항목 | 화면 수 | 클릭 수 | 소요 시간 | 사용자 흐름 |
| 예시 | 주문 완료까지 몇 화면인가 |
몇 번 터치해야 하는가 | 주문 완료까지 몇 초 걸리는가 |
어디서 이탈하는가 |
| → UX 분석은 예쁜 디자인을 보는 것이 아니라, 사용자가 목표를 얼마나 쉽게 달성하는지 분석하는 것이다. | ||||
5. 경쟁 서비스 분석 - 포지셔닝 분석
- 포지셔닝은 '고객이 해당 서비스를 어떤 이미지로 기억하는가'를 의미한다.
| 서비스 | Apple | IKEA | Tesla | Airbnb |
| 포지셔닝 | 프리미엄 | 가성비 | 혁신 기술 | 현지 경험 |
| → 같은 기능을 제공하더라도 어떤 고객을 대상으로 하고, 어떤 가치를 강조하는지에 따라 시장 내 위치가 달라진다. 그래서 경쟁사 분석 시 단순히 기능만 보는 것이 아니라, '누구를 위해 만들어졌고, 어떤 가치로 선택받고 있는가'까지 함께 확인해야 한다. |
||||
오늘의 인사이트
예전에는 좋은 아이디어나 좋은 기능이 있으면 자연스럽게 그것부터 떠올렸던 것 같다.
일단 멋있으니까... 그쪽으로 사고가 흐르는 건 어쩔 수 없는 수순이라고 생각했다.
(사실 사이드 프로젝트도 처음 구상은 그렇게 시작했다
심지어 시작점이 지인의 불편함을 해소하기 위함이었음에도)
사용자 스토리 역시 기능 설명서가 아니라 사용자가 어떤 가치를 얻고 싶은지를 설명하는 문서였고,
데이터 기반 문제 정의 역시 '전환율이 낮다'는 결과보다 왜 그런 현상이 발생하는지를 먼저 찾는 과정이었다.
(결과는 누가 봐도 보인다
프로젝트가 실패했는데 실패한 줄 모르는 사람이 있다면 그게 직무태만인 것이다)
PM은 프로젝트의 성패와 관계없이, 그 결과를 데이터로 설명할 수 있어야 한다.
특히 사용자 스토리 아티클에서 기능 자체보다
사용자가 얻고자 하는 가치가 중요하다는 내용이 인상 깊었다.
이번 퀴즈 역시 전환율이 낮다는 결과만 보는 것이 아니라(추상적 해석 X),
어느 구간에서 왜 그런 현상이 발생하는지를 먼저 확인해야 한다는 점에서 같은 맥락이라고 느꼈다.
오늘을 마무리하는 한 마디
-
감으로 짐작하지 말고, 고개를 들어 데이터를 보라.
뇌피셜이라 말하는 상대가 있다면 통계로 압도시키면 될 일이다.
오늘의 KPT 회고
| Keep | • 기능이나 해결책보다 먼저 문제를 정의하려고 한 점 특히 전환율이 낮다는 결과보다 어느 구간에서 왜 그런 현상이 발생하는지 보려고 한 점 • 기능 자체보다 사용자가 얻고자 하는 가치와 실제 문제를 먼저 이해하려고 한 점 |
| Problem | • 아직은 데이터를 봐도 어떤 지표가 핵심 지표인지, 어떤 지표를 우선적으로 확인해야 하는지 판단하는 데 시간이 걸림(지표 개념 자체를 아직 다 소화하지 못한 듯) • 경쟁 서비스 분석 시 기능 비교는 상대적으로 쉬운데, 포지셔닝이나 사용자 가치 관점으로 해석하는 부분은 경험이 더 필요하다고 느낌(이 또한 반복 학습만이 답이라 생각) |
| Try | • 앞으로 서비스나 사이드 프로젝트를 볼 때도 '무엇을 만들까?'보다 '어떤 문제를 해결하려는가?'를 먼저 고민하기 • 결과만 보고 판단하지 말고, 그 결과가 발생한 원인을 데이터로 설명하는 연습하기 • 경쟁사 분석 시 기능·UX·포지셔닝을 분리해서 보고, 사용자가 실제로 얻는 가치까지 함께 정리해보기 |
'TIL' 카테고리의 다른 글
| 오늘의 퀴즈 정리) 우선순위 설정 프레임워크 + 역기획과 PM 채용의 이해 (0) | 2026.06.10 |
|---|---|
| 숙련 과제 Part 1. 누구를 분석할 것인가?(페르소나 후보 분석 및 선정) (0) | 2026.06.09 |
| 오늘의 퀴즈 정리) AARRR, North Star Metric, OKR, 가드레일 지표, 허무 지표 (0) | 2026.06.04 |
| 당일 학습 내용 정리+오늘의 인사이트/KPT 회고 (0) | 2026.06.02 |
| 학습 정리+오늘의 인사이트/KPT 회고+Q&A(PM의 SQL 접근 권한) (0) | 2026.06.01 |