조직의 동의를 얻는 법

https://pixabay.com/en/paper-business-finance-document-3213924/

제품 담당자의 역할 중 가장 기본적이면서 동시에 가장 어려운 것 중 하나가 다양한 이해관계자들의 복잡한 관계들을 조율하고 설득하여 제품을 앞으로 끌고 나아가는 것이다. 실리콘밸리는 부서 간의 협업으로 팀이 구성 및 진행되고 (cross-functional, XFN 이라고 흔히 지칭), 제품 담당자들이 이런 협업 팀원에 대한 직접적인 권한이 없는 경우가 대부분이라 이해관계자들의 상충된 목표를 조율하는 것이 어지간히 어려운 것이 아니다. 더욱이 전략적 중요도 및 복잡도가 높은 제품을 담당할수록 다양한 부서의 높으신 분들의 ‘좋아요’까지 받아야 하는데, 이러다 보면 제품 출시일은 멀어져 가고 팀원들은 기가 빠지며 결국엔 모두가 제품 담당자를 원망하기 시작한다. 즉, 한번 꼬이기 시작하면 완전 총체적 난국. ㅠㅠ

이런 상황을 모면하기 위해서 제품 담당자는 조직의 동의를 얻는 시간을 최소화하는 것에 노력을 기울여야 한다. 조직 구성원 및 의사결정권자들의 ‘오케이’를 받는 방법은 사람마다, 또 조직 특성 마다 다르겠지만 다음은 내가 많은 시행착오를 거치며 터득한 몇 가지 ‘빠르게 동의에 이를 수 있게 하는 기법’들을 정리 및 공유:

기본 (default) 상황을 yes로 설정하고 이해관계자들에게 반박을 하도록 포지셔닝 하기

나는 예전에 이메일 상으로 어떤 안건에 대한 동의를 구할 때 그 내용에 대해 설명을 하고 ‘이렇게 해도 괜찮나요?’ 라고 묻곤 했다. 이런 경우는 이메일 수신자가 ‘오케이’라고 답변을 하지 않는 이상 기본 상황이 ‘안됨’이다. 행여나 안건에 동의를 전적으로 한다고 해도 답변이 오지 않으면 일을 진행할 수 없는 상황이기에 시간을 낭비하기 일쑤다.

요즘엔 많은 경우 ‘위 안건을 진행할 예정이니, 피드백 및 기타 의/이견 있으시면 알려주세요’ 식으로 이메일 스타일을 바꾸어 쓰고 있다. 이 경우엔 내가 강력하게 안건을 특정한 방향으로 추진하고 있다는 자신감을 수신자에게 전달할 수 있고, 동시에 ‘잘 진행되는 일인 것 같은데 정말 큰 문제가 있는 것이 아니면 굳이 꼬투리 잡을 필요 없지’식의 심리를 자극시켜 그들이 동의하는데 영향력을 끼칠 수 있다. 이런 적극적인 포지셔닝은 이메일 답변이 오지 않은 상황에서도 ‘암묵적 동의’라고 우길 수 있는 장점도 있지만, 상대방의 기분이 상할 가능성을 고려해 ‘이견이 있으시면 다음 주 수요일까지 답변 주세요’ 식으로 타임라인을 정해주면 예의마저 챙길 수 있다.

이해관계자 중 의사결정권자인 사람과 아닌 사람을 구분하기

이해관계자들 모두가 의사결정권자가 아니다. 예를 들어 신제품 출시 결정을 할 때 PR 부서는 그 제품에 대한 홍보 및 예상되는 질문/논란에 대한 대응을 제품팀에게 지원을 해 주는 역할을 수행해야 하기에 이해관계자 이지만 의사결정권자는 아니다. 즉, 예상되는 문제가 있다면 PR 부서는 제품 팀에게 그 문제의 위험성을 알리고 강력한 제품 출시 지연 권고는 할 수 있어도, 그 위험성을 이유로 제품 출시를 막을 수 있는 권한이 있는 것은 아니다. 이런 의사결정권이 없는 이해관계자들의 ‘소음(?)’을 줄이기 위해선 동의를 반드시 받아야 하는 의사결정권자들과 그들의 결정으로 인해 영향을 받는 순수 이해관계자들을 구분하고 그들의 요구를 다르게 받아드릴 수 있어야 한다.

