22일차[서비스 기획 숙련 챕터 2,3]

1. 오늘 달성한 목표

• 서비스 기획 숙련 강의 챕터 2,3 수강
• A/B 테스트 특강 듣기

 

2. 오늘 배운 내용 정리 | PM은 결국 “문서를 통해 팀을 움직이는 사람”이다

오늘은 PM이 프로젝트를 시작하고, 진행하고, 마무리한 뒤 실제 개발 문서까지 연결하는 실무 프로세스 전반을 학습했다.
단순히 기능 아이디어를 내는 역할이 아니라, 목표를 정렬하고 협업 구조를 만들며 실행 가능한 문서로 구체화하는 과정 전체가 PM의 일이라는 점을 더 명확히 이해한 하루였다.

---

2-1. 프로젝트의 시작: 킥오프는 방향을 맞추는 시간

프로젝트의 첫 단계인 킥오프는 팀이 같은 목표를 바라보도록 만드는 출발점이다.

오늘 가장 중요하게 느낀 부분은 킥오프에서 아래 요소들이 반드시 정리되어야 한다는 점이었다.

• 프로젝트 목표
• 범위 (무엇을 하고, 하지 않을지)
• 일정과 마일스톤
• 팀 역할과 책임
• 커뮤니케이션 방식
• 리스크
• 이해관계자 기대사항

특히 PM 입장에서는 범위를 초기에 명확히 잘라 두는 것이 이후 일정 지연과 스코프 확장을 막는 핵심이라는 점이 인상 깊었다.

---

2-2. 진행 단계: 공유는 협업의 속도를 만든다.

프로젝트 진행 중 공유는 단순 전달이 아니라,
**“필요한 정보를 필요한 사람에게 정확히 전달하는 일”**이라는 정의가 실무적으로 와 닿았다.

좋은 공유는 다음 효과를 만든다.

• 리스크 조기 발견
• 빠른 의사결정
• 팀 간 기대 일치
• 문서화와 히스토리 관리

결국 PM의 공유 능력은 팀의 실행 속도를 결정한다는 걸 배웠다.
특히 슬랙, 이메일, Jira처럼 채널별 목적을 나눠 운영하는 방식이 중요하다는 점이 실무적 포인트였다.

---

2-3. 마무리 단계: 회고는 다음 성공 확률을 높인다.

회고는 결과 평가가 아니라 팀의 프로세스를 개선하는 학습 시스템이라는 관점이 새로웠다.

오늘 배운 회고 구조는 아래 순서로 정리된다.

1. 무엇이 잘 되었는지
2. 어떤 문제가 있었는지
3. 왜 그런 일이 발생했는지
4. 다음에는 무엇을 바꿀지 액션 아이템 도출

특히 중요한 건 원인 분석에서 끝내지 않고 실행 가능한 액션 아이템으로 연결하는 것이었다.
이 부분은 PM의 개선 사이클과도 바로 연결된다고 느꼈다.

---

2-4. 실무 문서화: PRD부터 IA, 정책서, 에러케이스까지

오늘은 PM 문서의 핵심 구조도 함께 배웠다.

PRD (요구사항 정의서)

개발팀이 무엇을 만들어야 하는지 명확히 정의하는 문서다.

핵심 항목:

• 기능명
• 기능 설명
• 우선순위
• 구현 기준
• MVP 릴리즈 계획

여기서 느낀 핵심은 좋은 PRD는 기능 설명이 아니라 의사결정 기준을 남기는 문서라는 점이었다.

IA (정보 구조도)

사용자가 원하는 정보를 빠르게 찾을 수 있도록
서비스 구조를 설계하는 작업이다.

카테고리 구조, 메뉴 계층, 정보 흐름을 미리 설계하면
UX와 협업 효율이 동시에 좋아진다는 점을 배웠다.

서비스 정책서

기능의 운영 기준과 예외 규칙을 정의하는 문서다.

예:

• 비밀번호 변경 주기
• 로그인 방식
• 개인정보 처리 기준
• 결제 운영 정책

에러 케이스 정의

정상 흐름만 보는 게 아니라 실패 시나리오까지 설계하는 게 PM의 역할이라는 걸 다시 느꼈다.

---

2-5. 상세 기획: 결국 실행 가능한 수준까지 쪼개는 힘

마지막으로 스토리보드와 상세 기능 명세를 통해
기획을 실제 구현 가능한 수준까지 구체화하는 방법을 학습했다.

여기서 핵심은

• 유저 플로우 설계
• 입력값/출력값 정의
• UI 요소 명시
• 분기점과 예외 처리
  까지 포함해 디자인/개발이 바로 움직일 수 있는 수준으로 문서화하는 것이었다.

