🔗 이 글은 김영욱님이 브런치에 올린 아티클을 요약한 글입니다.
불확실성이 가득한 비즈니스 세상에서 PM/PO가 의사결정할 때 꾸준히 주의하고 극복해야 하는 4가지 인지편향을 소개합니다.
1. 확증 편향 (Confirmation Bias)
- 가장 흔향 편향입니다
- 자신이 옳다고 여기는 정보만 받아들이고 신념과 일치하지 않는 정보는 무시하는 경향
- 검색, 추천 콘텐츠에서 개인화가 발달하면서 내 신념과 연관된 정보나 광고가 지속적으로 노출되면서 확증 편항은 더 빠져나오기 힘든 성향을 가집니다
- 사용자에게 던지는 질문을 내가 옳다고 생각하는바를 유도하는 문장으로 만들 수 있습니다
- 대시보드의 지표가 편향되어 설정될 수도, 여러 지표 중 긍정적인 지표만 사용하게 될 수도 있습니다
💪 확증 편향을 극복하는 방법
- 편향을 가지고 있다는 사실을 늘 인식합니다
- 유도 질문을 철저하게 피합니다
- 여러 이해관계자로부터 균형된 피드백을 받습니다
- 목표치 설정을 각 팀 리더와 함께 셋팅하거나, ‘왜’에 대한 배경을 설명하고 의견을 구합니다
- 매 결정 시 ‘What’이 아닌 의사결정이 필요했던 ‘Why’를 충분히 만족하는지 리뷰합니다
📝 노트
- 확증 편향을 극복하기 위해서는 먼저 반대되는 의견에 충분히 리서치하거나 노출될 필요가 있고, 반대되는 의견이 충분히 설득력 있다면 내 의견을 바꿀 수 있는 유연성을 가지고 있어야 합니다.
- 이러한 마인드셋을 ‘Strong views, Wealky held’ 라고 합니다.
- Strong views, Wealky held에 대한 아티클을 첨부합니다
2. 매몰비용 오류 편향 (Sunk-cost Fallacy Bias)
- 이미 투자한 시간, 노력, 비용 때문에 미래의 불확실한 결과를 예상함에도 투자와 작업을 지속하고자 하는 편향입니다
- 손실 회피(Loss Aversion) 경향이 이런 편향을 만들어냅니다
💪 매몰비용 오류 편향을 극복하는 방법
- 간단하지만 가장 근본적인 지표가 될 수 있는 질문에 답변할 수 있는지 스스로 물어봅니다
- 만약 전사가 목숨을 걸어야 하는 상황에도 동일한 결정을 할 것인가?
- 기존 코드가 모두 날아가서 없어졌음에도 같은 방법으로 코드를 유지보수 할 것인가?
- 내 동료가 진행하는 프로젝트에도 내가 그 방법이 옳다고 해줄 수 있을 것인가?
📝 노트
- 매몰비용을 생각하지 않는 방법의 핵심은 지금까지 발생한 비용이 0이라고 가정하는 것입니다
- 지금부터 들일 노력과 노력에 따르는 이후 발생 가능한 이득만 객관적으로 비교하는것이 필요합니다
3. 이케아 효과/편향 (IKEA Effect/Bias)
- 본인이 직접 만든 제품에 대해 실제보다 더 큰 가치를 부여한다는 편향입니다
- 내가 노력을 기울였다고 해서, 투자를 했다고 해서 꼭 그 제품/서비스가 성공하지는 않습니다.
- 위 ‘매몰비용 오류 편향’과 이어져 내가 이만큼 노력을 했으니 그 노력만큼 성공적이지 못한 것은 다른 탓이라고 원인을 돌리게 됩니다
- 자신의 성과에 자부심을 갖는 것은 당연하지만, 노력과 투자부분이 제품과 서비스의 결과보다 강조되는 부분은 경계해야 하는 편향입니다
💪 이케아 효과/편향을 극복하는 방법
- 내가 PM으로서 개발/디자인/지원팀 간 적절한 조율을 하고 있는지 항상 체크합니다
- 올바른 성과 지표를 프로젝트 시작에 맞춰 준비하고, 지속적으로 리뷰합니다
- 팀 간의 우위를 경쟁하는 것이 아닌 제품/서비스를 성공시킨다는 공통의 목표를 꾸준히 자주 주지시킵니다
- 우리 팀 결과물을 다른 팀에 제공하는 등 크로스 레퍼런스를 적극 활용하고, 경쟁 제품/서비스에 대한 분석을 본인의 고객/사용자 관점에서 진행해봅니다
4. 오류 합의 편향 (False-Consensus Bias)
- 내가 생각하고 행동하는것 처럼 다른 사람도 생각하고 행동할 것이다라는 ‘오류 합의’를 하는 편향입니다
- 이 편향을 가지는 경우 본인이 생각한 UX Flow대로 모든 사용자/고객이 이용할 것이라고 생각 됩니다
- 이 편향이 발전하게 되면 우리의 생각과 다른 생각이나 아이디어를 가진 사람들을 배제하거나 무시하는 현상이 나타납니다
💪 오류 합의 편향을 극복하는 방법
- 본인의 목표를 항상 명확히 리뷰하고 팀 멤버들과 함께 리뷰합니다: ‘이 제품/서비스/기능은 고객/사용자에게 과연 합당한 것인가?’
- 고객/사용자에게 내 목표를 설명하고 그것이 맞는지 확인합니다
- 제품/서비스가 만들어지는 과정에 다양한 사용자군과 프로덕트 팀간의 피드백 프로세스를 통해 상호 생각의 오차를 줄여나갑니다