[PM부트캠프6기] 0324 Today I learned

오늘 늦잠자서 9시 2분에 들어왔다 ㅜㅜㅜ... 10분만 더 자야지가 이런 사태를 불러왔😅😅

그래도 후다닥 준비해서 오전 스크럼 마무리하고 오전에 읽을 아티클 하나 선정해서 읽고 인사이트를 남겼다.

 

그리고 오늘의 목표! 어제에 이어서 서비스 기획 입문 챕터 2 모두 수강을 이어서 진행하였다

---

서비스 기획 입문

[Chapter 2)

• 목표수립
  • 목표수립을 하기 위해서는 가장 상위의 목표 프로덕트 비전, OKR, KPI를 이해해야한다.
•  프로덕트 비전: 프로덕트가 장기적으로 어떤 모습이 되기를 원하는지에 대한 큰 그림
  • 팀에 나침반 같은 장기적인 방향성을 제시해준다.
  • 경영진이 주도해서 설정한 비전이 있어야 구체적인 사업을 진행할 수 있다.
• OKR: 목표(Objective)와 그 목표를 달성하기 위한 핵심 결과(Key Results)를 정의해서 목표 달성 진척도 측정
  • 주로 팀의 리더와 PM이 함께 설정한다.
  • 약간의 도전 요소과 포함되지만, 지나치게 비현실적이지 않은 수준에서 설정된다. (보통 7-80% 달성률)
  • 조직의 목표를 설정하기 위해서는 VOC, 내부 정량 데이터(주요 퍼널을 정의해 동종업계 기준 지표와 비교), 내부 전문가의 인사이트, 외부 레퍼런스와 비교, 외부 리서치 자료를 참고해보면 좋다.
  • KR은 "목표가 달성되면 어떤 지표가 변화할까?" 라는 역질문에서 시작하면 좋다.
  • KR 지표의 기준: Specific(구체적), Measurable(측정가능한), Achievable(달성가능한), Relevant(목표와 관련 있는), Time-bound(기간이 정해진)
• KPI: 조직, 팀, 또는 개인이 설정한 목표에 대한 달성 수준을 측정하기 위해 사용하는 정량적 또는 정성적 지표
  • KR은 비전을 달성하기 위해 조직과 팀원이 한방향으로 나아가도록 세운 도전적 목표이고, KPI는 비즈니스 전반의 성공을 측정하기 위한 지표에서의 차이가 있다.
• 목표 수립 과정
  • 프로젝트 혹은 과제의 목표가 이 비전, OKR, KPI에 기여할 수 있는지 확인하고 이에 따라 목표를 상세하게 세워야한다.
  • 비전은 장기적인 방향성을 제시하고, OKR은 단기적인 목표를 명확히, KPI는 그 목표 달성을 추적하는 방식이다.
• 주의점
  • 사용자 가치와 비즈니스 가치 사이에서 어느 한쪽에 치우치지 않도록 균형을 잘 맞추어 전략을 설정해야한다.
  • ex) 카카오톡 생일알림 기능이 편하다 vs 부담스럽다라는 사용자 의견이 갈렸긴 했지만, 비즈니스적으로 보면 카카오의 매출을 상승 시키는 것에 성공함 

OKR은 무엇을 달성한 것인가에 초점에 맞춰 주로 단기적으로 설정.
KPI는 어떻게 성과를 측정할 것인가에 초점 맞춰 지속적으로 추적. 

목표 수립에 있어서 가장 먼저 고려해야 하는건 프로덕트 비전, OKR, KPI 이다.
또 빠르게 목표를 잡고 실행하여 스프린트 기간마다 확인해 나가는 것도 좋다. 

