프로덕트 오너(조직을 성공으로 이끄는)

김성한

**전반적인 느낌 **

프로덕트 오너는 작년에 이어 이번이 2회독이었다. 책 내용에 대해서는 전반적으로 내가 다니고 있는 회사에서의 workflow와 거의 90% 이상 일치하여, 내가 프로덕트 오너가 아님에도 불구하고 회사일을 하는듯한 오묘한 느낌이 들었다.

프로덕트 오너?

1회독에 이어 프로덕트 오너라는 단어는 책을 읽는 내내 마음에 들지 않았다. 직역을 하자면 프로덕트를 소유하고 있는 소유자란 것인데, 다른 직군들은 프로덕트 오너가 제시하는 가설과 비전을 실현시켜주기 위한 도구라는 느낌이 들었다. 개발자와 디자이너들은 프로덕트 오너가 아니란 말인가? 물론 책에서는 오너십을 멤버들과 공유하는 것도 큰 role이라 제시하기는 하였지만, 책을 읽는 내내 개발자와 디자이너는 스티븐이 의뢰한 일을 처리하는 사람들로 느껴졌다. 추가로, 저자가 제시하는 다른 이름인 미니 CEO란 표현도 마음에 들지 않았다.

책에서 언급된 것과 같이, 아직 프로덕트 오너라는 직군이 안정적으로 정착하지 않았고, 회사마다 그 role이 조금씩 다른 것 같다. 나의 회사 생활을 돌이켜보면, 책에 제시된 프로덕트 오너의 role과 현재 회사에서의 planner들의 role은 큰 차이가 없는 것 같다. (팀에 따라 planner와 product owner라는 단어를 다르게 혹은 혼용해서 사용하고 있는듯하다.)

또한 role은 차이가 없지만, ownership은 모두가 공유하고 프로덕트 오너 혹은 planner가 아닐지라도 kickoff meeting에서는 자유롭게 가설에 대한 피드백 뿐만 아니라 제시할 수도 있다. (실제로 kickoff meeting 때 개발자가 제안한 가설이 실제 기획에 반영된 경우도 있다.)

거창하게 프로덕트 오너라고 오너십을 독점하는 듯한 이름보다는 다양한 직무의 사람들의 의견을 종합적으로 들으면서 ochestra라고 명명하는 것이 어떨까?

실제 Google이나 Amazon과 같은 유수의 IT 기업에서조차 product owner로 검색하면 project manager의 직군에 대한 job distribution이 나온다. 또한 Amazon의 leadership principle에 따르면 개발자가 반드시 갖추어야할 역량으로 ownership이 존재한다. 하나의 비전을 맞추어가는 모든 팀원들이 프로덕트 오너라 생각하고, ochestra의 역할로서 planner가 중요하다고 생각한다.

**Ochestra는 필요하다. **

상기 ‘프로덕트 오너?’에서 나는 프로덕트 오너에 제시된 role을 부정하는 것이 아니다. 프로덕트나 서비스들을 만들어감에 있어 Ochestra는 꼭 필요하다고 생각한다. Consensus를 일치시킨다던지, Communitaction이 필요한 Skateholder들을 모은다던지. 한 때 개발자 사이에서 Consensus가 일치하지 않아 고생한적이 있었다. 특정 Feature 개발을 하는 것은 아니였기 때문에, Planner나 프로덕트 오너가 할당되지는 않았지만, 결국 내가 Skateholder를 모두 불러모아 회의를 통해 정리하고, 문서로 정리한적이 있었다. 이 과정을 통하여 Ocehstra의 필요성을 느꼈다.

팀 내에서는 ‘교통정리’ 라 표현을 하는데, 현 회사에서는 백엔드 개발자들이 주도적으로 이런 교통정리를 하는 편이 많은 것 같다.

**커뮤니케이션 능력 **

스티븐 뿐만 아니라 재직 중인 회사의 planner (혹은 프로덕트 오너) 들의 일상을 살펴보면, 정말이지 많은 사람들과 커뮤니케이션을 한다. 매번 context switching 하기도 어려울텐데, 한 사람이 다양한 프로덕트를 맡으면서 감정을 배제하며 커뮤니케이션하고 있는 부분은 타고나야하지 않을까. 나같이 하나의 일에 집중하며 깊게 파는 성격은 한계가 있지 않을까 생각해본다.

결국은…

결국 기업의 핵심가치는 고객의 니즈를 충족해주는 것이다. 프로덕트 오너뿐만 아니라 다양한 직군의 사람들이 이러한 비전하에 각자 최선을 다 해야하지 않을까. 우리 모두는 오너니까.