[PM 원칙] 카카오스타일 PO의 서비스 뜯어보는 방법_by 이미림

기획 업무를 하다 보면 ‘내가 담당하는 서비스’ 그리고 ‘동종업계의 타서비스’를 많이 보게 됩니다. 자연스럽게 타 서비스의 UI/UX 변화를 알게 되고 신규 기능이나 개선 사항 등도 발견하게 됩니다. 이때 ‘타 서비스에서 신규 기능을 출시했네? 이 기능 좋아 보이는데 우리 서비스에도 적용 해야겠다!’라는 생각으로 해당 기능을 그대로 우리 서비스에 우겨넣는 경우가 많은데요, 저도 주니어 시절 이 같은 실수를 했습니다. 주니어 시절 저와 같은 실수로 리소스를 낭비하지 않았으면 하는 바람으로 ‘서비스 뜯어보기’ 방법을 소개하고자 합니다.

 

이미림

_현) 카카오스타일 PO

_전) 야놀자 프로덕트 오너

_전) 인터파크 쇼핑&투어 기획

“벤치마킹할 서비스를 선택하는 방법부터 자사에 적용하는 법까지 알아봅시다.”

 

 

원칙: “서비스를 뜯어보며 성장하자.”

 

‘서비스 뜯어보기’의 목적은 개인과 서비스의 성장에 있습니다. 어떤 서비스를, 왜 뜯어봐야 하는지, 어떻게 뜯어봐야 하는지, 그리고 우리 서비스에 어떻게 적용하는지에 대한 내용입니다. 개인과 담당 도메인 모두의 성장을 경험해볼 수 있을 한 가지 방편으로 읽어주면 좋겠습니다.

 

왜 뜯어봐야 할까요?

PO는 프로덕트의 성장에 고민이 많습니다. 늘 우리 서비스를 이용하는 유저 활동 데이터를 분석하고 특징을 파악합니다. 유저가 서비스를 처음 이용하는 시점부터 이탈하는 시점까지의 주요 퍼널별 데이터를 살펴보는데, 저는 미국의 기업가이자 투자자인 데이브 맥클루어(Dave McClure)가 개발한 AARRR 프레임워크를 주로 활용합니다. AARRR은 ‘고객의 획득(Acquisition), 활성화(Activation), 유지(Retention), 수익화(Revenue), 추천(Referral)’ 단계로 지표를 나누어보는 방법론입니다. 고객이 서비스를 경험하는 순서대로 지표를 보며 우리 서비스 어디에 문제가 있는지 어떤 지표를 개선해야 하는지 확인하는 데 유용합니다.

 

AARRR 프레임워크
  • Acquisition: 고객을 어떻게 데려올 것인가?
  • Activation: 고객이 서비스의 핵심 기능을 이용하는가?
  • Retention: 고객이 서비스를 지속적으로 이용하는가?
  • Revenue: 고객은 우리가 설정한 최종 목표인 결제를 하는가?
  • Referral: 고객이 자발적으로 우리 서비스를 추천하는가?

 

반드시 AARRR 프레임워크를 활용하지 않고도 자사 서비스 이용 유저와 유저의 서비스 이용 흐름을 파악했다면 ‘우리가 가진 문제’를 정의할 수 있습니다. 문제 정의 다음으로 ‘이 문제를 어떻게 해결할 것인가’를 고민하게 되는데, 이때 문제 해결에 대해 아무런 레퍼런스 없이 스스로 아이디어를 발굴하는 것에는 한계가 있고, 개선 방향에 대한 감 잡기도 쉽지 않습니다.

물론 경력 또는 경험이 어느 정도 쌓인 시니어라면 여러 프로덕트를 성장시키며 퍼널별로 발생하는 문제의 해결 방향을 쉽게 잡을 수도 있겠지만, 그동안 한 번도 고민해보지 못 한 문제에 직면하거나 경력이 적은 미들이나 주니어는 레퍼런스 없이 문제 해결의 힌트를 얻기 쉽지 않습니다.

그래서 우리는 타사 서비스를 레퍼런스 삼아 그들의 비즈니스를 이해하고, 서비스를 뜯어봐야 합니다.

그래야 우리가 겪는 문제를 타사가 어떤 방식으로 풀었는지를 알 수 있고, 그들이 푼 방식을 우리 서비스에 어떻게 적용할지 고민할 수 있고, 더 나아가서는 타사 서비스를 뜯어보고 더 좋은 아이디어를 떠올리고 디벨롭시켜 고객의 문제를 빠르게 해결할 수 있습니다.

 

비즈니스에 대한 이해

