주니어 PM이 의견 대립에 대처하는 자세
열정적인 사람들의 의견 대립, 지극히 당연하다!
01. 의견 대립, 건강하게 활용하기
매일 크고 작은 의사결정을 마주합니다. 갖고 있는 정보를 빠르게 조합해서 타율 높은 결정을 하고 싶지만 마음처럼 쉽지만은 않습니다. 특히 결정에 관여하는 사람이 많을 때, 고려해야 하는 요인이 복잡하게 얽혀있을 때 더욱 그렇습니다. 의견이 대립하는 현상 자체는 전혀 문제가 아니라고 생각합니다. 서로 다른 의견의 오감 없이 한 명의 머릿 속에서 나온 아이디어로 뭐든 척척 결정할 수 있다면 팀플레이를 할 필요가 없으니까요. 다만 의견 대립의 현상을 건강하게 활용하는 게 중요할 것입니다. 대립'만' 있으면 결국 결정이 없고, 결정이 없으면 새롭게 나아가기 어려우니까요.
특히 PM으로서 여러 회의에 참석하고 다양한 의견을 조율하면서, 의견 대립을 어떻게 핸들링할지 고민이 많았었는데요. 고민의 기록을 남겨보려고 합니다.
02. 다수결 결정은 지양합니다
예의의 관점에서나, 역량의 관점에서나 여러 명의 의견을 청취한 뒤에 결정하는 것이 대체로 옳다는 것을 알고 있습니다. 그래서 “저는 이걸 민주적으로 결정하면 안된다고 생각해요”라는 말을 회의에서 처음으로 꺼낼 때 망설였습니다. 자칫- 의견을 수집하지 않겠다는 고집스러운 태도로 오해받기 쉬운 표현인데요, 의견 교류나 아이디어 청취는 누구나 참여할 수 있는 형태로 하되- 최종 결정의 시점에서는 모두의 참여보다, 그 사안에 대해 가장 많은 정보를 갖고 있는 한 명이 결정하고 그 결정을 팀이 최대한 서포트하는 게 필요하다는 의미입니다. 의사결정권자가 누구인지는 사안에 따라 다를 수 있고요. 정확하게 말하자면 민주적 결정을 지양하는 것이 아니라 다수결 결정을 지양하고자 하는 것입니다.
이렇게 생각하게 된 배경에는- 제품에 대한 결정은 “우리 모두의 마음에 적당히 드는 결정”이 아니라 “고객에게 더 필요한 제품이 될 수 있는 변화를 가져오는 결정”이어야 한다는 생각이 있었습니다. 물론 대부분의 구성원이 (본인의 개인적인 취향이 아니라) 고객 경험 개선의 관점에서 의견을 내지만, 서로 약간씩 다른 그 의견들을 하나도 빠짐 없이 모두 반영해서 하나의 의견으로 뭉치다보면- 결국 각 의견이 가지고 있던 고객 경험에 대한 뾰족한 아이디어까지 함께 뭉개지는 역효과가 나기도 합니다. 그래서 저는 첨예하게 대립한 사안일 수록, 제품에 대한 의사 결점 시점에서 다수결을 선택하는 것이 대체로 나쁘다고 생각합니다.
내 의견이 채택되지 않을 수 있다는 것, 여러 의견이 나왔을 때 이에 대한 최종 의사결정은 내가 아니라 다른 구성원이 하기로 약속했다는 것-을 알면서도 적극적으로 의견을 나눌 수 있는 팀이 되려면 결국 최종 의사결정에 대한 신뢰가 필요한데요. 이 때 의사결정권자의 역량에 대한 신뢰가 참 중요하고, 이를 위해서는 의사결정권자 본인과 동료 모두의 참여가 필요하다고 생각합니다.
(의사결정권자 본인) 스스로 전문성을 입증하기
(동료) 의사결정권자 동료의 전문 역량을 신뢰하기
PM은 하드 스킬로 전문성을 입증하기는 어려운 직군이라고들 하는데요. 깊게 공감하고 저도 같은 부분이 어려웠습니다. 데이터베이스 구조에 대한 결정은 개발자가, 마케팅 채널 구성에 대한 결정은 마케터가 하는 것에 이견이 생기는 경우는 거의 없습니다. 그런데 회색 지대에서 발생하는 대부분의 의견 대립은, 그 결정을 위해 어떤 전문성이 필요한지도 회색 지대에 있는 경우가 잦습니다. 즉 PM이 ‘내가 00한 역량을 갖고 있기 때문에 이 사안에 대해서는 제가 결정을 내리겠습니다’라는 당위성을 확보하는 게 쉽지 않다는 것인데요. 단순할 수 있지만- 저는 이 때 ‘제가 이 사안에 대해 가장 많은 채널에서 VoC, 데이터를 수집하는 역할’이라는 점을 어필해 신뢰를 얻고자 노력했습니다. 말로 사는 신뢰는 잃기 어렵기 때문에, PM으로서 수집한 많은 정보를 꾸준히 동료들에게 공유하면서 신뢰를 사는 게 좋은 전략이었다는 생각이 듭니다.
03. 결정 자체보다 결정에 대한 검증이 더 중요합니다
주관적인 느낌이나 직관보다는, 데이터로 보충 설명이 가능한 의견이 좀 더 설득력이 있다는 건 모두가 알고 있습니다. 그래서 대부분의 구성원이 양적/질적 자료를 최대한 확보해서 의견을 내는데요, 사실 진짜 어려운 의견 대립은- 누구도 근거를 확보하기 어려운 사안에 대한 토론인 것 같습니다. 아직 가보지 않은 영역, 우리 모두가 잘 모르는 영역에 대해 이야기할 때 그렇습니다.
물론 지금 확보할 수 있는, 대강의 데이터나 비슷한 자료로 의견에 설득력을 더하는 것도 중요한데요. 그런 시간을 무한정으로 가져갈 수는 없습니다. 그래서 이럴 때는 기존 자료를 찾기 위해 더 오래 시간을 쓰는 것보다는 지금 고민하는 안을 빨리 실행해서 새로운 데이터를 얻는 게 낫다고 생각합니다.
일전에 이런 사례가 있었습니다. 웹사이트 GNB를 개편하는 프로젝트를 담당했었는데요. 전사 여러 브랜드 간의 위계를 새롭게 설정하고, 그 위계를 사이트 탐색 구조에도 반영하는 것이 목적이었습니다. 전사 전략에 맞추어 여러 번의 논의를 거쳐 브랜드 위계가 설정되었지만 이를 눈에 보이는 요소로 제작해 공유하는 과정에서 논의 결론을 이끌어내는 것이 좀처럼 쉽지 않았습니다. '브랜드 위계'라는 개념 자체가 추상적이기도 했고 팀 차원에서도 새로운 시도였기 때문에 참고할 만한 과거 자료가 부족했습니다. 그래서 근거와 근거가 대립하는 것이 아니라 각자의 생각/의견이 대립함으로써 논의가 과하게 길어지고 있다는 생각이 들었습니다.
그래서 AB test를 하기로 결정했습니다. 전사 브랜드 전체에 영향을 미치는 건이기 때문에 이미 사전의 여러 논의를 거쳐 to-be 모습이 거의 확정이 된 상태였고, 이렇게 결론이 정해져있는 건에 대해서는 실험 없이 배포하곤 했는데요. 이미 결론이 있다 하더라도, 그 결론의 효과를 검증하는 것이 필요하다고 생각했습니다. 그래서 어떤 것이 우리를 고민하게 하는지 취합해서 실험을 설계했습니다. (ex. 메인 웹사이트 to 하위 브랜드 메인 전환율)
다만 당장 A안, B안 중 무엇으로 배포할지를 결정하기 위한 실험이 아니라 A안, B안 간의 차이를 데이터로 확보하기 위한 실험이었습니다. 브랜드 위계 변화는 단기적인 지표 개선을 위한 액션이 아니기 때문에 당장의 실험에서는 B안이 질 수도 있다고 생각했고 설령 그렇다 하더라도 장기적인 관점에서는 B안을 채택하는 것이 합리적이라고 생각했기 때문입니다. 결과적으로는- 좋은 선택이었습니다. 실험을 함으로써, 과거에는 각자의 생각으로만 의논했던 것을 지표 관점에서 검토할 수 있게 되었거든요. 더불어 각자 막연하게만 기대/우려했던 것들에 대해 분명한 결과를 확인하고 장기 전략을 서포트하는 데에 집중할 수 있었습니다. 답정너(?) 배포건에서도 실험을 활용해 의견 조율 과정을 효율화할 수 있다는 걸 배운 경험이었습니다.
03. 의견을 잘게 쪼개봅니다
서로 비슷한 얘기를 하고 있는 것 같기는 한데 어떤 이유에서인지 결론은 좀처럼 도출되지 않는 경험, 가끔 있는데요. 이 때 각자의 의견을 부분부분 떼어보는 게 도움이 되었습니다.
예를 들어보겠습니다. 전사 백오피스를 리뉴얼하는 프로젝트를 담당할 때의 일입니다. 범위가 워낙 넓은 작업이다보니 기존의 백오피스 기능을 모두 다 들고 올 수는 없는 터라- 사업 운영에 필요한 최소한의 기능들만 먼저 MVP로 배포하고 그 외 기능은 후속 스프린트에 진행하기로 결정했습니다. 다만 이렇게 범위를 구분해놓았더라도, 장기 프로젝트 중간중간 예상치 못한 변수가 (한가득) 발생했기 때문에 배포 목표일을 앞두고 한번 더 잔여 작업 범위를 재산정할 필요가 있었습니다. 그래서 이 때 MVP 요건 중 신규 시스템 없이 기존 시스템에 연결해서 사용할 수 있는 기능이 있는지를 검토했고, 상품 결제시 사용할 수 있는 쿠폰 생성/관리 기능을 그 후보로 제안했습니다. 쿠폰 생성/관리 기능 자체는 기존 시스템의 것을 사용하되, 신규 시스템에서 만든 상품을 결제할 때에도 사용 가능한 형태로 연결할 수 있는지 개발자 동료들과 논의를 시작했습니다.
예상치 못한 의견 대립이 있었고, 이 기능이 꼭 MVP에 포함되어야 하는가 에 대한 논점 재발화도 있었습니다. 기존 논점에서 벗어난 이야기들이 조금씩 나오기 시작해 결국 그 자리를 한번 정리하고 몇일 뒤에 다시 모였습니다. 다시 모이기 전에 논의 기록을 톺아보니- 제가 문제 전달에만 집중했더라면 더 나았겠다 라는 생각이 들었습니다. '어떻게' 만들 것인가에 대한 의견을 애매하게 가져간 것이 문제였습니다. 백오피스 리뉴얼 프로젝트에 기술 부채 청산의 목적도 있는데 '쿠폰 생성/관리 기능은 기존, 상품은 신규' 식으로 기존 시스템과의 연결 지점을 만들어 놓는 것이, 개발자 동료 입장에서는 결코 합리적인 해결책으로 느껴지지 않았을 것입니다.
그래서 [쿠폰 생성/관리 기능 축소 필요성]과 [축소 방법에 대한 제안] <- 이렇게 2개로 이뤄진 제 의견 중에서 [축소 방법에 대한 제안]에만 반대하고 싶은 것인데, 반대하는 과정에서 마치 기능의 축소 필요성 자체에도 의문이 있는 것처럼 서로 오해를 하게 되었던 것입니다. 의견을 쪼개보니, 서로 어디까지 합의가 되었고 어디에서부터 논의를 하면 되는 것인지 좀 더 분명하게 보였습니다.
"배포 목표일까지 시간이 별로 없으니, 쿠폰 생성/관리 기능을 기존 기획보다 축소해서 만들어야 한다!"까지 우리가 같은 생각인 걸 알고 나니- 그 후 논의는 의견 대립이 아니라 아이디어를 하나씩 쌓아서 같이 결론을 만든다는 느낌이 들었습니다. 결론적으로 쿠폰 생성/관리에 필요한 백엔드 시스템은 신규 시스템에 만들어 기존 시스템과의 연결 고리를 끊어냈고, 대신 백오피스 내 쿠폰 생성/관리 기능 프론트 작업을 MVP에서 제외(프론트 작업 전까지는, 노션 템플릿으로 쿠폰 생성 요청 받아 개발자가 제작하기로 합의)함으로써 우리에게 필요한 합의를 이끌어낼 수 있었습니다. 글도 단락이 나뉘어져 있어야 어떤 내용인지 파악하고 어디까지 읽었는지 기억해내기 쉬운 것처럼, 의견도 일종의 단락을 나누어 쪼개서 주고 받아야겠다는 생각을 하게 된 경험이었습니다.
사실 위와 같은 전략을 적용하더라도, 의견 대립은 스트레스가 있는 상황입니다. 타인을 설득하고 타인에게 납득하는 과정이 쉽지 않아요. 그렇지만 서로 다른 의견이 활발하게 오가는 것은- 우리 팀에 내가 만드는 제품에 대해 내 생각이 있고, 해보고 싶은 것이 있는 구성원이 많다는 아주 감사한 현상이기도 합니다. 그래서 잘 핸들링할 가치와 필요가 크다고 생각합니다. 알찬 의견 많이 모아 제품에 꼭 필요한 결정을 이끌어내는 역할, 잘 해내고 싶습니다. 화이팅
