오늘은 PM의 핵심 역량 중 하나인 우선순위 결정 프레임워크에 대해 이야기해볼게. PM으로 일하다 보면 "이 기능 왜 지금 만들어요?"라는 질문을 수없이 받게 되거든. 이때 내 직감이나 "대표님이 시켜서요" 같은 말 대신, 논리적인 근거를 대기 위해 반드시 알아야 하는 도구들이야.
1. 객관적인 수치로 설득하는 RICE
RICE는 대기업이나 규모가 큰 프로덕트 팀에서 정말 자주 쓰는 프레임워크야. Reach(도달 범위), Impact(영향도), Confidence(신뢰도), **Ease(용이성)**의 앞 글자를 딴 공식이거든.
공식은 (Reach * Impact * Confidence) / Ease로 계산해. 예를 들어, 메인 화면의 배너를 개편하는 작업이 있다면 얼마나 많은 유저에게 노출되는지(Reach), 전환율에 얼마나 영향을 줄지(Impact), 우리가 예측한 데이터가 얼마나 정확한지(Confidence)를 곱한 뒤, 개발 공수(Ease)로 나누는 거지. 10년차인 내가 실무에서 써보니, 부서 간의 이해관계가 얽혀있을 때 이만큼 강력한 설득 도구가 없더라.
2. 빠르고 민첩하게 검증하는 ICE
RICE보다 조금 더 가볍고 빠르게 움직여야 하는 스타트업이나 초기 프로젝트에서는 ICE 프레임워크를 추천해. Reach를 제외하고 Impact(영향도), Confidence(신뢰도), Ease(용이성) 세 가지 요소만 곱해서 점수를 내는 방식이야.
공식은 Impact * Confidence * Ease로 아주 단순해. 점수 매기기가 직관적이라 팀원들과 브레인스토밍하면서 빠르게 우선순위를 정할 때 유용해. 다만, 주관성이 개입하기 쉽기 때문에 Confidence(신뢰도) 점수를 줄 때는 반드시 과거의 데이터나 유저 인터뷰 같은 객관적인 근거를 기반으로 점수를 매기는 연습을 해야 해.
3. 직관적이고 직설적인 MoSCoW
숫자로 계산하는 게 머리 아프다면, 요구사항의 중요도에 따라 분류하는 MoSCoW 기법을 써봐. 이건 요구사항을 네 가지 카테고리로 나누는 방법이야.
- Must Have: 서비스 출시에 절대적으로 필요한 핵심 기능 (없으면 출시 불가)
- Should Have: 중요하지만 대체 방안이 있는 기능
- Could Have: 있으면 좋지만 없어도 무방한 기능 (일명 Nice-to-have)
- Won't Have: 이번 스프린트나 릴리즈에서는 절대 안 할 기능 개발팀과 이번 배포 스코프(Scope)를 조율할 때 이 기준을 미리 합의해 두면, 일정이 밀려도 어떤 기능을 뒤로 미룰지 빠르게 의사결정할 수 있어서 정말 편해.
💡 핵심 정리
- RICE: 대규모 프로젝트나 이해관계자 설득이 필요할 때 수치적 근거로 활용하기 좋아.
- ICE: 초기 스타트업이나 빠른 실험이 필요할 때 직관적으로 점수를 매기기 유용해.
- MoSCoW: 개발 스코프를 확정하고 배포 일정을 조율할 때 직관적인 기준이 되어줘. 우선순위 프레임워크는 정답을 알려주는 마법의 공식이 아니라, 팀원들과 의사소통을 돕는 도구일 뿐이라는 걸 명심해. 어떤 프레임워크를 쓰든 팀원들이 납득할 수 있는 합리적인 기준을 세우는 게 진짜 실력이야. 이번 기획서에는 꼭 이 중 하나를 적용해서 논리를 탄탄하게 다져봐!