왜 뜯어봐야 하는지 이해했다면 그다음은 비즈니스에 대한 이해가 필요합니다. 현재 커머스 플랫폼의 PO로 재직한다고 가정하겠습니다. 커머스 플랫폼을 더 쪼개면 오픈마켓, 종합몰, 자사몰로 나눌 수 있습니다. 쪼개보는 이유는 같은 커머스에 속한다 하더라도 비즈니스 구조가 다르면 뜯어볼 서비스와 방향이 달라질 수 있기 때문입니다.

 

  • 오픈마켓 : 개인, 기업 셀러가 존재. 셀러가 많을수록 취급하는 상품 수도 많아져 경쟁력이 높아지는 구조
  • 종합몰 : 오프라인 유통판매 기업의 대형 셀러 위주로 구성. 어느 정도 브랜드력을 갖춘 상품을 취급하며 비교적 가격대가 높은 편
  • 자사몰 : 중간 유통 과정을 거치지 않고 셀러가 고객에게 직접 판매하는 구조로 독립적으로 운영

 

현재 속한 플랫폼이 오픈마켓에 속한다면 셀러를 확대해 취급 상품 수를 증대시키고 고객의 쇼핑 탐색을 편리하게 만들어주는 것에 집중하는 것이 좋습니다. 종합몰에 속한다면 보유하는 브랜드를 어떻게 더 잘 보여줄 수 있을지와 브랜드 관련 탐색 경험을 만들어주는 데 집중해야겠지요. 자사몰이라면 브랜딩과 플랫폼의 신뢰도를 높이는 데 집중할 겁니다. 궁극적으로 커머스의 목적은 ‘상품을 팔아 수익을 남기는 것’으로 모두 같겠지만 특성이 다를 수 있습니다. 플랫폼별 비즈니스에 대한 이해가 있다면 이를 기반으로 어떤 서비스를 어떻게 뜯어볼 것인지 명확하게 결정할 수 있습니다. 따라서 우리 프로덕트가 어떤 플랫폼에 속하고 어떤 비즈니스를 하는지 파악해놓는 게 좋습니다.

 

어떤 문제를 해결하려고 하는가?

PO라면 우리 서비스 유저가 어떤 어려움을 갖고 있는지 관심을 기울여야 합니다. 유저의 어려움을 확인하는 방법으로 고객 활동 데이터 분석, 유저 인터뷰, 사용성 테스트, 고객의 소리 등이 있습니다. 이 중 어떤 방법으로든 자사 서비스 이용 유저의 어려움을 파악해 문제를 리스트업해두고 ‘어떤 문제를 해결하면 가장 임팩트가 클지’ 곰곰이 생각해봅시다. 중요도와 시급성, 리소스 투자 대비 가장 임팩트가 큰 것을 고려해 우선순위를 정하고 우선순위가 높은 문제부터 해결해나가면 됩니다.

 

  • 문제
    • 제품 상세페이지(Product Detail Page, PDP)에서 주문서까지의 전환율이 낮다.
  • 해결 방법
    1. 주문서까지의 전환율이 낮은 이유에 대해 데이터를 딥다이브해 세부 문제를 찾는다.
    2. 주문서까지의 전환율이 낮은 이유에 대한 가설을 세워 A/B 테스트를 진행한다.
    3. 주문서까지의 전환율을 높일 수 있는 방법을 고민하고 개선한다.

 

PDP에서 주문서까지의 전환율이 낮은 문제를 예로 들어봤습니다. 이렇게 문제를 정의하고 어떤 방법으로 해결할지 대략적인 방안도 도출합니다. 해결 방법 중 2번은 가설을 세워야 하고, 3번은 방법에 대한 고민이 이루어져야 하는데 데이터를 보거나 미팅을 통해 동료의 의견을 들어볼 수도 있지만 타사 서비스를 뜯어보며 인사이트를 도출하고 해결하는 방법도 있습니다.

타사 서비스를 뜯어보기 전에 문제 정의 시점에서 ‘유저가 서비스를 이용하며 겪는 문제가 정확하게 무엇인지’ 뾰족하게 정의해놓는다면 더 깊이 있게 분석할 수 있으니 문제 정의 시 충분한 시간을 들여 고민해야 합니다.

 

타사 비즈니스에 대한 이해

지금까지 우리 문제를 정의했으니 그다음은 이 문제를 타사에서는 어떻게 다루는지 확인해볼 차례입니다. 저는 같은 비즈니스 영역의 ‘경쟁사’를 먼저 살펴보고, 그다음은 우리가 해결하려는 문제를 먼저 마주했을 확률이 높은 ‘카테고리별 대표 서비스’를 살펴보거나 기존에 이용했는데 ‘경험이 좋았던 서비스’를 살펴봅니다.

살펴보려는 서비스를 리스트업했다면 각 서비스의 비즈니스 이해도를 높일 차례입니다. 각 서비스의 배경지식을 익히고 최근 기사와 보도자료를 살펴보며 추가 정보를 획득합니다. 이런 과정에서 얻은 정보는 아래 예시와 같이 항목을 분류해 한눈에 비교해볼 수 있도록 정리합니다.

 

