PO
구루님, 실험도 하고 MVP도 잘라서 만들고 있는데요, 막상 기능을 결정할 때 뭘 먼저 해야 할지 막막해요. 대표는 이걸 하자고 하고, 개발팀은 리팩터링이 필요하다고 하고, 저는 또 사용자 피드백을 따라가고 싶고요. 도대체 우선순위는 어떻게 정해야 하는 걸까요?
구루
좋은 질문이야. PO가 실무에서 가장 많이 부딪히는 고민이지. 우선순위는 단순히 "먼저 할 일"을 정하는 게 아니라, 우리의 전략, 리소스, 사용자 가치 사이의 균형을 맞추는 작업이야. 전략적 사고 없이는 단기 반응에 끌려가기 쉬워.
PO
그럼 우선순위가 흔들리면 팀 전체가 불안정해지는 건가요?
구루
맞아. 팀은 결국 PO가 보여주는 "이걸 먼저 하자"는 메시지를 따라 움직여. 그런데 만약 PO가 스스로도 확신 없이 우선순위를 바꾸거나, 외부 요청에 휘둘려서 자주 뒤집는다면 어떻게 될까?
PO
팀이 혼란스럽고, 동기부여도 안 되겠네요. 내가 말한 방향을 믿을 수 없게 되니까요.
구루
정확해. 그래서 우선순위는 단순한 정렬이 아니라 리더십의 표현이고, 전략의 실행이야. 특히 스타트업처럼 리소스가 제한된 팀에서는, 무엇을 하지 않을지 결정하는 것이 더 중요할 때도 있어.
PO
결국, 어떤 일을 ‘먼저’ 하느냐가 아니라, ‘왜’ 먼저 해야 하는지를 말할 수 있어야겠네요.
구루
바로 그거야. 그리고 그 ‘왜’를 말할 수 있으려면, 문제의 본질, 전략의 방향, 그리고 리소스의 한계를 이해하고 있어야 하지. 이게 PO가 우선순위를 정할 때 생각해야 할 출발점이야.
PO
같은 기능이어도 상황에 따라 달라진다는 건가요?
구루
맞아. 우선순위를 정할 때 자주 놓치는 건 "전략적 맥락"이야. 같은 기능이라도 상황에 따라 중요도가 달라질 수 있어. 성장 단계에서는 유저 확보에 영향을 주는 기능이 우선이 되지. PMF 이후에는 리텐션이나 전환율을 높이는 기능이 더 중요하고, 스케일 단계에서는 효율성과 운영 자동화 기능이 핵심이 돼.
PO
그럼 단순히 긴급하거나 요청이 많다고 바로 하는 게 아니라, 이 기능이 우리 전략에 어떤 기여를 하는지를 먼저 따져야겠네요.
구루
맞아. 그래서 좋은 PO는 기능이 아니라 가설을 비교해. 어떤 가설이 우리 전략의 핵심 전제를 검증하는가? 어떤 위험을 줄여주는가? 이런 기준이 있어야 해.
PO
구루님 말씀을 들으니, 결국 어떤 가설이 가장 중요한지를 명확히 하는 게 우선순위 결정의 핵심이겠네요. 그런데 막상 현장에서는 여러 팀에서 다양한 요청이 쏟아지고, 리소스는 늘 부족하다 보니, 정말 중요한 가설에 집중하기가 쉽지 않다는 걸 느껴요. 다들 '이게 왜 지금 중요한가요?'라고 물을 때, 명확하게 답을 제시하는 게 어렵기도 하고요.
구루
아주 현실적인 어려움이네. 우선순위는 단순히 '무엇을 먼저 할까'를 정하는 기술적인 문제가 아니라, 팀 전체의 이해와 공감을 얻는 커뮤니케이션의 문제이기도 하거든. 팀원들이 "왜?"라고 묻는 건 당연한 거야. 그 질문에 명확하게 답을 못 하면, 아무리 좋은 우선순위 전략이라도 현장에서 실행되기 어렵지.
PO
맞아요. 저도 그 점을 많이 느껴요. 급한 대로 이것저것 처리하다 보면, 나중에 돌아봤을 때 "우리가 진짜 중요한 일에 집중한 게 맞나?" 하는 생각이 들 때가 많아요.
구루
그래서 더더욱 ‘아이젠하워 매트릭스’가 필요해. 일을 네 가지로 나누는 거지.
① 중요하고 급한 일: 당장 해결하지 않으면 사업에 피해가 가는 이슈. 예: 결제 오류, SLA 위반, 대형 파트너 계약 대응.
② 중요하지만 급하지 않은 일: 장기적으로 사업 방향에 영향을 주는 전략적 투자. 예: 신시장 검증, 유저 조사 기반의 기능 설계, 제품 리포지셔닝.
③ 급하지만 중요하지 않은 일: 긴급하게 보이지만 팀이 주도할 필요는 없는 요청. 예: 타 부서의 단순 요청, 반복적인 리포트, 긴급하다는 이유로 끼어든 사소한 요청.
④ 급하지도 중요하지도 않은 일: 시간만 잡아먹는 활동. 예: 목적 없는 회의, 영향력 없는 실험.
PO
대부분의 리소스가 ①과 ③으로 쏠리고 있어요. 특히 ③은 "급하니까 해달라"는 요청이 많아서 거절하기도 애매하고요.
구루
③은 과감히 위임하거나 기준을 만들어서 거절해야 해. PO는 회사 전체의 리소스가 2번 영역, 즉 ‘장기적 가치’를 만드는 데 쓰이도록 조율해야 해.
PO
그런데 2번은 항상 뒤로 밀려요. 눈앞의 이슈가 많다 보니, 신규 기획이나 리서치는 “나중에 하자”가 돼요.
구루
바로 그 ‘나중에 하자’가 쌓이면, 조직은 늘 문제 수습하는 팀이 되고 말아.
②번에 투자하지 않으면 우리는 성장하지 못하고, 늘 ‘급한 일에 반응하는 조직’으로 남게 돼.
PO
결국 PO는 '무엇을 만들지'가 아니라, '무엇에 시간을 쓰게 할지'를 결정하는 역할이네요.
구루
정확해. PO는 조직 전체 리소스를 가장 의미 있는 문제에 집중시킬 수 있어야 해. 그래서 ②번은 네가 직접 챙겨야 하고, ③번은 의도적으로 줄이거나 외부로 넘겨야 해.
PO
그럼 ‘중요하지만 급하지 않은 일’은, 급하게 만들지 않도록 미리 준비하고, 시스템적으로 달력에 넣어야겠네요.
구루
맞아. PO가 해야 할 최고의 우선순위 정하기는 ‘소방관’이 아니라 ‘설계자’가 되는 거야. 불 나기 전에 방화벽을 짓는 사람. 그게 진짜 영향력 있는 PO지.
PO
얼마 전에도 그랬어요. 대표님이 “이거 한번 검토해줘”라고 하셨는데, 팀 전체가 그거 하느라 계획했던 기능은 밀렸어요. 사실 사용자 피드백이나 데이터 상으로도 급한 일은 아니었거든요.
구루
대표님의 말이니까 당연히 급하다고 느꼈겠지?
PO
네… 안 하면 안 되는 것 같았어요. “지금 당장은 안 급합니다”라고 말하기 어려웠고요.
구루
자, 생각해보자. PO는 조직에서 어떤 역할이지?
PO
우선순위를 정하고, 팀이 가장 가치 있는 문제에 집중할 수 있도록 조율하는 사람이요.
구루
맞아. 그런데 누가 말했느냐에 따라 우선순위가 바뀐다면, 그건 우선순위가 아니라 서열이 되는 거야.
PO
...정확히는, 판단이 아니라 복종이네요.
구루
그렇지. 물론 경영진의 시야에는 넓은 맥락이 있을 수 있어. 하지만 PO는 그것을 요청(request)으로 받아들인 다음, 검토하고 평가해야 해. 즉, “누가 말했는가”보다 “그 요청이 어떤 문제를 해결하는가”에 집중해야 하지.
PO
그럼 대표님 요청도 ‘다른 요청과 동등하게’ 평가해도 되는 건가요?
구루
해야 해. 물론 예의와 커뮤니케이션 방식은 조심스럽게 해야겠지만, PO의 책임은 합리적 기준에 따라 판단하는 것이야. “현재 진행 중인 이 기능이 사용자 가치와 사업 임팩트가 더 크기 때문에, 이 요청은 다음 사이클에서 검토하겠습니다”라고 말하는 용기와 논리가 필요하지.
PO
실제로 그렇게 말하면 “이 친구 생각이 있네”라고 인정받을 수 있을까요?
구루
단순히 ‘싫다’가 아니라 ‘판단의 기준’을 보여주는 PO는 신뢰받아. 그리고 그게 반복되면, 조직도 더 이상 '위에서 시키면 움직이는 팀'이 아니라 '판단하는 팀'으로 성장해.
PO
결국, PO가 해야 할 일은 요청을 모두 들어주는 게 아니라, 모든 요청을 판단의 테이블 위에 올려놓는 것이군요.
구루
잘 정리했어. 요청을 거절하는 게 아니라, 우선순위에 따라 대응하는 것. 그게 PO가 위로부터도, 아래로부터도 존중받는 방식이지.
PO
그런데 실무에서는 숫자 중심으로 우선순위를 정하라는 압박이 많아요. 실험을 하면 어떤 게 전환율에 영향을 줄지부터 보거든요. 그러다 보니 숫자가 당장 잘 안 나오는 기능은 계속 미뤄지기도 하고요.
구루
맞아, 그게 흔한 오류 중 하나야. 모든 걸 단기적인 데이터로만 판단하면, 중요한 걸 놓치기 쉬워.
예를 들어, 결제할 때 "다음에도 이 카드를 사용하기" 같은 기능을 생각해보자.
PO
음, 그건 되게 작은 기능 같네요?
구루
그치. 그 기능 하나로 구매 전환율이 눈에 띄게 오르진 않아. 그래서 전환율, 클릭률 같은 지표만 보면 우선순위에서 계속 밀릴 수 있어. 그런데 반복 구매하는 고객 입장에서는 이 기능이 마찰을 줄여주고, 장기적으로는 전환 속도와 재방문율을 올려주는 핵심 경험이 될 수 있어.
PO
아, 그러니까 데이터는 중요하지만, 전략적 맥락을 놓치면 안 된다는 거군요.
구루
정확해. 숫자는 우선순위의 ‘결과’일 수는 있어도, ‘이유’가 되면 안 돼. 숫자와 맥락, 사용자 경험을 균형 있게 보는 눈이 PO의 핵심 역량이지.
PO
팀에서 요청을 정리하다 보면, 큰 고객이 요구한 기능이나 먼저 들어온 요청이 자동으로 앞줄에 배치돼요. 저도 모르게 “이건 일단 중요하다”라고 생각하게 되고요.
구루
흥미롭네. 한번 물어보자. 큰 고객이 요청했다는 이유만으로 그게 중요한 기능일까?
PO
보통은 “매출에 영향 줄 수 있다”는 생각 때문에 우선 처리하려 해요.
구루
자, 중요한 질문 하나. 그 요청이 다른 고객에게도 유의미한가? 아니면 그 고객만의 특수한 요구인가?
PO
가끔은 거의 그 고객만을 위한 기능이긴 해요…
구루
럼 제품을 더 좋게 만드는 일인가, 아니면 계약 유지용 커스터마이징인가?
PO
음... 커스터마이징인 경우가 많아요. 근데 그 고객이 빠져나가면 리스크라서 무시하기도 어렵고요.
구루
이해하지. 그런데 그렇게 계속 대응하다 보면 제품은 점점 특정 고객의 요구 집합체가 돼버리지. 그건 장기적으로 보면 제품의 방향성을 흐트러뜨리는 일이야.
PO
그럼 무조건 거절해야 할까요?
구루
아니. PO는 ‘예’와 ‘아니오’의 사람이 아니라, ‘왜’의 사람이야. “이 요청이 우리 제품 전략과 얼마나 맞는가?”, “다른 고객에게도 반복될 수 있는가?”, “이걸 지금 해야 할 명확한 이유가 있는가?” 이 질문을 항상 먼저 던져야 해.
PO
그리고 ‘먼저 들어온 요청이니까 먼저 한다’는 것도 같은 오류겠네요?
구루
그렇지. 요청의 시간 순서는 우선순위의 기준이 될 수 없어. 더 큰 문제는, 먼저 들어온 요청들에 치이다 보면 지금 중요한 것을 할 시간이 사라진다는 거야.
PO
결국, 큰 고객이나 빠른 요청이 우선되는 게 아니라, 그 요청이 해결하는 문제가 우리 전략과 얼마나 맞는지가 판단 기준이 되어야 하네요.
구루
정확해. “누가 요청했는가”, “언제 요청했는가” 이건 단지 참고 정보일 뿐. “무엇을 해결하며, 어떤 영향을 주는가”가 우선순위를 결정해야 해.
PO
이제 알겠어요. 요청을 그냥 받는 게 아니라, 그 요청이 어떤 문제의 징후인지를 보는 시야가 필요하군요.