본문 바로가기
개발/세미나

인프런 PM, PO 밋업 (240502)

by 상5c 2024. 11. 10.

일시

  • 24.05.02. 18:30 ~

링크

연사자

  • 김민우님

Product Manager

  • 문제를 정의하고 해결하는 사람.
    • 고객의 문제를 해결하는 제품을 만드는 사람
  • 전환 (핵심 역량)
    • 이 사람이 똑똑한가? 원래 하던 일을 잘하고 있는가?
    • 케이스
      • 비판적 사고
      • 자기 일 열심히
      • 논리적 체계적 사고
      • 커뮤니케이션
  • 예전에는 서비스 플래너? 라는 정체불명의 직책이 있었음.
    • 현재는 기획 == PM으로.. PM이 기획이라고 불리는게 아니라 기획이 PM이라고 불리는 느낌.

PM PO 용어에 집착하지 말자.

  • 해외에서는 PM(Porduct Manager)으로 통일. PO 안씀.
    • 자료 찾을 떄 참고.
  • 한국에서는
    • PO = 전략 + 의사결정
    • PM = 실행 이라고 많이 알려짐.
  • 용어 혼돈을 주는 것들
    • SAFe PM + SAFe PO = Scrum PO
      • SAFe에서는 역할을 둘로 구분..
        • PM → 비전, 전략
        • PO → 택틱
  • 아무튼 그러니 용어 집중하지 말자.
    • PO PM 지원할 때 어떻게 해야되나?
      • JD도 못미덥긴 함. 실제 회사에서 어떻게 일하는지 보자.
  • PO (프로덕트 오너)
    • scrum에서 나온 말.
    • 보통 PM이 전략, 고객 담당.
  • PM (프로덕트 매니저)
    • 마켓 리서치부터 계획 수립, 요구사항 정의해서 프로”젝”트 매니저에게 전달.
      • ProjectManager → 실행. 개발팀과 소통하며 제품 만듦
  • Scrum Porduct Owner
    • 전략 + 실행 모두 수행
    • 전략과 실행을 따로하면 동떨어진 실행을 하게 된다.
    • 주로 토스와 쿠팡에서 쓰이면서 PO가 퍼지게 되었음.

PM이 아닌 것

  • 기능을 기획해서 출시하는 사람?
    • 기능 출시가 목표인 PM (현실은 이렇다) → 이렇게 일하면 전문성을 쌓지 못한다고 생각
      • 기능 개발 프로젝트 시작한다.
      • 이해관계자 요구사항 취합하고 맞춰 기능을 기획한다. (특히 b2b가 그럼)
      • 프로젝트 담당할 디자이너와 엔지니어(리소스)를 할당받는다.
      • 기획서를 만들어 디자이너와 엔지니어에게 넘긴다.
      • 프로젝트 일정 내에 요구사항에 맞춰 개발을 완료하도록 프로젝트 관리한다.
      • 기능 완성해서 배포한다.
      • 다음 프로젝트로 넘어간다.
    • 토스에선..
      • 가설 수립, 검증, 데이터 기반…
  • PM은 이해 관계자들의 요구를 충족하는 제품 만드는 사람이 아니다.
  • PM은 이해관계자 커뮤니케이션이 주 역할인 사람이 아니다.
    • 남들도 다 하는 것임.

