PM/PO의 일을 5가지로 정리해 보자
프로덕트 로드맵, 메트릭, PRD, 유저 스토리, 백로그
"잘나가는 서비스 기획자 도그냥은 왜 PM/PO가 되었을까?" 리뷰 마지막 편.
프로덕트 매니징 업무의 핵심 사항들을 나만의 방식으로 재구성해본다.
1. 전략적 사고를 통한 프로덕트 로드맵 구축
PM/PO 역할의 핵심은 프로덕트 개발의 큰 그림을 그리는 것이다. 이는 기업의 미션, 비전, 전략, 그리고 구체적인 목표에 대한 이해를 바탕으로 프로덕트 로드맵을 구축하는 것에서 시작한다.
미션(Mission)
기업이 해결하고자 하는 본질적인 문제
기업이 추구하는 가치. 'Why?'
비전(Vision)
미션 달성했을 때의 이상적인 기업의 모습, 형태
전략(Strategy)
성공적으로 비전을 실현하기 위한 구체적 방법
지향적 목적(Goal) + 지표적 목표(KPI)
오브젝티브(Objective)
전략을 실행하는 데 필요한 세부적인 프로젝트, 단위 작업
Tactic과 유사한 개념
프로덕트 로드맵(Roadmap)
오브젝티브를 프로젝트별로 정리하고 순서를 정렬함
OKR(Objectives and Key Results)
프로젝트별로 수치적 목표를 세우고 관리하는 방식
여기서의 Objective는 Tactic이 아니라 Goal(지향적 목적)과 유사한 개념
2. 메트릭의 정의와 활용
프로덕트 오너의 핵심 업무 중 하나는 메트릭(Metrics)을 관리하는 것이다. 유의미한 지표들로 정의된 메트릭을 지속적으로 모니터링하며 합리적인 대응 전략을 수립, 개선해야 한다.
북극성 지표(North Star Metric)
서비스가 올바르게 성장할 때 항상 유지되어야 하는 지표
예) 페이스북의 신규 피드 수
프록시 메트릭(Proxy Metric)
프로덕트의 가치가 잘 전달되었을 때 나타나는 사용자의 행동 가설을 바탕으로 정의한 지표
인풋 메트릭(Input Metric)
결과 지표(Output Metric)에 영향을 주는 선행 지표
아웃풋 메트릭을 움직일 수 있는 지렛대(lever) 역할을 함
3. 애자일 방식에서의 요구사항 문서화
전통적인 폭포수 방식에서의 서비스 기획자는 '화면 설계서'를 작성하지만, 애자일 방식으로 일하는 '프로덕트 오너'는 주로 PRD를 작성한다.
화면 설계서
UI 화면 구성 옆에 설명을 쓰는 형태
정책을 정의하고, 완결성을 중시
파워포인트/Figma 활용
PRD(Product Requirements Document)
화면보다는 내러티브가 있는 문장 형태로 요구 사항을 정의한 문서
비전, 전략을 바탕으로 프로젝트의 배경과 유저 스토리를 설명함
기능 개발을 통해 해결할 수 있는 관점으로 고객의 문제를 정의하여 이해관계자들에게 공감을 얻어야 함
예) 아마존의 6 페이저
4. 유저 스토리와 완료 조건 정의
PRD에 요구 사항을 정의할 때, 유저 스토리와 완료 조건을 포함하여 서술한다. 유저 스토리와 완료 조건은 1:N의 관계를 가진다.
유저 스토리(User Story)
서비스가 제공해야 할 가치와 기능 요구 사항을 사용자의 관점에서 인지할 수 있도록 설명하는 방식
'사용자는 (가치)를 위해서, (태스크)를 할 수 있다.'
구체적인 UI의 형태나 개발 로직(ex. 버튼을 누른다)을 명시하지 않음으로써 개발자/디자이너의 적극적인 참여와 자유도를 높임
단, 원활한 디자인 작업을 위해서는 많은 소통이 필요하고, QA 인원을 위해 최종 디자인본으로 리뷰를 재차 진행하는 것이 좋음
유저 스토리 하나에 완료 조건이 너무 많아서 개발 범위가 넓을 경우, 여러 개의 Jira epic + story로 스프린트를 나누어 구성할 수 있음
완료 조건
개발을 통해 구현된 유저 스토리가 목적에 부합하는지 판단할 수 있는 조건들(성공에 대한 기준이 됨)
요구 사항을 통해 프로덕트가 갖춰야 하는 상세 스펙을 담는 그릇
케이스별 정책 및 플로우 정의, 분기 처리/예외 처리 등을 포함
개발 방법론
단순히 코딩을 통해 주어진 과제를 구현하는 것에 그치지 않고, 유저 스토리와 완료 조건을 통해 비즈니스에 대한 도메인 지식을 인지한 상태에서 자유도 높은 코딩을 할 수 있게 함
ADD(Acceptance Criteria Driven Development): 실제 사용자에게 영향을 주는 완료 조건을 계속 인식하면서 개발하는 방식. 기능의 결과를 바탕으로 테스트 코드를 만듦
DDD(Domain Driven Development): 비즈니스에 대한 이해를 바탕으로 개발하는 방식. 코드를 구성할 때, 실제 비즈니스 환경에서 사용되는 용어를 그대로 사용함
5. 백로그 관리
스프린트별로 진행할 작업을 적절한 비율로 선택하기 위해 균형 있는 백로그 선정 및 관리가 중요하다. PON 구분값을 활용하여 우선순위 선정에 참고할 수 있다.
PON 구분값
Problem: 기존 문제를 해결하기 위한 것인가
Opportunity: 더 큰 성장의 기회가 있을 것으로 예상되는 것인가
Needs: 이해관계자의 요청으로 제안된 것인가
현재 우리 회사에서는 애자일 방식을 표방하고 있지만, 나는 화면 설계서에 좀 더 가까운 PRD를 작성하고 있었다. 그렇다고 지금 당장 PRD에서 UI 형태, 개발 로직 등에 대한 서술을 없애기보다는, User Story를 좀 더 명확하게 공유하는 방향으로 일을 해보고자 한다. 조금씩 디자이너와 개발자 분들의 기획 참여도를 높이며 효율적인 팀을 만들어 나가고 싶다.