분류 : 경쟁 서비스 | 카테고리별 대표 서비스 | 경험이 좋았던 서비스

 

TIP_ 경쟁사 파악이 어렵다면 앱스토어 동일 카테고리의 TOP 3 서비스를 살펴보자.

 

위에 설명한 항목을 간략하게 표로 만들면 다음과 같습니다.

 

 

경쟁 서비스, 카테고리별 대표 서비스, 이 외 서비스를 분류해놓는 이유는 경쟁사인지 아니면 대표 서비스인지를 나누어 수월하게 비교하기위함입니다. 경쟁 서비스의 경우 ‘버전 기록, 주요 참고 내용’ 중심으로, 카테고리별 대표 서비스의 경우 ‘어떤 차별점이 있어 얼마나 성장한 서비스인지’ 중심으로, 이 외 서비스의 경우 ‘우리가 가진 문제를 해결하는 데 참고할 수 있는 기능을 UI/UX’ 중심으로 살펴봅니다.

각 카테고리가 서비스별로 1개씩 정의되는 경우 분류는 생략해도 무방합니다. 보통 여러 서비스를 같이 분류할 때 구분해놓으면 ‘경쟁사나 카테고리별 대표 서비스만 따로 보는 등’ 그때 그때 니즈에 맞게 빠르게 살펴볼 수 있는 이점이 있습니다.

지금까지 소개한 방법으로 서비스별 비즈니스 모델과 주요 특징을 살펴보고, 각 서비스에 대한 이해도를 높일 수 있습니다. 이를 벤치마킹 초반에 정리해두고, 수시로 보는 습관을 들이면 업계 트렌드도 빠르게 파악할 수 있어 인사이트를 얻는 데 큰 도움이 됩니다.

타사는 어떤 문제를 해결하려고 했는가?

타 서비스의 비즈니스 모델과 서비스 성격 파악으로 전반적인 서비스 이해도가 높아졌다면 이제 그들의 서비스를 보며 ‘어떤 문제를 해결하려고 했는가’를 추측해볼 수 있습니다. 앞에서 우리가 정의한 문제를 다시 가져와보겠습니다.

 

  • 문제 : PDP에서 주문서까지의 전환율이 낮다.

 

타 서비스에서 같은 문제를 이미 고민했다고 가정하고, 서비스의 PDP 지면을 구성하는 각 컴포넌트*를 살펴보면 PDP에서 주문까지의 전환율을 높이는 데 어떤 장치를 추가해두었는지 파악할 수 있습니다.

처음에는 우리가 가진 문제를 타 서비스도 가지고 있다고 가정하고 지면을 살펴봤다면, 이번에는 문제를 제외하고 넓은 관점으로 다시 지면에 위치한 컴포넌트들을 살펴보며 ‘이 컴포넌트의 목적은 무엇일까?’를 유추해봅니다. 이때 앞서 살펴본 ‘서비스의 비즈니스 모델, 주요 특징’ 등과 연결해 딥다이브할 수 있습니다.

아래 예시를 들어 조금 더 자세히 설명해보겠습니다.

 

* 각 지면 내 위치한 독립된 모듈. 예를 들어 상품 이미지 영역, 상품 정보 영역, 추천 영역 등을 컴포넌트라고 정의할 수 있습니다.

 

 

먼저 우리가 가진 문제를 타사에서는 어떻게 해결하려고 했는지 ‘문제 위주의 탐색’을 시작합니다. PDP가 A~F까지의 컴포넌트로 구성되는데, 그중 ‘전환율’을 높이는 데 영향을 미쳤을 만한 컴포넌트를 체크합니다. 체크한 컴포넌트가 실제로 전환율 상승 목적이었는지, 아니었는지는 크게 중요하지 않습니다. 중요한 점은 ‘우리 문제를 해결할 수 있는 힌트’를 얻는 겁니다.

두 번째는 우리에게 없는 컴포넌트, 기능, 정보 위주로 체크하고 ‘어떤 목적을 갖고 있을까’를 추측해봅니다. 예를 들어 ‘B. 배송 예측 정보’의 경우 ‘고객에게 배송 도착 정보를 안내해 배송을 기다리는 고객의 불편함을 해소하고 빠른 배송을 강조해 구매 의사결정을 도우려는 목적을 가졌을 거야’라고 생각해볼 수 있습니다. 이 서비스의 비즈니스 모델이 ‘빠른 배송’이면 이 영역은 매우 중요한 부분이니 더욱 강조되어 있을 겁니다. 이렇게 각 컴포넌트, 기능, 정보를 살펴보고 목적을 생각해보고 비즈니스에 대한 이해도를 바탕으로 이 서비스에서 강조하고 싶어 하는 부분은 무엇이고 어떻게 강조했는지 분석합니다. 그럼 우리 서비스에 어떤 기능을 어떻게 적용해야 할지 힌트를 얻을 수 있을 겁니다.

 

