프로덕트 메이킹에서 오너십이 중요한 이유

기획 직군만큼 포지션명이 어지럽게 얽혀 있는 도메인도 없을 것이다. PM으로 보통 줄여 말하는 기획자 포지션은 P가 Product의 P인지, Project의 P인지에 따라서도 느낌이 달라질 뿐더러 최근 몇 년 새엔 PM이 아닌 PO(Product Owner)와 같은 포지션도 등장했다. Growthhacker, 전략기획, 사업기획, 사업개발 등 ‘여튼 기획자가 하는 것 같은 일’을 일컫는 호칭은 회사마다 천차만별이다. 그럴 수 밖에 없다고 생각한다. 기획이라는 이름 아래에 온갖 일이 진행되는데, 영역이 광대하기 짝이 없을 뿐더러 각 회사마다 특히 필요로 하는 기획자의 스킬셋도 다르기 때문이다.

하지만 프로덕트 조직에서는 최근 PM보다는 PO로 기획 직군을 리포지셔닝하는 일이 점점 더 잦아지고 있다. 무시하기도 어려운 분명한 트렌드다. 직군의 명칭이 뭐가 그렇게 중요한지, 별로 대단한 일이 아닌 것처럼 보일 수 있겠지만 굳이 Owner라는 단어를 전면에 쓰기 시작한 것은 그만큼 프로덕트 조직이 잘 굴러가는 데에 오너십이 중요하다는 것을 많은 사람들이 깨닫고 있기 때문일 것이다.

오늘은 왜 프로덕트 조직에서 오너십이 중요한지 정리해 보았다.

이유 1. 결정권은 (대부분) 무거운 짐이다

그래서 떠안을 누군가가 있으면 좋다

애자일한 조직에서 일할 때 업무가 늘어지는 worst case는 서로가 서로에게 특정 사안에 대한 final call, 혹은 의사결정을 미룰 때다. 서로 긴밀하게 협업하고 토론하려면 위계 없이 커뮤니케이션이 이루어져야 하는데, 이 때 누가 논의를 주도하고 결정하는지는 당연히 흐려질 수밖에 없다. 결정을 따로 담당하는 사람이 존재하지 않으면 사안별로 결정을 주도하는 사람이 생기거나, 자주 발언을 하는 사람의 말에 자연스럽게 따르게 되는데 문제는 ‘자연스럽게’ 이런 일이 잘 발생하지는 않는다는 것이다.

아마 팀 단위의 협업을 해 본 누구나 “그 분위기”를 잘 알 것이다. 회의를 하자고 모였는데 밍숭맹숭한 말을 하다가 결론은 내리지 못하고 헤어지는 분위기. 수평적인 토의가 되어야 할 것 같으니 팀장이나 리드는 가급적이면 발언을 안 하고 자유발언이나 질문할 시간을 갖지만, 아무도 뭔가 말하지 않는 분위기. 조직 구성원들이 회의 시간에 말하고 있지 않다면, 발언에 대한 책임을 져야 할 것 같아서일 확률이 매우 높다.

프로덕트 오너라는 직책은 논의 주도와 의사결정을 책임지고 커뮤니케이션이 활발하게 진행되도록 담보한다. 이는 OO팀장, 혹은 OO리드 등으로 구분되는 매니저 포지션과는 완전히 다르다. 프로덕트 오너에게는 권한이 없다. 대신 논의를 정리하고 이를 바탕으로 태스크에 대한 크고 작은 결정을 내려야 할 의무만 있다. 팀 안의 누가 발언해도 결정에 대한 책임소재는 프로덕트 오너가 가지고 있기 때문에 발언의 무게가 가벼워진다.

참고: 꼭 PO가 아니더라도

태스크, 혹은 팀마다 오너가 있어도 좋다. 의사결정에 오너십을 가지는 사람이 있으면 일이 편하게 굴러가니까, 프로덕트 오너라는 포지션이 조직에 없다면 그러한 역할을 할 수 있는 사람이 있어야 한다. 다만 그 사람이 팀 리드나 C레벨과 일치하는 경우 다소 탑다운스러운 분위기가 조성될 수 있다는 점은 반드시 염두에 두었으면 한다. 그래서 이 경우를 회피하는 자연스러운 수단으로 PO를 채용하는 것이기도 하다.

