본문 바로가기
PM Career

[헤이조이스 콘조이스] 성공하는 PM의 7가지 법칙 Day 2

by B Diary 2022. 4. 19.

1. 토스 PO 안지영님* 👍

*토스의 7번째 멤버. 제네럴리스트(CS, PR, 마케팅, 사업개발)에서 PO로 직무 전환

PO로서 중심잡고 일하기

내가 이 방향으로 가는게 맞나? 내가 정말 중요한 일에 집중하고 있는게 맞나? 

 

1) 제품 방향성이 막연할 때, 중심 잡는 법

'백로그' 관리*가 중요하다. 백로그를 잘 관리하면 '뭐하지?'라는 고민에 방향을 줄 수 있고, 현재 어디에 집중하고 있는지 한 눈에 알 수 있다. 백로그는 결국 현재 팀 업무 현황에 대한 상황판 역할을 한다.

*토스에서는 'PON 리스트'라고 불리는 템플릿으로 백로그를 관리한다. (Day 1 아티클에서 김유리님도 소개했던!) 

  • KPI: 회사 측면에서 가장 상위레벨의 KPI (e.g. 고객경험, 매출, 성장 등) 이후 내가 실행한 프로덕트들이 어떤 KPI를 달성하기 위한 것이었는지 모아서 보면 방향성 맞게 잘 가고 있는지 점검해볼 수 있다. 
  • Sub metric: 우리 팀이 움직여야 하는 지표. 데이터 모델링을 통해 찾은 business lever를 활용하면 좋다. (e.g. NPS, 가입 전환율, 친구 초대 수 등)
  • 소스: 아이디어의 원천. 회고를 통해 아이디어의 원천이 골고루 분포하는지 점검하는 것이 좋다. (e.g. 고객, 팀 인사이트, 데이터 분석) 
  • PON(Problem/Opportunity/Needs): 내 제품의 문제와 기회요인들  
  • Definition of Awesome: 해당 기능이 구현됐을 때 미래의 모습. Value.  
  • Priority: 우선순위 판단  

 

2) 신규 개발할 때, 중심 잡는 법

MVP는 개발 공수 크기 자체보다는 '최소 가치'로 전달될 수 있게 기획된 제품이다. 우리의 가설이 옳았는지 검증하기 위해 제공될 가장 작은 가치가 담겨 있어야 한다. MVP 단계에서 하는 흔한 실수들은 다음과 같이 변경되어야 한다.

  • 있으면 좋으니까 개발하기 → 핵심가치를 검증하는데 필요하지 않다면 과감히 빼기
  • 런칭하자마자 대규모 푸시 보내기  → 소규모 오픈하여 고객의 목소리 면밀히 수집하기
  • 예측에 기반해 스펙 추가하기 → 코드 짜기 전에 고객에게 물어보고 짜기.
    • 고객이 뭔가를 해달라고 할 때 그 목소리를 곧이곡대로 든는 것이 아니라 그 이면에 정말로 원하는 것이 어떤 것인지 구체적으로 파악하기
  • 런칭하고 자랑하고 축하하기 → PM fit을 찾았을 때 축하하기

MVP를 대하는 PO의 마음가짐이 달라져야 한다. 런칭하자마자 동료와 고객에게 인정받고 싶은 에고를 버려야 한다. 오히려 아무도 안 쓸 것이라고 기대하고 만드는 것이 좋다. 이 제품이 6개월 뒤 없어질 수 있는 제품이라는 생각으로 만드는 것이 좋다. 런칭은 제품의 시작이기 때문에 그 자체가 축하할 일은 아니다. PM fit을  찾았는지 가늠해볼 수 있는 방법은 크게 다음 세 가지가 있다.

  • 우리 제품의 핵심가치를 1번이라도 경험한 사용자를 대상으로 간단한 설문을 실시하는 것이 좋다. "이 서비스가 없어지게 된다면 실망하게 될 사용자가 40% 이상"이라면 PM fit을 찾았다고 본다. (35~40%: 성공확률 높음, 20~30%: 애매한 grey zone, 긍정적인 신호의 마지노선, 20% 이하: 제품이 충분한 모수로부터 사랑받고 있지 않다.)
  • NPS(Net Promoter Score, 추천지수): "이 프로덕트를 친구나 동료에게 얼마나 추천하시겠어요?"에 대한 의견을 듣고, 점수를 매긴다. (0~6: 비추천, 7~8: 중립, 9~10 추천) 이후 추천 고객의 % - 비추천 고객의 % 가 80% 이상이 나와야 좋은 프로덕트로 평가된다.
  • Retention Curve: 토스에서는 40~50% 정도를 좋은 Retention rate라고 잡고 있다. 

