조직의 동의를 얻는 법

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ㅏ… 힘들어 ㅠㅠ)

제품 로드맵 설계하기

https://www.atlassian.com/blog/software-teams/product-roadmap-vs-product-backlog-how-to

제품 담당자의 역할 중 제품의 로드맵을 정하는 업무는 어지간히 골치 아픈 것이 아니다. 고객의 반응과 성장률이 큰 제품이라면 다양한 피드백과 넘치는 아이디어에 파묻혀 결정 장애에 빠지기도 한다. 물론 제품의 반응이 너무 나빠서 피봇을 해야 되는 것에 비하면 너무나 행복한 고민이지만, 아무리 좋은 고민이라도 어지간한 스트레스인 것은 사실. 제품 관리자가 점쟁이도 아닌데 몇 백 가지 넘는 아이디어 중 회사의 핵심 지표에 큰 영향을 줄 수 있는 두 세 개의 대박 아이디어를 어떻게 가려내야 하는가?

나도 예전에 막 컨설팅에서 테크로 넘어왔을 때 로드맵 관련 일로 많은 고생을 했었다. 나름 strategy guy라고 데이터를 기반으로 머리를 굴려서 제품 로드맵을 수립하여 상부에 보고 하였는데, 간단히 말해 ‘실무자들이 쌍욕을 하며 싫어할’ 계획을 쓰고 있었다는… ㅠㅠ 구체성은 하나도 없고 (전략 컨설턴트가 PM으로 넘어올 때 하는 가장 큰 실수 중 하나), 핵심 수치에 대한 너무나 뻔뻔한 가정, 그리고 윗 사람들이 듣기엔 너무 멋진 전략이나 현실과는 너무 동떨어진… 그런 로드맵. 당연히 나는 엄청 깨졌고, 거듭된 실패를 통해 제품 로드맵 실무를 어렵게(?) 체득하게 되었다. 이젠 괜히 제품 담당자랍시고 머리속에서 말도 안되는 아이디어를 로드맵에 꾸겨 넣는 대신, 다음과 같은 기법으로 사용자 니즈를 파악, 이를 기반하여 로드맵을 설계한다.

1. 계속 제기되는 현재 사용자들의 불만 사항, 그리고 제품 해지자들의 해지 사유 분석

사용자들이 제품 사용을 중단하거나 서비스를 해지하는 가장 큰 이유 중 하나는 제품이 사용자들의 문제를 제대로 해결시켜 주지 못했기 때문. 현재 사용자들이 고객센터로 문의하는 불만 사항, 그리고 서비스 해지자들의 해지 이유를 잘 수집하여 분석하면 제품 사용자 경험 및 기능에 대한 문제점들 발견할 수 있고 이에 대한 개선 사항을 로드맵에 포함시킬 수 있다. 이것은 너무 당연한 것이지만 제대로 된 분석 없이 섣불리 불만 사항만 대처하게 되면 제품이 죽도 밥도 아닌 것이 되거나, 자동차를 원하는 사람들에게 더 빠른 말 밖에 제공하지 못하게 되는 우를 범할 수 있기에 무조건적인 ‘고객 불만 = 제품 로드맵’의 행동은 지양해야 한다.

예전 링크드인 프리미엄 사업부에 있을 때 유료 고객 이탈이 너무 많아서 이를 해결하기 위한 제품 로드맵을 수립하라는 명령(?)이 떨어졌다. 여러 제품 담당자 동료들이 제품의 매력도가 없으니 이런 저런 기능들을 추가로 제공해 주면 고객들이 이탈하지 않고 프리미업 서비스를 계속 이용할 것이라고 주장하였다. 그러나 서비스 해지자들을 중심으로 설문조사를 해보니 많은 사용자들이 이미 있는 기능들 조차 충분히 인지하지도, 사용하지도 않고 있었다는 점을 발견하였다. 더 황당했던 것은 프리미엄 기능들을 사용한 일부 사용자들은 그들이 사용한 기능이 프리미엄 기능이라는 것을 몰랐다는 것! 제품의 핵심 기능들을 제대로 인지하지도 못하고 있으니 사용자들은 프리미엄 제품은 무료 제품과 변별력이 떨어진다고 생각하고 구독을 해지했던 것이다. 이런 인사이틑 통해 프리미엄의 제품 로드맵은 새로운 기능보다 사용자 교육 및 사용자 경험 개선에 초점을 맞추게 되었고, 이를 통해 new subscriber on-boarding, 링크드인 프리미엄 브랜딩 같은 UX에 근간이 되는 프로젝트들이 제품 로드맵에 들어가게 되었다.

