상대방을 성장시키는 피드백의 힘

Case: '스텔스 모드'로 진행된 신사업

• IT 대기업의 핵심 인력으로 구성된 '신사업 TF'

• CEO 직속으로, 극도의 보안을 유지하며 2년간 비밀리에 프로젝트 진행

• 시장 출시 전까지 내부의 그 어떤 팀과도 협업하거나 내용을 공유하지 않음

• 팀 내부에서는 "시장을 뒤흔들 혁신"이라며 높은 기대감과 자부심을 가짐

→ 야심 차게 런칭한 첫날 → 시장의 반응은 싸늘함. 핵심 기능이 사용자가 원하는 것과 완전히 동떨어져 있음 → 가끔씩 이해가 가지 않는 형편없는 제품을 만드는 회사들은 어떤 특징이 있을까?

단합력이 좋고 분위기가 화기애애한 팀이라도 결과가 좋지 못하고 성과를 내지 못하면 그 팀을 '좋은 팀'이라 할 수 있을까? 물론 겉보기에 좋아 보이고 서로 으쌰으쌰하는 분위기로 보이지만, 결국 좋은 제품을 만들지 못하면 그 팀의 존재 의미를 증명하기 어렵다. 그렇다면 이 팀은 왜 좋은 결과물을 만들어내지 못 했을까?

다양한 원인이 있었겠지만, '객관적인 사실 판단'과 '솔직한 피드백'이 부재했기 때문이라고 본다. 제품 개발 프로세스 중에 피드백이 없었기에 딱 그 정도 수준의 결과물이 나온 것이라고 냉정하게 말할 수 있다. 제품이 성장하려면 제품 기획, 개발, 출시, 이후 운영 또는 시도와 실패에 있는 모든 과정에서 피드백이 동반되어야 성장한다는 것은 자명한 사실이다.

성공하는 조직은 직급과 상관없이 양방향 소통을 통해 피드백을 주고받는다. 실패를 자산 삼아 성장하고 더 나아가 좋은 제품을 만든다. 인간은 본래 피드백을 통해 성장하도록 설계되어 있다. 피드백을 통해 상대방의 행동이 구체적으로 어떤 역할과 작용을 하는지 그리고 무엇인지를 객관적으로 알 필요가 있다.

내가 아닌 다른 사람으로부터, 자신이기에 미처 몰랐던 미흡한 부분, 잘못된 부분 등을 파악할 수 있다. 더 나아가 그런 부분을 수정하고 보완하여 더 나은 역량들로 채워나가는 식으로 '함께 성장하는 과정'이라는 인식을 갖추는 것이 중요하다. 이는 매우 중요하다고 생각한다.

즉 제품 성공의 오너십을 갖춘 PM이라면 제품의 성공을 위해서 PM이 속한 팀 내의 자유로운 피드백 문화를 만들어야 한다.

현업에 있어, 피드백은 옳고 그름을 떠나서 "상대방의 행동이나 업무에 대한 정보를 제공하는 것"이다. 상대방의 행동이 어떤 영향을 미치고 있는지 알려주는 것이다. 앞서 말했던 것처럼 피드백을 통해 내가 알지 못했던 미흡했던 부분을 앎으로 성장할 수 있다. 명심해야 한다. 피드백은 "비판이 아니라 더 나은 결과를 만들기 위한 정보 교환 과정" 일 뿐이다.

피드백을 비판과 혼용하는 사람이 있는데, 비판은 순수하게 그 사람의 잘잘못을 따져가며 지적하고, 즉 상대방의 가치를 깎아내리는 것에 초점이 맞춰져 있다.

우리는 알 수 있다. 피드백 문화는 한국 사회에서 아직까지 자리 잡기 힘들다는 것을. 몇몇 기업 또는 개인은 피드백이 팀 분위기를 해친다고 느껴서 일부러 좋게만 피드백 하는 경우도 있기도 하다. 왜 그럴까? 피드백을 하는 것이 두려운 것일까?

피드백을 꺼리는 이유는 사람마다 다르지만, 주로 방어적 태도, 회피, 또는 역공의 태도를 갖고 있다. 왜 이런 태도를 갖게 되는 걸까? 인간이란 동물은 왜 피드백에 방어적인 걸까? 어쩌면 생존의 위협과 직결되었기 때문은 아닐까 싶다. 피드백을 비판으로 받아들이고 비판은 곧 사회적 배제라는 위험으로 인식된다. 또 우리의 뇌는 자아 이미지를 보호하기 위해 정체성을 방어해야 한다.

이로써 피드백은 단순 정보가 아니라는 것을 알게 되었다. 피드백은 때론 받아들이는 사람의 태도에 따라 정체성(Identity)에 영향을 주고, 특히 전문성이 중요한 직업일수록 피드백은 더욱 위협적으로 인식한다.