Retention Curve ©(주)플래너리

리텐션이 잘 나온다면, 우리 제품에 가치를 발견한 사용자를 우리 제품에 가치를 발견하지 못한 사용자와 구별해주는 특정 행위들을 의미하는 '아하모멘트'를 찾을 단계이다. 즉, 아하모먼트는 우리 제품을 잘 쓰는 대부분의 사용자가 하는 특정 행위들을 의미한다. 아하모먼트를 찾아내면*, 우리 제품의 라이트 유저들이 로열 유저들이 되기 위해 해야 하는 액션들이 명확해진다.

아하모먼트 찾는 법을 위해 추천하는 아티클

 

3) 멘탈 중심잡기

어렵고, 지치고, 치이고, 두려울 때 중심을 잡는 팁을 위한 책 추천: <팀장의 탄생>

  • 내가 모르면 남들도 모르더라
  • 내가 어려우면 남들도 어려워하더라
  • 내가 나를 못믿는데, 고객을 어떻게 설득시킬 것인가?
  • 나는 나여서 내 방식으로 할 때, 나다울 때 가장 성공할 수 있다. 자신감!

 

2. 이마트 서비스기획 Chapter Lead 류예나님 👍

일 잘하는 PM의 잘 드러나지 않는 찐스킬

고객에 대한 인사이트와 리더십이 있다면 누구든 PM이 될 수 있다. 그리고 Convice, Creative Connect, Calm, 이 세 가지가 있으면, '일 잘하는 PM'이 될 수 있다. 

  • Convince(확신): 프로덕트에 대한 확신이 없으면 시작하지 말자. 
    • 방법을 찾는 것보다 문제를 이해하는 것이 훨씬 더 중요하다.
    • 많은 경우 Top-down 식으로 Painpoint 가설이 주어지고, 심지어 Solution까지 제시된다.
    • 진짜 Problem을 찾기 위한 100% 동의 가능한 가설을 찾아 재정의해야 한다.
    • "고객의 진짜 목소리를 들을 수 있는" 어떤 방식이든 상관없고, 데이터는 그것을 거들 뿐이다. 
  • Creative Connect(창의적 연결): 새로운 것을 만드는 것이 아니라 '기존 것을 연결하여 새로운 것을 만드는 것'
    • 창조는 낯선 것을 익숙하게(Creative Thinking) 하는 것이고, 혁신은 익숙한 것을 낯설게(Distruptive Thinking) 하는 것이다.
    • 아무도 예상하지 못한 솔루션으로 시장을 놀라게 하고, 결국 전체를 새로운 방향으로 이끌어 가는 사고 방식
    • 시장과 고객의 머리 속에서 당연시 하고 있는 고정관념들 중 파괴의 영역 선택 (업종, 배달, 시간, 가격, 서비스, 장소, 결제방식, 생산방식, 프로모션, 타겟 등)
창조란 모든 것을 연결하는 것이다. -Steve Jobs-
세상의 모든 창조는 이미 존재하는 것들의 또 다른 편집이다. -에디톨로지-
  • Calm: 완강한 저항이 있어도 적당함과 타협하지 않고, 침착하게 조긱간 원활한 가교 역할을 하는 것 
    • PM은 목표를 정하고 그 목표 달성의 방법을 제시하는 역할만 하는 것이 아니다. 수많은 사람을 만나고 복잡한 태스크를 다루는 만큼 다른 의견이 많을 수밖에 없다. 
    • 매일 반대되는 의견에 시달리고, 목표한 성과에 쉽게 도달하지 못하는 것이 실제 PM의 모습
    • "Keep Calm" 이런 과정에서 일희일비하는 모습을 보여주면 금세 추진력을 잃게 됨
    • 합리적 근거로 무장한, 일관되게 침착한 PM의 모습을 통해 팀원들은 창의적 발상의 힘과 자생적인 추진력을 얻게 된다.
    • 지속적으로 팀을 하나로 모으는 공감대 형성을 해야 한다. 모든 프로세스 설계에 '맥락 context' 공감은 필수다. 많은 시간과 노력이 들더라도 이 시간은 프로덕트의 성공을 좌지우지한다.

 

 

