신뢰받는 PM이 되는 실질적인 방법

글에서 PM이 왜 신뢰를 얻어야 하는지 풀어가는 방식이 재밌네요.

• 개발자에게 PM은 요구사항을 좀 더 형식적인 방식으로 전달하는 경영진의 일부로 보인다.

• 경영진에게 PM은 3개월짜리 작업을 하루 만에 할 수 없는 이유나 늘어놓는 개발팀의 일부로 보인다.

• 디자이너에게 PM은 첫 번째 제품을 출시하기 위해 설계 범위를 파괴하는 불도저로 보인다.

..PM의 현실에 대한 웃픈 묘사인데 사실 저도 저러고 살고 있네요. 모두에게 죄송한 존재랄까.. 모든 미팅에서 계속 🙏🏻이러고 다니지 않나요?

이렇게 PM의 역할이 매우 모호하기 때문에 자신의 존재를 정당화해야 한다는 부담이 PM에게 계속 작용합니다. PM 기능의 다면성과 모호성은 PM을 심리적으로 끊임없이 움츠러들게 하는데요, 그걸 극복하는 방법은 동료들로부터 신뢰를 얻는 것이라고 해요. 이건 예리한 진단과 처방이네요.

PM이 전달하는 텍스트(하자/말자, 된다/안된다, 당겨라/미뤄라 등) 자체가 환영받을 요소가 부족하기 때문에 컨텍스트(누가 이 텍스트를 전달하고 있는가?)에서 긍정적인 작용이 필요한 건 완전 맞는 거 같습니다.

그럼 어떻게 동료로부터 신뢰를 얻느냐,

1. 극도의 솔직함 - 모르면 그냥 모른다고 해라. 어디서 주워듣고 아는 척하는 건 듣는 사람의 BS(개X리)감지기를 작동시켜서 오히려 반감을 산다. 특히 기술 관련해서 그렇다는 이야기.

2. 도메인 전문성 - 완벽함을 요구하는 게 아니다. 팀원들이 PM이 리드하는 제품이 해당 도메인 유저의 니즈를 충족시킬 수 있을 거라는 확신을 가질 수 있을 만큼이면 된다는 이야기.

3. 투명성 - 특정 결정이 내려진 이유, 우선순위 조율이 왜 어떻게 이뤄져야 하는지, 팀이 왜 이걸 만들고 있는지 알려주는 것이 이해관계자를 만족시키는 것이란 이야기.

4. 데이터 신뢰의 균형 - 키 매트릭을 높일 방법에만 착안해서 데이터를 보고 지표를 추구하는 게 아니라 숫자만 추구한 의사결정이 가져올 위험이나 문제점을 인지한다는 부분.

5. 제품 감각 - 요즘 저도 많이 느끼는 건데, 아무리 많은 데이터와 사용자 조사를 했어도 그게 출시 후 유저에게 환영받을지는 모른다는 거예요. 요즘 이런 정성적인 접근이 인정받지 못하는 거 같은데.. 예민한 감각이 필요하다는 생각.

6. 단호함 - 무례하다는 뜻이 아니라, 모든 사람을 만족시키지 못할 수도 있다는 것을 알면서도 자신의 주장을 할 수 있는 자신감을 의미한 건데요, 제가 좋아하는 책에 이런 구절이 있어요. "가장 결정을 잘하는 사람이란, 거기서 올 최악의 결과를 인지하고도 여전히 결정할 수 있는 사람이다"

7. 결과물 출시 - 말만, 계획만 하고 몇 달 뒤에 나올 제품을 기다리게 하는 게 아니라 지금 당장 할 수 있는 묶음을 만들어 내놓는 걸 반복하는 리듬을 만들어주는 면.

8. 약속을 지킨다 - 하겠다고 한 일은 하고, 말겠다고 한 일을 만다. PM의 화폐는 신뢰라고들 하죠?

요런 글은 항상 제 현실과 동떨어져있지만.. 거울을 보는 심정으로 읽습니다.

*원글의 respect(존경)이란 텀을 저는 신뢰로 풀이했습니다.