2. 잠재 고객들이 구매에 대해 주저하거나 깊게 문의하는 것을 분석

B2B 제품인 경우 제품 판매 과정 중 잠재 고객들에게 굉장히 많은 문의 및 요구가 들어온다. 제품에 대한 상세 설명과 가격 흥정이 많은 부분을 차지하지만 그 외에도 추가 기능에 대한 요구 및 문의도 상당히 들어오는게 일반적이다. 이 중 신기하게도 어떤 특정 기능에 대해서 반복적으로 문의나 요구가 들어오거나 그 특정 기능 때문에 고객이 구매를 주저할 때가 있다. 이런 상황이 발생한다면 그 기능에 대해 고객의 니즈가 상당히 있다는 힌트이며, 해당 기능을 로드맵에 추가하는 것에 대해 신중하게 고려를 해 봐야 한다.

역시 링크드인에 있었을 때의 경험. 이 때 나는 프리미엄에서 신사업부로 팀을 옮겨 대기업의 IT 부서를 공략할 새로운 제품을 개발하고 있었다. 링크드인만이 가진 데이터 및 인사이트를 기반으로 만들어진 이 제품은 많은 회사들이 큰 관심을 가졌고 제품 개발 부터 사업화까지 승승장구 하는 것 처럼 느껴졌다 (초고속 승진 예감?). 하지만 이상하게도 잠재 고객사들과 통화를 하면 할수록 계속 같은 주제에서 영업이 막히는 것이었다. ‘SSO 지원되나요?’, ‘사용 내역 리포팅 기능엔 무엇이 있나요?’, ‘관리자 기능 X,Y,Z 가 필요해요’ 등의 기업 관리자 기능 관련 문의가 빗발쳤고, 첫 버전에서는 이런 것들이 지원되지 않는다고 하니 그 관심 많던 회사들이 순식간에 사라지고 말았다. 거대 B2C 인터넷 플랫폼을 운영하는 링크드인은 이러한 관리자 기능들은 중요하지 않으며 고유한 데이터를 이용한 핵심 정보 제공이 killer application이 되리라는 가정을 하고 제품을 만들었는데, 이 가정을 기반으로 한 우리의 MVP 제품은 쪽팔리게 폭망하였다. 기업용 솔류션은 그 무엇보다 보안, 중앙 관리, 그리고 리포팅 기능이 전제되지 않으면 그 어느 훌륭한 제품도 문전박대 당한다는 사실을 뼈아프게 배운 우리는 섹시하고 쿨한 기능들을 로드맵에서 다 빼고 ‘enterprise readiness’ 관련된 기능들과 백엔드 인프라 구축을 최우선 순위로 로드맵을 수정하게 되었다.

3. 주요 고객들의 니즈와 요구부터 로드맵에…