• 문제 정의 과정
  1. 현상 발견
     • 비즈니스, 사용자 양쪽에서 문제 현상을 살펴볼 것(OKR, KPI 달성을 가로막는게 무엇인지, 사용자 쪽에 무슨 문제가 있는지 확인)
     • 다양한 정량 / 정성 방법을 동원해서 문제 현상을 발견 - 적절한 타이밍에 서로 상호보완하는 방향으로 유연하게 활용할 것.
  2. 문제 정의
     • 목표 달성에 방해가 되는 문제 현상을 간단하게 작성하고, 이 현상으로 인해 발생하는 부정적인 영향이나 결과를 명확히 설명한다. 그리고 근본적인 원인이 무엇인지를 파악한다.
     • 즉 현상 / 영향(사용자, 비즈니스 구분) / 원인 세가지를 구분해서 생각 해야한다.
     • 방법론 (기본 Base: 쪼개서 생각하다보면 답이 보인다.)
       1. 5 Whys: 문제의 근본 원인을 찾기 위해 "왜?"를 5번 반복적으로 묻는 방법
          • ex) 문제: 사용자가 주문을 완료하지 않는다.
          • 1차 왜?: 사용자가 결제 페이지에서 이탈한다.
          • 2차 왜?: 결제 페이지가 로딩이 느리다.
          • 3차 왜?: 결제 서버의 성능이 부족하다.
          • 4차 왜?: 서버 최적화가 이루어지지 않았다.
          • 5차 왜?: 서버 최적화를 위한 자원 할당이 부족하다.
       2. 로직트리: 나무 구조처럼 하나의 큰 문제를 여러 가지 세부적인 나무가지로 분리한 후, 이를 다시 해결할 수 있는 구체적인 질문이나 하위 항목으로 나누는 방식
          • Mutually Exclusive(상호 배타적): 각 요소는 서로 겹치지 않아야 한다.
          • Collectively Exhaustive(전체 포괄적): 누락된 항목이 없도록 문제의 모든 측면을 다뤄야 한다.
  3. 핵심 문제 정의
     • 여러 문제가 있을 수 있지만, 모든 문제를 동시에 해결할 수 없으므로 우선순위를 매겨 핵심 문제를 선택해야 한다.
     • 우선순위 판단 방법
       • 높은 임팩트, 낮은 노력 (Quick Wins): 우선적으로 해결할 문제
       • 높은 임팩트, 높은 노력 (Major Projects): 중요하지만 해결하는 데 시간이 많이 걸리는 문제
       • 낮은 임팩트, 낮은 노력 (Fill-ins): 자투리 시간에 해결할 수 있는 문제
       • 낮은 임팩트, 높은 노력 (Hard Slogs): 가급적 나중에 해결할 문제
     • 우선순위는 시기마다 달라질 수 있으며, 당장은 중요하지 않아서 백로그에 넣어두지만 시대가 변화하면서 다시 수면 위로 올라올 수 있다 → 배민 함께주문 기능처럼.
  4. 주의할 점
     • 문제 정의를 제대로 하기 전에 미리 해결방안을 정해두고 시작하면 안된다. → 문제 정의가 왜곡될 수 있고 제대로 된 문제해결로 이어지지 않을 수 있다.
     • 문제를 발견했을 때 있는 그대로 해석해서 바로 해결방안을 도출하는 것이 아니라, 진짜 문제인지에 대해서 여러모로 정의해보는 것이 중요하다.
     • ex) 고객 VOC: “사용자가 앱 내의 텍스트가 너무 작아서 읽기 어려워요” 라면
     • 고객이 원하는대로 글씨 크기를 키우자 이런식으로 해결방안을 미리 정하는 것이 아니라
     • 고객이 시니어인가? 다른 고객들도 그렇게 느끼는가?, 해당 텍스트가 중요한가?, 진짜 크기가 작아서인가? 위치나 색상때문은 아닐까? 라는 질문을 던지며 문제 정의부터 제대로 하는 습관을 가져야한다.

내가 지금까지 생각했던 문제들은 사용자 관점에서의 현상만 기록한 것에 불과하다는 것을 알게되었다.
또한 고객의 문제를 그대로 해석했던 점도 있었던 것 같다는 반성을 하게되었다.

문제의 현상을 파악했으면 구체적으로 질문을 던지며 진짜 문제의 원인을 파악해볼 것.

고객의 문제를 그대로 해석하지말고, 다양한 관점에서 바라보는 시각을 가질 것.
고객의 목소리일지라도, 정말 이럴까? 에서 시작해서 어떤 고객인지, 다른 고객도 그렇게 느끼는지?, 어떤 원인이 있을지?에 대해서 먼저 질문해보는 시간을 가질 것.

