‘불확실성’의 시대, PM의 역할과 마인드셋

프로덕트 매니저(Product Manager, 이하 ‘PM’)의 일은 고객의 필요를 발견하고 그 필요에 충족하는 것이 ‘고객’도 좋고 ‘회사’도 좋을 수 있는 최적의 안을 찾는 것입니다. 소비자 측면과 사업 측면의 필요를 모두 충족시키는 프로덕트와 서비스를 고민하는 것이죠. 이때 ‘무엇을’ 할 것인지 고려하며, 기대효과를 측정하게 되는데요. 사업 측면에서는 현황이나 과거 지표로 예측할 수 있지만, 소비자 측면에서는 예측이 어렵습니다. 고객의 필요에 충족할 거라 추정되는 서비스를 제공하거나 혹은 고객으로부터 의견을 들어 개발하더라도 기대한 만큼의 효과가 나타나지 않기 때문입니다. 소비자가 직접 이용하기 전까지는 예측할 수 없죠. 

이번 글에서는 이러한 불확실한 시장 환경에서 PM이 소비자 측면과 사업 측면을 충족하는 가치를 발견하려면 어떻게 일해야 할지, 제 경험에 빗대어 이야기하고자 합니다.

1. PM의 역할: 불확실성을 타개하는 것

PM은 프로덕트 목표를 달성하기 위해 프로덕트가 사용자에게 제공할 가치를 고민합니다. 프로덕트 목표가 DAU 수치를 20% 높이는 것이라면 ‘어떤’ 사용자에게 ‘어떤’ 가치를 제공했을 때 가장 높은 확률로 목표에 달성할 수 있을지 살펴보는 것이죠. 예로 기존고객의 경우 접속 주기와 접속하는 이유를, 신규고객의 경우 재접속 주기, 이탈률, 이탈 원인 등을 분석하며 어떤 고객 경험을 개선했을 때 DAU 수치 20% 증가를 만들 수 있을지 고민하는 것입니다.

그리고 이 과정에서 타깃한 고객군의 수치를 얼마큼 개선했을 때 프로덕트 목표 수치를 달성할 수 있을지 예측하게 됩니다. 예로 신규 고객 이탈률이 80%(리텐션 20%)이고 이탈 고객의 50%가 ‘온보딩 기능 부재로 서비스 이해도가 낮음’이 이탈 원인으로 확인됐다면, 온보딩 경험을 개선해 신규 고객 이탈률을 50%를 개선하여 신규 고객 리텐션 60%를 만들 수 있다는 추정을 할 수 있게 됩니다. 그리고 이 수치가 전체 DAU에 얼마큼의 영향을 미칠지 추정하게 됩니다.

반면 고객 경험 측면에서 ‘어떻게’ 온보딩 경험을 개선해야 이탈률을 40%로 감소할 수 있을지는 예측이 어렵습니다. 왜냐하면 고객 경험은 고객이 실제 프로덕트를 사용하기 전까지는 알 수 없기 때문이죠. 우리 생각에 ‘고객이 온보딩에서 주요 기능을 익히길 원할 것’이라 예측해도 실제 고객이 원하는 건 다를 수 있고, 심지어 고객으로부터 필요한 기능을 요청받아 실제 프로덕트로 개발해도 사용률이 저조한 경우를 보이기도 합니다. 

이렇듯 고객 경험을 예측하기 어려운 것은 무형적 가치에 집중되어 있기 때문입니다. ‘서비스’는 유형적 제품으로 물리적인 혜택을 주기보다는 유형적 제품을 매개하거나 무형적인 경험 그 자체로 유용성을 입증하는 것이 IT 산업의 모습이기 때문이죠. 이런 상황에서 우리 PM은 고객에게 가치 있는 경험을 발견해 내야 합니다. 프로덕트의 목표를 달성하기 위해 불확실성을 타개할 책임이 있는 것입니다.

2. 실무: 고객으로부터 학습하기