좋은 건 알겠는데, 그게 우리 회사랑 맞나요? 
우선순위를 좀 봐야겠네요. 이미 많은 일이 있어요. 
왜 바꾸죠? 바꿔서 뭐가 달라지나요?
(회사에 더 오래 다닌) 제가 이미 해봤는데, 그거 우리랑 잘 안 맞아요.

 

구체적인 침착 스킬 강화법

  • 일관된 커뮤니케이션: 이럴 땐 PM의 피드백이 이럴 거라고 예측 가능하게 하자.
  • Daily 미팅, 1:1 미팅: 어떤 형태든 상관 없다. 구성원들과 짧고 굵게 자주 만나 맥락(Context)을 자주 공감하자.
  • 화가 난 나와 감정을 분리: 관리 갈등 스킬은 PM을 빛나게 한다. 잘 모르겠다면 3분만 도망가자. 
  • 고객의 시점에서 생각하기: 다른 의견이 있을 때 내가 아닌 3인칭 고객의 시점에서 생각해보면, 객관적인 판단이 가능하다.
  • 우선순위: 해야 할 것보다 하지 않아야 할 것에 초점을 맞추자. 우선순위 관리법 Moscow 등

TIL(Today I Learned) 작성하기

  • 매일매일 배운 것을 노션이나 메모장 등에 조금씩 정리하는 방법
  • 예시: 새로운 조직에서 팀 세팅과 조직장과의 Align한 과정, 새롭게 조인한 팀원들과 조직변경과정에서 어려움, 팀원들과 1on1 하면서 놓치지 말아야 할 포인트들, 하드스킬 업그레이드에 필요한 것들, 면접 보면서 더 챙겨야할 것들.. 등 무엇이든!

이것부터 배우자, 하드스킬!

  • step 1 필수
    • 논리적 설득력(가장 중요): 목표-가설수립-검증, OKR, KPI, PRD, 6pager, Working Backwards
    • 개발 프레임 이해 (두번째 중요): 직접 개발할 필요는 없지만, 현재 회사의 기술 구조를 이해하고 구현가능성을 아는 것이 중요
      • FE, BE, 서버(물리서버/클라우드서버) <-> 클라이언트, DBMS, API(Application Program Interface), 앱 OS별 특성 등
    • 협업툴, 커뮤니케이션툴, 프로토타이핑툴, 프로세스관리, Userflow, 스토리보드 작성, 일정관리, 백로그관리, SB작성 등
  • step 2 중급: 있으면 이직이 용이함. 주로 '그로스해킹' 관련 스킬들
    • SQL, Python 등을 통해 간단한 데이터는 내가 뽑을 수 있는 능력 
    • GA, Amplitude, 어트리뷰션툴(앱스플라이어, 에어브릿지)
    • 리텐션(클래식, 범위, 롤링리텐션) 추적
    • 태블루: 데이터 시각화
  • step 3 고급: 유니콘 같은 캐릭터
    • 간단한 코딩과 디자인이 가능한 만능캐

 

기타 읽어볼만한 자료

라비 메타 PM 블로그 "What’s Your Shape? A Product Manager’s Guide to Growing Yourself and Your Team" 아티클 소개

Product Manager에서 Product Lead로 가는 길이 나에게 맞는지, 내가 갖고 있는 역량을 체크해보자. 

&copy;Ravi-Mehta

 

3.  지그재그 PO 이미준님* 👍

*롯데온에서 10년차 기획자였다가 PM/PO로 직무 변경, <현업기획자 도그냥이 알려주는 서비스기획 스쿨> 저자

