06. 서비스 기획자의 역할(1)
1. 서비스 기획자란?
- 팀 플레이어 역할 (제품'에 대해서 이야기하는 사람)
- PO, PM, 기획자 등 세부적인 업무는 상이, but '커뮤니케이션'이 가장 중요한 직업
1) 서비스 기획자란?
- 서비스 기획자
- 서비스 기획자 역할: 사용자의 필요성을 파악, 이를 해결하기 위한 방안을 설계하는 역할
이를 위해, 사용자를 이해하고 그들의 문제를 해결할 수 있는 제품 혹은 서비스를 기획하고 제공.
- 협업능력 필요: 서비스 기획자는 혼자서 제품을 만들 수 없기 때문에 UX, 개발팀, 비즈니스 등 다양한 부서와 협업하는 능력이 필요. 각 팀의 역할을 이해하고, 팀 간의 어려움을 해결하며 보틀넥을 제거하는 역할도 수행.
- 기획서 작성 및 실질적인 커뮤니케이션 능력: 기획자는 자신의 의도와 제품의 의도를 명확하게 전달하는 능력이 필요.
- 다양한 역량 필요: 디자인(UX), 기술(Tech), 사업(Business)의 역량을 갖춰야 한다. 사용자 친화적인 화면설계와 제품의 스펙, 그리고 사용자와 사업자 모두를 고려한 사업적인 역량이 필요.
2) 서비스 기획자의 주요 업무
- 4가지 단계 전반적인 이해 필요.
- 어떤 도메인, 시장, 제품에 자신이 관심있는지 먼저 확립하는 것이 중요.
2-1) 서비스 기획 (Pre-Production 레벨에서 하는 업무, 가장 중요):
제품이 개발 단계에 들어가기 전에 서비스의 목표를 설정하고 실현하기 위한 프로젝트 전반을 담당.
- 설계도(시장 리서치, 정보구조(IA) 설계, 화면 설계 등)에 집중하며, 제품이 실현 가능한지 확인.
- 검증과 검토 단계
2-2) 기술 기획:
서비스 출시를 위해 적용할 기술을 검증하고 적용 범위를 검토.
- 기술이 실제로 구현 가능한지에 대한 기본적인 이해도가 필요, 스펙 정의, 기술 리뷰 및 회고, QA 등을 수행.(커뮤니케이션 비용 비약적 감소)
2-3) 운영 기획:
서비스의 원활한 운영을 위해 장애 대응, CS응대 등의 지원 업무를 수행.
- 주니어 레벨의 기획자가 시장 상황, 서비스 범주, 스펙에 대한 이해도를 높이기 위해 이 업무를 담당.
2-4) 데이터 기획:
서비스 운영 및 개선을 위해 로그 설계, 운영, 데이터 추출 및 분석을 진행.
- 데이터가 시장, 제품에 어떤 의미를 갖고 있는지 판단, 분석 업무가 중요.(데이터 추출보단 분석하는 역량이 중요)
- 데이터의 결과가 어떤 의미를 가지는지 분석하는 역할이 중요하며, 이를 위해 도메인 지식이 필요.
3) 조직 성격별 서비스 기획자 역할
3-1) 제품 개발: (내부 프로덕션팀에서 고객의 니즈 상품 개발 → VOC 확인)
- 가장 일반적인 형태
- 외부 사용자의 니즈를 정제하여 제품 방향성을 설정: 이를 위해 고객의 니즈를 데이터를 통해 추출하거나 운영팀을 통해 직접 VOC를 확인.
기술, 운영, 데이터 기획 등 모든 업무를 인하우스에서 진행.
- 비즈니스관련 팀과 논의를 통해 피처리스트정리
3-2) 내부 제품 개발: (Customer(제품사용자)가 이미 인하우스에 있는 형태)
- 내부제품(ex.인하우스 대시보드) 개발
- 사용자가 내부에 있어 니즈 파악이 용이
- 커뮤니케이션 비용이 가장 낮은 형태: 인하우스 직원들이 사용 → 사용성,디자인 덜 고려 → 커뮤니케이션 비용 감소
3-3) 외부제품개발: (외주를 통해서 제품을 개발)
- 내부에 개발팀이 없거나 외주를 통한 개발팀을 운영하는 형태 (개발팀 미보유, 개발은 외주사용)
- 내부에서 피처리스트 정리하여 외부개발조직에게 전달
- 커뮤니케이션 비용이 가장 높은 형태(외주기에 비용 최고가)
2. 서비스 컵셉과 방향성 도출하기
- 서비스 컨셉: 어떤 작품이나 제품, 공연, 행사 따위에서 드러내고자 하는 주된 생각
1) 서비스 컨셉의 중요성
- 문자,슬로건적으로 WHY에 대한 답변
- 서비스 컨셉: 서비스를 이해하고, 사용하려는 사용자나 팀 내의 다른 멤버들에게 서비스의 특징과 목적을 명확하게 전달하는 역할.
- 컨셉이 명확하면 사용자의 이해도를 높이고, 서비스에 대한 진입장벽을 낮춰준다.
- 서비스, 제품을 왜 해야 하나요? → 시장에 대한 상황에 적합성 파악 → 시장 상황에 맞는 서비스 컨셉 도출 → 논리를 통해 개발자, 디자이너, 사업팀 등을 설득해야 함
2) 좋은 컨셉과 나쁜 컨셉
- 컨셉이 한 귀에 들어오냐 ↔ 안 들어오냐
- 내부 팀과의 커뮤니케이션에서도 컨셉이 명확하면 서비스 개선에 대한 필요성을 명확하게 인식시키고, 팀원들의 동기부여를 유발
- 좋은 컨셉을 도출 = 좋은 기획자
3) 서비스 컨셉 설정 단계
- 아래부터 적용시 좋은 서비스 컨셉트 기획 가능
3-1) 문제의식 발굴: 사용자의 니즈와 내부 팀의 니즈를 파악.
-시장 트렌드
-서비스 모니터링
-개인의 경험
등을 통해 니즈를 파악합니다.
3-2) 문제의식 검증: 문제의식이 실제로 문제로 인식되는지 검증.
- 데이터 추출 및 분석: (정량적 지표) 실질적으로 사용성 측면에서 문제 의식 발굴
(이탈률, 부정적인 지표 확인)
- 리서치: (정성적 지표) 즉각적인 사용자의 목소리를 통해서, 정말 문제인지 인지 판별
- 벤치마킹: 경쟁사, 자신이 몸담고 있는 도메인에서 잘하고 있는 부분은 적용, 못하고 있는 부분은 개선 (문제의식부터 잘못된 부분인지 캐치)
3-3) 개선사항 도출: 문제의식을 바탕으로 문제 해결 방안을 제시.
- 해결방안이 실제로 구현 가능한지 production 단계 검증
3-4) 서비스 컨셉 설정: 문제의식과 해결 방안을 토대로 서비스의 주된 생각이나 가치를 정의.
- 문제 발굴 → 문제 검증 → 문제 판별 → 해결책
- 서비스 설계의 가설을 설정하는 단계
- 서비스의 제공 가치를 정의하는 단계
3-5) 성공사례. Airbnb
- 문제의식: 샌프란시스코의 디자인 콘퍼런스 때문에 숙소 만실 (숙소 부족 인지)
- 문제검증: 에어베드 2개를 두고, 이베이 같은 곳이 숙소와 아침식사 제공의 공고
- 결과: 다수의 사용자가 서비스 이용
- 개선사항: 문제의식 검증 후, 여러가지 집의 형태 확대
- 서비스 컨셉: 세계 전지역 ‘언제 어디서나 좋은 숙소를’ 슬로건과 컨셉 제공
4) 서비스 컨셉 설정 고려사항
- AARRR 프레임워크: 서비스 개선 단계별 확인 지표설정하고 가설 검증을 진행 (서비스 컨셉 도출 단계에서 확인 가능)
4-1) AARRR 프레임워크 각 단계별 고려사항
- Acquisition(사용자 유치): 사용자 유치를 위한 가설을 설정
(측정지표(KPI) 검증 = 트래픽, DAU, MAU)
- Activation(사용자 활성화): 이미 서비스가 출시되었을 때, CAC, CPC, 이탈률 등을 KPI로 설정하고 기능 추가/수정을 진행.
(측정지표(KPI) 추가/수정 = CAC, CPC, 이탈률(부정적인 지표를 확인하여 개선), 사용자 유치)
- Retention(사용자 유지): 서비스의 재사용율을 높이기 위해, 재방문 수와 재방문률 등을 KPI로 설정. (KPI: 재방문 수, 재방문)
- Referral(사용자 추천): 사용자 추천을 통해 공유수, 초대코드 등을 KPI로 설정하여 바이럴 마케팅을 진행. (KPI: 공유 수, 초대코드(추천인, 수신인 베네핏))
- Revenue(수익): 최종 목표는 케이스마다 다르므로, DAU, 매출, 이탈률, 사용자 피로도 등 케이스에 맞는 KPI를 설정. (KPI: 케이스마다 상이(DAU, 매출, 이탈률, 사용자 피로도 등))
3. 목적 중심 조직, 기능 중심 조직에서의 기획자의 역할
1) 기능조직(Component Team)과 목적조직(Feautre Team)
- 기능조직: 동일한 직군의 인력으로 조직을 구성하며, 필요에 따라 리소스가 할당되어 업무를 진행
동일한 직군의 인력으로 구성된 조직으로, 각 팀의 역량에 따라 아이템이 할당되어 업무를 진행. 기획자 중심으로 커뮤니케이션이 진행되며, 전문성이 뛰어나다.
- 목적조직: 다양한 직군의 인력(기획,개발,디자인,사업…)을 하나의 목적 아래에 조직을 구성하여 업무를 진행
다양한 직군의 인력을 하나의 목적 아래에 모아 업무를 진행. 서비스의 전 과정을 함께하며, 프로젝트에 따라 특정 기능이 부각되지 않는다.
- 양자택일하는 것이 아니라, 상황에 따라 적절한 조직 구조를 선택합니다. 예를 들어, 빠른 커뮤니케이션이 필요한 경우에는 TF팀과 같이 기획, 디자인, 개발이 한 팀에 모여 작업을 진행하기도 합니다.
1) 기능조직과 목적조직의 비교
| 기능조직(Component Team) | 목적조직(Feautre Team) | |
| 조직 운용 방향 | 가능한 많은 업무를 한번에 처리할 수 있도록 최적화 | 가능한 많은 고객 가치를 전달하도록 최적하 |
| 업무 진행 방식 | 여러 개의 프로젝트를 병렬적 진행 | 한가지 프로젝트만 진행 |
| 조직 규모 | 조직규모가 상대적으로 크며, 지속 성장하는 경향 | 조직규모를 유지하는 경향 |
| 조직간 의존성 | 팀 간의 의존성이 추가 계획 수립으로 이어짐 | 유연성을 높이기 위해 팀 간의 의존성을 최소화함 |
| 전문성 | 한 가지의 직군의 조직원으로만 구성 | 다양한 직군의 조직원으로 필요에 따라 구성 |
| 조직 운용 방식 | 워터폴 선호 | 애자일 선호 |
| 실행 난이도 | 상대적으로 쉬워 보임 | 상대적으로 어려워 보임 |
1) 기능조직(Component Team)에서의 서비스 기획자 역할
- production 단계로 커뮤니케이션 비용 더 발생
- 주로 운영중인 제품에 대한 기능개선이 필요한 경우 배치됨
: 초기제품 보다는 이미 사용하고 있는 사용자가 있는 서비스에 대해 기능 개선, 서비스 운영
- 기획자는 각 기능을 하나의 프로젝트 단위로 할당 받음 (서비스의 여러가지 기능 중에 한-두가지만 기획자 담당)
: Ex) 인스타그램 - 다양한 기능 중 릴스, 포스팅, 검색, 팔로워 등 서비스에서 일부 2,3개 할당
- 제품의 방향성 및 요구사항은 정해져있는 케이스가 많음
2) 목적조직(Feautre Team)에서의 서비스 기획자 역할
- 신규 프로젝트 or TF형태에서 많이 보이는 형태
- 기획자는 하나의 제품단위로 프로젝트를 할당 받음 (기획자의 역량)
- 제품의 방향성 및 요구사항 설정 필요
- 제품내 각 기능간의 상호관계를 고려 필요 (리소스,시간 조율 없이, 프로젝트 담당자로 이행 가능)
- 각 인원은 하나의 프로젝트에 집중하는 케이스가 많음
n 모르는 단어
- 보틀넥: 시스템의 성능을 제한하는 요소 (비즈니스: 생산 과정에서 한 단계가 다른 단계보다 느려 전체 프로세스의 효율성을 저하시키는 경우, 그 느린 부분)
- DAU(Daily Active User): 일간 활성 사용자 수
- WAU(Weekly Active User): 주간 활성 사용자 수
- MAU(Monthly Active User): 월간 활성 사용자 수
- CPC(cost per click): 사용자가 1번 클릭하는데 드는 비용
'PM(Product Manager) > 학습일지 2주차' 카테고리의 다른 글
| 5 day 2024.01.13. (2) (1) | 2024.01.13 |
|---|---|
| 5 day 2024.01.13. (1) | 2024.01.13 |
| 4 day 2024.01.12. (1) | 2024.01.12 |
| 2 day 2024.01.10. (1) | 2024.01.10 |
| 1 day 2024.01.09. (3) | 2024.01.10 |