3. 특강 내용 | PM은 감이 아니라 실험으로 의사결정한다.

오늘은 PM 실무에서 핵심적인 역량 중 하나인 A/B 테스트 설계와 결과 해석 방법을 깊이 있게 학습했다.
그동안 A/B 테스트를 단순히 “A안이 좋을지 B안이 좋을지 비교하는 방법” 정도로 이해하고 있었는데, 오늘 강의를 통해 문제 정의 → 가설 수립 → 지표 설계 → 통계적 검증 → 배포 의사결정까지 이어지는 하나의 프로덕트 실험 프레임워크라는 점을 명확히 이해하게 되었다다.

---

3-1. A/B 테스트는 더 나은 선택을 위한 데이터 실험

A/B 테스트는 기존안과 신규안을 서로 다른 사용자 그룹에 노출해
어떤 안이 목표 지표를 더 잘 개선하는지 검증하는 대조 실험 방식이다.

예를 들어,

• 구매 버튼 위치
• 추천 알고리즘
• 푸시 문구
• 할인 쿠폰 대상
  같은 요소를 바꿨을 때 실제 사용자 행동이 어떻게 달라지는지를 확인할 수 있다.

오늘 가장 크게 느낀 건,
PM의 의사결정은 직감보다 “실험 가능한 질문을 만드는 능력”에서 시작된다는 점이었다.

---

3-2. 좋은 실험은 문제 정의에서 시작된다

강의에서 특히 중요했던 부분은 실험 전에 문제를 문장으로 정의하는 과정이었다.

예:

예약 버튼 클릭률이 목표 대비 n% 미달이다다

이렇게 문제를 수치로 정의해야

• 무엇을 바꿀지
• 어떤 가설을 세울지
• 어떤 지표를 볼지
  가 명확해진다.

PM 입장에서는 이 단계가 결국
**“무엇이 문제인지 팀이 같은 언어로 이해하게 만드는 과정”**이라고 느꼈다.

---

3-3. 핵심은 가설을 문장형으로 만드는 힘

오늘 배운 가장 실무적인 포인트는
가설을 명확한 문장으로 만드는 방식이었다.

예:

예약 버튼을 가격 정보 위에 위치시키면 클릭률이 증가할 것이다다

좋은 가설은

• 변경 대상 1개
• 기대 행동 1개
• 측정 지표 1개
  로 명확해야 한다.

특히 한 번의 테스트에서는 하나의 변수만 변경해야 한다는 원칙이 실무적으로 정말 중요하게 느껴졌다.
그래야 결과 원인을 정확히 해석할 수 있기 때문이다.

---

3-4. PM이 꼭 알아야 하는 3가지 지표 구조

오늘 강의에서 가장 PM 실무에 바로 연결된 부분은
성공지표 / 보조지표 / 가드레일 지표 설계였다.

성공지표

실험 성공 여부를 판단하는 핵심 지표
예: 구매 전환율, 예약 클릭률

보조지표

결과를 더 깊이 이해하는 보조 맥락
예: 장바구니 담기율, 페이지 체류시간

가드레일 지표

원하지 않는 부작용 감시
예: 이탈률, 환불률, 오류율

이 구조를 보면서
PM은 단순히 “올랐냐”만 보는 사람이 아니라,
성장과 리스크를 동시에 관리하는 사람이라는 점을 다시 느꼈다.

---

3-5. 통계적으로 유의미해야 진짜 결과다.

오늘 특히 이해가 잘 된 부분은 p-value 해석 방식이었다.

핵심은 아래 한 줄로 정리된다.

• p-value < 0.05 → 통계적으로 유의미
• p-value > 0.05 → 우연일 가능성이 큼

즉 숫자가 올랐더라도
그 변화가 우연인지 실제 효과인지 검증해야만 배포 결정을 할 수 있다.

이 부분은 앞으로 PM 과제에서 실험 결과를 설명할 때
훨씬 설득력 있게 활용할 수 있을 것 같다.

---

3-6. 실험 결과 해석에서 조심해야 할 함정

강의 후반부에서 좋았던 건 단순 성공 사례보다
잘못된 해석을 막는 방법을 알려준 부분이었다.

특히 기억에 남은 개념:

• 초두효과 → 기존안 익숙함 때문에 초반 A안 우세
• 신기효과 → 새로워 보여서 초반 B안 과대평가
• 세그먼트 분석 → 특정 연령/디바이스에서만 효과 발생

이걸 통해 PM은 평균값만 보는 게 아니라
누구에게 효과가 있었는지까지 세분화해서 보는 시야가 필요하다는 걸 배웠다.