모든 제품 담당자의 마음은 제품을 사용하는 모든 사용자들에게 최상의 경험과 제품 기능들을 제공하고 싶지만 현실은 부족한 시간, 인력, 돈. 안타깝지만 한정된 시간과 자원으로 최대한의 효과를 내기 위해서는 전략적으로 가장 중요한 고객들의 니즈와 요구를 로드맵에 우선적으로 반영하는 것이 좋다. 한정된 고객(사)들의 니즈를 우선적으로 반영하기에 이들의 니즈와 요구가 그들이 정말 필요한 기능인지 검증할 필요가 있는데, 이를 위해 많은 실리콘밸리 회사들이 Customer Advisory Board (CAB)라는 프로그램을 통해 전략적 고객(사)들을 초청, 제품 로드맵과 전략을 공유하고 피드백을 받는 방식을 취하고 있다. CAB에 참여하는 고객사들은 새로운 기능과 제품을 미리 맛보기를 하면서 새로운 사업 전략을 도모해 볼 수 있으며, 우리는 새롭게 준비하는 제품의 반응을 미리 듣고 정식 출시 전 까지 제품을 개선할 수 있기에 win-win 시나리오를 만들어 낼 수 있다. 단, CAB 프로그램은 상호 매우 민감한 정보들을 공유하기 때문에 양사 간 확고한 신뢰가 있을 때만 추구하는 것이 좋다. B2C인 경우 ‘파워 유저’들을 대상으로 포커스 그룹 연구를 한다던가, 모수가 충분하고 정보가 새어 나가는 것을 방지하고 싶다면 소규모의 A/B test를 통해 새로운 제품과 기능들의 효과를 가늠해 보고 로드맵을 조정하면 된다.

4. 데이터 분석. (사실 이것이 기본 중에 기본)

사용자 니즈를 파악하는데 데이터 분석만큼 쉬운 길이 없다. 심지어 사용자들 단 한 명과도 이야기 하지 않고도 그들이 원하는 것을 가늠할 수 있다. 예를 들어 유료 고객 유입 퍼널 (funnel) 중 급격하게 수치가 떨어지는 곳이 있다면 그것은 고객으로 변환될 준비가 되지 않은 사용자가 필요 없이 많이 유입 되었다던가, 아니면 잠재 고객들에게 불필요한 사용자 경험에 마찰(friction)을 주어서 걸음을 돌리게 만드는 것이라고 유추해 볼 수 있다. 만약 고객 유입이 제품의 가장 중요한 지표 중 하나라면 이런 가설을 빨리 증명하고 문제점을 해결할 수 있는 프로젝트를 로드맵 상단에 배치해야 할 것이다. 퍼널 분석 뿐만 아니라 사용자들이 고객센터 등에서 입력하는 문의 사항 분석 (customer query analysis) 혹은 UI 배치 대비 과사용 (over-idex) 되는 경우 (예: 두 번 째 탭 맨 밑에 있는 기능이 첫 번 째 페이지 가운데 위치한 기능보다 더 많이 눌림) 사용자의 니즈와 관심을 가늠할 수 있다. 단, 사용자들이 보인 행동에 대한 why에 대한 정확한 답을 찾을 수 없기 때문에 추가적인 분석 및 조사를 한 후에 로드맵을 수정하는 것을 권장한다.

Build what users want. 사용자들이 원하는 것을 만들어야 한다는 실리콘밸리의 식상한 구호다. 그 누구가 일부로 사용자들이 원하지 않는 것을 만들겠는가? 사용자가 원하는 제품을 만드는 것은 결코 말 처럼 쉽지 않지만 위와 같이 능동적이고 계량적으로 사용자의 니즈를 파악하여 로드맵을 설계한다면 사용자들이 원하는 제품에 조금 더 가까이 갈 수 있을 것이다.

image credit: Atlassian blog

Easier said than done

요새 연말 모임이 잦다 보니 평소에 보지 못했던 사람들과 이런 저런 이야기를 나누는 시간이 많아졌다. 그러다가 가끔 대화가 서로 하는 일, 혹은 최근 이슈가 되는 일들이 회자되곤 하는데 이럴 때 마다 꼭 크게 훈수를 두시는 분들이 있다. ‘그건 이렇게 하면 되지’, ‘내가 해봐서 아는데, 그건 이러이러 한거야’, ‘에이~ 그건 바로 저렇게 풀면 되는거 가지고… [회사]는 그것도 못하나?’

제 3자가 보기엔 문제가 단순해 보이고 왜 그걸 풀지 못하는지 의아해 하는 경우가 있다. 물론 정말 간단한 해결책이 있는데 완전 깜빡하고 있는 경우도 있지만, 대부분의 경우는 말은 쉽지만 실제로 문제를 해결함에 있어 밖에서 보는 사람은 절대 알 수 없는 매우 애매한 뉘앙스 및 복잡한 문제들이 도사리고 있어서 술자리에서 가볍게 얘기하는 수준으로 문제를 해결할 수 있지 아닌 경우가 대부분이다.

