Chap 02. 서비스 기획자, PM, PO는 왜 필요한가

1. 인터넷 서비스의 역사와 기획자의 역할

< 출처 : 제로베이스 >

• 프론트엔드의 PO
  • 고객과 직접 대면 ⇒ 고객 데이터 분석, UX/UI에 강점 ⇒ 개발팀과 마케팅팀을 설득하면서 제품의 방향성을 잡아나감
• 어드민, 백엔드의 PO
  • 회사 비즈니스를 위해 사내 직원, 파트너 직원들이 사용하는 어드민과 백엔드 서비스의 PO
  • 고객 데이터 보드가 사업적인 임팩트와 생산성에 대한 데이터를 주로 활용하게 됨
  • 어떤 업체와 어떤 기능을 구현 또는 고려해서 제휴를 하고 어떤 상품을 판매하면 고객의 만족도와 회사의 매출에 얼마나 영향이 있을지
  • 또는 우리 어드민 서비스에서 어떤 기능을 어떻게 개선했을 때 우리 파트너사의 생산성 혹은 사내 직원들의 생산성이 얼마나 늘어나는지 등에 대한 데이터를 주로 다룸
  • 시스템 자체의 인프라 생산성과 정부의 규제를 지키기 위한 정책 준수 등에도 많은 리소스를 할당하고 있음
    • 시스템이 커지고 사용자가 많아질수록 지켜야 할 규제는 많고 또 시스템이 감당해야 하는 부하가 늘어나기 때문
• PO는 보통 스토리보드를 그리지 않고 제품을 정책을 정하고 해당 제품에 대한 PRD를 작성함

---

2. 서비스 기획자가 하는 일

• 해당 기업의 체계를 파악하기 위해 컨플루언스(위키 툴)를 많이 이용함
• ★ 본인이 없어도 다른 사람들이 이 일을 했을 때 빠르게 적응을 시키게 하기 위해서 해당 업무의 배경과 의사결정 과정 등을 일목요연하게 정리하는 것이 좋음

---

1)  문제 인식(목표 정의) 

• 현재 제품이 있다면 우리 제품에 대한 문제 정의일 것이고
• 제품을 만들어야 한다면 기존에 어떤 문제가 있어서 우리가 이것을 어떻게 해결해 나가야 할지에 대해 정의하게 될 것임
• 문제는 시스템 자체의 이유거나 정부의 규제 등으로 인해 생겨난 문제일수도 있음
• ★ 다양한 문제 중에서 우선순위를 정해서 가장 중요한 문제를 정하는 것이 중요함
• 타 부서에서 우선순위로 요청이 오는 문제가 실제로 급한 문제인지 미팅과 조사를 통해 확인해봐야 할 필요가 있음
  • 그 급한 문제가 우리 프로덕트와 큰 방향에서는 급하지 않은 이슈일 수도 있고, 그 문제점을 꼭 제품 기능 구현이 아니라 다른 방법으로 해결하게 되는 경우도 많음

---

2)  시장조사 & 벤치마킹 

• 해결하고자 하는 문제의 배경을 조사함
• 신사업을 할 경우 기존에 안되었던 것이 법적으로 문제가 있었는지 이와 비슷한 회사에서는 어떻게 해결하고 있었는지에 대한 조사를 함
• 해당 문제를 겪고있거나 해결하고자 하는 사용자 인터뷰를 면밀하게 하는 것이 중요함
• 신사업이나 기존 사업에 대한 확장이 아닌 기능, 시스템 인프라 개선이면 기존 시스템에 대한 분석과 그로 인한 사용자의 불편함을 실제로 조사하고 분석해야 함 ⇒ 이번에 꼭 해야 하는 중요한 일인지 파악!
  • 시스템 : 인프라 담당자 분과의 인터뷰
  • 기능 : 해당 기능을 사용하는 분들에 대한 상세한 인터뷰
• 신사업 혹은 확장 ⇒ 사업 계획서
• 인프라에 대한 개선 ⇒ 인프라 테스트 결과물, 사용자 UT

---

3)  정책 결정 요구사항 정의 

• 신사업, 기능 업데이트를 하기로 결정했으면 정책을 결정하고 기능에 대한 요구사항을 정해야 함
• 정책은 법적인 요건을 바탕으로 만듦
• 요구사항 정의서는 사용자 입장과 우리의 현재 리소스, 시스템적 이슈를 고려해서 만듦

---

4)  서비스 기획 

• 와이어프레임을 포함한 스토리보드 작업을 수행함
• 와이어프레임, 프로토타입 만드는 걸 디자이너가 하는 조직도 있음

---

5)  커뮤니케이션 & 매니징 

• 데일리 스크럼 : 매일 정해진 시간에 진행상황 공유

---

6)  QA 

• 개발 후 테스트
• QA팀이 있는 조직이어도 기획자가 해당 정책에 맞는 테스트 케이스는 QA팀에게 전달하거나 보통은 기획자도 같이 QA 하는 것이 일반적임
• QA팀이 없거나 QA 일정이 밀려 있다면 혹은 우리 프로덕트만 QA를 하기 위한 환경이 아직 세팅이 되어있지 않다면 사내 기획자, 디자이너, 개발자들이 QA 진행함
• QA가 끝나면 배포 공지를 하고 배포 시행함
  • 출시할 때는 보통 해당 프로덕트의 조금이라도 관련있는 모든 인력에게 공지함
  • 고객에게도 앱 스토어 업데이트 공지, 팝업 공지(고객이 꼭 알아야 하는 경우)

