1️⃣ 문제 정의를 기능이 아닌 ‘목표·철학’에서 시작
단순 기능 개선이 아닌, 서비스/경쟁사 간 철학적 차이를 기반으로 문제를 재정의
개선안 → 지표 → 실험 설계로 이어지는 일관된 사고 흐름
서비스 선정, 페르소나 도출 과정에서도 “왜 이 대상을 선택/제외했는지”를 논리와 근거로 설명
실무: 회사 히스토리·기존 기획 맥락을 고려해 문제를 재해석하려는 적극성이 두드러짐
→ “무엇을 만들까”보다 “왜 이 문제를 풀어야 하나”를 먼저 정의하는 PM 사고방식
2️⃣ 데이터 기반 가설 설정 및 검증 시도
감이 아닌 데이터·지표를 근거로 한 가설 수립
A/B 테스트 설계 시 기대효과뿐 아니라 가드레일 지표(리스크 관리 지표)까지 고려
‘스크롤 스톱 지점’ 등 구체적인 사용자 행동 데이터를 모니터링 지표로 활용
쇼핑/커머스 도메인 특성에 대한 이해를 바탕으로 우선순위 판단 시도
→ 입문 단계에서 현업 PM의 실험·검증 사고를 적극적으로 적용
3️⃣ 구조화된 커뮤니케이션과 문서화 역량
페르소나 비교, 우선순위 판단, 실험 가능성 분석을 표와 구조로 정리
와이어프레임을 활용해 기획 의도를 팀이 실행 가능한 형태로 시각화
CS·개발 협업을 고려한 에러 코드 설계 등 실행 이후를 고려한 설계 관점
→ 개인 사고를 ‘설득 가능한 문서’로 전환하려는 방향성은 매우 적절
4️⃣ 피드백 수용 및 재질문 루프
피드백 수용 → 본인 관점으로 재정리 → 추가 질문으로 확장
단순 반영이 아닌 이해 여부를 확인하려는 학습 태도
→ 성장 속도를 빠르게 만드는 좋은 학습 습관
1️⃣ 문서 목적 대비 설명 밀도 부족
현재: 많은 고민과 논리가 문서에서는 축약되어 드러남
문제: 작성자 본인은 이해하지만, 읽는 사람은 중간 맥락을 추론해야 하는 구조
원인: 기록용 문서처럼 핵심만 남기고 연결 설명을 생략
실무 관점: 기획 문서는 ‘나의 생각 정리’가 아니라 타인을 설득하기 위한 도구
2️⃣ 근거 자료와 해석 간 거리감
현재: 기사/외부 자료를 근거로 사용하되, 해석이 다소 도약되는 구간 존재
문제: 근거의 타당성이 약해지면 문서 전체 신뢰도 하락
사례: ‘빅세일 = 라이트 유저 확보’, ‘앱 설치 이벤트 = 외부 검색 유입’ 등
고려: 자료가 직접적으로 말하지 않는 부분은 가설로 명확히 구분 필요
3️⃣ 지표·용어 정의의 불명확성
현재: 전환율, 전환율 격차, 칼럼 충분성 등 용어가 암묵적으로 사용됨
문제: 실무 문서에서는 독자가 “이 지표가 정확히 무엇을 의미하지?”라는 의문을 가질 수 있음
사례: 장바구니 전환율 vs 전체 전환율, 시간형 데이터의 타입 오류(pdp_duration_sec)
4️⃣ 가설 논리의 일부 취약 지점
현재: 직관적으로 그럴듯하지만 데이터·도메인 관점에서 위험한 가설 존재
사례
“Returning 유저는 리뷰가 없어도 된다”
“정보 과다 → 피로도 → 이탈” 가설 vs 실제 체류시간 데이터
문제: 커머스에서는 사용자 친숙도보다 상품 관여도·적합성이 더 큰 변수일 수 있음
5️⃣ 실험 설계의 정밀도 부족
현재: 하나의 A/B 테스트에서 여러 변수를 동시에 변경
문제: 결과 해석 시 원인 분리가 불가능
추가: 실행 순서, 실험 단위, 리소스 제약에 대한 고려 부족
1. ‘설득용 문서’ 기준으로 설명 밀도 조정
모든 핵심 판단에 대해
왜 → 무엇을 봤고 → 그래서 어떤 결론에 도달했는지를 문장으로 연결
표/요약 뒤에 1~2줄의 해석 문장을 반드시 추가
2. 지표·용어 정의를 문서 초반 또는 각 섹션에 명시
전환율, 격차, 점수 기준, 컬럼 선택 이유를 명확히 정의
데이터 타입(시간/비율/Boolean) 검증 습관화
3. 근거 자료와 가설을 명확히 분리
“자료가 말하는 사실” vs “이를 바탕으로 한 나의 가설”을 구분 표기
해석이 도약되는 경우, 가정 조건을 명시
4. A/B 테스트 설계 원칙 준수
하나의 실험 = 하나의 변수
우선순위가 높은 가설부터 단계적 실험 로드맵으로 제시