어떻게 뜯어봐야 할까요?

지금까지 왜 서비스를 뜯어봐야 하는지와 우리가 가진 문제를 어떻게 발견하고 정의하는지를 알아보았습니다. 뜯어볼 서비스의 선택과 비즈니스 이해도를 높이는 방법도 다뤘습니다. 이번에는 서비스를 ‘어떻게’ 뜯어봐야 하는지 알아보겠습니다. 앞에서 정의한 문제 기준으로 서비스 뜯어보는 방법을 구체적으로 설명하겠습니다.

 

  • 문제 : PDP에서 주문서까지의 전환율이 낮다.
  • 살펴볼 지면 : PDP
    • 전환율 개선이 필요한 주요 지면을 의미합니다.
  • 플랫폼 : 모바일(모바일웹, 앱(iOS, 안드로이드), PC 웹
    • 개선하려는 플랫폼이 PC인지, 모바일인지 확인 후 개선이 필요한 대상을 결정합니다.

 

TIP_ App의 경우 운영체제에 따라 UI/UX가 다르게 구현되어 있을 수 있음을 인지할 것

 

  • 살펴볼 서비스 : 서비스명 1, 서비스명 2, 서비스명 3
    • 경쟁, 카테고리별 대표, 경험이 좋았던 서비스 등 살펴볼 서비스를 선정합니다.

위 내용이 정해졌다면 이제 각 서비스의 PDP를 뜯어볼 준비를 마친 겁니다.

 

각 서비스의 PDP는 어떻게 구성되어 있는가?

자사와 타사의 PDP가 어떤 컴포넌트와 기능, 정보로 구성되어 있는지 확인합니다. 다음 예시 이미지와 같이 자사, 타사를 구분하고 PDP 전체 구성을 정리해 한 화면에 놓고 비교하면 각 서비스별 특징을 한눈에 비교할 수 있습니다.

 

 

각 서비스에서 비즈니스 모델을 지면 내 어떻게 녹여두었는지, 어떤 부분을 강조했고 차별화시켰는지 등 서비스별로 간략하게 분석하고 정리합니다. 앞서 살펴본 ‘타사 비즈니스에 대한 이해’에서 설명한 대로 각 서비스의 최근 기사나 보도 자료를 확인하고 내용을 정리해뒀다면 주요 내용을 더 쉽고 빠르게 파악할 수 있습니다.

 

PDP 내 컴포넌트, 기능, 정보가 어떤 특징을 가지는가?

이제 각 서비스별 A~G까지의 컴포넌트별 기능과 정보를 더 세부적으로 정리해봅니다. 같은 컴포넌트가 모든 서비스에 있다고 하더라도 각 서비스마다 제공하는 UI/UX, 기능 등이 다를 수 있으므로 꼼꼼하게 살펴봐야 합니다. 각 영역의 정보를 아래와 같이 정리합니다.

서비스를 살펴보니 A 컴포넌트에서 확대하기 기능을 제공하고 있습니다. 확대하기 기능을 제공하는 목적은 고객에게 상품 정보를 더 자세히 보여주어 탐색 편의성을 높이려는 의도로 유추할 수 있습니다. 하지만 모든 상품에 확대하기 기능이 적용되어 있지 않은 것으로 봤을 때 상품 이미지 확대하기 기능은 판매자가 ‘이미지를 확대해볼 수 있을 만큼 고화질의 사진’을 등록한 경우 제공한다는 것을 예상할 수 있습니다. 따라서 이 기능을 도입하려면 ‘고화질 사진 등록’이 선행되어야 합니다.

이렇게 컴포넌트별 정보와 기능을 정리하고 ‘이 기능은 왜 제공하고 있을까?’, 자사에 ‘제공하려면 무엇이 선행되어야 할까?’ 같은 질문을 던지고 파악해야 합니다. 당연히 이를 문서에 정리해놓아야겠지요? 단순히 정보만 나열해놓으면 유의미한 인사이트를 얻기 힘들고 자사 서비스에 왜 적용해야 하고, 어떻게 적용해야 하는지 매번 시간을 들여 다시 고민해야 합니다. 그러니 서비스를 뜯어볼 때 떠오른 느낌, 생각, 인사이트 등을 같이 정리해두는 습관을 들이기 바랍니다.

 

좋았던 점, 아쉬운 점, 적용할 점

지금까지 서비스를 자세하게 뜯어보고 인사이트까지 정리했다면, 이제 최종으로 정리할 시간입니다. 서비스를 분석하며 좋았던 점, 아쉬운 점, 우리 서비스 문제 해결에 도움이 될 만한 적용할 점을 적습니다. 다음과 같은 질문을 스스로에게 던지며 정리해봅니다.

 

 

최종 비교

서비스별로 지면 구성이 어떻게 되어 있는지, 컴포넌트와 기능 그리고 정보가 어떻게 노출되어 있는지, UI/UX는 어떤지 등을 전반적으로 살펴보고 정리를 마쳤습니다. 그럼 서비스마다 갖고 있는 특징과 차별점을 하나의 표로 정리하고 비교할 차례입니다.

 

 

작성한 표를 보고 어떤 부분을 어떻게 적용할지 고민해봅니다. 혼자 고민하고 의사결정하기 어렵다면 팀원들과 리뷰하고 함께 보며 자유롭게 의견을 들어보는 것도 좋습니다. 이 과정에서 생각지 못한 좋은 아이디어가 나올 수도 있습니다.

 

어떻게 적용해야 할까요?

지금까지 서비스를 왜 그리고 어떻게 뜯어보는지 설명했습니다. 마지막으로 우리 서비스에 적용하는 방법을 알아보겠습니다. 서비스별 ‘적용할 점’을 리스트업했으니 이제 적용 예정 기능의 목적과 도입 시 선행되어야 할 점을 적습니다. 이어서 우리 문제를 해결하는 데 가장 적합하다고 생각되는 우선순위대로 나열합니다. 예를 들어 다음과 같이요.

 

1. 카테고리별 유사 상품 추천

  • 해당 상품과 같은 카테고리 내 유사 상품을 추천해, 고객이 원하는 상품을 더 쉽고 빠르게 탐색할 수 있게 해 주문서까지의 도달율을 높인다.
  • 선행 : 유사 상품 추천이 가능할 정도의 상품 풀(pool)이 있는지 확인

 

2. 포토 리뷰 모아보기

  • 고객이 작성한 리뷰 중 이미지 리뷰만 모아 PDP 상단에 노출해 상품에 대한 객관적인 정보를 제공하고 고객의 구매 결정을 돕는다.
  • 선행 : 전체 이미지 리뷰 개수 확인, 카테고리별 이미지 리뷰 개수 확인
    • 리뷰가 충분히 없을 경우, 이미지 리뷰를 늘리는 과제가 먼저 선행되어야 함

 

3. 라이브방송 숏클립

  • 기존 진행한 라이브 방송을 짧게 편집해 PDP에 노출해 고객이 상품에 대한 풍부한 정보를 얻어 구매를 결정할 수 있도록 돕는다.
  • 선행 : 제공 가능한 라이브 방송 콘텐츠가 있는지 확인

 

우선순위가 정리되었다면 요구사항을 PRD(Product Requirements Document)로 작성하는 단계로 넘어갑니다. 배경, 목적, 가설, 성공 지표 등을 정의하고 기능적 요구사항, 유저 스토리 등을 포함해 작성하면 됩니다. 이 단계에서 사용성 테스트나 A/B 테스트 진행 여부를 결정하고 단계별 일정 계획을 수립합니다.

사용성 테스트는 배포 예정 기능의 프로토타입을 제작하여, 특정 유저에게만 공개하고 배포 예정 기능을 어떻게 사용하는지 테스트하는 방법입니다. 사용성 테스트를 활용하면 배포 전 신규 기능에 대한 유저 반응과 사용성을 미리 체크하고 개선한 후 배포할 수 있어 리스크를 줄일 수 있지만 준비 시간과 비용이 수반됩니다. A/B 테스트는 서비스에서 발생할 수 있는 다양한 변수를 최소화한 상태로 출시 전 일부 고객 대상으로 가설을 검증해볼 수 있는 테스트입니다. 신규 출시 기능이 자사 서비스 고객에게 유의미한지 배포 전 정확한 지표를 통해 미리 파악하고 싶다면 A/B 테스트를 진행하고 테스트 결과에 따라 전체 배포하는 것이 좋습니다.

벤치마킹한 서비스를 우리 서비스에 적용할 때 기억해야 할 점은 ‘타사에 노출된 형태를 그대로 따라 하지 않는 것’입니다. 타사에 ‘카테고리별 유사 상품 추천’ 컴포넌트가 카테고리를 선택할 수 있는 UI로 되어 있다고 우리 서비스에도 그대로 적용하면 어떻게 될까요? 다음과 같은 문제가 발생해 기대한 효과를 얻기 어려울 수 있습니다.

  • (타사) 카테고리별 유사 상품 추천
    • 카테고리 : 백화점, 아울렛, 소호&스트릿, 디자이너, 브랜드 직영몰
  • 발생할 수 있는 문제
    • 우리는 타사가 가진 ‘카테고리’ 중 1개 카테고리밖에 취급하지 않는다.
    • 타사의 카테고리 모두 취급하지만 ‘일부 카테고리’는 판매 가능 상품이 거의 없다.
    • 전체적으로 상품 판매수가 적어 정확한 추천이 이루어지지 않는다.

그러므로 이 형태가 타사에서 잘 워킹한다 하더라도 우리 서비스에 그대로 가져오기보다는 ‘우리 서비스 성격과 타깃’을 고려해 반영해야 합니다.

‘당연한 거 아닌가?’라고 생각할 수 있지만 연차가 있는 기획자도 실수할 수 있는 부분입니다. 저 역시 과거에 비슷한 실수를 한 적이 있습니다. 커뮤니티 성격을 가진 콘텐츠 전용관을 만든 적이 있었습니다. 카테고리별로 콘텐츠를 모아보고 고객들끼리 콘텐츠를 보며 서로 커뮤니케이션할 수 있는 서비스였습니다. 보도자료를 통해 경쟁사의 업데이트 소식을 알게 되었는데요, 며칠 경쟁사의 서비스를 이용해보니 고객 활동성도 매우 높아 우리 서비스에 도입해도 잘 워킹할 것 같다는 근거 없는 확신이 들었습니다. 이후 경쟁사에서 추가로 배포한 보도자료에는 해당 서비스 제공을 통해 주문 전환율 및 주요 지표가 증대되었다는 효과가 담겨 있었습니다. 이를 보고 서비스 성과가 입증되었다고 판단해 본격적인 벤치마킹에 돌입했죠. 우리 데이터 및 서비스 현황 분석을 마치고 벤치마킹한 서비스를 최종 도입했는데 성과가 좋지 않아 오픈한 지 단 두 달 만에 서비스를 종료해야 했습니다. 종료 전, 주요 지표 증대를 위해 여러 액션 아이템을 실행했지만 백약이 무효했습니다. 적지 않은 리소스와 시간을 들인 만큼 속상했죠. 서비스 종료 후 프로젝트 실패 원인을 복기하는 시간을 가졌는데, 주된 실패의 원인은 다음과 같았습니다.

 

  • 자사 ‘주요 타깃’에 대한 고려가 되지 않았다.
    • 경쟁사의 주요 타깃은 20~30대인데, 우리는 40 ~ 50대다. 커뮤니티가 활성화되려면 많은 사람이 자주 글을 써야 하는데, 우리 유저의 경우 연령대가 있다 보니 모바일로 타이핑하는 게 쉽지 않아서인지 글을 쓰는 유저가 현저히 적었다.
  • 콘텐츠 업로드 방식의 차이를 간과했다.
    • 콘텐츠를 모아보는 전용관에 ‘퀄리티 좋은 콘텐츠’가 노출되려면 ‘검수’가 필요한데, 우리는 사람이 일일이 수동 검수하는 프로세스여서 주말에는 업로드되는 콘텐츠가 없어 서비스가 정체되었다. 반면, 타사는 콘텐츠 자동 검수 기술을 이용하고 있어서 주말에도 활발하게 콘텐츠가 업데이트되었다.

 

이렇듯 타사에서 잘된다고 우리 서비스에 적용했을 때 잘된다는 보장이 없습니다. 그러므로 벤치마킹 후 기능을 도입할 때는 ‘우리 서비스 성격과 주요 타깃에 잘 맞는가?’를 필수로 확인해야 합니다. 또한 우리 고객이 갖고 있는 문제를 해결할 수 있는지 충분히 검토하고 이를 고려해 자사 서비스에 맞게 기획해야 합니다. 뜯어보기의 목적은 우리가 가진 문제 해결을 위해 타사 서비스를 이리저리 뜯어보면서 비교한 후 우리의 문제를 해결하고 부족한 부분을 보완하는 것임을 잊지 말아야 합니다.

 

◆◆◆

 

지금까지 서비스 벤치마킹 방법으로써 ‘뜯어보기’를 알아보았습니다. 왜 해야 하는지, 어떻게 해야 하는지, 자사 서비스에는 어떻게 적용할 수 있는지 전반적으로 다뤘습니다. 주니어라면 벤치마킹의 기본기를 배울 수 있고, 미들이라면 본인의 벤치마킹 방식과 비교하며 발전할 수 있을 겁니다. ‘벤치마킹은 이렇게 하는 거구나. 잘 정리되어 있네. 다음 프로젝트 진행 시 나도 적용해볼까?’라는 생각이 드는 글이라면 좋겠습니다.

사수도 없이 일하던 주니어 시절 저는 정말 아무것도 모르는 기획자였습니다. 어쩌면 기획자라는 직무에 대한 이해도 없던 상태였을지 모릅니다. 기획서를 쓰는 방법도, 스토리보드를 그리는 방법도, 프로젝트 전체를 리드하는 방법도 모두 생소했고 어려웠습니다. 첫 회사는 스타트업이라 규모도 작았고 사수도 없어 더 힘들었던 것 같습니다. 하지만 어려움은 극복하라고 있는 법! 그 당시 겪고 있던 어려움을 극복하고자 나름대로 기획자가 하는 일을 열심히 찾아 공부했습니다. “이것도 모르냐”는 타박을 듣고 업무 시간이 훨씬 지난 밤 늦게까지 기획서를 쓰고, 주말에도 열심히 공부했던 기억이 납니다. 벤치마킹 업무도 처음에는 너무 어려웠습니다.

어느 정도 연차가 쌓이니 벤치마킹이 예전처럼 어렵지 않게 되었습니다. 서비스를 조사하는 데 걸리는 시간도 짧아졌습니다. “대리님! 저희 팀에 대리님 문서가 좋은 벤치마킹 사례로 공유됐어요.” 어느날 회사 후배가 기분 좋은 소식을 전해주었습니다. 평상시 하던 대로 작성해놓은 문서라 주목받을 정도는 아니라고 생각했는데 후배의 말을 듣고는 벤치마킹 문서를 만들며 어렵다고 징징대던 주니어 시절이 떠올랐습니다.

그래서인지 “기획자는 무슨 일을 하나요?”, “어떻게 하면 PM · PO가 될 수 있나요?”, “PM · PO가 갖춰야 할 역량은 무엇인가요?” 같은 질문을 받을 때마다 주니어 시절이 떠올라 최대한 많은 것을 알려주려고 노력합니다. 10년 넘게 실무에서 부딪혀가며 배운 노하우와 경험을 주변 주니어뿐 아니라 직접 알지는 못하지만 기획자 · PM · PO가 되고 싶은 주니어에게도 정보를 나눠주고 싶어 글을 쓰고 있습니다. 주로 직접 부딪히며 배우고 느낀 것들, PO는 어떻게 일하는지에 대한 글을 다루고 있으니 궁금하거나 어려운 점이 있다면 제 블로그* *도 찾아주시길 바랍니다.

오늘도 책을 읽으며 배우고 성장하는 데 진심인 독자분들께 개인적으로 너무 좋아하는 작가인 보도 섀퍼의 글귀를 선물하며 글을 마무리합니다.

 

“배움과 성장을 즐기는 사람이 성공할 확률이 높은 이유는 그 과정을 통해 인생을 수정하는 것이 두려움이 아니라 얼마나 즐거운 일인지를 알게 되기 때문이다. 배움과 성장이 없으면 ‘변화’는 일어나지 않는다.”

__《이기는습관》(보도섀퍼) 중에서


<프로덕트 매니저 원칙> 카카오스타일 이미림 PO와

함께 하는 북토크&네트워킹

[래빗톡#2] 원칙자들 : 삼자대면이 오는 2월 15일 열립니다!

지금 신청하세요!

저자 장홍석

대학에서는 컴퓨터공학을 전공했습니다. 개발보다는 기술과 제품으로 현실의 문제를 푸는 것이 좋았습니다. PM으로 시작한 커리어는 스타트업 CEO까지 연결되었습니다. 지금 내가 남기는 점들은 훗날에 모두 선으로 연결된다 믿습니다. 성장을 위한 고통을 즐기며, 읽고 쓰는 것을 좋아합니다. 사람들의 불필요한 시행착오를 줄여, 더 빠른 성장에 도움을 주고 싶습니다.

_전) 딜리셔스 공동대표/CPO

_전) 네이버 신규 프로덕트 리드