• 가설 수립 & 검증
  • 해결 방안 도출: 이때 해결 방안은 아직 확정된 내용이 아니라, 검증되지 않은 가설 (=가설 기반 사고)
  • 가설 수립
    • 가설은 보통 '~하면 ~할것이다' 로 작성된다.
    • 좋은 가설은 왜 이렇게 도출되었는지에 대한 정량적인 근거, 이 가설을 어떻게 실천할 건지에 대한 자세한 내용, 그리고 이렇게 했을 때 어떤 데이터가 얼만큼 변할지 + 목표 지표에 대한 내용, 이 가설을 검증할만한 방법까지 자세하게 작성한 것이다. (ex) 지원동기 작성 퍼널에서 이탈하는 유저의 90%는 직장인이다. (근거) → 직장인 지원동기 예시를 보여주면 공감대를 형성해 불안감을 해소할 수 있으니 이탈 유저 90% 중 30%가 지원서를 제출할 것이다. 어떤 예시가 더 효율이 좋을지 A/B테스트 실험을 설계해보자. (가설)
    • 가설 검증 방법
      • A/B 테스트 - 두가지 버전 중 어떤 게 더 좋은지 알고 싶을때
      • 사용자 인터뷰 - 사용자가 무엇을 원하는지 알고 싶을때: 초기 아이디어 검증이 필요할 때
      • 유저 테스트 - 제품을 실제로 써보며 개선할 점을 찾고 싶을 때
      • 오픈 후 결과 데이터 분석 - 기능 출시 후 데이터로 성과를 확인하고 싶을 때
      • → 각 방법마다 장단점을 고려해서 선택해야한다.
  • 가설 검증
    • 정성 리서치만으로는 정확도에 한계가 있고, 정량 리서치만으로는 고객의 진짜 의도와 속뜻을 증명하기 어렵기 때문에 신뢰할 수 있는 결과를 위해선 두가지 리서치가 함께 진행되어야 한다.
    • ex) 쿠팡 유료 멤버십 서비스 로켓와우를 중도 해지한 고객이 있다. 인터뷰(정성)에서 고객에게 멤버십 해지 사유를 물으니 "혜택이 유용하지 않다"고 답했다. 더불어 서베이(정량)를 진행했을 때 무료배송, 새벽배송 및 당일배송이 와우 전용 혜택인줄 모른다고 체크했다. but 이 고객은 이러한 혜택을 이용했음을 확인했다.
    • → 즉 어떤 고객은 와우 전용 혜택을 경험하고도 이를 혜택으로 인지하지 못한다는 가설을 세우고 이에 맞게 액션을 취해서 로켓 와우 이탈을 줄일 수 있었다.
    • 가설 검증 후 예상보다 결과가 나쁘더라도, 이를 통해 얻은 인사이트를 기반으로 가설을 수정해서 다시 검증하고 점진적으로 개선해나가면 된다.

가설 설정할 땐 최대한 구체적으로 작성할 것. (근거 + 목표)

가설 검증할 때에는 정성 / 정량 리서치를 함께 진행해서 정확도를 높이는 것이 좋다.

완성도와 임팩트는 뭐가 더 중요하다는게 아니라 목표에 따라 둘 사이의 밸런스가 중요하다. 
작은 단위로라도 임팩트가 크게 변화할 수 있다. 즉 강력한 가설 하나만으로 큰 성과를 만들어낼 수 있다.

• 서비스정책이란?: 서비스 운영에 필요한 모든 규칙과 기준을 담은 안내서 
  • 예시: 회원가입 정책(연령 제한, 지역 제한, 이용 자격 등), 서비스 운영 정책(콘텐츠 가이드라인, 저작권, 금지 행위 및 제재, 동시 접속 제한 등), 결제 정책(배송/반품/환불, 결제), 개인정보 정책
• 좋은 서비스 정책: 서비스의 목적에 부합하면서도 사용자 경험을 해치지 않고, 법과 운영 현실 모두를 고려해 리스크를 최소화한 결정이다.
  • 서비스 방향성 제시 : 당근마켓의 동네 인증 등
  • UX의 일관성 확보: 정책은 서비스 전체의 일관된 경험을 만들어줌
  • 리스크 대응: 악용 케이스에 대한 대비 필요 → 반품 정책을 악용한다든지, 1원 송금 인증을 악용해서 10만원 벌은 고객 등
  • 법적 준수: 개인정보보호법, 전자상거래 등 관련 법령을 준수, 앱푸쉬 보내기 전 알아야 하는 정책들 반영
  • 운영과 기술 구현 가능
  • 사용자 입장에서 이해 가능
  • 일관성 있고 예외가 적음
