PM과는 다른 하루 일과 PM이 개발자/디자이너와 일정을 맞추고
요구사항을 정리하는 역할이라면, PO는 고객/시장/이해관계자와의 접점을 바탕으로 제품 방향을 결정하는 역할입니다.
그럼 PO의 하루는 어떤 일로 구성될까요?

1. PO는 제품의 방향을 책임진다
PO는 ‘무엇을 만들지’를 결정하는 사람입니다. 이 결정은 단순히 내부 요청이나 운영 편의가 아니라,
시장 흐름과 사용자 문제 해결을 기반으로 내려야 하죠.
주요 업무 예시:
- 제품 로드맵 작성 및 주기적 리뷰
- 새로운 기능 제안 → 시장/고객 근거 수집
- 성과지표(KPI, 리텐션, 전환율 등) 모니터링
2. 고객/이해관계자 커뮤니케이션이 많다
PM은 팀 내부 커뮤니케이션에 집중한다면, PO는 외부와도 많은 접점을 가집니다.
PO가 자주 만나는 대상들:
- 경영진 (비즈니스 우선순위)
- 마케팅팀 (신규 기능/런칭 계획)
- 고객 (VOC 인터뷰, 설문 피드백)
→ 그래서 PO는 커뮤니케이션 능력 + 설득력이 매우 중요합니다.
3. 기능 우선순위 결정에서 ‘비즈니스 기준’이 들어간다
PM은 내부 피드백과 일정 중심으로 조율하지만, PO는 기능 하나를 만들 때도 ROI(비용 대비 효과)를 고려합니다.
예시:
- A기능은 사용자 요청이 많지만 수익에 미치는 영향이 적음
- B기능은 도입 시 구독률 상승 가능성이 높음 → 이 경우 B가 우선순위가 됨
4. 실무 TO-DO는 이런 것들
| 구분 | 실제업무예시 |
| 전략 수립 | 제품 로드맵 작성, 기능 도입 기준 정의 |
| 데이터 분석 | 리텐션 분석, A/B 테스트 결과 해석 |
| 고객 인터뷰 | 주요 이탈 고객 대상 인터뷰 진행 |
| 문서 작성 | 기능 정의서 + 비즈니스 근거 정리 |
| 리뷰 주관 | 스프린트 리뷰 회의 주관 및 개선 피드백 수렴 |
PO는 제품의 ‘방향’과 ‘성과’를 함께 본다
PM은 “잘 만들기”를, PO는 “왜 만들지”와 “얼마나 잘됐는지”를 함께 봅니다.
그래서 PO는 다음과 같은 질문을 스스로에게 자주 던집니다:
- 이 기능은 고객 문제를 진짜 해결할까?
- 수익에 얼마나 기여할 수 있을까?
- 이 기능의 성공은 어떤 지표로 판단할 수 있을까?
정리하며
PO는 단순한 프로젝트 매니저가 아닙니다.
비즈니스 전략, 사용자 문제 해결, 수익성과 성장성 판단까지 책임지는 제품 오너입니다.
PM에서 PO로 넘어간다면, 이제 당신의 관심은 ‘기획서’가 아니라 ‘제품의 방향’으로 향해야 합니다.
'UX 디자이너로 살아남기' 카테고리의 다른 글
| 119. PO의 문서 작성법 : 기획안이 아니라 전략서다 (0) | 2025.06.14 |
|---|---|
| 118. PM에서 PO로 전환하기 전, 꼭 점검할 3가지 (1) | 2025.06.10 |
| 116. PM과 PO는 뭐가 다를까? 실무에서 느낀 진짜 차이 (0) | 2025.06.03 |
| 115. PM의 일주일, 이렇게 툴로 자동화한다 #4 (0) | 2025.05.28 |
| 114. 툴을 조직 언어로 바꾸는 순간, 모두가 따라온다 #3 (0) | 2025.05.26 |