진짜 PM

  • 한마디로 주어진 문제만 해결하는게 아니고, 일이 되도록 하는 것.
    • 고객, 이해관계자 요구사항을 충족시킨다고 성공할 수 없다는 것을 이해한다.
    • 비즈니스에서 어떤 성과를 내야 하는지 이해한다.
    • 회사의 전략에 맞춰 제품의 방향성을 세운다.
    • 제품에서 어떤 지표를 개선해야 하는지 안다.
    • 어떤 레버리지를 이용할 수 있는지 이해한다.
    • 정량적, 정성적으로 고객들의 문제를 파악할 수 있다.
    • 어떤 문제를 해결하면 좋은 성과를 낼 수 있는지 이해한다.
    • 하나의 문제를 해결하는 방식이 다양하다는 것을 이해한다.
    • 프로덕트 디자이너와 엔지니어들과 함께 다양한 가설과 해결책을 탐색한다.
    • 정량적, 정성적으로 검증한다.
  • 현대적 PM이면 그림 직접 그릴일 거의 없다.
    • Figma, wireframe 죄송하지만 뒤떨어짐… 상세한 기능 명세서와 화면 설계서 안만든다.
    • 기획/디자인/엔지니어 철저히 분업하면 “넘어온대로 만들면 된다”는 마인드가 생긴다.
      • 모든 직군이 제품의 성공보다 프로젝트 수행에 초점을 맞추게 된다. 안티패턴.
      • Feature factory. 기능을 찍어내는 공장이 됨.
      • 스타트업에서는 특히 나쁜 업무 방식임. 각종 안티패턴 존재
    • 상세 문서부터 만드는 팀은 대부분 가설 검증 X
      • product iteration 하는 팀
        • 가설 수립, 수정, 시도, 발전
        • 스타트업에게 중요한 방식
        • 검증할게 많다.
      • 상세 스펙 문서에 집중하는 팀
        • 요구사항을 확정하고 일정 맞추는 것을 중시
        • 요구사항 변경을 나쁜 것으로 여김
        • 고객을 만나서 가설을 검증하고 경로를 수정하는 일은 일어나지 않음.

PM은 뭐 하는 사람이냐?

  • PM 바이블로 여기는 책 - INSPIRED (MARTY CAGAN)
    • 아래 내용들은 다 여기 나온 내용이 많음.
  • 프로덕트가 성공하려면?
    • 성공적인 프로덕트: 두 가지를 만족해야 한다.
      1. 고객에게도 가치,
      2. 우리 사업에도 도움.
      • 이걸 되도록 하는게 PM의 역할
  • 성공적인 프로덕트 네 가지 조건
    • valuable 고객이 가치를 느낀다.
    • usable 사용성을 느낀다
    • feasible 기술적으로 구현 가능하다
    • viable 사업적 타당한. 이해관계자들이 받아들일 수 있는 제품. 이걸로 팔 수 있겠다, 운영할 수 있겠다.
  • 제품 조직이 마주하는 네 가지 리스크
    • value risk 고객들이 원하지 않고 유저가 사용하고 싶어하지 않는 제품
    • usability risk 사용자들이 이용하기 어려운 제품
    • feasibility risk 알고 보니 기술적으로 구현하기 너무 어려운 제품
    • business viability risk 사업적으로 타당하지 않은 제품. 비용 비효율, 법이나 규제 저촉
    • PM은 네가지 리스크 중 특히 value, business viability risk를 책임지는 직무이다.
  • PM은 제품의 성과 전반을 책임지는 사람이기도 하다.

PM 고유의 전문성?

  • PM 고유의 전문성 네 가지
    • 우리 사용자와 고객에 대한 심층적인 지식
    • 데이터에 대한 심층적인 지식
    • 우리 비즈니스에 대한 심층적인 지식
    • 우리 산업에 대한 심층적인 지식

우리 사용자와 고객에 대한 심층적인 지식

  • 프로덕트 만들 때 제일 중요한 것?
    • 고객이 어떤 문제를 갖고있는가, 솔루션을 만들었을 떄 어떤 어려움을 해결하는 가.
  • 정성적 지식, 정량적 지식. (만나기, 행동 패턴)
  • 프로덕트 기반은 실제 사용자와 고객들에 대한 심층적 지식
    • PM은 고객 전문가가 되어야 한다. 고객 심층적 지식 없이 하는 생각은 그저 ‘추측’이다.
  • 고객 전문성을 쌓으려면?
    • 직접 만나야 한다.
    • 고객 관찰(어떻게 쓰나, 다른 제품은 어떻게 쓰나) 이야기 나누기
    • 1:1 심층 인터뷰, 사용성 테스트 등.
  • 이것들은 고객 만나기가 아니다.
    • 고객지원 부서가 수집하는 VOC 전달받기
    • 영업 부서가 듣고 온 고객 의견 전달받기
    • 리서치 담당자가 수행한 리서치 결과를 전달받기
  • 직접 만나야만 얻을 수 있는 것들
    • 어떤 사람을 깊이 알고자 할 때 어느 쪽이 효과적일까?
      • 중간 매개자를 통해 전달 받기 vs 직접 인터랙션 하기
    • 전달받으면 생략이 많아진다.
      • 어떤 생각, 고민, 행동이 있었는가. 어떤 맥락에서 어떤 경험을 하고 느꼈는가?
    • 고객 깊이를 알고 싶을때도 마찬가지.
  • 직접 만나서 관찰하고 소통하면 얻을 수 있는 것
    • 설문조사는 더 궁금한게 있을 때 후속 질문이 어렵다. 직접 만나야 함.
    • 고객에 관한 생생하고 풍부한 정보.
    • 요약 안된 풀 버전
  • 준비하고 고객 만나라. 무작정 고객 만나라는게 아님.
    • 공부와 준비가 필요함.
    • 리서치 설계, 실제로 수행하면서 지식을 몸에 체화시키는 작업이 필요함.
      • 안하면 되는대로 질문하게 됨. 원하는 주제에 대한 질문이 안나온다.