이메일로 동의를 구하는 경우 To 에 의사결정권자를 열거하고 나머지는 Cc로 처리한 후 의사결정권자들을 직접 호명하여 그들의 동의를 구하는 방법이 꽤 괜찮은 전략이다 (예: Peter, please approve this plan) . 물론, 이것은 의사결정권이 없는 이해관계자들의 의견을 무시하라는 것이 절대 아니다 (그랬다간 제품 담당자로써 처참히 실패하는 지름길). 반드시 사전에 이해관계자들의 의견 취합 및 조율은 하되, 최종 의사결정에 있어서 최단거리의 길을 (= 의사결정을 해야 되는 사람들 관여) 택하라는 것이다.

짧은 주기의 업데이트를 통해 작은 변화에 대한 동의를 반복적으로 구하기

제품 담당 멘토링을 받으면 가장 자주 듣는 ‘제품 담당자들의 가장 큰 실수’가 있는데, 사무실 구석에서 몇 주 간 고생해 너무나 완벽하고 멋진 제품 제안서를 써 왔더니 그 모두가 무시하고 코드 한 줄 쓰여지기 전에 폐기되었다는 이야기다. 아무리 멋진 아이디어라도 조직에 공감대를 형성할 수 없으면 실현 가능성이 0으로 수렴 되기에, 제품 담당자는 제품에 대한 비전과 아이디어 만큼 그것을 구현할 수 있는 공감대 형성에 많은 시간을 투자해야 한다.

이럴 때 효과적인 것이 짧은 주기의 업데이트를 이해관계자들과 자주 하는 것이다. 잦은 만남을 가지면 동의를 해야할 부분들을 각개 격파를 할 수 있는 여지가 생긴다. 작은 부분들 하나 씩 의/이견을 취합하여 조율하고 동의에 이르는 과정을 반복하다 보면 (= agile한 공감대 형성) 큰 그림이 완성되는 상황에 더 쉽게 도달할 수 있다. 간단히 말해 개구리를 상온의 물이 담긴 냄비에 넣고 서서히 열을 가하는 것과 뜨거운 물을 갑자기 부어 화들짝 놀래키는 것의 차이인 것이다.

어느 크기의 변화가 동의를 얻기 더 쉬울까?

이해관계자들의 의/이견이 blocker인지 strong opinion인지 구분하기

만약 이해관계자들의 의/이견이 없다면 빠르게 동의에 이를 수 있겠지만, 다양한 의견의 충돌 및 정-반-합의 과정은 더 좋은 결과를 가져다 주는 건강한 스트레스이기에 무조건 다른 의견의 형성을 막는 전략을 택하는 것은 어리석은 일이다. 또 현실적으로도 중요한 안건의 의사결정 과정에 있어서 이해관계자들의 의/이견이 없을 수 없다. 결국 중요한 것은 이런 의견들을 빨리 취합하여 조율하는 것인데, 이것을 효율적으로 처리하는 방법 중 하나가 그들이 제시한 의견이 blocker인지 strong opinion인지 확인하는 것이다. Blocker란 제시한 문제점을 해결하지 않으면 해당 안건을 진행시킬 수 없다는 것이고 strong opinion이란 말 그대로 당사자의 (강한) 의견이라는 것인데, 의견을 이 두 가지로 분류한 후 blocker를 위주로 문제를 해결하면 많은 시간과 노력을 아낄 수 있다.

아까 위의 예를 다시 들어, 어느 제품을 출시할 때 높은 가격 책정으로 인해 부정적인 언론이 우려되어 단가를 인하할 수 있을 때 까지 출시 유보를 주장한 PR/마케팅 부서가 있다고 가정하자. 이런 경우 제품 담당자는 해당 부서에게 blocker인지 strong opinion인지 구분해 달라고 요청하고, 부정적인 언론이 제품 수요에 지대한 영향을 끼쳐 사업 성과에 문제가 있을 것 같기 때문에 blocker라고 답변을 받으면 재고를 하면 되고, 반면 부정적인 언론이 지금 상승 중인 회사 선호도 이미지에 누를 끼칠 수도 있을 것 같다는 생각이 든다고 답변을 받으면 (대체적으로, 특히 데이터가 없을 경우) strong opinion으로 취급하고 넘어가면 되는 것이다. 이 상황에서 blocker가 아니라고 의견을 폐기하는 것 보다 다음 버전 혹은 추후 집고 넘어가야 할 상황으로 명시하고 나중에 까먹지 않고 처리한다면 협업 관계를 더 돈독하게 할 수 있는 이상적인 상황까지 만들 수 있다.

