숨이 턱끝까지 차오르는 목요일 오후의 요구사항 회의. 개발팀은 “이게 왜 필요한가요?”라고 묻고, PO는 매번 “현업에서 꼭 해 달라고 하네요”라는 답변만 반복합니다. 익숙한 풍경인가요? 만약 그렇다면, 당신은 지금 제품 책임자(Product Owner)가 아니라 ‘Product Proxy’, 즉 요구사항 배송기사 역할을 하고 있을 가능성이 큽니다.

현장에서 만나는 많은 PO들이 “결정권이 없어서 힘들다”고 토로합니다. 하지만 권한은 누군가 쥐어 주는 것이 아니라, 자신이 직접 증명하는 가치로부터 나옵니다.

 

전달자(Messenger)의 함정에서 벗어나기

우리가 흔히 범하는 오류는 PO의 역할을 ‘요구사항을 잘 정리해서 개발팀에 넘겨주는 것’으로 오해하는 것입니다. 하지만 명확히 그렇지 않습니다.

“제품 책임자(Product Owner)의 책무를 단순히 요구사항 전달자(Requirements Deliverer)나 대리인(Proxy)으로 해석하는 편견을 깨야 한다.”

단순히 ‘전달’만 하는 사람은 갈등을 중재할 수는 있어도, 가치를 창출할 수는 없습니다. 현업의 목소리를 그대로 옮기는 것은 친절할지는 몰라도 전략적이지는 않습니다. 진정한 PO는 비즈니스 전략이라는 필터로 요구사항을 걸러내고, 때로는 “안 됩니다”라고 말할 수 있는 용기를 가진 사람입니다.

‘무엇’이 아닌 ‘가설’로 대화하세요

이해관계자의 강력한 요청 앞에서 PO가 무력해지는 이유 중 하나는 ‘데이터’가 없기 때문이 아니라 ‘논리적 프레임’이 없기 때문입니다. 모든 백로그 아이템을 작성할 때, 아래의 [가치-가설 문장]을 완성하지 못한다면 그 항목은 아직 개발팀에 넘겨줄 준비가 되지 않은 것입니다.

1. [대상]을 위해
2. [기능/솔루션]을 제공한다면
3. [기대 성과]라는 결과가 나타날 것이다.
4. 우리는 [측정 지표]가 변화하는 것을 보고 이를 증명할 것이다.

이렇게 프레임을 바꾸는 순간, 대화의 주도권은 ‘누가 시켰느냐’에서 ‘얼마나 가치 있느냐’로 이동합니다. “다운로드 버튼을 만들어주세요”라는 요청을 “운영팀의 보고서 작성 시간을 50% 줄이기 위한 가설”로 재구성하는 것, 그것이 PO가 보여줄 수 있는 전문성의 실체입니다.

 

판을 뒤집는 질문의 힘

회의실의 분위기를 바꾸는 건 거창한 프로세스가 아닌 경우가 많습니다. 이해관계자와의 팽팽한 긴장 속에서, 혹은 확신 없는 요구사항 앞에서 다음 질문을 던져보세요.

“이 기능이 완벽하게 구현되었음에도 불구하고, 우리가 기대한 비즈니스 지표가 전혀 움직이지 않는다면 무엇을 해야 할까요?”

이 질문은 상대방으로 하여금 ‘기능의 구현’이 아니라 ‘결과에 대한 책임’을 생각하게 만듭니다. PO는 바로 그 지점에서 코칭과 의사결정을 시작해야 합니다.

애자일은 단순히 빨리 만드는 것이 아니라, ‘제대로’ 만드는 것입니다. 요구사항 배송기사이기를 거부하고 비즈니스의 가치를 고민하기 시작할 때, 팀의 백로그는 단순한 ‘일감 목록’이 아닌 ‘성공을 위한 지도’가 될 것입니다.

 

Professional Scrum Product Owner 워크숍

PO의 역할을 아는 것과 현장에서 증명하는 것은 다릅니다.

‘요구사항의 늪’에서 벗어나 비즈니스 가치를 설계하는 진짜 PO의 감각을 깨우고 싶다면, Scrum.org의 PSPO 과정이 그 답이 될 수 있습니다. 제품 백로그를 전략적 무기로 바꾸는 여정에 함께하세요.

👉 [PSPO 과정 자세히 보기]