_전) 마이리얼트립 리드 프로덕트 매니저

_전) 쿠팡 프로덕트 오너

_전) 네이버 프로덕트 매니저

저자 황인혜

타고난 문과생으로 테크와는 거리와 멀던 제가 벌써 프로덕트 매니저로 10년째 프로덕트를 만들고 있습니다. 쿠팡에서 판매자부터 구매자, 오픈마켓부터 글로벌 앱 론칭까지 다양한 도메인과 프로덕트를 담당 후 현재는 서비스 오픈 마켓 플랫폼 크몽에서 프로덕트를 리드하고 있습니다. 프로덕트 커리어에 대해 고민하는 분들에게 도움을 드리기 위해 커리어 컨설팅 서비스를 하는 전문가로 크몽에서 활동하고 있습니다.

_현) 크몽 프로덕트 디렉터

_전) 쿠팡 그룹 프로덕트 매니저

_전) 롯데백화점 유통전략연구소 연구원

저자 서점직원

그림 그리는 걸 좋아하지만 실력이 형편없어 미대를 가지 못했고 소프트웨어 공학과를 졸업했지만 개발에 대한 자질이 부족해 기획자가 된 10년 경력의 기획자입니다. 우리나라 특성에 맞는 UI/UX 연구에 관심이 많습니다.