• 서비스 정책 기획 과정: 왜 필요한가 → 무엇을 고려해야 하나 → 어떻게 만들고 실행할 것인가
  • 고려 요소 정리할 때 외부요인(법률, 플랫폼 정책, 연동 기준 등)과 내부요인(기존 정책과 충돌 여부, 리스크 요소 등)으로 나눠서 정리해야한다.
  • 정책을 기획했다면 내부적으로 공유하고 피드백 받아야함.

서비스 정책도 굉장히 다양하며, PM이 이러한 서비스 정책도 정해야 한다는 것을 새롭게 알게되었다.

그저 법이나 정책에 따라서 정해지는줄 알았는데, 세부적으로 정책 구조를 설계할 때 정해야 할 것들이 많다.
→ 이용권 종류, 결제 방식, 자동 결제 여부, ... 등 하나하나 직접 다 짜야함. (구체적인건 자료로 확인)

내가 알던 앱푸시들도 다 서비스 정책이었고, 자세한 규정이 있다는 것을 알게 되었다..(굉장히 밀접해있었구나..)

서비스 정책 기획할 때는 동종업계 다른 서비스의 정책을 참고하면 좋다.

• 와이어프레임: 웹사이트의 골격이나 애플리케이션의 사용자 인터페이스 및 핵심 기능을 나타내는 단순한 선과 도형으로 구성된 다이어그램
  • 최근에는 프로덕트 디자이너의 고유 영역으로 보지만, 회사마다 다를 수 있다.
  • 설계 단계
    1. 화면의 목적을 정의한다 - 사용자가 여기서 어떤 행동을 하길 바라는가? 처럼 목표 행동을 정의
    2. 목표 행동을 가로막는게 무엇일까? 병모고 포인트를 찾아서 제거
    3. 노출되어야 할 정보를 전부 나열 - 사용자에게 보여줘야 할 정보를 모두 나열하고, 관련 정보끼리 그룹핑
    4. 여러 화면을 넘나드는 맥락의 흐름을 함께 설계 - 화면 간 연결 방식을 설계
    5. 사용자 행동의 순서에 따라 레이아웃 구조 결정 - 사용자 시선 흐름도 고려하기
    6. 다양한 케이스를 고려한 와이어프레임을 그리기 - 사용자의 행동이 실패했을 때, 정보가 비어있을 때 등
  • 그리는 도구: 종이와 펜, 파워포인트/키노트, 피그마

와이어프레임 작성 시, 유저 플로우를 생각하는 것이 가장 중요한 것 같다.
해당 단계에서 끝이 아니라 맥락의 흐름을 다양한 케이스별로 나눠서 구조를 설계할 것.

최종적으로,
목표 수립 단계에서 중요한 것은 
1. 프로덕트 비전에 대해서 먼저 살펴본다.
2. 그 비전에 맞게 해당 팀에서 사용자를 구분해보고 방문 목적에 따라서도 나눠본다.
3. KR을 잡기 위해서는 "프로덕트가 사용자에게 기대하는 최종 액션은 무엇인가?"를 떠올리며 잡는다.

문제 정의 단계에서 중요한 것은
1. 다양한 방법을 활용해서 문제 발견 (프로덕트 분석시에는 가장 상위에 있는 구좌일수록 중요도가 높다는 것을 기억)
2. 사용자 입장에서 어떤 불편함이 있을지, 사용자를 쪼개서 생각
→ 문제의 원인의 원인을 찾자 !!!

가설 수립 & 검증 단계에서 중요한 것은
1. 구분한 사용자들에게 각각 다르게 원인을 제거한 지면을 보여준다.
2. 검증하기 위해, 목표 수립 때 잡았던 지표를 사용자를 구분해서 각각 살펴본다.
3. 정성 / 정량적 리서치를 통해 교차 검증

 

이렇게 오늘은 챕터 2를 모두 수강하였다.

문제 정의 ~ 가설 수립 & 검증 단계까지 새로운 점들과 중요한 것들을 자세하게 배울 수 있었다.

 

이후엔 이제 오후 팀 스크럼을 진행했고, 아티클들 자세히 들여다보았다.

 

오늘은 사실 꽤나 불량학생이었다ㅠㅠ 그래서 학습 자료에 나와있는 숙제들 하려다가 못본척 패쓰했는데....내일 해야겠지,,하하

오늘은 놓아주고 내일을 힘차게 바라보자 아자쓰!!!!!!!!!!!!!!!!