서비스 기획자, PM, PO는 왜 필요한가﹖
인터넷 서비스의 역사
크게 네 가지 시대로 나눌 수 있다 게시판 시대 / 포탈 시대/ 모바일 시대/ 포스트 코로나 시대
서비스기획자, PM, PO담당 업무와 필요역량 정리
⚡︎서비스 기획자
(스토리보드에 중심을 두고 일함)
⭐️ 담당 업무
→ User Scenario 발굴 및 개선, 고객 니즈 분석 및 요구사항, 우선순위, feature 정의, 상세설계 작성
🌟 필요 역량
→ 데이터에 기반한 논리적인 사고를 바탕으로 사용자와 서비스에 대한 인사이트
→ 협업 부서와의 커뮤니케이션을 통해, 의견 차이를 조정하고 결과물에 대한 시너지
⚡︎PM(Product Manager)
(제품과 관련된 모든 활동을 담당하고 관리하며 책임을 지는 사람)
⭐️ 담당 업무
→ 시장의 흐름, 해결할 가치가 있는 문제 정의, 문제를 해결할 수 있는 핵심적인 기능을 설계하고 비즈니스, 디자인, 테크 조직과 협업하여
제품에 반영
🌟 필요 역량
→ 데이터를 기반으로 한 의사결정 및 문제 해결 능력
→ 어떤 상황에서도 프로덕트를 성공시킬 수 있는 의지와 역량
→ 자신의 생각을 글과 목업으로 누구에게나 명료하게 설명할 수 있는 능력
⚡︎PO(Product Owner)
(비즈니스 및 의사결정에는 Waterfall, 개발에는 Agile 두 가지에 대한 책임)
⭐️ 담당 업무
→ 제품을 주도하는 역할, 문제 또는 사업 영역을 정의하고, 실행의 우선순위를 결정
→ 유효한 가설을 수립하고, 실험을 통해 도출된 인사이트를 기반으로 가설 검증 및 Product-Market Fit을 찾고, 제품을 고도화
🌟 필요 역량
→ 데이터 기반으로 다양하고 복잡한 문제를 해결하는 Analytic Mindset
→ 궁극의 고객 경험을 달성하고, 시장을 혁신하는 제품을 발굴할 수 있는 역량
→ 성과를 만들어내는 Grit(열정과 집념이 있는 끈기)
스스로 목표와 전략을 설정하고 논리적인 커뮤니케이션을 통한 협업
서비스 기획자가 하는 일
서비스를 만들기 위한 설계도를 그리는 사람
문제인식(목표 정의)
시장조사 & 벤치마킹
→ 사업계획 & 전략기획
→ 사용자 및 환경 분석
정책 결정 요구사항 정의
→ 정책서 및 요구사항 정의서
서비스 기획
→ 기획서(스토리보드)
커뮤니케이션 & 매니징
→ 칸반보드 회의록
QA
→ Qa 시나리오 버그리포트
매뉴얼 & 가이드 작성
- 매뉴얼
서비스 운영 (지표확인)
→ 분석 환경 설계 매뉴얼
→ 지표 통계 리포트
그로스 해킹
→ A/B 테스트 결과 리포트
✨ 한줄 ✨
→ 기업 마다 다양해서 이 모든 업무를 다 할 수 있는 상황이 생길 수도 있고 아니면 특화되어 주 포지션이 생길 수도 있다.
서비스기획자가 목표를 잡는 방법론
⚡︎ OKR(목표,성과 지표)
OKR | KPI |
개인, 팀 및 모든 조직과 자유롭게 연결된 전략 | 개인, 팀 간에 상하위로 일치된 전략 |
회사의 목표를 달성하기 위해 무엇이 중요한지 모두에게 알림 | 전체 전략을 각 부서의 운영 활동 및 접근방법을 모색 |
나타난 결과치 보다는 결과의 이유에 집중 | 나타난 결과치에 보다 집중 |
공격적인 목표치를 설정 | 달성가능한 목표치 설정 |
역할에 맞게 명확한 커뮤니케이션을 할 수 있는 프레임워크 | 조직 성과와 연계 |
상향식 및 하향식 | 리더십 주도 - 하향식 |
성장지향 | 성과 관리 중점 |
⭐️ OKR의 특징
1. 전사적 목표 일치
2. 도전적 목표 설정
3. 투명한 목표 공유
※인사평가를 OKR로 하면 안 됨 그러면 목표를 낮게 잡는 단점이 생김
우선순위 잡는 일반적인 방법론
⚡︎ R.I.C.E방법론
→ 해당 기능을 사용할 사용자 수에서 고객의 영향력을 더 하고 그리고 해당 기능에 대한 스스로의 자신감을 더하고 그것을 투입 리소스로
나누는 기법
→ 이 방법론을 통해서 좀 더 적은 리소스로 더 많은 고객에게 더 큰 영향력을 끼칠 수 있는 것을 먼저 개발할 수 있도록 하는 것
• Reach
→ 도달 범위, 특정 기간에 해당 기능을 사용할 수 있는 사용자 수
• Impact
→ 고객에게 줄 수 있는 영향력(매우 큰, 적당히 높음 등)
• Confidence
→ 신뢰도 기획자가 생각하는 해당 기능에 자신감
• Effort
→ 개발, 기획, 디자인 리소스
⚡︎ 보안으로 쓰는 MoSCoW 방법론
• Must Have
→ 꼭 만들어야 하는 기능으로 법적, 보안적 이슈 및 서비스의 핵심을 위해서 꼭 구현해야 하는 기능
• Should have
→ 우선순위는 높지만, 이것이 없어도 큰 문제는 아닌 기능
• Could have
→ 있으면 좋은 기능
• Won't have
→ 이번에는 만들지 않을 기능
⚡︎Tip. 실무하다가 바쁠 때 4분면 두고 생각
✨ 한 줄 ✨
아침에 자다가 그 목표를 생각하게 되면 일찍 일어나게 되고 또 가슴이 떨릴 정도로 야심 차게 목표를 잡아라 끊임없이 배우고 배우고 배워라..
보통 기획자가 하지 않는 일 (코딩, 디자인, 사업개발, PR) 하지만 작은 조직 경우 다할 수도 있다.
'PM > daily-study' 카테고리의 다른 글
제로베이스 PM스쿨 1주차 ☀️4 (0) | 2023.02.21 |
---|---|
제로베이스 PM스쿨 1주차 ☀️2 (0) | 2023.02.10 |
제로베이스 PM스쿨 1주차 ☀️1 (0) | 2023.02.06 |
제로베이스PM스쿨 0주차 스타뜨(feat.OT)👊 (0) | 2023.02.06 |
댓글