제품의 CEO가 되는 것은 내가 생각한 것과 달랐다.

저자는 처음으로 제품을 관리하게 되어 설렘이 있었다고 합니다. 한 10년이 넘는 시간이 흘렀으며 제품관리에 대한 사례나 자원들이 없었고 무슨 업무를 하는지 명확히 알려주는 곳도 없었다. 내가 알고 있는 것은 제품의 CEO가 되는 것뿐이었다.

그 기회에 대해 매우 설렜고 CEO로서 나는 팀을 성공시킬 것이었다. PM으로 고객의 니즈를 이해하고 팀이 그들에게 솔루션을 제공할 것이었다. 나는 PM으로서 CEO가 해야하는 것에 대해 해야할 것을 생각했다. 

• 큰 도전적 목표를 설정하기
• 일을 신중하게 우선순위에 따라 정하기
• 완전한 투명성으로 일하기
• 고객이 요청하는 것에 대해 다 만들지 않기

하지만 제품의 CEO가 되는 것은 책에서 읽은 규칙을 따르고 훌륭한 리더를 모방하려는 것 이상이란 것을 배웠다. 제품 관리의 모범 사례들이 매우 유용하긴 하지만 올바르게 적용되어야 한다. 내가 처음 제품을 관리하며 발견한 학습과 실제 실행 간의 차이점은 다음과 같았다.

 

큰 도전적 목표를 설정하기

내가 그 제품을 맡았을 당시 처음 본 것은 전임자가 설정했던 도전적 목표였다. 우리는 고객에게 인상을 줄 수 있는 혁신의 온라인 경험을 구축하고 있었다. 이 제품은 낮은 수준의 운영활동 부터 최고 경영진 보고서에 이르기까지 모든 것을 관리할 예정이었다. 심지어 경영진이 다른 앱을 필요로 하지 않을 슈퍼앱을 만들 계획이었다.

왜 우리는 이렇게 했냐구? 우리는 성공하는 기업들의 8가지 습관의 책에서 배운 것을 생각했고 팀에게 공격할 큰 도전적 목표를 주면 병력을 결집해 멋진 것을 만들 것이라고 생각했기 때문이다.

 

현실 : 

몇달이 지나고 이 프로젝트는 주요한 프로젝트가 아니란 것을 꺠달았다. 오래된 기술 스택을 업그레이드 하는 단순한 목표에 부가된 것이었다. 나는 팀이 기술업그레이드와 도전적 목표를 혼합하고 있단 것을 깨달았고 진행 중인 작업이 크게 증가되며 프로젝트 완성 기간이 20년에 걸릴 것 같다는 것이었다. 우리는 엔진을 업그레이드 하면서 경주용 차를 트랙에 올리려 했지만 그럴 필요가 없었다. 이들을 두개의 다른 프로젝트로 분리해 기술 업그레이드 범위를 고정하고 프로젝트 비용을 크게 줄였다. 우리의 도전적 목표는 새로운 플랫폼에서 점진적으로 개선될 수 있도록 우선순위를 매겼다.

 

일의 우선순위 정하기

프로젝트에 참여하게 되며 나는 전임자가 하던 방식 대로 우선순위를 정하기 시작했다. 그는 매우 실무적이었고 모든 달러가 효과적으로 사용되도록 하기 위해 열심히 일했다. 그래서 나는 모든 지역에 그들이 무엇을 하고 싶어하는지 물어보고 그 비용을 계산했다. 나는 기능들을 순위로 매기고 팀이 어떤 작업을 할지 결정했다. 내가 직접 모든 일을 우선순위에 따라 정함으로서, 우리가 올바른 일을 하고 있다는 것을 확실히 할 수 있었다.

 

현실 : 

몇달 후 나는 이 과정에서 문제를 보기 시작했다. 이해관계자들이 자신의 요청을 수집하고 크기를 산정하는데 노력했으나 그들은 프로젝트가 밀려나고 있다는 것에 불평하고 있었다. 더 나은 방법이 필요했고 나는 수익을 기준으로 이해관계자의 상대적 크기를 살펴보았다. 그런 다음, 수익에 따라 레벨을 나누고 이 용량을 이해관계자들에게 할당했다. 마지막으로 그들은 우선순위가 매겨진 백로그를 작성하고 자신의 용량에 따라 그 기간에 수행할 작업을 결정했다.

이 것은 이해관계자들에게 사고방식을 바꾸게 했는데, 이전에는 그들이 나와 싸우며 본인들의 점진적 필요가 다른 팀 보다 더 중요하다고 주장했는데, 이제는 그들에게 자신의 작업에 대한 100% 소유권을 부여함으로 그들은 내부적으로 원하는 것을 전달하기 위해 타협할 수 있게 되었다. 수년간 나는 이러한 교훈을 다시 배웠는데, 명확한 경계를 가진 특정 작업에 대한 소유권을 사람들에게 부여하면 내가 계속 간섭하는 것 보다 더 나은 결과물을 제공한다는 것을 알게 되었다.

 

