제품 배포하기 바쁜 우리, 제품 발견은 언제 하나요?
구조적 한계 속에서 제품의 '진짜 기회'를 찾는 PM의 현실적 고민
제품을 '만드는 것'과 '발견하는 것' 사이에서
혹시 테레사 토레스(Teresa Torres)라는 이름을 들어보셨나요? 프로덕트 관리 분야에서 꽤 유명한 코치이자 작가입니다. 그녀는 PM의 업무를 크게 두 가지 축, 즉 제품 발견(Product Discovery)과 제품 배포(Product Delivery)로 나누어 설명합니다.
쉽게 말해 Delivery가 "주어진 기능을 일정에 맞춰 잘 만드는 것"이라면, Discovery는 "도대체 무엇을 만들어야 고객에게 진짜 가치를 줄 수 있는지 찾아내는 과정"을 뜻합니다. 토레스는 이 두 가지가 끊임없이 순환해야 한다고 강조하죠.
이론적으로는 참 멋진 말입니다. 하지만 저를 포함한 많은 PM 분들이 현업에서 느끼는 감정은 조금 다를 것 같습니다. "좋은 건 알겠는데, 당장 이번 스프린트 배포도 벅차다"는 현실적인 한숨이 먼저 나오니까요. 저 역시 최근 업무를 돌아보니, 정해진 기능을 구현하는 Delivery에만 너무 많은 에너지를 쏟고, 정작 중요한 Discovery에는 소홀했던 것은 아닌지 반성하게 되었습니다.
왜 우리는 '배포'에 더 집중하게 될까?
처음에는 제가 게으르거나 요령이 부족해서라고 생각했습니다. 하지만 곰곰이 생각해 보니, 이는 개인의 문제라기보다 조직이 작동하는 구조적인 문제와도 깊게 연관되어 있다는 생각이 들었습니다.
대부분의 기업은 1년 단위로 인사를 평가합니다. 그리고 우리는 OKR(Objectives and Key Results)과 같이 명확하고 측정 가능한 목표를 세우죠. 측정 가능하다는 것은 역설적으로 '불확실성'을 싫어한다는 뜻이기도 합니다. Discovery는 본질적으로 불확실한 가능성을 탐구하는 과정이라 당장의 성과로 증명하기 어렵습니다.
반면, Delivery는 명확합니다. "기능을 출시했다"는 사실 자체가 눈에 보이는 성과(Key Result)로 인정받기 쉽습니다. 그러다 보니 자연스럽게 우선순위는 '불확실한 탐색'보다 '확실한 구현'으로 쏠리게 됩니다. 예측 가능한 업사이드(Upside)를 달성하는 것이 조직 입장에서는 안전한 선택이니까요.
'답'이 정해져 내려오는 Top-Down의 딜레마
이런 구조 속에서 목표는 종종 '해결해야 할 문제'가 아니라, '구현해야 할 솔루션'의 형태로 내려오곤 합니다. 리더십 그룹이나 의사결정권자(이른바 Hippo)가 이미 "이 목표를 달성하려면 이걸 만들어야 해"라고 방법을 정해서 제안하는 경우죠.
PM으로서 커리어가 쌓일수록 이 지점이 가장 고민스러웠습니다. 위에서 내려온 제안을 받으면 생각의 틀이 딱 그만큼으로 제한되더군요. 그 제안을 어떻게 하면 잘 만들까만 고민하게 되고, "이게 최선인가?"라는 질문은 생략되기 쉽습니다.
하지만 리더의 의견에 맹목적으로 따르기만 해서는 제품이 폭발적으로 성장할 기회를 놓칠 수 있습니다. 그렇다고 근거 없이 반대만 할 수도 없는 노릇이죠. 이 사이에서 저는 저만의 현실적인 대안을 찾아보게 되었습니다.
현실적인 PM의 생존법: '선택지'를 늘리고 '연결'하기
저는 이 딜레마를 선택지를 늘리는 방식으로 풀어가 보려 노력하고 있습니다.
리더의 의견(Top-Down)이 내려오면, 그것을 절대적인 정답이 아니라 하나의 선택지로 생각하는 것입니다. 그리고 저는 주말 아침이나 개인 시간을 쪼개서라도 업계 동향을 살피고 데이터를 뒤져봅니다. 그렇게 얻은 인사이트로 또 다른 선택지들을 기계적으로라도 더 만들어 봅니다.
그리고 리더와 논의할 때, 이 선택지들을 동일 선상에 놓고 비교합니다. 이때 중요한 것은 설득의 화법이었습니다. "당신의 생각이 틀렸고 내 생각이 맞다"가 아니라, "당신의 의도와 목표를 실현하기 위해 고민해 보니, 당신의 아이디어를 더 구체화하고 발전시킨 이런 대안들도 있더라"는 맥락으로 연결하는 것입니다.
이렇게 접근했을 때, 리더는 자신의 의견이 존중받았다고 느끼면서도 새로운 대안에 대해 훨씬 개방적인 태도를 보여주었습니다. 결과적으로 조직의 목표를 달성하면서도, 제가 발견한 Discovery의 가치를 녹여낼 수 있었습니다.
일단 달려보고(Try), 다시 맞추기(Sync)
물론, 아무리 논리적으로 준비해도 리더의 직관이나 상위 컨텍스트를 이기지 못할 때가 있습니다. 제 Discovery 결과와 리더의 지시가 충돌할 때죠.
그럴 때 저는 "일단 해보겠습니다(Try)"라는 태도를 취하는 편입니다. PM이 알지 못하는 리더만의 시야와 책임감이 분명히 존재하기 때문입니다. 공감이 안 되더라도 일단 그 목표에 몰입해서 수행해 봅니다.
재미있는 건, 일단 실행에 옮기고 나면 구체적인 경험과 데이터가 쌓인다는 점입니다. 머릿속으로만 싸우던 때와는 다릅니다. 그 경험치를 가지고 다시 리더와 싱크업(Sync-up)을 하면, 이전보다 훨씬 객관적이고 생산적인 대화가 가능해집니다. 어쩌면 이것이 조직이라는 거대한 배 위에서 PM이 균형을 잡으며 나아가는 가장 현실적인 방법이 아닐까 합니다.
마치며
연차가 찰수록 PM에게 기대하는 역할은 단순히 '잘 만드는 사람'에서 '무엇을 만들지 결정하는 사람'으로 확장되는 것 같습니다. Delivery의 압박은 여전하지만, 그 안에서 틈틈이 Discovery의 불씨를 살리는 것이야말로 저의 성장을 위해, 그리고 제품의 진짜 도약을 위해 꼭 필요한 과정임을 깨닫습니다.
오늘도 수많은 기능 명세서와 일정표 사이에서 고민하는 동료 PM 분들께, 저의 이 작은 시행착오와 생각이 조금이나마 공감이 되고 위로가 되었으면 좋겠습니다. 우리는 시키는 대로 만드는 사람이 아니라, 함께 답을 찾아가는 사람이니까요.