예를 들어 ‘가짜 뉴스’가 2017년의 큰 이슈 였는데 많은 사람들은 ‘딱 보면 가짜인지 아는데 그걸 왜 페이스북이랑 트위터에서 못 잡아내는거야?’라고 불평을 한다.

페이스북이랑 트위터에 다니는 똑똑한 수재들이 가짜 뉴스가 정말 ‘딱 보면 알 수 있는’ 것이었으면 왜 여태껏 해결을 못했겠는가. 근본적으로 가짜 뉴스는 ‘딱 보면 알 수 있지’ 못하거니와, 많은 인터넷 플랫폼 사업자들은 컨텐츠의 내용의 진위를 (가짜 뉴스, 댓글 조작 등) 평가 및 판별하는데 있어 크게 사용자 제보, 머신러닝, 그리고 실제 인력을 투입하는데, 이런 다양한 기법 및 최첨단 기술을 활용해도 다음과 같은 뉘앙스와 복잡함으로 문제 해결이 용이하지 못하다:

사용자 제보

혹자는 사용자들이 ‘신고하기’로 제보된 뉴스를 골라서 거르면 가짜 뉴스 문제가 해결될 것이라고 생각한다. 문제는 가짜 뉴스에 현혹된 사람들은 그 뉴스를 믿기에 ‘신고하기’를 누르지 않는다. 되레, 그들은 ‘좋아요’ 혹은 ‘추천’을 마구 누를 가능성이 더 높다. 또한 이런 플랫폼들은 보통 추천 알고리즘으로 컨텐츠를 사용자에게 개인화 해서 보여주기 때문에 설령 ‘딱 보면 가짜인지 아는’ 사람들이 있더라도 그들에겐 이런 가짜 뉴스가 보여지지 않을 가능성이 높다.

머신러닝 적용

머신러닝이 실리콘밸리에서 큰 유행처럼 번지고, 또 그 그대치에 걸맞는 결과들이 나오면서 (예: 알파고) 가짜 뉴스 파악에도 머신러닝이 많이 적용되고 있다 (페이스북 예). 많은 사람들은 머신러닝이 가짜 뉴스를 포함 많은 문제점들을 해결해 줄 것이라고 생각하지만 머신 러닝은 항상 precision 과 recall 이라는 제한이 존재한다 (참고: precision = 예측한 결과가 실제 맞는 경우, recall = 검출율; 모든 ‘true’ 중 맞게 예측한 정도). 99% precision이 있는 가짜뉴스 판별 시스템을 만든다고 해도 1%의 가짜 뉴스는 미꾸라지 처럼 빠져 나가고, 또 이런 높은 precision의 경우엔 recall이 상대적으로 낮아 가짜 뉴스를 막는데 큰 도움이 되지 못한다. 최대한 많은 가짜 뉴스를 걸러내기 위해 recall을 높이면 precision이 낮아지므로 가짜 뉴스가 아닌 무고한 뉴스들도 가짜 뉴스를 걸러내는데 희생(?) 당할 수 있는 위험이 있다.

실제 인력 투입

어떻게 보면 가장 확실한 방법은 ‘전수 조사’를 하는 것이다. 하지만 페이스북 같은 거대 플랫폼에서 올라오는 모든 뉴스들을 사람이 일일히 팩트체크를 하는 것은 현실적으로 불가능하다. 설령 전수조사가 가능하다고 해도 실제로 ‘딱 보면 아는’ 가짜 뉴스가 얼마나 될까? 또한 개개인의 조사자들이 가진 가치관과 지식의 차이 때문에 매우 일관적이고 공편하게 가짜뉴스에 대한 판단을 내리는 것이 정말 어려울 것이다.

.

영어 표현 중에 ‘easier said than done’ 이라는 말이 있다. 간단히 말해 ‘말이 쉽지’ 라는 뜻. 실제로 안에서 일어나는 일을 알지 못하면 모든게 쉽게 느껴질 수 있다. 나 역시 한 때 어느 제품이나 서비스를 사용하며 안좋은 경험이 있을 때 마다 ‘아 이런 회사가 이런것 기본적인 것도 못하네’ 라고 매섭게 비평을 할 때가 있었는데, 막상 ‘내부자’가 되어보니 정말 ‘easier said than done’임을 실감하며 나의 과거 모습이 부끄러워 진다.

위에 연말 모임의 분위기를 살짝 망치는 ‘훈수쟁이’가 되지 않기 위해서라도 많은 문제들이 ‘easier said than done’임을 인정하고, ‘정답’을 제시하는 것 보다 문제를 해결하는데 도움이 되는 새로운 접근 방식, 그리고 관련된 경험을 공유하는 것을 의식적으로 노력해야겠다.

제품 관리의 예술 (The Art of Product Management)

https://pixabay.com/en/ethics-right-wrong-ethical-moral-2991600/

테크 회사의 제품 담당자 인터뷰를 준비하는 분들이 가끔 조언을 얻고자 지인을 통해 내게 연락이 오는 경우가 종종 있다. 거의 모든 분들이 가장 두렵고 알고 싶어하는 것은 바로 ‘코딩 할 줄 알아야 되나요?’의 질문에 대한 답변. 이 질문을 조금 일반화 시키면 제품 담당자가 되기 위해 기술적인 역량이 필요한가에 대한 물음일 것이다. 코딩 까지는 아니더라도 (나의 생각은 여기에) 일단 제품 담당자라고 하는 직군은 논리적 사고와 계량적인 방법론들을 이용하여 사용자들이 원하는 제품을 정의하고 성공을 위해 팀을 이끌어 나가는 집단이라고 일반적으로 정의하곤 한다.

이에 제품 담당자가 갖추어야 할 계량적이고 기술적인 소양에 대해서 최근 십여년 간 많은 블로그와 서적을 통해 기술되었고, 이렇게 생성된 정보들이 제품 담당자들 사이에, 그리고 제품 담당자가 되고 싶어하는 자들에게 널리 알려지게 되었다. 예를 들어 그로스해킹과 A/B 실험의계량적인방법론들, 기존의 소프트웨어 개발 주기의 폭포(waterfall) 모델에서 상황의 변화에 민첩하게 대응할 수 있는 애자일(agile) 기법의 정수로 알려진 스프린트(sprint) 모델 등, 간단한 구글 검색 혹은 아마존 서적 검색을 하면 자세한 정보를 누구나 알 수 있게 되었다. 심지어 이런 기법들을 집대성하여 제품 담당자 취업대비서까지 나온 상황이다.

이런 책들과 블로그를 읽다 보면 A/B 실험에 대한 직관력을 키워서 좋은 성과를 달성하고 스프린트 기법을 통해 제품을 빨리 출시하고 개선하는 법을 통달하면 훌륭한 제품 담당자가 될 것 같은 느낌이 든다. 하지만 실제로 제품 담당자의 커리어를 걷다보니 훌륭한 제품 담당자가 되기 위해서는 제품 관리의 예술적인 (= the art of product management) 부분이 위의 계량적인 방법론을 숙달하는 것 못지 않게, 혹은 더 중요한 역할을 한다고 느낄 때가 많이 있다.

제품 관리의 예술적인 부분? 제품 관리의 예술적인 부분이란 계량화나 객관적인 비교가 어려운, 제품의 심미적인 그리고 가치관에 관한 영역이라고 할 수 있다. 어느 것이 더 아름다운가? 어느 것이 더 가치있는 것인가? 어느 것이 더 옳은 것인가? 이런 것을 판단하기엔 계량적인 접근 방법이 어렵거나 맞지 않을 때가 대부분이다 — 특히 가치와 윤리에 관련된 제품 결정을 해야할 때는 더더욱.

예를 들어 어느 화상채팅 앱을 특정 사용자들이 섹스팅 앱으로 사용하고, 그들의 인앱 매출이 상당한 부분을 차지한다면 그 해당 제품 관리자는 어떠한 결정을 내려야 할까? 플랫폼 자체는 중립성을 가지고 있고 그 플랫폼을 이용하여 나쁜 행위를 한 사람들의 잘못이라고 생각할 수 도 있다. 더 나아가, 성인 사이의 동의하에(consent) 이루어진 일이라면 전혀 문제가 될 일이 아니라고 까지 할 수 있다. 상황을 조금 더 엮어보자. 만약 해당 집단에서의 인앱 매출을 포기했을 때 회사를 운영할 수 없을 정도의 타격이 온다면? 그럼에도 불구하고 제품 담당자로써 내 제품을 통해 그러한 행위가 이루어지는 것이 내 양심에 ok 인가? 또 내 제품의 비전과 일치하는가? 비전과 일치하는 것이 의미가 있기라도 한 것인가?

또 다른 예로, 어느 커뮤니티 사이트 플랫폼에서 혐오 단체가 온라인 커뮤니티를 형성하고 이 커뮤니티를 이용해 어느 특정 집단을 비하, 모욕, 공격을 한다면, 그 커뮤니티 사이트 제품 담당자는 어떠한 판단을 해야할까? 마찬가지로 플랫폼의 중립성이라는 논리는 이용하여 용인할 것인가 아니면 제제를 가할 것인가? 제제를 가하면 또 다른 형태의 억압이 아닌가? 어느 것이 옳은 결정인가?

위 두 예 모두 대중들이 일반적으로 생각하는 가치관/윤리관과 제품 담당자의 성공 지표(매출, 사이트 접속/사용량 등)가 대립하고 있는 경우이다. 제품의 성공 지표들을 기준으로 A/B 실험을 진행한다면 섹스팅 앱과 혐오 단체 커뮤니티를 유지시켜야 하는 결론이 나올 것이다. 극단적인 예를 들어 너무 당연한 결정을 어렵게 포장 했다고 할 지 모르겠지만, 실제 상황들은 더 복잡하게 얽히고 뉘앙스가 가득하여 이런 상황에서의 의사 결정이 여의치가 않을 때가 너무나 많다.

나 역시 제품 담당자로서 가장 어려웠던 시기들은 이런 가치관과 윤리가 엮인 제품 결정을 내려야 하는 경우였는데, 이런 고난(?)을 극복하는데 개인적으로 도움이 되었던 것은 마이클 샌달 교수의 ‘정의란무엇인가’ 강의를 다시 듣는 것이었다. 강의에서 공리주의에 대한 이야기나 나오는데 ‘greatest good for the greatest number’의 사고 방식이 현재 테크회사의 데이터를 기반으로 하는 의사결정 저변에 깔려있는 가치라고 생각된다. A가 B 집단 보다 10% 결과가 좋으면 A 방식을 택하였을 때 피해가 보는 사람이 있더라도 전체로 봤을 때 A집단의 효용이 높기 때문에 A를 선택하는 것이 옳다는 그로스 해킹의 기본 접근 방식이 바로 이런 것이 아닌가. 진부하지만 너무 명쾌한 공리주의에 대한 반론 ‘그렇다면 콜로세움에서 사자의 먹이감이 된 몇 명의 그리스도 인의 죽음은 몇 만 명의 로마인들의 즐거움을 위해 정당화 할 수 있는가?’ 역시 위 두 예의 딜레마와 일맥상통한다.

‘정의란 무엇인가’ 수업을 듣거나 책을 읽은 사람은 알겠지만 사실 이런 윤리적/가치관적인 문제들에 대한 정답은 없다. 위 예에서 나온 고민들도 어떻게 결정을 내리던 옳은 결정이라고 하기엔 무리가 있다. 단, 어느 확고한 가치관과 논리를 기반으로 어느 제품에 대한 의사 결정을 하고, 동시에 그런 결정을 내림에 있어서 올 수 있는 한계점들에 대해 고민과 해결책들을 제시하는 것이 바로 제품 관리의 예술적인 부분이라고 생각한다. 이런 깊은 생각을 하고 데이터가 답해 줄 수 없는 문제들에 대해 ‘신의 한 수’의 결정을 내릴 수 있는 제품 담당자들이 정말 고수인 것이다.

결론: Product management is as much of an art as it is a science.

공리주의의 아버지 제레미 벤담 형님과 함께 (실제유골임)

.

베끼기, 가짜, 그리고 소비자 태도에 대한 생각

올해 테크 및 스타트업 업계에서는 유난히 베끼기와 가짜에 관련한 뉴스들이 많은 한 해 였다. 가짜 뉴스, 스타트업끼리, 또 정부의 스타트업 아이디어 베끼기 논란 등. 개인적으로도 직/간접적으로 이와 관련된 문제를 겪었는데 이를 통해 베끼기와 가짜 논란의 이유에 대해 깊게 생각하고, 또한 조금 흥미로운(?) 소비자들의 반응을 관찰할 수 있는 기회가 되었다. 이와 관련하여 나의 생각을 정리.

*본론에 들어가기에 앞서 ‘IANAL’ (I am not a lawyer – 나는 변호사가 아닙니다)라는 단서와 함께 개인적인 생각을 적어둔 것라는 점을 명시해 둠.*

베끼기와 가짜의 문제는 크게 다음의 세 가지의 MECE 하지 않는 이유에서 나온다고 생각한다. 지적재산권 침해, 가장(impersonation)으로 속는 소비자, 그리고 상도/상생의 가치관 부재.

지적재산권 침해 => 베끼기

지적재산권 침해는 남이 가지고 있는 상표권이나 지적재산을 무단으로 도용하는 것이다. 예를 들어 유치원 홍보물에 뽀로로 캐릭터를 사용하는 경우. 많은 경우는 지적재산권에 대한 깊은 생각 없이 순진(?)하게 법을 범하게 되는 것이지만 악의적인 의도를 가진 사람들을 남의 지적재산의 도용을 통하여 자신의 상품과 서비스가 유명한 브랜드와 연관되어 있거나 그들이 보증하는 것 처럼 보이게 한다. 더 심한 경우엔 원천 기술을 그대로 베껴 지적재산의 원 보유자가 가진 경쟁 우위를 무마시키는 사태를 야기하기도 한다. 다행인 것은 지적재산권 침해는 법적으로 보장을 받을 수 있지만, 동시에 절차가 매우 길고 복잡할 수 있기 때문에 (예: 삼성 vs 애플 특허 분쟁) 본질에만 집중하고 빨리 움직여야 하는 스타트업 같은 경우는 지적재산권 침해 문제에 엮이는 것 자체가 골치 덩어리이다.

가장(impersonation)으로 속는 소비자 => 가짜

가짜를 진짜처럼 가장하여 판매하는 것에 대해서는 순진한 실수가 있을 수 없다. 가짜를 진짜처럼 가장하여 판매하는 자들의 의도는 분명하다. 소비자를 속이는 것, 혹은 소비자를 통해 더 많은 대중을 속이는 것. 이 때문에 가장(impersonation)이 가짜/베끼기의 문제 중 가장 비열하고 악질적이다.

그런데 이런 가짜에 대한 소비자의 태도가 참 재미있다. 명품 브랜드의 경우 소위 ‘A급 짝퉁’이라고 암암리에 알려주고 판매할 경우엔 소비자들은 생각보다 호의적인 반응을 보인다 (최소한 한국에서는). 오히려 진짜에 더 가까운 가짜일수록 그 실력을 인정해 주면서 구입하려고 한다. 명품 브랜드를 소유한 척 함으로써 남에게 보여지는 (허위) 경제력 및 품위는 가지고 싶으나 실제로 그런 것을 이룰 수 없는 괴리감을 탈출하려는 시도인지, 쓸데 없이 ‘비싸기만 한’ 제품에 대한 반감인지 모르겠다. 동시에 가짜 휘발유, 가짜 자동차 부속 등 사치와 심미적인 것이 아닌 것들에 대해서는 같은 소비자들이 정 반대의 태도를 보인다.