나도 최근에 큰 변화와 논란이 수반되는 프로젝트 몇 개를 수행하면서 이 기법을 많이 사용하기 시작했는데 , 내가 담당하는 제품과 관련하여 받은 80%의 의견들은 blocker가 아니었다. (상상해보라, 그 80%가 blocker인 줄 알고 다 대응하고 전략을 수정하였으면 걸렸을 추가 시간과 노력을…😱)

.

아무리 위 기법들이 그럴 듯 하게 들려도 사실 모두의 동의를 빠르게 이끌어 내는 것은 정말 어려운 일이다. 그렇다고 동의를 얻지 못해 프로젝트를 진행시키지 못했다는 것은 제품 담당자의 변명이 될 수 없다. 제품 담당자는 그 제품의 성공에 최종 책임을 지는 사람이기 때문이다. 어떻게 보면 동의를 얻지 못했다는 핑계는 제품 담당자로써 능력이 없다는 뜻일지도 모른다. 정연한 논리, 제품에 대한 뜨거운 열정, 자신의 주장을 뒷받침 해 줄 수 있는 데이터, 그리고 위 기법들 + alpha를 총 동원하여 조직의 동의를 얻고 제품을 성공의 방향으로 계속 끌고 나가야 한다. (Aㅏ… 힘들어 ㅠㅠ)

프로덕트 매니저 개론

작년 이 맘 때 쯤 ‘프로덕트 마케터 개론’이라는 글을 통해 프로덕트 마케팅 직군에 대한 글을 쓴 적이 있는데, 어느새 그 화려한 마케터의 삶을 접고 제품 담당자로 커리어를 전환한지 거의 일 년이 되어간다. 사업을 전반적으로 총괄하는 업무를 수 년 동안 해 오면서 제품에 관여를 많이 해 왔지만 회사 연구개발 부서에서 엔지니어들과 머리를 맞대고 제품을 hands-on으로 담당해서 만드는 일은 지난 일 년이 처음. ‘직접 경험해 보지 않으면 아는 척 하지 마라’는 말에 너무나 공감이 가는 것이, ‘위에서’ 업무를 조율하고 지시하는 것과 실제로 내가 ‘현장’에서 무엇을 만들어 낸다는 것은 하늘과 땅 차이라는 것을 뼈저리게 경험하였다. 이런 경험을 통해 제품 담당자가 무엇을 하는 사람이고, 또 훌륭한 제품 담당자에서 돋보이는 성향들을 관찰하고, 습득하고, 정리할 수 있는 기회가 되었다

주의: 이것은 나의 제한된 경험을 바탕으로 정의 된 것이고, 실제로 회사마다 제품 담당자의 정의 및 역할이 다르기 때문에 아래의 내용을 ‘canonical definition’으로 받아드리면 곤란 하다는 것을 미리 공지함.

제품 담당자란? (Who is a product manager?)

“Product Manager is the ultimate person responsible for the success of the product — he/she makes the ‘magic’ happen.”

간단히 말해 제품 담당자는 해당 제품의 전반적인 성공을 책임지는 사람이다. 어느 ‘무엇 (what)’으로 ‘누구 (who)’에게 가치를 제공하는 일을 하고, 그 결과에 따라 성과를 평가받는 직군이다. 제품의 성공 여부를 최종적으로 책임지는 역할이기에 ‘CEO of the product’이라고도 하지만 CEO와 다르게 제품 담당자들을 제품에 관여하는 사람들에 대해 인사권이 전혀 없는 ‘이빨 없는 호랑이’이다. 엔지니어들은 제품 담당자가 원하는 기능을 복잡하고 기술적으로 멋지지 않다고 무시하면 그만, 프로덕트 마케터들이 제품 담당자가 정의한 고객 페르소나 밖의 타겟층에게 마케팅을 해도 제품 담당자가 딱히 할 수 있는 것을 별로 없다. (특히, 그 마케팅을 통해 매출이 확 늘어난다면 더더욱!)

