brunch

You can make anything
by writing

C.S.Lewis

by 김긍정 Jan 10. 2021

'환상의 팀워크'를 위한 10가지 고뇌

Good team vs Bad team  [코드스테이츠 PMB 4기]


앞서 작성한 엔터 회사가 좋아하는 프로덕트 매니저는? 글의 말미에 '끝까지 읽은 분이 있다면 본인의 경험과 의견을 나누어주세요'라고 남겼는데 정말로 어떤 분께서 장문의 메일을 보내주셨다. 

이 메일 덕분에 '브런치'에 쓸 글들에 조금 더 애정을 갖게 되었다.

'내가 되고 싶은 PM의 3가지 역할' 의견에 덧대어 보내주셨는데, 이번 포스팅은 그 중 2번째 '각자의 역할에 충실할 수 있도록 도우며'에서 좀 더 나아간 '좋은 프로덕트 팀'에 대한 개인적인 생각이다.







현직 프로덕트 매니저들이 하나같이 추천하는 PM 필독서가 한 권 있는데 책 제목은 [인스파이어드]로

부제로는 '감동을 전하는 IT 제품은 어떻게 만들어지는가?'다. 책 소개에는 다음과 같이 말한다.




최고의 기업과 팀이 일하는 방식과
나머지 평범한 기업과 팀이 일하는 방식에는 여전히 큰 차이가 있습니다.
이 고유한 차이가 모여 최고의 기술 제품을 만듭니다.



 '감동을 전하는 IT 제품은 팀이 일하는 방식에서 나뉜다'를 주제로 저자는 책에서 [Good Product Team] vs [Bad Product Team]에 대해 이야기하고 있다. 





'환상의 팀워크'와 '환장할 팀워크'. 

그 한 끗 차이는 어디에서 오는 걸까? 나는 개인이 가져야 할 [마인드셋]과 협업 시 고려해야 할 [커뮤니케이션], 프로덕트 팀의 의사결정에서 가장 우선시되어야 할 [데이터 수집]으로 생각해 보았다.



아래는 위 링크 내용의 번역본 중 내가 참고하고 싶은 부분만 편집한 것으로, 나는 팀 자체를 '좋다', '나쁘다'라고 이야기하고 싶지 않기 때문에 '팀워크'라고 표현을 바꾸고 정리했다.


#마인드셋 (개인)
1. 좋은 팀워크는 참조 고객에 집착한다. 나쁜 팀워크는 경쟁자에 집착한다.

2. 좋은 팀워크는 그들이 기대했던 아이디어가 고객에게 효과가 없을 수도 있다는 것과 검증된 아이디어 조차도 희망하는 성과 수준이 되려면 여러 번의 이터레이션이 필요하다는 것을 잘 알고 있다.
나쁜 팀워크는 로드맵에 있는 것들을 만들며 그저 만들어진 품질과 일정에 준수하는 것에 만족한다.

3. 좋은 팀워크는 혁신을 위한 새로운 아이디어를 끊임없이 시도하면서도 매출과 브랜드를 지키는 방법을 늘 고려한다. 나쁜 팀워크는 테스트를 실행하기 위한 권한을 기다리고 있다.


#커뮤니케이션 (협업)
1. 좋은 팀워크는 회사 전반에 걸쳐 현명하고 사려 깊은 리더들과 브레인스토밍 토론을 즐긴다. 
나쁜 팀워크는 외부의 누군가가 팀에 제안할 때 방어적인 자세를 취한다.

2. 좋은 팀워크는 엔지니어가 매일 제품 발견을 위한 프로토타입을 만들어 볼 수 있는 시간이 있는지 확인하고 더 나은 제품을 만드는 방법에 대한 생각을 실행해 볼 수 있다. 
나쁜 팀워크는 스프린트 미팅에서 엔지니어에게 프로토타입을 보여주고 추정을 하려고 한다.

3. 좋은 팀워크는 아이디어의 가치를 결정하기 위해 빠르게 제품 아이디어를 시도해보는 많은 기법에 능숙하다. 나쁜 팀워크는 우선순위 로드맵을 만들기 위해 미팅을 진행한다.

4. 좋은 팀워크는 비즈니스 성과에 유의미한 영향을 만들어 냈을 때 서로 축하한다.
나쁜 팀워크는 뭔가를 출시했을 때 서로 축하한다.


#데이터수집 (의사결정)
1. 좋은 팀워크는 최종 사용자 및 고객과 매주 직접 만나고 최신 아이디어에 대한 반응을 확인한다. 
나쁜 팀워크는 그들 자신이 고객이라 생각한다.

2. 좋은 팀워크는 비전과 목표, 고객 불편의 관찰, 제품을 사용하며 만들어 낸 분석 데이터, 문제를 해결하기 위해 새로운 기술을 끊임없이 탐색하는 과정을 통해 영감과 제품 아이디어를 얻는다. 
나쁜 팀워크는 영업팀과 고객으로부터 요구사항을 수집한다.




개인으로서는 본질인 고객에 집중하며 계속 프로덕트를 디벨롭시키려는 열정적인 마음을 가져야 하며

협업 시에는 눈에 보이는 결과만큼 과정을 중요시하며 서로의 업무 진도를 체크하고 효율성을 높여야 한다. 최악의 커뮤니케이션은 피드백으로 인해 기분이 상할까 걱정하느라 서로의 시간을 낭비한다는 것이다.  

마지막으로 프로덕트 팀의 의사결정은 데이터에 기반해야 한다. 데이터를 분석하는 것만큼 어려운 것은 편향되지 않도록 데이터를 수집하는 것이다. 그래야 그 데이터가 유의미하기 때문이다. 





이러한 나의 생각들을 바탕으로 미래의 내가 프로덕트 팀에 합류하게 되었을 때 조금이라도 더 올바른 PM의 역할을 하길 바라며 회고를 추가해 [내가 생각하는 좋은 프로덕트 팀워크 체크리스트]를 만들어 보았다. (열심히 고뇌한 지금의 나를 잊지 말길...)



이미지 사용 시 출처 링크를 남겨주세요 :')



끝으로 <Don't be a lawyer>의 IT 기획자 버전 영상을 첨부한다. 

수정사항 물어다 주는 부엉이가 되지 않도록... 앞으로 더 열심히 공부해야겠다고 다짐해본다.




브랜드를 사랑하는 앱등이로 시작해 제품이 아닌 가치를 파는 잡스병을 거쳐 
혁신을 꿈꾸는 프로덕트 매니저에 도전하다. 코드스테이츠 PM 부트캠프, 그 100일간의 기록
김긍정 brunch.co.kr/@positive-kim


https://youtu.be/2D1LsFPkcFs

내가 좋아하는 [크레이지 엑스 걸프렌드] 명장면. 넷플릭스에서 전 편을 볼 수 있다. (출처 : 유튜브_췌옹CHEONG)


브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari