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