[번역] 5년동안 프로덕트 매니저로써 배운 5가지 원칙

---

5년동안 프로덕트 매니저로써 배운 5가지 원칙

Written By Bhavya Bansal

이미지 출처 : 원본 포스트

프로덕트 매니저로써 1년이 지난 후 나는 내가 배운 것에 대해 글을 쓰기 시작했다. 그때는 매년 이 글을 써야겠다고 생각했다.

그렇지만 미루는 것은 역사라고 말하는 것처럼 계속 미루고 쉬었다.

 

또 다른 중요한 한 해를 보내고 나서 되돌아보며 (이제는 조금 더 정기적으로 글을 쓰기를 바라면서) 지난 몇 년 간 내가 배운 가장 중요한 5가지 배움이 여기 있다.

 

1. 프로덕트 매니저의 배움 중 50%는 일하면서 일어나고 나머지 50%는 업무 외적으로 공부하는데 투자한 시간에서 일어난다.

 

우리는 보통 업무에 관련된 결과물들에 너무 관여해서 업무 외적으로 학습하는 건 중요하게 여기지 않는다. 하지만 업무와 관련 없는 콘텐츠(다른 산업, 모든 분야의 신기술에 대한 읽기/듣기)를 소비하는 것이 혁신적인 아이디어와 해결책으로 이어지는 업무의 새로운 관점을 가져오는 것을 알게 되었다.

 

어떻게 일어나는지: 우리의 현재 업무 범위는 항상 우리의 마음 속에 있고, 새로운 기술이 세상을 어떻게 바꿀 것인지, 특정 전략이 회사에 효과적이었는지/아닌지와 같은 콘텐츠를 소비하면서, 우리는 이것들을 일련의 아이디어를 통해 현재 업무와 무의식적으로 연관시키고, 아하! 하는 순간이 오는 것이다.

어떻게 하는가?
강력하게 추천되는 뉴스레터와 팟캐스트로 시작해라.
예를 들면 The Ken, The Pragmatic Engineer, The Hasrd Copy, Lenny's Newsletter&Podcast, The Product Podcast.

우선, 기본 일정에서 하루에 15분에서 30분 정도 시간을 할애해야 한다. 나는 아침 식사를 하면서 30분 정도 책을 읽는 것이 효과가 있었다.

 

2. 측정하고, 측정하고, 측정해라

이미지 출처 : 원본 포스트

뉴가 조직에서 데이터의 중요성에 대한 질문을 물어본다면 모두가 매우 중요하다고 말할 것이다.

하지만 실행에 있어서 이 주장은 대부분 립 서비스로 남아 있다.

뛰어난 기능을 찾는 투자자들, 백만 달러의 고객을 목표하는영업팀, 그리고 그렇게 갈망하던 더 높은 등급을 얻기 위해 기능 이후에 또 기능을 출시하려는 PM들의 소용돌이 속에서 우리는 종종 알 수 없는 영향력을 가진 수많은 기능을 축적했다는 사실을 간과한다.

 

투자자, 영업팀, 회사의 경영진이 효과와 수익성을 추구할 때 계속된 과제가 발생하지만, 그 길은 막막해 보인다. 상당한 시간과 자원을 투자해 철회하는 것을 망설이면서, 누적된 기능들이 너무 복잡하고 확장할 수 없는 상품이라는 결과가 되기 때문이다.

 

따라서 기능/제품 자체를 구축하는 것보다 기능/제품을 구축하는 이유를 정의하는 것이 더 중요하다.

어떻게 하는가?
a. 사전 개발 단계 : 우리가 해결하려고 하는 문제를 이해하고 이에 대한 영향을 파악하는데 많은 시간을 소비해라.

b. 제품 개발 단계 : Mixpanel, Zoho Analytics 또는 Google Analytics와 같은 기존 도구를 활용하여 영향도 측정을 위한 샘플 퍼널을 구성하는데 시간을 소비해라.

c. 개발 이후 단계 : 기능/제품 출시 후에는 추적 정확성을 확보하기 위해 2일 이내에 신속하게 데이터를 평가하고 
퍼널링한다. 그리고 이 측정을 매주 반복한다. 통찰력을 도출하고 가설을 형성하고 반복적인 변화를 만든다. 지속적으로 영향을 측정하여 계속 진행할지 아니면 되돌릴지를 명확하게 결정한다.

예외는 존재하지만, 특히 초기 스타트업이나 외부 요인과 연관된 특징에 대해서는 처음부터 지속적으로 측정하는 문화를 내장하는 것이 중요하게 남아있다.

 

3. 심층 작업을 위한 시간을 만들어라

여기에 대해서는 이전 아티클에서 짧게 언급한 적이 있다. 그러나 아직까지도 일부 PM들이 바람직한 결과를 얻지 못하는 가장 큰 이유이기 때문에 5년이 지났음에도 언급할 가치가 있다.

 