완전한 투명성으로 일하기

각 업무를 분배할 때마다 이해관계자들에게 업무에 대한 상세한 내용을 포함한 내역을 보냈다. 여기에는 계획, 요구사항 제출, 정제, 개발, 단위 테스트 및 UAT가 포함되었다. 이 것은 우리가 애자일로 전환하기 전이며 폭포수 모델의 릴리즈를 사용하고 있을 떄였다. 

 

현실 : 

매 업무 분배 시 똑같은 패턴을 보았는데, 많은 이해관계자들로 부터 요구사항에 대한 답변이 늦어져 결국 개발 주기가 엉망이 되었다. 그들에게 미리 제공했음에도 왜 이런 일이 발생한 것일까?

너무 많은 투명성도 문제가 될 수 있다는 것을 알게 되었다. 투명성은 이해관계자들에게 내가 하는 모든 것을 보여주는 것을 의미하는 것이 아닌 그들이 알아야 하는 것을 보여주는 게 중요하다는 것이다. 내가 그들에게서 필요한 것의 목록을 살펴보며, 나는 이해관계자들에게 필요한 것에 대해 더 명확해져야 한다는 것을 알게 되었다.

나는 적시에 요구사항을 요청하는 필요성에 초점을 맞추기로 했다. 더이상 개발 프로세스의 타임라인을 보내지 않았고 요구사항 제출에만 집중한 메모를 보냈다. 이것엔 여러 중요한 날짜들이 포함되어 있었다.

* 요구사항이 제출되어야 하는 기간

* 이해관계자들에게 알림이 보내질 떄 

* 요구사항이 더 이상 받아들여지지 않는 기간(마감기한)

* 시간에 따른 현재 상황을 알려주는 유용한 RAG 차트

최종 날짜 이후에는 해당 릴리스의 용량을 상실하게 되며, 프로세스를 변경에 따라 요구사항에 대해 제때 제출되는 것을 확인할 수 있었다.

 

고객이 요청하는 것을 다 만들지 않기

나의 상사는 스티브잡스의 빅 팬이었다. 그는 스티브 잡스의 명언인 "고객에게 그것을 보여주기 전까지 본인이 원하는 것을 모른다"라는 말을 좋아했다.

그는 영업의 백그라운드를 갖고 있지만 그들에게 무엇을 원하는지 물어보지 말라고 했다. 만약 물어보게 된다면 괜한 기대감이 커질 수도 있다는 생각이었다.

 

현실 : 

나는 판매팀에게 나와 이야기하고 싶어하는 고객을 찾아달라고 요청했다. 우리가 그냥 자신의 생각을 공유하기 원하는 고객이 있음을 알게 되었다. 게다가 제품에 대한 바램 뿐 아니라 경쟁사 제품의 장점이나 단점도 알게 되었다. 또한, 고객에게 원하는 작업을 시킬 수 있다는 것도 꺠달았다. 그 당시 우리는 시스템에서 사용자 권한을 관리하는 방법을 찾고 있었다. 우리 고객 중 한명이 현재 시스템에 답답함을 느꼈고 그녀는 자신만의 해결책을 만들어 스프레드 시트로 관리하고 있었다. 나는 그녀의 새로운 시스템을 디자인 할 시 사용할 수 있었다. 도움이 되는 고객님 감사합니다 :) 

 

제품의 CEO가 된다는 것은?

CEO가 되는 것은 보다 어렵다. 나는 어릴 떄는 정말 멋진 일을 할 것이라 생각했는데 모두에게 무엇을 해야하는지 말할 수 있을 거란 생각 때문이었다. 하지만 내가 깨달은 것은 그가 단순히 30만명의 직원들에게 무엇을 해야할지 말하는 것이 아닌 내가 책임져야 할 직원들과 그들의 이야기를 들어야 한다는 것이다. 뿐만 아니라 8000만명의 고객을 행복하게 유지하기 위해 주주와 이사회 들의 이야기도 고려해야한다.

제품의 CEO가 된다는 것은 단지 책을 읽고 모범 사례를 적용하는 것이 아닌 실제로 일을 해내는 미묘한 부분이다. 잡스가 고객이 원하는 것이 무엇인지 모른다고 말했다고 해서 그가 고객의 의견을 듣지 않았단 것은 아니었단 것 처럼.

 

 

 

 

 

 

출처 : 

https://www.mindtheproduct.com/being-a-ceo-of-a-product-wasnt-what-i-thought-it-would-be/