_현) 프리랜서 프로덕트 기획자

저자 이상범

저는 프로덕트 기획업을 통해 다양한 기업을 탐험하는 것을 즐깁니다. 이런 여정에 심취해 닉네임도 ‘Journey’라 지었습니다. 통신, 금융, IT, 커머스, O2O 등 다업종에서 다양한 프로덕트를 기획하면서 ‘유연한 사고’의 중요성을 깨달아, 현재 몸담고 있는 기업의 프로덕트 조직에 이런 철학을 전파하는 중입니다.

_현) 에너지엑스 CPO

_전) 쿠팡 프린시펄 PO

_전) 라인 PM

_전) KB국민카드 기획자

_전) KT 프로젝트 매니저

저자 강형모

대략 10년은 개발 리드를 했고, 대략 10년간 PO 리드로 일하고 있습니다. 프로덕트 구축은 기술적 업적이지만, 고객의 마음을 움직이는 것이 그 여정의 본질이라고 생각합니다. 사랑하는 아내와 두 딸 하윤이 하음이의 아빠이면서 주말엔 몰래 코딩합니다.

_현) 엔카닷컴 프로덕트 오너 리드

_전) 네오랩 컨버전스 응용S/W 센터장

_전) NCSOFT Japan 게임 개발

_전) 이모션, 펜타브리드 개발 리드