계속해서 여러 방향으로 밀려남에도 불구하고, 매일 해야하는 작업 블럭을 세팅해두는 것은 유저 리서치, 디자인 피드백, PRD, 데이터 분석의 질을 보장하기 위해서 필수적이다. 그렇지 않으면 이러한 작업들은 영구적인 소방 모드로 전환되고, 최소한의 작업만이 수행되는 결과를 가져온다.

 

PM들이 참여해야 하는 대부분의 회의는 그들이 이끄는 프로젝트와 관련되어 있지만, 심층 작업에 동일한 중요도를 할당하면서 시간을 상자 단위로 쪼개는(time-boxed = time blocking) 스케쥴링 작업은 필수적이다.

어떻게 하는가?
자비 없이 우선순위를 정하고 명확하게 의사소통하라. 예를 들어, 각 Slack 알림에 심층 작업과 빠른 응답 간의 컨텍스트 전환을 고려해서 응답한다.

 

4. 버그가 있는 배포 비용은 일반적으로 예정보다 이른 배포의 ROI보다 높다

이미지 출처 : 원본 포스트

프로덕트 매니저가 특정 날짜에 기능을 출시하도록 압박할 때마다 10센트를 벌었더라면 엄청난 부수입을 얻었을 것이다!

농담은 차치하고, 마감기한을 압박하는 것은 외부 요인이나 인위적으로 생긴 절박함에서 시작될 수도 있다. 그럼에도 불구하고 출시 전의 철저한 테스트가 마감기한을 충족하는 것보다 비중이 높다는 것을 인식하는 것은 중요하다.

첫째로, 버그를 발견하고 보고해야 할 책임을 사용자에게 부여한다. 하지만 사용자의 관점에서 생각해보자: 버그가 많은 제품이나 기능을 발견하면 즉각적인 보고가 아니라 불만을 가지게 된다. 따라서 버그를 보고하는 사용자는 제품이 매우 불만족스럽거나 예외적으로 충성도가 높은 것이다. 무조건적인 사용자 충성도를 높이는 것은 어려운 일이지만, 불만을 가진 사용자는 심각한 결과를 초래할 수 있다.

 

둘째로, 일반적으로 제품의 버그를 해결하는 데 소요되는 시간이 더 길다. 낮은 환경에서 탐지된 버그에 대해서는 개발자가 신속하게 해결하고 테스트할 수 있다. 하지만 제품 단계에서 버그가 보고되면 사용자 알림과 개발팀의 인식 사이에 지연이 발생한다. 이후 QA 팀은 새너티 테스트를 수행하고 코드 병합 및 기타 릴리스 작업을 수행한다.

자, 내 입장을 오해하지는 마라. 나는 '빠르고, 자주 실패한다'는 원칙을 굳게 믿는다. 그러나 그것은 실험적인 기능에 대한 것이어야 하고, 품질을 타협하는 구실이 되어서는 안 된다.

어떻게 하는가? 
첫째, 프로젝트를 면밀히 관찰하고 가능성 있는 모든 지연에 대해 예측한다. 팀의 차단을 해제하거나 해결을 위해 단계를 높이거나 필요에 따라 범위를 조정하여 이러한 지연을 적극적으로 사전에 관리한다.

둘째, 제 시간에 기능을 출시하는 초점을 맞추면서도 마감일을 맞추는 것보다 품질을 우선시할 때 현실적인 단점도 인식한다. 품질에 중점을 둔 의사결정을 추진할 때는 이러한 절충점을 경영진에게 명확히 전달해야 한다.

 

5. 실패는 개인적인 것이고 성공은 팀을 위한 것이다

이미지 출처 : 원본 포스트

이 글은 어디서나 읽어보았을 것이고 새로운 정보는 아닐 것이다. 하지만 프로덕트 매니저로서 이것을 강조하지 않을 수 없다.

 

프로덕트 매니저로서 제품을 엔드-투-엔드로 소유하는 것은 팀 내의 모든 결점에 대한 책임을 진다는 것이다. 직접적인 책임은 각각의 팀에게 있지만, PM은 간접적으로 책임이 있다. 실패가 오롯이 그들의 잘못은 아니지만, PM들은 종종 책임을 떠맡는데, 특히 프로젝트에 상당한 시간과 노력을 투자한 후에는 개인적으로 어려움을 느낄 수 있다.

 

반대로 제품이 번창할 때는 개발자, 디자이너, 마케터, 영업사원 등 다른 사람들이 공동으로 노력한 결과다. 프로덕트 매니저가 결정적으로 프로세스를 조정하고 중요한 비전이 일치하도록 유지하지만, 성공이 저절로 이루어지는 것은 아니다. 팀의 협력 정신, 변함없는 헌신, 그리고 집단적 전문성의 정점이다.

 

PM에게 이 균형을 조정하는 것은 분명히 힘들지만, 좋은 사람들은 좌절에 직면했을 때 회복력을 발휘한다. 그들은 실패에 대한 책임을 기꺼이 받아들이면서 팀원들의 값을 헤아릴 수 없는 기여를 인정하고 감사해 한다.

어떻게 하는가?
이를 위해서는 모든 신 제품/기능 배포에 대해 이를 실행하고 점진적으로 내재화하는 것 외에 다른 방법이 없다.