새싹 IT 서비스 기획자(러닝스푼즈) 프로덕트 설계 1

23.01.02 ~ 23.01.04

이번 현직자 강의는 프로덕트 설계다.
프로덕트 설계는 다음과 같이 진행됐다.
 

1. 개요
2. 프로덕트 설계
3. 서비스 기획
4. 프로토타이핑/UT
5. PO의 기타 업무

PO가 전반적으로 맡게 되는 업무의 흐름을 배울 수 있었다.
특히 기획 이외에도 챙겨야 할 부분과 서비스를 출시할 때, 주의해야 할 점들도 배울 수 있었던 강의였다.
 
 

1. 개요

Product Manager (PM)이 되기 위해서는 어떤 역량을 키워야 할까?
바로 Tech, Business, UX 세 가지의 영역의 역량이 필요하다.
그럼 왜 이 역량들이 필요할까?
 
1) 테크
기술적인 지식이 있어야 기획을 할 시, 실제로 구현이 되는지 판단할 수 있다. 그리고 개발팀들과 소통을 할 때 원활한 소통을 진행할 수 있다.
 
2) UX
기획자는 서비스의 화면을 설계해야 하고, 사용자들이 어떤 행동 패턴을 하고 무엇을 원하는지 파악해야 한다.
즉, 사용자의 경험을 많이 생각해야 한다.
 
3) 비즈니스
서비스를 통해서 어떻게 수익을 얻을지, 기업이 성장할지도 판단하고 계획해야 한다.
 

세 가지 측면을 공통적으로 가지고 있어야 하고 회사, 서비스에 성장이나 가치를 제공할 수 있는 사람이 = PM이다.

 

PM이 가져야 할 역량

 
 

2. 프로덕트 설계

프로덕트를 설계할 때 "이 서비스를 어떻게 해야 성공할까?"라는 고민을 많이 할 것이다. 이 과정에서 어떤 방식으로 고민을 하는지가 성공한 프로덕트를 나오는데 큰 역할을 한다.
 
지금부터 하나하나 알아가 보자.
 

왜 사람들은 우리 서비스를 사용하지 않을까?

스타트업의 실패 원인 통계 자료

통계 자료를 보면 시장 니즈가 없어서 망하는 것을 볼 수 있다.
처음 프로덕트를 기획했을 때, 분명 사용할 사람은 있기 때문에 프로덕트를 기획하고 시장에 출시를 했을 것이다.
하지만 시간이 지날수록 유저의 수는 변하지 않고 감소하는 것을 볼 수 있을 것이다. 쓸려는 사람은 있지만, 대세는 아니기 때문이다(고객이 많지 않음).
그래서 우리는 진정한 고객이 원하는 니즈를 만족시킬 수 있는 프로덕트를 찾아서 설계해야 한다.
 
이를 위해서 PMF(Product Market Fit)를 찾는 것이다.
 

2-1. PMF(Product Market Fit)

PMF

• 지수적이며 자생적인 성장
• 좋은 시장에 그 시장을 만족시킬 수 있는 제품을 갖고 있는 것
• Value proposition(어떤 제품 또는 서비스를 만들 것인가)과 Customer segment(누구를 위해 그것을 만드는가) 사이의 핏을 맞추는 과정

 

PMF를 찾는 과정

1) 문제 정의
2) 솔루션 도출
3) 사업 모델 검증
4) 규모 확대 or 피벗

PMF를 찾아 정의를 한 제품일수록 유저의 이탈률이 적고 서비스가 유지될 수 있는 것이다. 그리고 이를 기반으로 업그레이드하여 성장할 수 있는 것이다.
 
만약, PMF가 없거나 못 찾을 경우는 다음을 고려해야 한다.

• 우리 제품을 구매하는 고객의 형상에 대해 특정하기 어려움
• 고객 여정을 명확하게 그리지 못함
• 무료 사용자는 우리의 제품을 사용하는 것이 아님
• 판매 주기가 느리거나 발생하지 않는 제품
• 평가판(trial) 사용 후 즉시 이탈

유저가 어디에서 많은 트래픽이 일어나는지 파악하여 이를 기점으로 PMF를 정의한다면 서비스를 유지하고 업그레이드하는 데에는 큰 도움이 될 것이다. 이런 것을 찾고 생각하는 것이 PM, PO, 서비스 기획자가 해야 하는 것이다.

 
 

2-2. Aha Moment

Aha Moment

• 제품의 핵심 가치를 경험하는 순간 서비스를 계속 쓰게 되는 특이점
• 정량적으로 정의되는 이 행동을 한 유저 대부분(약 95%)이 리텐션이 생기는 행동
• 정성적으로도 상식적으로 인과관계가 성립하는 순간
• 복잡하고 정교한 분석의 결과가 아닌, 아주 단순한 산수이며 팀원들이 무지성으로 추종할 수 있는 단순한 문장

 