저자 김승욱(CK) 

하기 싫은 일들을 돌고 돌아 프로덕트 매니지먼트 직무에 어느 정도 만족하고 안착한 직장인입니다. 뛰어난 프로덕트 리더들을 보며 ‘가면 증후군’에 시달리지만 극복하려고 노력 중입니다. 좋은 프로덕트가 더 나은 세상을 만든다는 낯 간지러운 말을 진심으로 믿고 있으며, 좋은 프로덕트를 만드는 과정에 기여하는 이 일이 현재까지 해본 일 중 가장 보람차다고 느끼고 있습니다.

_현) 리멤버 디렉터 오브 프로덕트

_전) 쿠팡, 시니어 프로덕트 매니저

_전) 마켓디자이너스 CEO 스태프 & PM

저자 이미림

무언가 하나에 빠지면 집요하게 파는 걸 좋아합니다. 흥미가 없으면 무엇이든 오래 하지 못하는 편인데 어쩌다 보니 기획에 푹 빠져 올해로 12년차 PO가 되었습니다. 학창 시절부터 글을 읽고 쓰는 것, 발표하는 것, 계획 세우는 것을 유독 좋아했는데 어쩌다 보니 ‘좋아하는 일’을 모두 할 수 있는 직업인 PO를 하고 있네요(이게 바로 덕업일치..?) . 매번 느끼지만 내가 ’좋아하는 일‘을 직업으로 가지고 있는 건 너무 행복한 일인 것 같습니다.