오히려, 제품 담당자는 미식 축구의 ‘쿼터백’과 더 유사하다고 할 수 있을 것 같다*. 미식 축구에서 쿼터백은 공을 남에게 건내 주거나 패스를 통해 팀이 전진하도록 하는 업무를 가진, 팀에서 가장 주목받고 중요한 포지션이다. 쿼터백은 스냅이 이루어지면 재빨리 어디가 막혔고 어느 선수가 공을 받을 수 있는 위치에 있는지를 파악하여 의사결정을 해야만 한다. 제품 담당자도 제품의 개발 및 출시에 있어 여러가지 난관을 재빨리 파악하여 팀이 성과를 낼 수 있도록 신속한 의사 결정을 해야한다. 게다가 감독처럼 ‘지시’를 내리는 것이 아니고 동료 엔지니어와 함께 데이터를 보면서 직접 (hands-on) 이런 결정을 내려야 한다. 그리고 결정적으로, 쿼터백은 경기를 이기면 팀을 대표해서 주목을 받고 지면 팀을 대표해서 욕을 먹는데, 이 역시 제품 담당자의 역할과 일맥상통한다. 비록 제품 담당자가 코딩 한 줄 하지 않았지만 그것에 대한 책임을 지는 것이다. (심지어 칭찬을 받으면 팀에게 공을 돌리고, 욕을 먹으면 혼자 짊어지는 미덕도 역시 비슷.)

제품 담당자의 주 업무는?

위 제품 담당자의 정의의 마지막에 “he/she makes the ‘magic’ happen”이라는 문구가 있다. 일부로 멋지게 쓰려고 한 것이 아니라, 저 단어 외로는 광범위하고 때마다 너무 다른 제품 담당자의 주 업무를 표현하기 어려워서 쓴 것이다. 물론, 제품 담당자의 기본 업무는 엔지니어와 같이 협업하여 멋진 제품을 정의하고 개발하여 시장에 출시하는 것이다 (define, build, and release the product to market). 하지만 그것은 성공적인 제품의 필요조건이지 절대로 충분조건이 될 수 없다. (아니, 그 보다 더 본질적으로 ‘제품’이라는 것이 세상에 존재하기 위해 필요한 너무나 당연한 기본 업무 밖에 되지 않는다). 이런 기본적인 업무 외에 제품의 성공에 기여하기 위해 수행해야 하는 제품 담당자들의 주 업무는 다음과 같다고 생각한다:

고객의 숨은 니즈 파악

헨리 포드의 유명한 일화가 있다: “내가 고객들에게 무엇을 원하는지 물어봤다면 그들은 ‘더 빠른 말’을 원한다고 대답을 했을 것이다”. 고객들에게 직접 그들의 니즈를 물어 어떠한 제품을 만들어야 할 지 파악하는 것은 혁신적인 제품일수록 어렵다. 그것을 경험하기 전 까지는 그러한 제품이 필요한지 알지도 못하기 때문이다. 자동차라는 제품을 눈으로 보기 전에는 더 빠른 말이 고객들이 상상할 수 있는 최고의 제품이었다. 아이폰을 보기 전에는 컴퓨터의 키보드를 전화기에 옮겨 놓는 것이 대중이 상상할 수 있는 최고의 제품이었다. 하지만 고객들의 진정한 니즈는 A 지점에서 B 지점까지 더 편리하고 빨리 갈 수 있는 수단이었고, 컴퓨터 앞에 앉아서만 할 수 있는 일들을 이동 중에서도 계속해서 경험하는 것이었다. 마케팅 부서에서 제공하는 인사이트는 이러한 고객의 니즈에 대한 힌트를 줄 수 있어도 정말 고객들이 원하는 것이 무엇인지, 그리고 또 어떠한 경험과 제품이 그런 궁극적인 니즈의 ‘심금’을 울릴 수 있는지 깊게 생각하고 파악하는 것은 제품 담당자의 몫이다. 말로는 쉽지만 실제로는 너무나 어려운 업무이다.

