PO라고 하면 하나의 역할처럼 보이지만
실무에서는 완전히 다른 종류가 존재한다.
같은 PO인데도
어떤 회사에서는 전략가처럼 움직이고
어떤 회사에서는 기획자처럼 일한다.
프로덕트 오너 (기본형 PO)
백로그 관리
우선순위 결정
스프린트 운영
지금 뭘 만들지
뭘 나중으로 미룰지
전략은 위에서 내려오는 경우가 많고
본인은 실행에 집중한다
방향은 이미 정해져 있고
실행 속도를 올리고 싶을 때
대표의 전략을 구체화해줄 사람이 필요할 때
자기 주장이 강하기보다는
정해진 방향을 잘 풀어내는 사람이 맞다.
제품보다 “비즈니스 결과”에 더 가깝다.
매출
전환율
리텐션
이걸 기준으로 판단한다.
어떤 기능이 돈이 되는지 판단
실험 설계
성과 분석
PM과 겹치는 영역이 많지만
차이는
PM은 방향을 만든다면
비즈니스 PO는 성과를 만든다
제품은 잘 만들어지고 있는데
그걸로 돈을 못 벌고 있을 때
외부 제휴나 협업이 필요한 시점일 때
제품이 아니라
성과를 만들어야 하는 단계다.
이건 회사마다 다르지만
권한이 큰 PO다.
제품 방향 일부 결정
우선순위 독립적으로 판단
조직 간 의사결정 참여
사실상 이런 역할이다.
작은 제품의 책임자
혹은 특정 도메인의 오너
하지만 현실은 중요하다.
책임은 크고
권한은 애매한 경우도 많다
대표가 IR, 대외 미팅 등 외부 활동이 많아지고
내부를 계속 챙기기 어려워졌을 때
일 단위 보고와 의사결정을 위임해야 할 때
이때는 “대신 책임질 사람”이 필요하다.
기술 이해도가 핵심이다.
API
아키텍처
데이터 구조
이걸 기반으로 의사결정한다.
주로 이런 상황에서 필요하다.
플랫폼 개발
인프라 개선
복잡한 시스템 연동
하는 일은 이쪽이다.
기술 스펙 정의
개발 난이도 판단
기술 부채 관리
대표나 의사결정자가 기술 이해도가 낮고
개발 조직을 연결해줄 중심이 필요할 때
기술을 모르면
의사결정이 느려지는 구간에서 필요해진다.
사용자 경험에 집중한다.
UX
기능 흐름
사용성
비즈니스보다
“잘 쓰이는지”를 본다.
주로 하는 일은 이렇다.
사용자 시나리오 설계
기능 디테일 정리
QA 기준 정의
좋은 제품을 만드는 데 집중한다.
“사용자가 잘 쓰게 만드는 PO”
기능은 이미 충분히 나왔고
이제는 더 잘 쓰이게 만들어야 할 때
이 단계에서는
“만드는 것”보다 “잘 쓰이게 하는 것”이 중요하다.