_현) 카카오스타일 PO

_전) 야놀자 프로덕트 오너

_전) 인터파크 쇼핑&투어 기획

저자 김수미

웹 기획자라는 이름으로 킥오프해서 과제 매니저, 프로덕트 매니저, 프로덕트 오너 다양한 이름으로 경력을 쌓아왔습니다.

_전) 무신사 커머스코어실 실장, 제품 리더

_전) 메쉬코리아 서비스 기획 팀장, 리드 PO

_전) 위메프 플랫폼기획 PM

_전) GS홈쇼핑 서비스기획 PM

_전) 티켓몬스터 PM, 배송WG PO

저자 신필수

게임을 통해 컴퓨터와 인연을 맺었습니다. 문제를 해결할 때 단순하되 효과가 확실한 방법을 좋아합니다. 솔직한 커뮤니케이션을 두려워하지 않으려 부단히 노력 중입니다. 2014년에 베를린으로 건너가 5년 반 동안 스타트업 환경에 푹 빠져 일했습니다. 기술, 미디어, 외국어, 게임, 건강 등 다양한 분야에 관심이 많습니다. 레진코믹스에서 《독일만화》 웹툰을 연재했으며, 현재 요즘IT에서 맨오브피스라는 필명으로 글을 연재 중입니다.

_현) OP.GG Ad 스페셜리스트

_전) 펍네이티브 시니어 프로덕트 매니저 외 다수

_전) 앱리프트 어카운트 매니저

_전) 이노게임스 프로젝트 매니저

❮코딩하는 토끼들 디스코드 서버❯

코딩하는 토끼들은 세상의 모든 학생, 취준생, 직장인을 위한 개발 커뮤니티 서버에요.

개발, 기술블로그, 인사이트, 스터디, 채용, 행사 등 정보를 공유하고 있으며, 현재 약 200명이 활동 중이에요.

Leave a Reply

©2020 GoldenRabbit. All rights reserved.
상호명 : 골든래빗 주식회사
(04051) 서울특별시 마포구 양화로 186, 5층 512호, 514호 (동교동, LC타워)
TEL : 0505-398-0505 / FAX : 0505-537-0505
대표이사 : 최현우
사업자등록번호 : 475-87-01581
통신판매업신고 : 2023-서울마포-2391호
master@goldenrabbit.co.kr
개인정보처리방침
배송/반품/환불/교환 안내