피드백은 왜 실패할까? 우리는 비판이 아니라 피드백, 상대가 더 나아졌으면 하는 바람이자 의도일 뿐인데 왜 실패할까? 우리가 좋은 의도로 피드백을 해도 전달 방식이 부적절하거나, 피드백 전달자와의 상황에 대해 맥락이나 전달자의 의도에 대한 이해가 부족하면 비판으로 받아들이는 경우가 있다. 상대방에게 피드백을 전달하기 필요한 최소한의 신뢰 관계도 없을 경우도 마찬가지다.

자 그럼 피드백을 수용하려면 어떻게 해야 할까?

위협 요소를 제거해야 한다. 피드백은 비판이 아닌 성장의 기회로 인식할 수 있도록 유도해야 하고, 구체적인 데이터를 제공하고 맥락을 설명해줘야 한다. 최종적으로 자율성을 보장해 상대방의 정체성을 지켜주어야 한다.

효과적인 피드백을 하려면, 행동과 사람에 초점을 맞추지 않고 객관적 데이터가 배경인 관찰 사실을 전달하는 관찰(Observation)과, 피드백 대상자의 행동이 불러일으킨 사실(Fact) 기반의 영향(Impact)을 설명하고, 나아가 상대방이 앞으로 어떻게 개선되었으면 하는지에 대해 실행 가능하면서도 명확한 방향을 제시하는 기대/제안(Expectation/Suggestion), 3가지 원칙이 있다.

원칙대로, 좋은 바람(의도)으로 피드백을 하면 상대방도 받아들이기 쉬울 것이다. 하지만 관건은 상대방이 그 피드백을 어떻게 받아들이는가이다. 그럼 왜 인간은 좋은 피드백도 받아들이기 어려울까?

앞서 말했던 것처럼, 자아 방어 메커니즘이 있기에 아무리 좋은 피드백이라도 비판으로 받아들이는 경우도 있다. 또는 과거 학습된 대응 방식이 '피드백 = 실수 지적', '실수 = 실패'라는 잘못된 등식이 자리 잡고 있는 경우도 있고, 피드백을 성장의 기회로 보는 성장 마인드셋이 있는 게 아니라, 오히려 개인의 역량은 타고나는 것이라는 고정 마인드셋(Fixed Mindset)을 가진 사람도 있기 때문에 좋은 피드백도 그 사람의 여건에 맞춰져 비판으로 받아들일 수도 있는 것이다.

피드백을 수용하기 위한 3단계를 제시해본다. 누군가 피드백을 해줬을때 방어적 태도를 멈추고 들어보고 인정하기(Acknowledge)와, 내가 아닌 상대방의 관점에서 바라보는 이해하기(Understand)가 있고, 피드백으로써 받은 명확한 개선 방안을 토대로 나를 개선하기 위해 구체적인 개선 계획을 세우는 행동(Act)이 있다.

그럼 PM은 PM으로서 어떻게 피드백을 해야 할까? 어떤 피드백을 해야 할까? 왜 해야 할까?

PM은 개발자, 디자이너, 마케터 등 각 역할군에 맞게 비즈니스 목표와 연계된 맥락을 제공하며 피드백을 하는 동시에, 팀으로부터 제품 방향성에 대한 의견을 받고, 개발자의 기술적 한계, 디자이너의 디자인 원칙을 소통하며 양방향 피드백 관계를 형성하고 PM 역시 피드백을 받아야 한다. 더 나아가 고객의 피드백을 수집하고 관리하며 사용자 피드백을 통한 제품 개선에 목적을 두고 제품 개선을 위해 우선순위를 팀과 의사소통하며 결정한다.

더 나아가 각 팀 구성원과 신뢰 관계를 만들 수 있고, 업무적이나 개인적으로 성장할 수 있는 1:1 미팅, 프로젝트 개발 종료 후에 각자 배운 점과 개선점을 논의할 수 있는 회고 미팅과, 각 구성원 모두에게 피드백을 받는 360도 피드백을 통해 다양한 관점에서의 피드백을 수집하여 최종적으로 PM의 자기 인식을 향상하는 데 도움이 될 수 있는 방법들을 팀 내에서 구조화해야 한다.

좋은, 또는 훌륭한 PM의 이상적 모습은 모든 구성원들의 성장을 유도할 수 있도록 코치의 역할로 나아가야 한다. 구성원들의 성장이 곧 제품의 성장을 의미하기 때문이다. 하지만 결코 코칭은 쉽지 않다. 앞서 말한 것처럼 피드백을 받아들일 준비가 된 사람이 있는 것처럼, 코칭도 코칭을 받을 준비가 되어 있는 사람에게만 가능하다. '미션팀'을 만들기 위해 '성장 마인드셋(Growth Mindset)'이 각 구성원에게 내재화되어야 하고, 서로 간 '건강한 피드백을 통해 성장하며 PM의 '코칭 일상화'를 통해 함께 나아가야 한다는 것이다.