소비자의 태도가 어찌하던 진짜로 가장한 가짜는 창조자(original creator)에게 너무나 치명적이다. 알고도 가짜를 사는 소비자층이 형성되면 기술과 디자인을 선도하기 위해 모험을 감행한 수고의 보상이 사라져 창조자들은 큰 경제적인 피해를 입는다. 감쪽같이 소비자들을 속여 가짜를 판매하는 경우에는 소비자들은 사기를 당한 셈이 되고, 창조자에겐 매출 피해는 물론, 가짜 제품의 낮은 사용자 경험이 창조자의 브랜드에 악영향을 끼치는 lose-lose 상황이 형성된다.

스타트업에 그나마 다행인 것은 이런 가짜가 흔하게 나오지는 않는다는 점. 단, 피싱 (phishing) 및 악성 소프트웨어들이 진짜로 가장하여 소비자를 위험할 위험이 있으니 항상 주의해야 한다.

상도/상생의 가치관 부재 => 베끼기 & 가짜

어느 선을 넘어야 가짜이고 베끼기인가. ‘아 다르고 어 다르다’고 해서 나훈아와 너훈아가 전혀 관련이 없는 두 인물이라고 할 수 있을까? 장르의 유사성, 포맷의 벤치마킹 등으로 용인될 수 있는 부분은 어디까지일까?

몇 초 후 사라지는 비디오 메시지라는 재미있는 포맷을 통해 미국 청소년들을 사로잡은 스냅챗. 올 해 초 페이스북의 대항마로 주목받아 화려하게 주식시장에 데뷔하였다. 그것을 본 페이스북은 보란듯이 인스타그램에 스냅챗의 핵심 기능들을 그대로 베껴서 구현, 10억명이 넘는 인스타그램 사용자들에게 추가로 스냅챗을 사용할 이유를 없애버렸다. 케빈 시스트롬은 뻔뻔하게(?) 이런 새로운 메시징 포맷을 선구한 스냅챗이 멋지다는 멘트까지 날리기도 하였다. 아니나 다를까, 수 달 만에 인스타그램 내에서 스냅챗 유사 기능을 사용하는 사람들의 숫자가 (DAU/MAU) 스냅챗을 월등히 능가하게 되었다. 언론들은 Snapchat copycat (“가짜 스냅챗”) 이라는 수식어를 쓰면서 대기업이 작은 회사를 고사시킨다고 비난했지만, 위의 지표에서 보듯이 사용자들은 굳이 마다하지 않는 듯 한 사용 패턴을 보였고 주가는 이를 반영하였다.

한국에서는 구닥 – 스냅킥, 라마마 – 타로냥 등의 업체들이 위와 비슷한 논란들이 있었는데, 이 논란들은 모두 포맷을 참고한 (혹은 서비스를 홀딱 베낀) 측의 사과와 서비스 중단으로 마무리 되었다. 포맷을 참고 했다고 굳게 믿는다면 인스타그램 처럼 욕을 먹더라도 묵묵히 뚫고 나가지 못해서 억울한 면이 있을 것이고, 정말 악의적으로 잘 나가는 (나갈 것 같은) 서비스를 표절 하였다면 한국의 스타트업 커뮤니티의 자정 능력이 빛을 발한 것이다.

그 진실이 어떠하던 결론적으로 이런 베끼기와 가짜의 경계선에 있는 상황들에 대한 가치 판단은 정말 어렵다. 하지만 이 모든 상황에서 알 수 있는 것은 ‘포맷 인용자’들의 상도 및 상생의 가치관이 없어 보인다는 점. 물론 가치관 자체를 어떻게 정의하냐에 따라 일정 부분은 비판의 대상에서 제외할 수 있겠지만 전반적으로 ‘시장 기회가 보이고 경쟁자가 하던 것을 베끼던 포맷을 참고하던 법적인 문제가 없기 때문에 우리도 해야겠다’라는 사고 방식이 컸던 것 같다. 개발사들은 자신들이 악의적인 의도가 없고 상도와 상생의 의지가 있다고 한다면 포맷을 참고하는 데 있어서 한 번 더 생각해 보도록 해야할 것이다.

.