---

7)  매뉴얼 & 가이드 작성 

• 공지할 때는 매뉴얼과 가이드를 같이 첨부해서 실무 부서의 이해를 도와야 함
• 해당 가이드를 보통은 기획자가 쓰는 것이 일반적인데 바쁘면 디자이너분께 부탁을 할수도 있는 영역임

---

8)  서비스 운영(지표확인) 

• 출시 이후가 가장 중요함!
• 실제로 운영을 하면서 우리가 의도한 대로 사용자들이 사용하고 있는지 데이터를 봐야함
• 백엔드 어드민의 경우
  • 신규 서비스와의 연동 ⇒ 매출 혹은 예약률
  • 시스템이나 기능 개선 ⇒ 기능 사용률, 실제 사용자 인터뷰를 통해 지표 확인
• 우리의 가설이 맞았는지 틀렸는지 더 개선할 점은 없는지, 해당 업데이트가 다른 부분의 인사이트에 도움이 될 수 있는 부분이 있는지 파악해야 함

---

9)  그로스 해킹 

• 대고객 서비스라면 지속적인 성장을 위해 A/B 테스트를 하면서 그로스 해킹을 하면서 해당 기능 혹은 프로덕트에 대해서 더 발전 시키게 됨
• 조직 내에 그로스 해커가 있다면 그로서 해커와 함께 데이터를 뽑아보면서 같이 제품을 개선할 것이며
• 그로스 해커가 없다면 기획자가 하게될 것임

---

3. 목표를 잡고, 우선순위를 정하는 법

•  OKR (Objective, Key Result) 
  • 미국에서 구글 초기 투자자인 John Doerr에 의해 널리 알려짐
  • OKR에서 가장 중요한 것은 모든 조직 구성원이 하나의 큰 목표를 일치시켜서 내가 하는 일은 모두 다 그것을 이루기 위해서다라는 방향성과 목표가 공유되는 것임
  • ex. 모든 이용자들에게 가장 운영하기 편한 안전한 주문, 예약 시스템을 제공한다
  • ex. 대한민국의 모든 사람에게 가장 신뢰성있는 크립토 거래소를 만든다
  • 오브젝트를 설정하기 위해서는 모든 조직 구성원이 공감할 수 있는 목표여야 함
  • 아침에 자다가 그 목표를 생각하면 일찍 일어나게 되는 가슴이 떨릴 정도로 도전적인 목표를 설정해야 함
  • 목표를 설정하면 조직 구성원들에게 공유하고 절대 바꾸지 말아야 함
    • OKR은 매우 도전적인 목표이므로 절대적으로 바꾸고 싶을 수도 있음
    • OKR을 바꾸지 않기 위한 철칙은 인사평가를 OKR로 하지 않는 것임
    • 인사평가와 결부되면 목표를 도전적으로 잡는 데 망설여질 수 있을 것이기 때문

---

< OKR의 특징 >

• 전사적 목표 일치 + 도전적 목표 설정 + 투명한 목표 공유
• Key Results는 객관적인 수치가 중요함
• ex. 구매 전환율 40% 달성, 상품 등록 효율 20% 개선

---

< RICE 기법 >

• 목표를 위한 우선순위를 정하는 것도 기획자의 역할
• 적은 리소스로 더 많은 고객에게 더 큰 영향력을 끼칠 수 있는 것을 먼저 개발해야 함

• RICE 점수 = {(해당 기능을 사용할 사용자 수) + (고객의 영향력) + (해당 기능에 대한 스스로의 자신감)} / (투입 리소스)
• Reach : 도달 범위, 특정 기간에 해당 기능을 사용할 수 있는 사용자 수
• Impact : 고객에게 줄 수 있는 영향력 (매우 큰, 적당히 높음 등)
• Confidence : 신뢰도 = 기획자가 생각하는 해당 기능에 대한 자신감
• Effort : 개발, 기획, 디자인 리소스

---

< MSCW 방법론 >

• 적은 리소스로 더 많은 고객에게 더 큰 영향력을 끼칠 수 있는 것을 먼저 개발하다보면 시스템적인 이슈를 간과할 수 있음
• 시스템적인 이슈나 법적 이슈는 기능적인 부분보다 크리티컬 할 수가 있음
• 이럴 때 보안으로 쓰는 것이 모스코우라고 하는 방법론임
• Must Have : 법적, 보안적 이슈 및 서비스의 핵심을 위해 반드시 구현해야 하는 기능
  • ex. ISMS를 인증받기 위해 고객에게 좀 더 불편하거나 혹은 영향이 없지만 시스템의 안정성을 위해서 또 보안 수칙 준수를 위해서 개선해야 하는 작업, 결제 시스템 붙이는 작업 등
• Should Have : 우선순위는 높지만 이것이 없어도 큰 문제는 아닌 기능
• Could Have : 있으면 좋은 기능
• Won't Have : 이번에는 만들지 않을 기능

---