고객이 필요할 것이라 예측하거나, 고객으로부터 필요한 기능을 요청받아 서비스를 제공해 본 적 있나요? 그 결과는 어땠나요? 성공적이었나요? 아마 항상 기대한 결과를 얻진 못했을 것 같습니다. 기대한 바와 고객의 실제 행동에 간극이 있기 때문이죠. 스티브 잡스는 ‘많은 경우 사람들은 원하는 것을 보여주기 전까지는 무엇을 원하는지 모른다(A lot of times, people don't know what they want until you show it to them.)’ 고 말했죠. 

고객이 프로덕트를 직접 사용해야 고객 가치를 발견할 수 있다는 점은 사용자로부터 직접 확인하며 배워야 함을 시사합니다. 또한 소비자와 사용자의 니즈는 주변 환경에 따라 계속해 변화하는데, 프로덕트가 주변 환경을 통제할 수 있는 것이 아니기에 사용자를 더 잘 이해해야 하고 이에 맞춰 경험을 제공해야 합니다. 그래서인지 IT 업계에서는 MVP, AB Test와 같이 시간과 에너지를 최소화해 고객 반응을 검증하여 프로덕트를 점진적으로 발전해 가는 업무 방식에 관심을 두는 것 같습니다.

이렇듯 우리는 고객으로부터 배워야 하는데, 여러 직무 중 PM은 더욱이 고객으로부터 사고해야 합니다. 프로젝트 방향성 수립부터 전반적인 과정을 이끌어 출시 및 운영하기까지 모든 과정에서 팀이 한 방향을 바라보도록 이끌어야 하기 때문이죠. PM은 ‘문제 정의 - 문제 탐구 - 해결 방안 탐구’ 과정을 지날 때마다, 최대한 자신의 편견과 의견을 제거하고 고객으로부터 힌트를 발견해야 합니다.

1) 문제 정의

우선 문제 정의 단계에서는 고객이 가진 문제가 프로덕트 목표를 달성하는데 임팩트가 있을 지점을 고려하는데, 이때 기회라 판단하는 근거를 객관적 사실로 확인해야 합니다. 한 예시로 A라는 이커머스 서비스의 목표가 상품 클릭 수 대비 구매 전환 비율을 높이는 것이라고 가정해 볼게요. 먼저 구매 전환율을 고객, 상품 등 여러 관점에서 분석할 수 있을 것입니다.

위 목록 중 상품 목록 화면에 따라 유독 유입 대비 구매 전환율이 낮은 화면이 있다면, 그 이유를 더 심도 있게 분석해 갑니다. 의문점을 탐색하며 기회가 되는 요소를 찾아가는 것이죠. 분석하던 중 한 가지 의문을 발견했습니다.

리뷰 없는 상품과 리뷰 있는 상품의 구매 전환율을 비교했을 때, 리뷰 없는 상품이 클릭 수는 3배 높은 반면 구매 전환율은 리뷰 있는 상품의 1/5을 못 미치고 있습니다. 리뷰 없는 상품에 관심은 높지만 구매까지 이끌지 못하고 있음을 추정되며, 동시에 구매 전환율을 증가시킬 기회라 볼 수 있습니다.

이제 그 문제를 고객이 실제로 얼마나 겪고 있으며 해결할 수 있을지 살펴봅니다. 위 사례의 경우 리뷰 없는 상품을 보았지만 구매하지 않은 고객이 전체 고객의 몇 %를 차지하는지, 그 고객 중 몇 %의 구매 전환을 이끌었을 때 프로덕트가 목표한 구매 전환율에 도달할 수 있을지 측정해야 하는데요. 이를 위해서는 고객 목소리를 들어야 합니다. 

예를 들어, 리뷰 없는 상품을 클릭, 장바구니, 찜을 했지만 리뷰 있는 상품을 구매한 고객에게 구매 완료 시점에 앱 내 설문을 수집할 수 있습니다. 상품을 구매할 때 주요하게 보는 것을 묻거나, A 상품(리뷰 없는 상품)과 B 상품(리뷰 있는 상품)을 보고 B 상품을 구매한 고객에게 구매 이유를 물을 수 있겠죠. 그저 상품이 더 마음에 들어 구매한 것인지, 다른 불편함이 있는 것인지 (우리의 추정대로) 리뷰가 없어서 구매하지 않는 것인지 확인해야 합니다. 

이 과정이 중요한 것은 주요한 문제인지를 확인해야 하기 때문입니다. 우리가 생각한 문제(=리뷰 없는 상품의 구매 전환율이 낮음)가 실제 고객이 불편함을 겪고 있는 상황인지(=리뷰가 없어서 구매를 망설이게 됨) 확인하는 것이죠. 조사 결과, 전체 고객 대비 높은 비율의 고객이 ‘리뷰가 없어서’ A 상품을 구매하지 않는 이유라 언급했다면, 이제는 문제를 탐구할 때입니다.

2) 문제 탐구

