Winnie The Pooh Bear

📕 독서 기록

[독서 기록📚] 프로덕트 매니저 원칙 (3): 서비스 뜯어보기 신공, 본질적인 문제를 풀어라 알맞은 방법으로

alwayshappydaysforever 2025. 4. 2. 18:13
반응형

 

 

[독서 기록📚] 프로덕트 매니저 원칙 (2): 시작하는 PM을 위한 5가지 스킬, 더 큰 차이를 만드는 킥

[독서 기록📚] 프로덕트 매니저 원칙 (1) 시작하는 PM을 위한 선배와의 3문3답PM으로 성장하고 싶다면 소통 능력 / 신뢰감 / 지식을 쌓으세요 -킥오프부터 차이를 만드는 PM이 되세요- 고민되는

alwayshappydaysforever.tistory.com


03 서비스 뜯어보기 신공 (이미림 선배) 

 

kaily의 브런치스토리

커머스플랫폼 기획자 | 국내 IT 기업에서 PO로 재직중입니다. 커머스/패션/여가 플랫폼에서 다양한 서비스 기획을 해 본 N년차 기획자로서 경험을 통해 얻은 Insights를 공유합니다.

brunch.co.kr

 

서비스를 뜯어보며 성장하자
'서비스 뜯어보기'의 목적은
개인과 서비스의 성장에 있습니다.

1. 왜 뜯어봐야 할까요? 

1. 비즈니스에 대한 이해

- 우리 프로덕트가 어떤 플랫폼에 속하고 어떤 비즈니스를 하는지 파악해놓는게 좋습니다. 

 

2. 어떤 문제를 해결하는가

- 어떤 과제? 리소스 투자 대비 가장 임팩트가 큰 것 

- 문제가 정확하게 무엇인지 뾰족하게 정의

 

3. 타사 비즈니스에 대한 이해 

  경쟁 서비스 카테고리 대표 이외 서비스 
서비스명      
BM      
타깃 고객      
서비스 특징      
주요 지표      
버전 기록      

 

+각 서비스별 최근 기사나 보도 자료 정리하면 기능 캐치업하는 게 더 수월해질 것 

 

4. 타사는 어떤 문제를 해결하려고 햇는가? 

- 우리가 정의한 문제: PDP(상품상세페이지)에서 주문서까지 전환율이 낮다 

- 봐야할 부분: 

    a. PDP에서 주문서까지 전환율을 높이는 어떤 장치를 해놨을까?

    b. 각 컴포넌트, 기능, 정보는 어떤 목적을 가지고 있을까? (우리에게 없는 것 위주 / Ex. 배송 예측 정보 - 빠른 배송을 강조해 구매 의사결정 도움) 

 

2. 어떻게 뜯어봐야 할까요? 

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

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

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

- 최종 비교 

3. 어떻게 적용해야 할까요? 

- 서비스별 적용할 점을 리스트업했으니, 

이제 적용 예정 기능의 1) 목적2) 도입 시 선행되어야 할 점을 적습니다

 

ex. 카테고리별 유사 상품 추천 기능 

- 목적: 같은 카테고리 내 유사 상품을 추천해, 고객이 원하는 상품을 더 쉽고 빠르게 탐색할 수 있게 해 주문서까지 도달율을 높인다.

- 선행: 유사 상품 추천이 가능할 정도의 상품 pool이 있는지 확인

 

ex2. 포토 리뷰 모아보기

- 목적: 고객이 작성한 리뷰 중 이미지 리뷰만 모아 PDP 상단에 노출해 상품에 대한 객관적인 정보를 제공하고 구매결정을 돕는다

- 선행: 전체 이미지 리뷰 개수 확인 / 카테고리별 이미지 리뷰 개수 확인 

- 리뷰 가 충분히 없을 경우 이미지 리뷰를 늘리는 과제가 먼저 선행되어야 함

기억할 점; 타사에 노출된 형태를 그대로 따라하지 않는 것
-> 우리 서비스 성격과 타깃을 고려해 반영해야 한다 

 

 

04 본질적인 문제를 풀어라, 알맞은 방법으로 

더 나은 프로덕트를 만드는 과정에서 고민이 될 때, 
풀리는 고객 문제와 핵심 원인에 집중해야 한다 

왜냐고?
좋은 프로덕트는 필수적이고 본질적인 고객 문제를 잘 해결해줘서,
고객이 만족하고 너무 만족해서,
돈을 내서라도 계속 쓰고 싶은 프로덕트이기 때문입니다.

1. 제품 개선 순환 과정 (PIC, Product Iteration Cycle) 

PIC
: 고객이 쓰고싶은 제품일 확률을 높이는 과정 
: 필수적이고 본질적인 고객 문제를 잘 해결해줘서,
고객이 만족하고 너무 만족해서, 돈을 내서라도 계속 쓰고 싶은 프로덕트를 만들어낼 확률을 높이는 프레임워크 

 

- 애자일 소프트웨어 개발과 PIC

: MVP를 만들어 사용자 피드백을 기반으로 지속적으로 개선에 대한 가설을 세우고 검증하고 피드백을 받음 

: 이 과정이 PIC라는 프레임워크 

 

- 우리가 풀려는 고객 문제가 필수적이고 본질적인지, 고객 문제의 핵심 원인이 내가 생각한 게 맞는지 되짚어봐야 됩니다. 

2. PIC 1단계: 기회 포착 

고객에게 이런 니즈가 있는데 불만족스러워한다. 
이 문제가 가장 시급하고 만족시켜(해결해)주면 사업 목표를 달성할 수 있다. 
= 어떤 고객 문제를 풀면 목표가 달성될지 고민해야 한다. 
= 어떤 문제가 가장 임팩트가 클까?

 

3. PIC 2단계: 가설 수립 

가장 시급한 고객 문제의 핵심 원인은 이렇다.
이렇게 풀면 해결되고 기대효과가 날 것이다
= 이 문제의 핵심 원인은 무엇일까?

 

고객 VOC의 표면적인 말만 듣고 잠재 핵심 원인들을 정의했고,

이미 마음이 가있는 원인에 대한 VOC들 위주로 귀를 기울였기 때문입니다.

 

4. PIC 3단계: 실행 

핵심 원인과 더불어 제한된 시간과 리소스를 고려해서 
이런 요건을 갖추어 1차 가설을 검증하자. 
= 어떤 기능이 문제해결에 필수적일까?

 

고객 문제와 핵심 원인에 집중하지 않으면 '나와 동료들의 주관대로 고객이 원하는 프로덕트와 기능을 정의한다'는

부작용이 발생합니다.

현상: 쿠팡에서 화장품을 맘 편하게 사기 어렵다
문제: 품질에 대한 신뢰를 가지지 못한다
원인: 제품이 진품인지 믿기 어렵다

현상-문제-원인을 파악했으면 문제-솔루션 적합성을 판단해야한다.

> > 이 때 동료들의 가설과 논리에 비판적이어야 합니다. 

 

5. PIC 4단계: 가설 검증 

사용자 문제가 해결되지 않았고,
그 결과 목표가 달성되지 않았다.
이유는 이러이러하니 다음엔 이렇게 하자
= 문제가 풀렷나? 왜?
= 목표가 달성되었나? 왜? 

 

고객 문제와 그 문제를 해결했을 때

움직일 행동지표부터 돈까지 연결되는 지표구조를 만드는게 해결책이 될 수 있습니다.

 

Solve the Right Problem and
Solve it right

 

책 추천

  • 린 스타트업
  • 인스파이어드
  • 린분석
  • 스프린트
  • 스티브 크룩의 사용성 평가, 이렇게 하라
반응형