좋은 아이디어에 'NO' 말하는 용기
PM의 거절은 '제품 보호'의 시작이다
PM으로 일하다 보면 하루에도 수십 번씩 "이 기능 좀 넣어주세요", "저 아이디어는 어때요?"라는 요청을 받습니다. 갓 입문한 PM에게 동료들의 이런 열정적인 요청을 거절하기란 결코 쉬운 일이 아닙니다. 모두가 좋은 의도로 제안한 것이고, 실제로 들어보면 꽤 괜찮은 아이디어인 경우도 많기 때문입니다. 하지만 PM의 가장 중요한 역량은 'Yes'를 외치며 기능을 찍어내는 것이 아니라, 수많은 '좋은 아이디어'들에 대해 단호하게 'No'라고 말할 수 있는 용기에 있다고 생각합니다.
'Yes'의 함정: 제품이 '프랑켄슈타인'이 되는 순간
만약 PM이 모든 요청에 "좋아요, 해봅시다"라고 대답한다면 어떤 일이 벌어질까요? 처음에는 팀원들이 자신의 의견이 반영된다며 좋아할지도 모릅니다. 하지만 시간이 지나면 제품은 정체성을 잃고 비대해지기 시작합니다. 이것저것 다 갖다 붙인 탓에 메뉴는 복잡해지고, 사용성은 떨어지며, 개발팀은 감당할 수 없는 유지보수 비용과 기술 부채에 허덕이게 됩니다. 우리는 이것을 '피처 크립(Feature Creep)'이라고 부릅니다.
누더기처럼 기워진 '프랑켄슈타인' 같은 제품은 결국 아무도 만족시키지 못하는 실패작이 됩니다. 따라서 PM이 거절하는 것은 상대방의 의견을 무시하는 것이 아니라, 제품의 핵심 가치를 지키고 사용자에게 명확한 경험을 제공하기 위한 '제품 보호'의 가장 기본적인 방어 행위입니다.
'데이터와 전략'에 기반한 우선순위 조정
물론 무작정 "안 돼요"라고 말하는 것은 소통을 단절시킵니다. 훌륭한 PM은 "안 돼요" 대신 "지금은 이것이 더 중요합니다"라고 말합니다. 거절의 근거를 내 주관이 아닌, 제품의 '로드맵'과 '데이터'에서 찾아야 합니다. "제안해주신 A 기능도 좋지만, 현재 데이터상 이탈률이 가장 높은 B 구간을 개선하는 것이 이번 분기 목표인 매출 증대에 3배 더 효과적입니다"라고 논리적으로 설명해야 합니다.
아이젠하워 매트릭스나 RICE 스코어링 같은 프레임워크를 활용해, 제안된 아이디어가 현재 우리 제품의 우선순위 큐에서 어디에 위치하는지 시각적으로 보여주는 것도 좋은 방법입니다. 이렇게 하면 상대방은 자신의 아이디어가 거절당했다고 느끼는 것이 아니라, 합리적인 의사결정 과정에서 후순위로 조정되었다고 받아들이게 됩니다.
거절은 곧 '가장 중요한 일'에 대한 집중
결국 PM의 'No'는 단순히 무언가를 하지 않겠다는 부정이 아닙니다. 그것은 "우리는 지금 가장 중요한 문제 해결에 모든 리소스를 집중하겠다"는 강력한 긍정의 선언입니다. 스티브 잡스는 "집중이란 '해야 할 일'에 대해 'YES'라고 말하는 것이 아니라, '하지 않아야 할 일'에 대해 'NO'라고 말하는 것이다"라고 했습니다.
이해관계자들은 당장은 자신의 요청이 거절당해 서운해할지 모르지만, 결국에는 집중력을 발휘해 성과를 만들어내는 PM을 신뢰하게 됩니다. 모든 사람을 만족시키려다 제품을 망치는 관리자가 될 것인지, 아니면 욕을 좀 먹더라도 제품을 성공시키는 리더가 될 것인지 선택해야 할 때, 주저 없이 '거절할 용기'를 내시길 바랍니다. 그것이 바로 PM이 월급을 받는 이유입니다.
