💎 Keep | 계속 유지할 강점
1️⃣ 문제 정의를 기능이 아닌 '목표·철학'에서 시작
- 단순 기능 개선이 아닌, 이버 vs 쿠팡의 철학적 차이 분석한 '리텐션' 재정의
- 개선안 → 지표 → 실험 설계로 이어지는 일관된 논리 구조
- 실무: 회사의 히스토리, 기존 기획안의 구조를 보았을 때 적극성이 두드러짐
→ "무엇을 만들까"보다 "왜 만들어야 하나"부터 시작
2️⃣ 데이터 기반 가설 검증 역량
- A/B 테스트 설계 : 추측이 아닌 실험 구조로 가설 검증
- 도메인 특성 이해 : 쇼핑 앱에서 다크모드보다 '혜택 가시성'이 중요하다는 우선순위 판단
- 기대효과를 정량 지표로 명확히 정의해 검증 가능성 확보
→ 입문 단계에서 현업 PM의 사고방식 체득
3️⃣ 실행 관점의 커뮤니케이션 도구 활용
- 와이어프레임 시각화 : 기획 의도를 개발/디자인팀에 오차 없이 전달
- 질문 구체화 : 에러 코드 설계 → 실무 적용 기준까지 확장
→ "내 머릿속 아이디어"를 "팀이 실행 가능한 형태"로 전환
4️⃣ 피드백 수용 & 재질문 루프
- 튜터 답변 이해 → 내 관점으로 재정리 → 확인 질문
→ 단순 수용이 아닌 능동적 학습 자세
🛑 Problem | 개선 필요한 부분
1️⃣ 부작용 지표에 대한 고려 부족
- 현재: "사용률 20% 증가" 같은 긍정 지표만 설정
- 문제: 팝업 노출로 인한 결제 이탈률 등 부정적 영향 지표 부재
- 원인: 기대효과에만 집중, 리스크 판단 근거 미제공
- 고려: 실험을 쪼개 둔 것이 롤백 리스크 최소화였는데 실패 기준이 부재
- 실무: 보통 개발, 인건비 기준 매출이 넘지 않았을 때가 실패 (예:영화)
2️⃣ 실행 순서에 대한 단계화 미흡
- 현재: 혜택 알림 팝업 + 조건 맞춤 제안 나열
- 문제: "뭐부터 작업하죠?" 질문에 답 없음
- 원인: 우선순위/단계 구분 없이 아이디어만 제시
- 고려: 실험 동시 진행의 실무적 한계 인식 (리소스·통계적 유의성 제약)
3️⃣ 에러 코드 설계에서 노출 대상 기준 불명확
- 현재: CS·개발 커뮤니케이션 효율 중심 설계
- 문제: 사용자 노출 여부 판단 기준이 초기에 명시 안 됨
- 원인: 도메인 특성(B2B 교육)을 서론에 배치하지 않음
- 고려: 백엔드 서버에서 충분히 빠르게 파악이 되는 문제=UX 부정적 경험 초래
🚀 Try | 다음 실행 항목
⚡ 즉시 적용
1. 기대효과 지표와 부작용 지표를 세트로 설계
- 모든 주요 지표에 긍정/부정 지표 함께 정의
예: "팝업 노출 시 혜택 사용률 20% 증가 + 결제 이탈률 5% 이내 유지" - 기능 성공 여부뿐 아니라 부작용 발생 여부까지 동시 검증
2. 해결안 제시 시 실행 로드맵 함께 제시
- 단계별 실행 구조로 정리
- 1단계(MVP): 혜택 알림 팝업
- 2단계(고도화): 조건 맞춤 제안
- 실무 관점에서 바로 판단 가능한 형태로 문서화
- 각 협업자가 가장 먼저 해야할 것을 문서에 명확히 제시해야 검토하는 편
- 병렬 실험 시 협업자, 조직의 특성을 고려하고 설득 근거를 제시할 것
3. 에러 코드 설계를 '역할 분리' 기준으로 접근
- 사용자 / CS / 내부 로그로 정보 노출 범위 분리
예: "사용자에겐 친화적 메시지, CS에겐 코드+상황, 로그엔 전체 스택" - 서비스 도메인·CS 역할·사용자 숙련도 기준으로 정책 결정
- 서버팀과 사전 합의를 기본 프로세스로 포함
4. 선택의 결과보다 '선택의 기준'을 문서에 남기기
- 도메인 특성을 서론에 먼저 명시
예: "B2B 교육 플랫폼 특성상 CS팀이 기술 문제 직접 해결 → 에러 코드 노출 필요" - 왜 이 선택이 해당 도메인에서 합리적인지 명시
- 이후 회고·협업·리뷰 시 판단 근거로 활용 가능하도록 정리
📈 중기 역량 개발
- 타 서비스 에러 처리 분석 3건
- B2C(쿠팡) vs B2B(Cafe24) 비교
- 노출 방식, CS 대응 구조 정리
- CS-개발 협업 구조 학습
- 티켓 시스템, 로그 추적 방식 공부
- 실무자 인터뷰 or 아티클 3개 읽기
🌱 장기 성장 방향
- 트레이드오프 판단 기준 정립
"사용자 친화성 vs 내부 효율" 같은 딜레마 상황별 의사결정 원칙 만들기 - 이해관계자별 체크리스트 템플릿
기획 문서 작성 시: 사용자/CS/개발/디자인 관점 필수 검토 항목 정리
PM 새내기 생활 중