🧡 | PM이 주의해야할 의사결정편향 | 패스트캠퍼스 PM부트캠프 2기

 저번 포스팅에서 언급했듯이, 프로덕트매니저는 협업 부서 관계자들과 긴밀히 소통하며 실현 가능한 계획을 세워야 한다.
 또한, 데이터를 기반으로 우리의 프로덕트가 올바른 방향으로 가고있는지, 끊임 없이 자문하며 프로덕트의 모난 점들을 깎아냄으로 결국엔 고객이 원하는 서비스의 형태로 나아가야한다. 하지만 이러한 역할을 수행해야하는 PM이 편견을 가진다면, 프로덕트는 점점 역행하기 마련이다. PM이 의사결정을 할 때에 아래의 4가지 편향들을 주의하며, 주관적인 생각들과 미련들을 정리해나아가야한다.

---

 

 

| PM이 주의해야할 의사결정 편향 4가지

1. 확증 편향(Confirmation Bias)

• 자신이 옳다고 생각하는 것에만 정보를 받아들이고, 신념과 일치하지 않으면 받아들이지 않는 것
• 내가 전문가 영역에 들어갔다고 생각하는 순간부터, 나의 의견을 뒷받침해줄 의견만 찾는 경향이 있음
• 나의 의견이 틀렸다는 의견을 받아들이지 않음
• 고객 대상 설문조사를 할 때에도 영향을 미침
  • 이미 사용자나 고객에게 전송한 설문지 안에 편향된 질문으로 원하는 답변을 유도 하는 경우

확증편향을 피하는 연습

• 나는 편향을 갖고 있다는 사실을 늘 인식하고, 받아들이기
• 사용자 리서치 / 서베이 / 피드백 질문 시 반드시 대답의 스코프를 제한하는 유도질문을 철저하게 제한
• 여러 계층을 대표하는 고객 / 사용자 / 동료 / 관계자로부터 균형된 피드백을 받기
• 목표치 설정을 팀 리더들과 함께 셋팅을 하거나, PM이 직접 리더들에게 "why"에 대한 배경을 꼭 설명하고 의견을 구하기
• 매 결정 시 "what"이 아닌 이 결정이 필요했던 배경 "why"를 충분히 만족하는지 리뷰하기

---

 
 
| PM이 주의해야할 의사결정 편향 4가지

2. 매몰비용 오류(Sunk-cost Fallacy)

• 불확실하고도 승산도 없어보이는데 지금까지의 매몰된 비용 때문에 미래에 대한 부정적인 결과를 예상함에도 불구하고 투자와 작업을 지속하는 것
• 지속적으로 정당성을 부여하여 비논리적으로 작업하는 것

매몰비용 오류를 피하는 연습

• 만약 지금 이 제품 / 서비스에 전사가 목숨을 걸어야 하는 상황이어도 이런 결정을 할 것인가?
• 기존의 코드가 모두 날라가서 없어졌음에도 이런 방법으로 코드를 유지보수할 것 인가?
• 내 동료가 진행하는 프로젝트임에도 내가 그것이 옳다고 해줄 수 있는가?

---

 
 
| PM이 주의해야할 의사결정 편향 4가지

3. 이케아 효과(IKEA Effect)

• 일반적으로 사람들은 본인이 직접 만든 제품에 대해서는 실재보다 더욱 큰 가치를 부여한다
• "내가 노력을 이만큼 기울였으나, 이번에 성공하지 못한 것은 환경 탓이다"
• 우리팀이 만든 코드를 비논리적이고 배타적으로 옹호하는 관대함
• 자신의 성과에 자부심을 가져야하는 것은 맞지만, 제품의 경쟁력과 마켓쉐어가 더 중요하다

이케아 효과를 피하는 연습

• 내가 PM으로서 개발 / 디자인 / 지원팀 간 적절한 조율을 하고있는지 항상 체크하기
• 올바른 성과지표를 프로젝트 시작에 맞춰 준비하고, 지속적으로 리뷰해야 함
• 팀 전체가 팀 간의 우위를 경쟁하는 것이 나닌 제품 / 서비스를 성공시킨다는 공통의 목표를 꾸준히 주지시키기
• 우리 팀의 결과물을 다른 팀에게 제공한다던지 하는 크로스 레퍼런스를 적극 활용하고, 타사의 경쟁제품 / 서비스에 대한 분석을 본인의 고객 / 사용자의 관점에서 진행해보기

---

 
 
| PM이 주의해야할 의사결정 편향 4가지

4. 오류합의 편향(False-Consensus Bias)

• 내가 생각하고 행동하는 것 처럼 다른 사람도 그럴 것이다 라고 착각하는 것
• 팀 모두가 이렇게 생각하면 아닌 생각을 가진 사람이 배제당할 수 있다
• PM으로서 치열하게 고민해야하는 이유는 다른 이해관계들의 공통함수를 담는 것이다

오류합의 편향을 피하는 연습

• PM 본인의 목표를 항상 명확히 리뷰하고 팀 맴버들과 함께 리뷰
• 이 제품 / 서비스 / 기능은 고객에게 과연 합당한 것인가?
• 고객에게 내 목표를 설명하고 그것이 맞는지 확인하는 절차를 갖기
• 제품 / 서비스가 만들어지는 과정에 다양한 사용자군과 프로덕트팀 간의 피드백 프로세스를 명확하게 디자인하여 서로 간의 생각의 오차를 줄이기

---

 
 

강사님께서 "다양한 사람들의 교집합을 찾는 것이 중요하다"고 강조하셨다.
요즘은 특히 정해진 유행에만 따라가던 시절(노스페이스 군단, 스키니진 등-)이 아닌, 다양성이 인정되는 시기인 만큼
다양한 사람들의 의견(특히 소수의 사람들의 의견)들에도 세심하게 반응하며 최대한 다수가 공감할 수 있는 프로덕트를 향해 가는 것이
지금 이 시대 프로덕트 매니저의 덕목이라 생각된다.