225. 기능 우선순위 문서, 이렇게 정리하면 됩니다

기획은 하고 싶은 게 아니라, 해야 할 걸 선택하는 일입니다
 
PO/기획자로 일하다 보면
기능 아이디어는 넘쳐나는데,
막상 “어떤 걸 먼저 해야 하죠?”라는 질문엔 말문이 막힐 때가 있습니다.
 
그럴 때 필요한 게 바로 기능 우선순위 문서(Prioritization Doc)입니다.
 
이 문서는 단순한 리스트가 아닙니다. 리소스는 한정되어 있고, 모두가 다른 의견을 낼 때
객관적인 기준으로 방향을 제시해주는 전략 도구입니다.

우선순위를 정하는 기준, 꼭 있어야 합니다

기능 우선순위는 사람마다 다르게 느껴집니다.
→ “이거 급해요!”
→ “아니, 이건 꼭 이번에 들어가야 해요!”
 
그래서 우선순위 기준을 명확히 하지 않으면
팀 전체가 감정적으로 결정하게 되고, 후폭풍이 생깁니다.
 

실무에서 많이 쓰는 기준 3가지

1. Impact vs Effort

• 효과(Impact)가 크고
• 노력(Effort)은 적은 것부터!

	Effort 낮음	Effort 높음
Impact 큼	✅ 지금 해야 함	고민 필요
Impact 작음	나중에 해도 됨	❌ 보류

 
→ 직관적이고 빠르게 판단 가능해서 많이 씀

2. RICE Score

• Reach: 몇 명에게 영향?
• Impact: 얼마나 큰 변화?
• Confidence: 데이터 근거 확실성
• Effort: 리소스 소요량

(R × I × C) / E = 우선순위 점수
 
→ 다소 계산적이지만, 숫자로 보여주기에 설득력↑

3. MoSCoW

• Must: 반드시 이번에 포함
• Should: 포함되면 좋음
• Could: 여유 있으면
• Won’t: 이번엔 안 함

→ PO가 다양한 이해관계자 요청을 분류할 때 유용

기능 우선순위 문서 구조 예시

1. 기능/요구사항 명
2. 문제/배경 요약
3. 우선순위 기준 적용 결과 (예: RICE 점수 or Impact 등급)
4. 예상 기대 효과 및 리스크
5. 권장 일정 또는 제외 사유

작성 팁

• 한눈에 보기 좋게 표나 시트 형식으로 작성
• 기능 단위가 아니라 문제 단위로 정리할 것 → 예: “쿠폰 시스템 개선” → “재방문율 30% 향상 목표”
• 1~2줄 코멘트를 붙이면 설득에 효과적 → “최근 CS VOC 15건 발생 / 경쟁사 대비 미비한 기능”
• 내부 요청 vs 사용자 이슈 구분해서 정리

정리하며

우선순위를 정하지 않으면
모든 기능이 “지금 꼭 해야 할 것처럼” 보입니다.
 
📌 PO의 역할은 “무엇을 먼저 할까”가 아니라 “무엇은 지금 안 해도 되는가”를 설득하는 것입니다.
기능 우선순위 문서는 그 기준과 방향을 기록하는 팀의 합의 도구이자 실행의 기준선입니다.