1. 목적 Object
- 최대 2~3 문장 이내로 이 문서의 목적 및 다룰 내용 밝히기.
- 이 문서를 읽기 위해 시간을 할애해야 할지 스스로 판단할 수 있도록
2. 배경정보 Background
- 약 2~3문단~반장 정도 왜 이 신규 기능이 필요한지 설명,
- 일련의 진행 상황, 풀고자 하는 문제, 앞으로의 방향성 이해할 수 있도록
3. 고객을 위해 어떤 일을 하는가? What job are you doing for the customer?
- 목록형태로 작성
- 각 고객이 왜 이 해당 기능을 '고용'할지에 대해 짧고 명확하게 명시
- 중요도 순으로 나열
- ex) 정확하게 어떤 음식을 주문할지 알고 들어온 고객은 실시간 배송 정보를 눈으로 확인하기 위해 이 새로운 지도 기능을 고용한다.
- 주로 3~5가지 항목이 나열, 너무 다양한 고객이 있다는 것은 PO가 정말 중요한 고객이 누구인지 파악을 못했다는 증거.
4. 원칙 Guiding Principal
- 이 기능을 개발하고 고객에게 선보이는 과정에서 결정을 내릴 때 잣대로 삼을 원칙 나열
- 중요도 순으로, 6개 내로 한정(너무 많은 원칙이 있는 것도 PO가 간소화하지 못했다는 증거이므로 꼭 따라야 하는 주요 원칙만 선정)
- ex) 고객은 음식배달 현황을 파악하는 걸 가장 중요하게 생각한다. 배달 현황을 파악하는데 도움이 안되는 지도 기능은 철저하게 배제한다. 위성이미지, 교통상황 등
5. 목표 Goals
- 새로운 기능 선보였을 경우, 어떤 목표를 달성할지 설명
- 무조건 수치화
- 주로 2~3개 (너무 많은 목표는 우선순위 미파악의 증거)
6. 주요 지표 Key Metrics
- 목표에 사용되는 지표 포함, 기능이 고객을 위해 제대로 된 목적을 수행하고 있는지 나타낼 수 있는 지표 3~4가지 선정
- 이미 트래킹하고 있는 수치가 있다면 나중에 변화되는 수치와 비교 시 활용
- ex) 지도를 열어 확인하는 고객 수를 파악할 수도 있지만, 고객센터 관련 문의 수 변화로도 파악 가능-줄어야 정상
7. 개발 계획 Road Map
- 단계별: 1단계는 빨리 테스트해 볼 수 있는 최소 기능 모델 Minimum Valiable Product을 완성하는 데 사용, 그 후 2단계, 3단계로 고도화
- 기간별: 단기간(1달 이내), 중장기(3달 이내), 장기(6개월 이내)로 나누어 시기별로 무엇을 해야할 지 설명
- 개발 계획 섹션은 개발팀 또는 팀장 검토 후 수정, 이때 개발 완료 예정 시간 Estibated Time of Arrival과 상태 표기(문제없을 시 그린, 문제 있을 시 옐로 또는 레드)
8. 자주 묻는 질문 FAQ
- 개발팀이나 유관부서에서 할 질문 예측하여 미리 답변 제시
- ex) 새로운 지도 기능은 안드로이드와 ios모두 동시 적용되나요? 안드로이드 업데이트 후 ios 업데이트 예정, 자세한 사항은 개발 계획 섹션을 확인해주세요.
이런 문서 작성 후 개발팀에 미리 문서 공유, 회의에서는 주요 내용만 다시 구두로 설명해 주고 곧바로 질의 시간. 개발팀에서 궁금해하는 모든 것을 PO가 대답해줘야 한다. 모르는 경우 최대한 빨리 확인해서 답변.
*출처: 김성한, 조직을 성공으로 이끄는 프로덕트 오너, 세종서적(2020)