살을 깎는 트레이드오프 (trade-off)

100이면 100, 내가 아는 모든 제품 담당자들은 할 것은 너무 많고, 주어진 로드맵을 온전히 실행하기 위해 필요한 엔지니어 팀원들은 너무 적다고 불평을 한다. 단 한 명도 팀에 엔지니어가 넉넉하여 여유롭다고 하는 경우를 보지 못하였다. 항상 제품 담당자들이 꿈꾸는 ‘이상적인’ 제품과 그 제품을 만들 때 현실적으로 닥치는 기술적인 난관, 버그, 제품 방향의 긴급 수정 등의 일들이 생기기 때문이다. 이럴 때 제품 담당자의 핵심 업무는 제품의 성능, 기능, 출시 기한을 어떻게 타협할 것인가에 대한 어려운 결정을 해야만 한다. 꼭 필요한 기능 (must-have) 중에서 또 다시 추리고, 엔지니어들과 묘수를 찾기 위해 고민을 하고, 고객들이 이탈한다고 ‘협박’하는 영업팀과 마케팅팀들의 원성을 원활하게 조율하되, 제품의 궁극적인 비전에서 벗어나지 않는 트레이드오프 결정 과정은 과학이 아닌 예술에 가깝다고 할 수 있다.

팔방미인 코스프레 (jack of all trades)

이 외에 제품 개발 및 출시에 있어 막히거나 더딘 부분이 있으면 제품 담당자가 책임지고 해결해야 한다. 아무리 그것이 자잘하거나 제품 담당자의 ‘job description’ 밖에 있는 것일지라도 제품의 성공을 막는 그 어느 요인이 있다면 그것은 자동적으로 제품 담당자의 업무가 되는 것이다. 고객 인터뷰를 하거나, 고객의 항의성 C/S 전화를 받고, 영업팀에서 급하게 필요한 자료를 만들어 주고, 현장에서 일어난 일을 수습하기 위해 당장 뛰어 나가는… ‘제품 담당자 직군 매뉴얼’에 쓰여있진 않지만 제품 담당자들이 때와 상황에 맞추어 해야하는 업무이다. 이런 것들을 다 해결할 때 비로소 ‘magic’이 일어날 수 있는 기회가 생기는 것이다.

훌륭한 제품 담당자가 되기 위하여…

동료 제품 담당자들과 ‘우리 업’에 대해서 종종 이야기를 하는데, 이야기를 하면 할수록 훌륭한 제품 담당자가 되기 위해선 계량화 하기 어려운 ‘소프트’한 것들이 매우 중요한 것 같다는 결론을 자주 내리게 된다. 실제로 내가 존경하고 훌륭하다고 생각되는 제품 담당자들을 관찰하고, ‘전설적인’ 제품 담당자들의 글을 읽고 제품을 경험하며, 또 그들에게서 종종 조언을 들으면 다음과 같은 ‘soft skill’들의 훈련과 발전이 훌륭한 제품 담당자의 길로 가는데 도움이 될 것이라 생각된다:

기술적인 호기심 가득 (Technically Curious)

최근에 제품 담당자가 되고 싶어하는 친구들에게 가장 많이 들은 질문이 “코딩 할 줄 알아야 되나요?”, “기술적인 지식이 깊어야 하나요?”이다. 특히 컨설팅 및 MBA 출신 친구들이 다른 ‘스펙’은 다 되는데 기술적인 부분이 약하다고 제품 담당자에 지원하는 것을 고민하는 것을 많이 본다. 몇 달 전 Hunter Walk와 이 부분에 있어서 Q&A를 할 수 있는 시간이 있어 물어봤는데 그의 대답이 이 질문에 매우 적절한 것 같다.

“You don’t have to be technical per se, but you need to be technically curious. (기술적일 필요는 꼭 없지만, 기술적인 것에 대한 호기심이 있어야해요)”