Aha Moment의 기준

• simplicity, not science
• 팀원 모두가 쉽게 추종할 수 있는 숫자를 찾는 것이 중요

 

Aha Moment 운동

아하 모먼트에 기여하는 일을 한 사람은 착한 사람, 기여하지 않는 일을 한 산 사람은 나쁜 사람

아하 모먼트 운동

 
 

Aha Moment 찾는 과정
 

1) 리텐션 데이터 확인

• 현재의 리텐션 상태 이해
• 예) 30일간의 그래프 시각화
• 코호트 분석: 특정 기간 공통된 특성이나 경험을 갖는 집단 간의 행동 패턴을 비교 분석
• 활용 툴: Google Analystics, Mixpanel, Amplitude, …

2) 가설 설정

• 어떤 행동이나 기능이 리텐션에 영향을 줄 수 있을지 가설 설정
• 가장 충성도 높은 유저와 이탈한 유저 간의 raw data 비교 등

3) 가설 검증

• 유저들을 특정 행동을 했는지 안 했는지에 따라 그룹화
• 행동 기반 코호트 차트로 행동과 리텐션의 연관 관계 확인
• 모든 핵심 행동을 기준치와 비교해 보고, 기준치와 큰 차이가 없다면 다른 지표에 집중

4) 적정한 액션의 빈도 탐색

• 최적의 리텐션을 위해 해당 액션이 몇 번 이루어져야 하는지 확인
• 해당 행동을 한 유저들 중 남아있는 유저(Retained)와 남아있는 유저들 중 해당 행동을 한 유저(Took Action)의 교집합을 아하 모먼트로 정의 가능
• 특정 행동의 빈도수 또는 유지 여부에 따라 코호트를 분석하면, 리텐션을 높이기 위해 가능한 많은 특정 행동을 해야 한다는 결론에 이를 수 있음
• 겹쳐진 영역을 최대화할 수 있는 최적점을 찾으면서, 그 외 영역을 최소화해야 함
• 최적점을 찾기 위해 특정 행동을 하지 않았으나 유지된 유저의 칼럼을 추가
• 교집합의 영역이 극대화되는 지점 탐색

5) 그래프 점검

• 행동 분석을 위한 코호트 차트를 만들어 리텐션 시각화

6) 인과관계 파악

• 최적의 구분점과 행동을 찾았어도, 해당 분석은 상관관계를 나타냄
• 인과관계 파악을 위해서는 제품의 변화가 실제로 리텐션이 어떤 영향을 주는지 A/B 테스트 등 실행

 
 

3. PO의 기타 업무

3-1. QA

QA(Quality Assurance)

• 개발 후 운영(리얼) 서버에 배포하기 전에 기획에 맞게 개발되었는지 검증하는 행위
• 체크 포인트
  • 기능성: 기획자가 의도한 기능들이 올바르게 작동하는지 검증
  • 심미성: 오탈자가 있는지, 표시되는 이미지에 문제가 없는지 검증
  • 호환성: 디바이스/OS/버전/브라우저 등에 따라 동일한 형태로 구현되는지 검증

 

테스트의 분류

정적 테스트 (Static Test)

• 프로그램 코드를 실행하지 않고 여러 참여자가 모여 소프트웨어 개발 중에 생성되는 모든 명세나 코드를 검토해서 실패(failures)보다는 결함(defects)을 찾아내는 방법
• 동료 검토 (Peer Review)
  • 동료에게 코드나 여러 가지 산출물에 대한 검토를 의뢰
  • 비공식 검토 (격식 x, 형식 x)

 
동적 테스트 (Dynamic Test)

• 테스트 데이터를 이용해 실제 프로그램을 실행함으로써 오류를 찾는 방법
• 구조 기반 테스트 (화이트 박스 테스트)
  • 구현된 소스코드와 내부 구조를 바탕으로 T/C를 결정
• 명세 기반 테스트 (블랙박스 테스트)
  • 소스코드, 내부 구조 참고 x
  • 사용자의 요구사항이 기술된 명세나 테스터의 경험을 바탕으로 T/C를 결정

동적 테스트 프로세스

 

기획자는 제품의 기획과 개발이 끝나고 업무가 끝나는 것이 아니다. 기획이 끝나고 난 이후, 실제 기획한 기능들이 제대로 작동하는지 체크하는 것과 특정 시나리오들을 세팅하여 테스트를 완료하는 것도 중요하다.
이를 체크하지 않고 시장에 서비스를 출시했을 시 생기는 불이익들은 고스란히 우리에게 돌아오기 때문이다.

---

출처

[새싹X러닝스푼즈] 유니콘 기업 현직자에게 배우는 IT 서비스 기획자 취업 캠프 프로덕트 설계
https://sesac.seoul.kr/course/active/detail.do