이유 2. No라고 말하는 건 생각보다 매우 힘들다

그래서 말해줄 누군가가 있으면 좋다

조직 안에서 프로젝트는 언제나 동시에 여러 개가 돌아가기 마련이고, 서비스가 라이브로 돌아가고 있는 경우엔 유지보수 이슈로 ASAP 처리가 필요한 태스크도 수시로 생긴다. 이 경우 PM/PO는 각 스프린트에서 리소스가 들 거라고 예상하지 못했던 ‘의외의 태스크’에 얼마나 리소스를 적절히 분배하는 게이트키퍼의 역할을 해야 한다.

이 ‘의외의 태스크’가 PM이나 PO를 거치지 않고 각 조직원에게 직접 전달이 되었을 경우, 조직원들은 큰 단위의 조직에 협력하고 있다는 것을 증명하기 위해 대부분의 리퀘스트를 거절하지 않을 가능성이 크다. 이렇게 업무 플로우가 흘러가면 스프린트에서 처리되어야 하는 태스크는 ASAP이 붙은 태스크 뒤로 밀려날 수밖에 없다. 그래서 태스크의 필요성을 따져 반드시 지금 처리해야 하는 의외의 태스크만 진행을 결정하고, 다른 태스크에는 No 혹은 Hold의 결정을 내리는 사람이 필요한 것이다. 즉 PO가 오너십을 가지고 관할하는 의사결정이란 해당 조직이 맡은 태스크 자체를 넘어 태스크 매니지먼트 영역도 포함한다.

이유 3. 애매모호한 영역은 언제나 생긴다

그게 누구의 일인지 구분해줄 누군가가 있으면 좋다

아무리 마이크로 레벨로 팀을 쪼갠다고 해도, 각 도메인 사이에 애매모호하게 걸친 태스크는 반드시 생긴다. 이때 이 애매모호한 영역의 태스크를 누구든지 가져가지 않으면 태스크는 어느 순간 사라져버린다. 그렇게 미완의 백로그가 늘어간다.

기술부채라는 개념은 이제 흔히들 알고 있을 거다. 나는 이와 유사한 개념으로, 3년차를 넘기는 스타트업엔 태스크 부채가 실존한다고 생각한다. 여력이 없어서 손대지 못했거나 우선순위가 낮아서 미루거나 누가 해야 할 일인지 몰라서 어정쩡하게 ‘언젠간 하자’고 넘겨버린 일들의 산더미같은 모음 말이다.

PO는 자신의 도메인에 대한 오너십을 가지고, 주인 없는 태스크 중 적절한 것을 재빨리 주워와 조직의 태스크 부채를 줄인다. 오너십이라는 말을 떠올렸을 때 가장 많은 사람들이 생각하는, 직접적인 오너십에 해당한다. 그래서 PO가 맡는 도메인은 구체화되어있을수록 좋다. 유저 경험을 담당하는 PO보다는 온보딩을 담당하는 PO, 결제를 담당하는 PO, 기기 대응을 담당하는 PO… 와 같이 도메인을 쪼갤수록 PO가 오너십을 발휘하기도 쉬워진다. 각 도메인에 오너십을 가진 사람이 많아질수록 태스크 부채는 줄어든다. 그래서 화면별로 PO를 세우는 경우도 적지 않다.

Product Owner, 그리고 Product ownership이란 말은 거창한 개념이 아니다. 오히려 실무를 진행하며 느꼈던, 뭐라고 표현할 수 없는 갑갑함을 제거하기 위한 꽤 구체적인 아이디어에 가깝다. 조직이 어딘가 잘 굴러가지 않고 삐걱인다고 느낀다면 프로덕트 오너십을 한 번 점검해 볼 좋은 기회일 수 있다.