테크 회사에서 제품 담당자는 기술을 이용하여 고객에게 가치를 줄 수 있는 제품을 만들고, 그 제품의 성공을 책임지는 사람이다. 이에 기술을 어떻게 이용해서 어떤 멋진 경험을 선사할 수 있을지 항상 고민해야 한다. 이런 호기심 없이는 세상을 바꾸는 훌륭한 제품을 상상해 내고, 또 그것을 현실적인 제약에 맞추어 성공적으로 구현해 내는 훌륭한 제품 담당자가 될 수 없을 것이다.

왜? What & WHY

무엇을 만들 것인가, 즉 제품에 대한 정의를 하는 것은 제품 담당자의 기본 역량이자 업무이다. 하지만 뛰어난 제품 담당자들은 제품 정의에 대한 명확한 논리와 강력한 설득력이 있다. 왜 주어진 상황이 문제인지, 그리고 그 문제를 풀기 위해서 왜 이러한 제품을 만들어야 하는지에 대해 정확한 논리와 뜨거운 열정이 느껴지는 제품 담당자들과 일하는 팀은 대체적으로 능률이 더 높으며 제품의 성과도 훨씬 좋은 편이다. 문제에 대한 인식과 제품에 대한 정의가 명확하기에, 애매하고 대충 정의된 제품을 만들 때 늘 따라오는 trial & error 및 기타 ‘삽질’과 짜증남을 피할 수 있기 때문에 그런 것 같다.

추상화 (Abstraction)

제품을 개발할 때 고객들이 가지는 문제, 그리고 그것을 풀 수 있는 방법을 잘 추상할 수 있으면 문제의 어느 특정한 부분에 발목 잡히지 않고 문제의 전반적인 본질을 이해할 수 있으며, 또 이에 필요한 해법의 방향과 전략을 가늠할 수 있다. 예를 들어 위에서 언급한 ‘더 빠른 말을 원하는 고객’들의 진정한 니즈는 이러한 추상화 과정을 통해 파악할 수 있는 것이다. (추상화를 못했다면 아마 더 단단한 말굽, 더 공기역학적인 안장, 말의 근육량을 늘릴 수 있는 사료들에 집중했을 것이다.) 단, 여기서 중요한 것은 추상화의 과정은 자세한 것에서 부터 시작한다는 점. 자세한 것을 제대로 이해하지 못한 상태에서 그냥 큰 그림만 겉핥기 식으로 파악하는 것은 위험하다. 또한 너무 과하게 추상을 하여 현실과 너무 동 떨어지는 상상을 하는 것은 큰 꿈을 꾸는 제품 담당자가 아닌 허황된 생각만 하는 바보라는 것을 경계해야한다. (‘빠른 말’에서 얻은 ‘아 고객들은 한 곳에서 다른 곳으로 빨리 이동하고 싶어하는구나’ 라는 인사이트를 ‘순간 이동 텔레포터’ 제품으로 풀려는 꼴)

유연함 (Flexibility)

팔방미인 코스프레를 하기 위해선 유연한 성격 및 뛰어난 ‘현장 적응 능력’이 있어야만 한다. 유연하지 못하고 ‘대쪽’같은 성격을 가지고 있다면 답답한 상황에 스트레스만 쌓이고 자신이 정한 제품 담당자의 역할에 대한 제한적인 ‘행동 반경’ 때문에 제품의 성공에 크게 기여하지 못할 가능성이 높다. 물론, 제품의 비전과 제품의 핵심적인 가치에 대해선 확고함이 필요하겠지만 비전과 전략만큼 중시되는 제품 담당자의 실행 능력에 있어서 만큼은 유연함이 필수이다.

.

제품 담당자라는 직군… 실리콘밸리에서는 흔하다고 하지만 기존 직군들과 비교해서는 상대적으로 새롭고, 이에 직군에 대한 정의와 역할이 아직 명확하지 않은 상태이다. 앞으로 더 많은 훌륭한 제품 담당자들의 활약을 통해 이 직군이 조금 더 명확해지고 회사에서 ‘없어서는 안될’ 너무나 당연하고 필요한 직업으로 거듭나길 바라며, 나 역시 이 개인적인 바램에 일조할 수 있도록 더욱 더 열심히 살아야겠다.
.

* 참고: 이 정의는 내 친구이자 훌륭한 제품 담당자로 십 수 년 동안 실리콘밸리에서 활약하고 있는 Sachin Rekhi에게서 차용한 것임.

.