ICE 우선순위화 도우미(ICE Prioritization Helper)

우선순위화 프레임워크의 신뢰도 문제

모든 PM에게는 각자의 우선순위화 프레임워크가 있습니다. RICE, ICE, MoSCoW, 가중치 점수(weighted scoring)까지, 선택지는 끝이 없고 무엇이 최고인지에 대한 논쟁은 더 끝이 없습니다. 하지만 이들 모두는 하나의 근본적인 약점을 공유합니다. Confidence 점수는 거의 항상 만들어낸 숫자라는 점입니다.

ICE -- Impact, Confidence, Ease -- 가 널리 쓰이는 이유는 단순하기 때문입니다. 세 개의 점수를 곱해 순위를 만들면 되니까요. 2023년 Productboard 설문에 따르면 60%가 넘는 제품 팀이 어떤 형태로든 점수 기반 프레임워크를 우선순위화에 사용합니다. 하지만 팀이 근거 없는 confidence 점수를 실제 데이터처럼 다루는 순간, 그 단순함은 오히려 리스크가 됩니다.

문제

Impact 점수는 추정에 가깝습니다. Ease 점수는 대체로 낙관적입니다. 하지만 가장 위험한 것은 Confidence 점수입니다. 그것은 엄밀함(rigor)의 착시를 만들기 때문입니다. PM이 어떤 아이디어에 "Confidence: 7/10"을 붙이는 순간, 전체 우선순위화 모델은 그 숫자가 근거에서 나온 것처럼 취급합니다.

현실에서 confidence 점수는 아이디어에 대해 PM이 느끼는 감정에 더 가깝지, 얼마나 많은 증거가 있는지와는 다릅니다. Amos Tversky와의 협업으로 잘 알려진 Daniel Kahneman의 인지 편향(cognitive bias) 연구에 따르면, 사람들은 자신의 예측에 체계적으로 과신하는 경향이 있으며, 전문가의 confidence와 실제 정확도의 상관관계는 완벽한 상관 1.0 기준 약 0.2 수준입니다.

그 결과 우선순위화 프레임워크는 부정확한 입력으로부터 정밀해 보이는 출력값을 만들어냅니다. 팀은 사실상 무작위에 가까운 순위 리스트를 실행에 옮기고, 결과가 기대에 못 미치면 실행을 탓하게 됩니다.

이 프롬프트의 작동 방식

ICE 우선순위화 도우미(ICE Prioritization Helper) 프롬프트는 점수를 계산하는 데서 멈추지 않고, 그 점수 자체에 의문을 제기합니다. 입력한 각 아이디어마다 어떤 증거가 Impact 추정을 뒷받침하는지, 어떤 가정이 Ease 점수 밑에 깔려 있는지, 그리고 가장 중요한 Confidence를 어떤 하위 요소로 나눠 봐야 하는지를 묻습니다.

하나의 confidence 숫자 대신, 이 프롬프트는 여러 차원에서 confidence를 평가합니다. 증거의 질(evidence quality)은 어떤지, 직감뿐인지 데이터가 있는지, 유사한 선례(comparable precedent)가 있는지, 그리고 검증되지 않은 가정(assumption risk)이 얼마나 많은지를 봅니다.

이렇게 분해하면 백로그(backlog)에 숨어 있던 진짜 불확실성이 드러나고, 우선순위가 크게 뒤바뀌는 경우도 많습니다.

언제 사용할까

• 분기 계획(quarterly planning) 중 백로그를 냉정하게 우선순위화해야 할 때
• 이해관계자가 사적인 선호 프로젝트를 밀어붙일 때 구조화된 방어 논리가 필요할 때
• 디스커버리 스프린트(discovery sprint) 이후 여러 기회를 비교하고 순위를 정해야 할 때
• 팀이 다음에 무엇을 만들지 두고 의견이 갈릴 때 공통 평가 프레임워크가 필요할 때

흔한 함정

첫 번째 점수에 앵커링(anchoring)하기. 첫 번째로 점수를 매긴 아이디어가 나머지의 기준점이 됩니다. 비교하기 전에 각 아이디어를 독립적으로 평가하거나, 순서를 섞으세요.

confidence 분해를 무시하기. 프롬프트가 임팩트는 크지만 증거의 질은 낮다고 말한다면, 그건 기능을 바로 만들라는 뜻이 아니라 빠른 실험을 먼저 하라는 신호입니다.

ICE로 판단할 수 없는 결정을 맡기기. 우선순위화 프레임워크는 같은 범주 안의 선택지를 정렬하는 데 도움을 줍니다. 그 범주 자체를 추구할 가치가 있는지까지 말해주지는 못합니다. 전략적 질문은 점수 모델이 아니라 전략적 사고가 필요합니다.

Pendo 연구에 따르면 평균적인 소프트웨어 제품에서 기능의 80%는 거의 또는 전혀 사용되지 않습니다. 더 나은 우선순위화는 단지 순서를 잘 정하는 문제가 아니라, 점수가 낮은 아이디어를 과감히 죽일 수 있는 규율의 문제이기도 합니다.

참고 자료

• Feature Adoption Report - Pendo
• Thinking, Fast and Slow - Daniel Kahneman (summary)
• Product Prioritization Trends - Productboard