기획자 vs. PM(PO)

처음 기획자에서 PM이 되었을 때, 연사가 생각한 역할

  • 프로젝트 범위 정의: release plan
  • 상세 항목 스펙 정의
  • 디자인, 개발 일정 확인
  • 일정 내 스펙 자르기
  • 협업팀 커뮤니케이션
  • PRD, Userstory 티켓 생성

팀원들이 PM에게 바랬던 역할

  • 비즈니스 임팩트를 최대화 할 수 있는 방법: roll-out plan
  • 영업팀, 마케팅팀 설득 (사내 홍보를 해서라도!)

 

좋은 PM이 되기 위한 공부, 'PM의 정석'

1. 원서 책 읽기: Marty Cagan의 <Inspired>, <Empowered>, Melissa Perri의 <Escaping the build trap> 추천

(번역 어휘가 실무와 상이해서 오히려 느리고 부족해도 원서가 좋음)

2. Medium 블로그와 유튜브에 #ProductManager 키워드 검색, Product school 채널 영상 보기

3. 문서 템플릿 찾기: #Project Initiative #6Pager #Product roadmap #PRD

 

공부한 것을 바탕으로 나만의 양식 만들기

Product Vision 문서 예시

Mission is a general statement of how you will achieve your vision.
Strategies are a series of ways of using the mission to achieve the vision.
Goals are statements of what needs to be accomplished to implement the strategy. 
Objectives are specific actions and timelines for achieving the goal.
  • 우리의 고객은 누구인가? 상품데이터를 가져다 쓰는 타도메인
  • 상품팀의 vision: 다양한 BM으로 확장 가능한 유연한 커머스 구조를 구축한다. 
  • 전사 mission / 팀의 mission: 많은 상품을 확보할 수 있는 구조를 만든다. 
  • 이번 분기 goal: 분기 목표 전사 방향성을 고려하고 팀의 미션 기준 목적을 설정 
  • Objective: 분기 목적에 따른 업무 목록의 정리 

Roadmap 문서 예시

Vision과 Mission을 정의하면, Roadmap에서 의미, 우선순위를 고려한 스펙의 방향성을 논의하기가 쉬워진다.
로드맵에 들어갈 프로젝트에 팀원들과의 1:1을 통해 의견과 관심사를 반영하고 리스트업의 우선순위도 논의하면 좋다. 
  • 지난 분기 성과 리뷰: Top 3 pain point, Top 10 success, 수치적인 결과(효과, 달성비중, 비용절감 등)
  • Vision과 전사 Mission에 충실한 업무목록과 우선순위

PRD 예시

PRD는 프로젝트의 시작부터 끝까지 함께 목표를 되새기며 개발자, 디자이너 모두가 하나의 목표로 움직이게 하는 문서이다.
Vision부터 PRD까지 'WHY'가 계속 연결되는 것이 중요하다.*
*WHY를 설득하는데 '데이터'만큼 효과적인 것이 없기 때문에, 데이터 분석 역량이 중요하다.
  • 배경(background)
  • 목적(goal/objective)
  • 대안의 설정 및 선택의 이유
  • 가설과 검증 매트릭(Metrics)
  • 구현 원칙(Guiding Principle)
  • 기능적 요구사항 + SPEC 문서
  • User story + Acceptance Criteria
  • 디펜던시(Dependency)
  • 디자인파일, 개발정리파일 링크
  • 일정(milestones)
  • MVP 이후 추가 개선 플랜
  • 참고자료 + 오픈 후 성과 관련 문서
나 역시 순식간에 엄청나게 많은 문서를 찍어내면서, 스스로 일을 잘 하고 있다고 생각했어요 -Melissa Perri

 

4. 뱅크샐러드 CPO 박지수님*

*디자이너(에듀테크 UX/UI 디자이너) 출신 PM, <팔리는 프로덕트> 저자 

 

사용자 인터뷰 잘 하는 법에 대한 강연을 해주셨는데, 내용이 너무 '뱅크샐러드'에서의 인터뷰 경험에 촛점이 맞춰져 있어서 기록해두고 곱씹어볼 만한 내용은 없었다.