데이터에 대한 심층적인 지식

  • 유저 데이터 분석 툴로 우리 제품이 어떻게 이용되고 있는지 전문가 수준으로 알아야 함. 변화도.

  • 데이터가 시간이 지나며 변화하는 것도 알아야 함

  • 데이터 분석가의 도움도 가능하지만 맡기기만 해선 안됨.

  • PM의 데이터 활용 (크게 보면 4가지)

    1. 지표 이용해 사업 현황 한눈에 파악
      • 9월 → 10월 넘어갈 때 유지한 고객은 n명, Month over month 리텐션 율은 97%
      • 지난 주 30만 사용 (WAU)
      • 각 영역별 다양한 지표들이 존재함.
        • acquisition
        • engagement
        • retention
      • 주니어/시니어 가르는 행동
        • 시니어 PM이라면 지표 직접 설정. 의사결정
        • 주니어 PM이라면 기존 지표 읽고 내가 담당하는 제품 현황 파악, 개선 지점을 찾음.
      • 지표 잘 이해하려면
        • 어떤 지표가 있고 무엇을 의미하고 어떤 의사결정을 할지.
        • 건강검진과 같다고 생각한다고 함.
          • 모르는 사람이 보면 암호. 전문의는 데이터.
        • 프로덕트 지표들
          • d7 retention
          • nrr
          • mrr
          • activation rate
          • time spend/wau
          • L5+/7
      • 데이터 툴 다루는 역량
        • SQL 방식 → 쿼리 작성
        • tableau, redash 등 비즈니스 인텔리전스 툴
        • amplitude mixpanel 등 프로덕트 애널리틱스 툴 (데모데이터 체험할 수 있다)
          • ab180 등… 리셀러 있음
          • 원본 데이터 뽑아서 직접 분석하려면 엑셀, r, python 등 다뤄야 할 수 있음.
            • sql만으로 충분하다고 생각.
    2. 데이터 드릴다운해서 인사이트 찾기
      • 전체 집계 값을 더 깊이 들여다보기
        • 예) 지난 주 사용자(WAU) 10만
          • 연령대로 보면 10대가 8만으로 80%…
          • 지역별로 보면 …
          • 기존과 신규로 나눠보면 …
        • 데이터 드릴다운 - 총집계된 지표를 자세히 쪼개서 보는 것.
      • 드릴다운 잘하려면?
        • 데이터 툴을 잘 다루는 능력이 필요.
      • 호기심과 집요함
      • 엑셀 피벗 테이블
        • 빨리할 땐 이거 씀.
    3. 실행하기 전 타당성 평가, 우선순위 세우기
      • 팀의 귀중한 시간과 자원을 쓰는 것이라 최대한 안될 만한 것에 낭비해선 안된다.
      • 결과 예측은 어려운 일.
        • 예) 새로 기능 만들면?
          • 얼마나 쓸지
          • 유저 만족도는
          • 리텐션과 매출은 얼마나 높아질지?
        • 결과 예측하라는게 아니다. 미리 타당성을 평가하라는 말임.
          • VOC → 실제 고객 불편인가 타당성
          • 지표(데이터)를 보면 개선 영향도를 알 수 있다
    4. 실행한 뒤 결과 정략적으로 측정하고 평가
      • 몇 명이 사용하는가? feature adoption
        • 목표만큼 많은 유저가 사용하면 1차적 성공으로 판단.
      • 한 번 사용 후 계속 이용하나? feature retention
        • 한 번 이용하고 마는게 아니라 계속해서 이용한다면 2차적 성공으로 판단.
      • 지표 개선 측정은 당연한 일이다.

  • 지식 습득 → 업무 적용 → 개선 → 반복해서 체화해야 한다.

  • 역량 어떻게 쌓나요? 저희 회사는 데이터 없고 환경이 안되어있어요.

    • 데이터 기반으로 일하려면 → 데이터 관련 환경, 즉 적절한 툴이 있어야 함.
    • 데이터 제대로 축적되어야 함
      • 유저 행동(event) 특히 PM에게 중요.
    • 사이드 프로젝트?
      • 의미있는 데이터로 의미 있는 의사결정 및 실행을 해야 한다.
        • 충분히 많은 유저, 의미 있는 데이터가 쌓여야 한다.
        • 현실적으로 어려움…
      • 데이터 기반 일하는 역량을 쌓기 위해 사이드 하는건 비추.
    • ‘그런 회사’에서 일해야만 역량을 쌓을 수 있다.
      • 우리 회사를 그런 곳으로 만들거나 (어렵고 번아웃옴. 비추)
      • 그런 회사로 가거나