문제를 탐구할 때는 고객이 가장 필요로 하는 것이 무엇일지 발견해야 합니다. 리뷰가 없는 상품이 구매를 방해한다는 문제를 발견하면 우리는 자연스레 이유를 추론하게 됩니다. ‘실패할 것이 두려워서’, ‘앞서 구매한 고객의 후기를 참고하고 싶어서’, ‘어떤 사이즈를 골라야 할지 가늠이 안 되어서’ 등 여러 이유가 떠오르는데, 이때 우리는 생각을 멈추고 고객에게 물어야 합니다. 문제를 겪고 있는 고객군에 1:1 인터뷰 혹은 UT 등의 정성적 조사를 통해 고객이 리뷰 없는 상품에서 본질적으로 겪고 있는 문제, 해결되어야 할 니즈가 무엇인지를 확인해야 합니다.

여러 고객을 인터뷰한 결과 고객이 리뷰 없는 상품에 겪고 있는 어려움은 ‘상세 페이지의 상품과 실제 상품의 차이’, 이로 인한 ‘품질과 사이즈 인지의 어려움’이라는 것을 발견하게 됐습니다. 이제 우리는 고객의 어려움을 추정할 수 있게 됐습니다. 염두에 둬야 할 것은 해결 방안을 확정하지 않는 것인데요. 고객의 불편함을 프로덕트에서 어떻게 해결하느냐에 따라 고객 경험이 달라질 것이기에 해결 방안을 검증해 가야 합니다.

3) 해결 방안 탐구

문제를 해결하는 방안은 여러 아이디어가 있을 수 있습니다. 이때 우리가 해결하는 방안이 실제 고객의 문제를 해결하는 결과로 나타나는지 확인되어야 합니다.

위의 예를 이어, ‘사이즈 인지의 어려움’ 문제에서 상세 페이지 상품과 실제 상품의 간극을 해결할 방법을 아래 두 가지로 가정해 봅시다.

a. 프로덕트가 사이즈 측정 기준을 세우고 직접 측정 및 상품 상세 사진을 업로드한다.

b. 파트너에게 사이즈 측정 기준을 제공해 이에 맞춰 업로드하게 한다.

이때 b안의 경우 파트너는 하나의 상세 페이지를 여러 플랫폼에 업로드하고 있기에 우리 프로덕트만을 위한 상품 상세 페이지 제작은 번거로운 일이 되어 참여율이 낮을 수 있습니다. 그렇다면 프로덕트가 직접 관리할 수 있을 것인데, 이것이 실제로 적절한 해결 방안이 될 것인지 검증해야 합니다.

예로 가장 구매 전환율이 높은 화면에 상위 노출된 리뷰 없는 상품 100개에 우리가 직접 상품 상세 사진을 제공하고, 이때 고객의 구매 전환율이 증가하는지 확인하는 것이죠. 프로덕트가 직접 상품 상세 사진을 통제하는 것이 ‘사이즈 인지의 어려움’이라는 문제를 해결하는 해결 방안이 될지 확인합니다.

결과는 둘 중 하나, 고객의 구매 전환율이 증가했거나 고객의 구매 전환율이 증가하지 않았을 것입니다. 고객의 구매 전환율이 증가했고 그 수치가 프로덕트 목표를 달성할 만하다면 다음 과정인 4) 해결 방안 최적화로 진행할 수 있습니다. 하지만, 고객 구매 전환율이 증가하지 않았다면요? 그 수치가 임팩트를 내기에 충분하지 않았다면 어떻게 해야 할까요? 다시 고객의 목소리를 들어야 합니다. 상품 상세 사진을 보았음에도 왜 상품 구매를 망설이게 되는지, 구매를 방해하는 요인이 무엇일지 더 깊이 고객을 탐구해야 합니다. 그리고 다시 가설을 세우고 해결 방안을 검증해야 합니다. 

4) 해결 방안 최적화

위에서 해결 방안을 발견했다면 이제 최적화해야 할 때입니다. 해결 방안을 인적, 물적 자원을 최소화할 서비스로 제공해야 하는 것이죠. 모든 상품을 찍어서 업로드하는 것은 회사 입장에서 많은 시간과 사람의 수고를 필요로 하기에, 적정한 범주에서 방안을 찾아야 하는데요. 실제로 몇몇 패션 플랫폼에서는 아르바이트를 고용해 직접 사이즈표를 수동 입력하여 운영하기도 합니다. 이처럼 인적, 물적 자원 비용이 최소화될 해결 방안을 함께 고려해야 합니다.

3. 마인드셋