우리 비즈니스에 대한 심층적인 지식

  • 우리 회사의 go to market 전략 이해
  • 우리 사업이 어떤 식으로 작동하는지 이해
  • 다양한 이해관계자들이 어떤 니즈를 가지는지 이해
  • 우리 수익모델 이해
  • 마케팅, 매출, 비용요소, 개인정보, 윤리적 고려 등
  • 제품팀 다른사람들은 여기 신경을 안쓴다.
  • 지식 쌓으려면?
    • 공부.
      • 일반 지식(전략, 마케틱, 영업) → 책이나 기타 등등
      • 우리 회사의 비즈니스 현황 → 물어봐서 아는 수밖에 없다.

우리 산업에 대한 심층적인 지식

  • 경쟁사 지식 + 산업 주요 동향 파악
  • 기술 트렌드, 고객 행동, 고객 기대
    • ai.. 어떻게 제품에 적용할 수 있을까..
  • 과거 시장이 아닌 내일의 시장을 대상으로 제품을 만듦

학생이나 취준생은?

  • 쉽게 가르칠 수 없는 역량
    • 논리적 체계적 사고
    • 복잡한 현상에서 핵심 파악
    • 문제 정의 구조화
    • 해결책 도출
    • 조리 있게 커뮤니케이션.
    • 특히 비판적 사고
      • 면접을 심층적으로 보다보면 티난다.
      • 주도적으로 문제 정의하고 해결해본 경험이 도움 되는 것 같다.
  • 서비스 기획 아이디어? 근거가 없으면 오히려 마이너스일지도.
    • 밖에서 낼 수 있는 아이디어는 근거가 없는 경우가 많다. 왜 중요한지, 정말 이게 방향이 맞고 적절한 역할인지.

타 직군에서 직무 전환을 노리는 사람은?

  • 왜 어떤 문제를 도출했고 어떻게 해결하려 했는지가 중요.
  • PM 대부분은 신입때부터 커리어 쌓은게 아님. 타직군 전환이 더 많다고 생각.
    • 결국 내 일을 잘하고 PM 소양을 보이는 사람이 전환이 잘되는 듯 함.

질문

회사를 바꾸고자 설득한다면 뭐부터 하실건지? 제일 중요한게 뭐라고 생각하시는지

  • 뜻을 같이하는 사람을 만들어라.
  • 회사의 변화에는 두 가지가 필요. “리더의 의지”와 “작게작게 시작해 보는 것”
    • 예를 들어 프로덕트 관점에서
    • 작게 시작해 볼 것. 문제의식을 공감하는 사람들이랑 시작해보길 추천함.
    • 인내심이 많이 필요하다. 대표도 경영진도 의지가 있었지만 3년정도 걸린 것 같다. 인내심을 가지고 주변 사람과 작게 시작해 볼 것.
저작자표시

관련글

티스토리툴바