위에서 살펴본 과정(문제 정의 - 문제 탐구 - 해결 방안 탐구 - 해결 방안 최적화)이 매끄럽게 진행되면 좋겠지만, 그렇지 않을 수도 있습니다. 만약 3) 해결 방안 최적화 과정에서 프로덕트가 상품 사진을 직접 컨트롤했는데 실제 고객의 구매 전환율을 높이지 못했다면, 그 이유를 다시 고객으로부터 확인하고 고객이 겪는 어려움을 탐구해야 합니다.

프로덕트 목표를 달성할 만큼의 임팩트가 예상되지 않는다면, 그 기회를 발견하기 위해 동일한 과정을 되풀이해야 하는 것이죠. 이렇듯 고객 경험 예측이 어려운 불확실한 상황은 예상과 다른 케이스가 발생할 수 있음을 늘 염두에 두고, PM의 마인드셋을 기억해야 합니다. 특히 회복 탄력성, 학습력, 실행력을 갖춰야 하는데 하나씩 살펴보겠습니다.

1) 회복탄력성

우리는 문제를 탐구하고 적절한 해결 방안을 찾아가는 과정에서 여러 가설을 검증합니다.

• 고객의 A라는 불편함이 우리의 a로 해결될 것이다.
• 고객의 A라는 불편함이 우리의 b로 해결될 것이다.

이때 한 가설 시나리오의 검증 결과가 옳았다고 잘한 것도, 틀렸다고 잘못한 것도 아니라는 점인데요. 가설 검증은 답을 찾는 것보다는 고객을 이해해 가는 과정에 가깝기 때문입니다. 여러 가설 검증을 거치며 프로덕트 목표에 달성할 만한 고객 경험을 찾아가고 있는지가 중요합니다. 그래서 하나의 결과에 일희일비하지 않는 것이 중요할 것입니다. 설령 가설 검증에 실패하게 되더라도 실패에 머무르지 않고 다시 고객의 문제를 해결하기 위해 나아가야 합니다. 그리고 이 과정에서 ‘학습’해야 하죠.

2) 학습력

우리가 시나리오를 세워 가설을 검증하는 이유는 결국 프로덕트 목표를 달성할 가장 좋은 기회를 발견하기 위해서입니다. 그래서 가설 검증을 통해 고객, 시장, 서비스나 프로덕트에 대한 이해도를 높여야 하는데, 가설 검증에 성공했다면 어떤 점이 성공을 이끌었는지, 더 잘할 수 있는 부분은 무엇일지 질문하고 반대로 실패했다면 어떤 점이 실패하게 한 주요 원인이었는지, 다음에는 무엇을 검증하는 것이 가장 중요한 문제인지 질문하고 고객에 대해 학습해 가며 다음 프로세스를 준비해야 합니다. 그리고 동시에 ‘실행력’이 필요합니다.

3) 실행력

가설 검증 과정과 학습을 통해 우리가 이해한 방향에 맞춰 다음 과정을 실행해야 합니다. 다시 가설을 세우고 검증하는 것일 수도 있고, 기회를 발견하기 위해 여러 차례 고객을 만나야 할 수도 있습니다. 중요한 것은 회복 탄력성과 학습력을 기반으로 끈질기게 고객 문제를 해결하기 위해 나아가는 실행력입니다. 문제 정의부터 해결 방안을 최적화하기까지 PM은 긴 호흡으로 과정에 임해야 합니다. 여러 실패가 있을지라도 고객의 불편을 해결하는 데 집착해 묵묵히 추진해 나갈 수 있는 실행력이 중요합니다.

마치며

지금까지 ‘불확실성’의 시대에서 PM이 어떻게 일해야 할지 역할과 실무, 마인드셋을 살펴봤습니다. 무엇보다 위와 같은 실무 방향과 마인드셋이 사내 문화로 공유되는 것이 중요할 텐데요. 프로덕트와 서비스를 만드는 것은 PM 혼자가 아닌, 여러 이해관계자가 함께해야 가능하기 때문입니다. 그래서 같은 방향을 공유하지 못한다면, 누군가는 가설 검증 실패를 보고 성과가 없다고 사기가 저하되거나, 가설을 검증해 가는 과정에서 장기 운영되는 서비스를 만들지 않음에 불만을 토로할 수도 있을 겁니다. 

물론 완벽하게 옳은 방향이란 없을 거고, 우리 프로덕트의 성장을 이루려면 어떤 문화를 만들어야 할지, 함께 고민하며 찾아가면 좋겠습니다. 방향이 어떠하든 우리는 한마음으로 프로덕트의 성장을 만들기 위해 고민하는 조직이니까요.

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.