Day 11 (3주차)
| 시간 | 학습내용 | 소요시간 | 메모 |
|---|---|---|---|
| 아침 | 3주차 발제 설명회, PM 취업 Q&A 특강 | ||
| 점심 전 | 2주차 TIL 썸네일 변경, 스포티파이 PM 팟캐스트 | 1시간 | |
| Arvo | 서비스 기획 입문 [1-1]~[1-2] | 4시간 | 강의 러닝타임은 2시간 18분인데 왜 두배나 걸렸는지? |
| 딴짓 - Bolt로 크롬 익스텐션 만들기 시도 | 30분..? | 1트->실패 | |
| Evening | 오후 스크럼, TIL 작성 |
팟캐스트 - 스포티파이 플랫폼 PM 인터뷰
🔗The Platform PM role at Spotify
👞플랫폼 PM의 정의와 역할
- 인터뷰이 : Nils, 2015년부터 스포티파이에서 플랫폼 PM으로 활동
- Nils가 정의한 플랫폼 PM: '아이디어를 실제 제품으로 출시하는 과정에서의 모든 장애물을 제거하는 역할'
🎵플랫폼 PM의 특이점/ 스포티파이 내에서의 문화
-
가시적인 제품이 아닌 '역량(Capability)' 제공:
- 일반적인 PM이 최종 사용자에게 패키지화된 제품을 제공한다면, 플랫폼 PM은 내부 개발자가 더 빠르고 효율적으로 일할 수 있는 환경과 도구를 제공합니다.
-
고객층: 스포티파이 내부의 모든 개발자가 고객입니다.
- 내부 개발자들 = Captive Audience 라는 점이 일반 프로덕트 고객들과의 차이
- 플랫폼 PM은 이들의 니즈를 정확히 파악하는 것이 중요함
-
고객(개발자)과의 관계 형성
- 근거리 관찰: 플랫폼 PM은 고객과 같은 사무실(혹은 같은 슬랙)을 쓰기 때문에 업무 방식을 직접 관찰하기 용이합니다.
- 데이터 활용: Git 레포지토리 활동, 빌드 시스템 신호 등을 통해 개발자의 여정을 데이터로 재구성합니다.
- 문서화 문화: 스포티파이는 긴 문서를 통해 전략을 공유하며, PM은 이를 읽으며 회사의 방향성과 개발자의 니즈를 파악합니다.
-
주요 변화: 기술 중심에서 '여정(Journey)' 중심으로
- 최근 스포티파이는 팀 구조를 iOS, Android 같은 기술 스택 중심에서 개발자 여정(User Journey) 중심으로 재편했습니다.
- 이유: 플랫폼별로 중복된 도구가 개발되는 낭비를 줄이고, 기능을 구현하는 개발자가 여러 플랫폼을 넘나들며 일관된 경험을 하도록 하기 위함입니다.
- 방식: 'iOS 팀' 대신 '빌드 팀', '로컬 개발 경험 팀' 등으로 나누어 특정 도메인 전체를 책임지게 합니다.
📊플랫폼 PM의 성과 측정
플랫폼 PM의 가장 큰 고충은 "내가 만든 도구가 회사의 매출에 얼마나 기여했는가?"를 증명하기 어렵다는 점입니다. Nils는 이를 해결하기 위해 지표를 다각화합니다.
1. Golden Path
Golden Path: 신규 입사자가 도구 설치부터 첫 Pull Request(PR)까지 막힘없이 갈 수 있도록 만든 최적의 가이드라인. 핵심은 <가장 쉬운 방법으로 최선의 방법을 만드는 것>
- Time to First PR (태어나서 처음으로 회사 코드에 기여하기까지 걸리는 시간):
단순히 이 시간이 짧다고 해서 온보딩이 성공한 것XX
가이드만 따라 하면 누구나 할 수 있기 때문 - Meaningful PR (의미 있는 PR):
스포티파이는 단순 오타 수정이나 문서 변경이 아닌, 실제 시스템에 영향을 주는 복잡도를 가진 첫 번째 코드 제출까지의 시간을 측정합니다.
이를 통해 신입 개발자가 실제 '생산성'을 갖추기까지의 실질적 기간을 파악합니다.
Insight Point💡 자율성 vs 표준화 (자율적인 팀 문화와 표준화된 도구 사이의 긴장감)
모든 것을 강제하면 팀의 자율성이 해쳐지지만, 표준화를 거치지 않으면 유지 보수 비용이 폭등함.
➡️ 가장 반복적이고 소모적인 작업을 Golden Path로 표준화하여 개발자가 창의적인 업무에 리소스를 집중 할 수 있는 환경을 설계
➡️ 표준은 구속이 아니라, 더 높은 차원의 자율성을 위한 기반
2. '몰입 상태(Flow State)'의 가치 강조
-
정성적 가치:
플랫폼의 궁극적인 목표는 개발자를 'Flow(몰입)' 상태로 만드는 것.
"도구가 느리거나 복잡해서 흐름이 끊기지 않게 하는 것이죠." -
창의성 해방:
Nils는 이를 "Unlock creativity"한다고 표현.
-> 숫자로 치환하기 어렵지만, 조직의 경쟁력을 결정짓는 핵심 요소로 리더십에 어필해야 할 대목이라고 강조.
3. 데이터 활용 (온보딩 지표, eNPS)
- '우리 개발 환경이 얼마나 복잡한가'를 측정하는 척도로 데이터를 활용합니다.
(개별 개발자의 생산성을 감시하는 용도XX) - 환경의 복잡도가 낮아지면 자연스럽게 온보딩 지표와 개발 만족도(eNPS)가 올라감
🚀 What motivates a platform PM - '지연된 보상'을 견디는 힘
"Customer facing 프로덕트에 비해 internally facing 프로덕트는 성과가 가시적으로 드러나지 않는 경우가 많음. 이러한 점이 커리어적 동기부여나 보상의 결여로 이어지지는 않는지?"
💭 Nils는 플랫폼 PM으로 8년 넘게 생존하며 성공할 수 있었던 커리어 전략을 다음과 같이 조언
1. Delayed Gratification을 받아드리는 자세
서비스 PM은 기능을 배포하면 사용자 지표가 즉각 요동치지만, 플랫폼 PM은 인프라를 개선해도 그 효과가 수개월 뒤에 나타나거나 당연하게 여겨지는 경우가 많습니다. "보상이 늦게 오거나 아예 나타나지 않을 수도 있다는 점을 편안하게 받아들여야 한다"고 Nils는 강조합니다.
2. 도메인에 대한 진정한 흥미 (Subject Matter Interest)
기술적 지식이 반드시 깊어야 하는 것은 아니지만, 개발자들이 겪는 고충과 기술적 생태계 자체에 대한 깊은 관심이 있어야 합니다. 단순히 커리어를 위한 징검다리로 플랫폼 PM을 선택하면, 눈에 보이지 않는 성과를 만들어내는 과정에서 쉽게 지칠 수 있기 때문입니다.
3. 성과를 '달러($)'로 환산하는 능력
플랫폼 PM이 승진하거나 연봉을 높이기 위해서는, 추상적인 인프라 개선을 비즈니스 가치로 번역하는 능력이 필수적입니다.
- 예: "빌드 속도를 20% 개선했다" → "연간 000시간의 엔지니어 공수를 절감하여 비즈니스 기능을 더 빨리 출시할 수 있는 기회비용을 확보했다"
4. 배경의 다양성 (Engineer vs. Pure PM)
| Background | What to Improve |
|---|---|
| 엔지니어 출신 | 결정 내리는 법과 제품적 사고(Customer Awareness)를 배워야 합니다. |
| 일반 PM 출신 | 기술적 도메인에 온보딩 필수. |
| 엔지니어의 "이건 식은 죽 먹기예요"라는 말이 진짜인지 판단할 수 있는 감각 필요 |
- 두 배경이 서로 보완하는 조직 문화를 만드는 것이 개인의 커리어 성장에도 유리함.
🔥Engineer-turned-PM + Pure PM 의 시너지 효과
1. 하드 스킬의 상호 보완 (Skill-set Cross-pollination)
-
Learn form Engineer PM
기술적 의사결정의 '트레이드오프(Trade-off)'를 판단하는 감각을 익힐 수 있습니다.
E.g. "이 기능을 구현하는 데 2주가 걸린다"는 말을 들었을 때, 그것이 기술적 부채 때문인지 아니면 아키텍처의 한계 때문인지 옆에 있는 엔지니어 출신 PM과 토론하며 기술적 직관을 기를 수 있습니다. -
Learn from Pure PM
복잡한 기술적 성과를 '비즈니스 언어'로 번역하는 법을 배웁니다.
사용자 리서치 설계, 시장 분석, 이해관계자 설득 같은 '제품 사고(Product Thinking)' 프레임워크를 공유받으며 기술에 매몰되지 않는 균형 잡힌 PM으로 성장합니다.
2. 의사결정의 사각지대 제거 (Eliminating Blind Spots)
플랫폼 제품은 기술적으로는 훌륭하지만 사용성이 엉망이거나(Engineer's bias), 기획은 멋지지만 구현 불가능한(Pure PM's bias) 경우가 많음
-
두 배경이 섞인 문화에서는 기획 단계부터
"이 도구가 개발자의 워크플로우를 망치지 않는가?"와
"이 도구가 회사의 전략적 방향과 일치하는가?"라는 질문이 동시에 던져집니다. -
이 과정에서 PM은 '비판적 사고'를 훈련하게 되며, 이는 나중에 어떤 도메인으로 옮기더라도 실패 확률을 줄여주는 강력한 자산이 됩니다.
3. 리더십 및 커뮤니케이션 스펙트럼 확장
PM의 커리어 정점은 결국 '언어의 확장성'에 있습니다.
엔지니어와 대화할 때는 기술적 깊이를 갖춘 언어로 신뢰를 얻고, 경영진과 대화할 때는 ROI(투자 대비 효율)와 임팩트 중심의 언어로 설득해야 합니다.
서로 다른 배경의 PM들이 모인 조직에서 일하면, 자연스럽게 양쪽 진영의 언어를 모두 구사하는 '이중 언어 사용자(Bilingual)'가 됩니다. 이는 시니어 PM이나 CPO(최고 제품 책임자)로 성장하기 위한 필수 조건입니다.
서비스 기획 입문 Chapter 1: 유저를 이해하는 법
시장조사 및 데스크 리서치의 필요성과 How-to
대표적인 유저 리서치 방법론 - 사용사 인터뷰, UT, 설문조사
<회사 분석 및 평가 How-To>
-
회사 비전: 서비스/프로덕트 분석 시 'Why?'에 대한 실마리를 제공.
- 대표 인터뷰 기사, 채용공고에서 Vision 체크.
- 회사의 목표와 방향성을 확인할 수 있음.
-
대표자 약력 및 회사 설립 History:
- 대표자·설립자의 성향과 가치관이 비전 및 회사 문화에 반영되기 때문.
★ 대표 분석은 프로덕트 분석만큼 중요.
- 대표자·설립자의 성향과 가치관이 비전 및 회사 문화에 반영되기 때문.
-
재무현황:
- 기사: 보도자료 형태는 성과를 강조하므로 비판적 시각 필요.
- 혁신의 숲 / The VC: 스타트업 기업 평가 시 유용한 데이터 제공.
- 중소기업 현황 정보 시스템: 기초 재무제표 열람.
* 기업의 재무제표를 꼼꼼히 파악해야 회사 평가에 대한 감이 생김. - 상장기업 IR 자료: 비즈니스 목표, 주요 KPI, 이슈, 전략 등 파악 가능.
-
신사업 동향: 채용공고, 기사 활용.
-
파트너 사이트: B2B 비즈니스 모델, 성과 파악에 용이.
- 사이트가 없을 경우 매체 소개서(아이보스, 오픈애즈 등 마케터용 정보 사이트) 활용.
무엇을 분석해야 하는가?
- 주력 서비스가 무엇인가, 타겟은 누구인가, 목표하는 성과는? -> 어떤 기획이 필요한가?
- 비즈니스 관점에서 서비스를 분석하고 내부 데이터(CTR 등)지표 확인하는 연습
- 도메인/마케팅 용어 익히기
-
사용자 VoC: 실제 사용자 이용 경험.
⚠️커뮤니티 특성상 부정적 반응이 많음. 일부가 전체를 대변하지 않음에 유의 -
서비스 개편 내역: 릴리즈 노트, 버전 업데이트 기록.
-
서비스 지표: 정량 데이터 기반 분석이 필요할 때 활용.
- 검색어/검색량 분석 툴 (트렌드, 키워드 리서치)
- 앱·시장 리포트
-
광고 소재: 단순 마케팅이 아닌 경쟁사의 전략, 타겟, 시장 흐름에 대한 힌트. (예: 메타 광고 라이브러리)
🔍데스크 리서치 Case Study: 무인양품 Passport 앱
- 개인적 경험에서 느낀 Pain Point와 다른 사용자들의 VoC 비교 ➔ 통계화 ➔ 문제점 정리
- 기업 아이덴티티, 브랜드 가치관, 조직구조 파악
- 왜 이런 문제점이 여태 방치되고 있었는지?
- 문제 상황에 대한 솔루션이 현실적으로 적용될 수 있는지?
- 소비자 심리, 행동 패턴 분석: 지리적 특성을 이해하고 정량적 데이터 활용
데스크 리서치 관련 참고 사이트
✅ 파트너 전용 웹사이트
- 카카오 비즈니스 https://business.kakao.com/
- 카카오 비즈니스 가이드 https://kakaobusiness.gitbook.io/main
- 네이버 비즈니스 https://business.naver.com/service.html
- 네이버 비즈니스 스쿨 https://bizschool.naver.com/
- 당근 비즈니스 https://business.daangn.com/
- 배민외식업광장 https://ceo.baemin.com/
- 쿠팡 마켓플레이스 https://marketplace.coupangcorp.com/s/
- 쿠팡이츠 사장님 포털 https://store.coupangeats.com/
- 요기요 사장님 포털 https://partner.yogiyo.co.kr/
- 토스 비즈니스 https://business.toss.im/
✅ 광고 매체 소개서
- 아이보스 https://www.i-boss.co.kr/ab-7654
- 오픈애즈 https://www.openads.co.kr/item
✅ 검색어 키워드 트렌드/검색량 분석 도구
- Google 트렌드: 구글 검색 및 유튜브 검색 기준으로 특정 키워드의 검색량 변화를 확인
- 네이버 데이터랩: 네이버 내 검색어 트렌드를 분석
- 카카오 데이터 트렌드: 카카오톡을 비롯한 카카오 생태계 내 검색어 트렌드를 제공
- 블랙키위: 네이버와 구글의 검색량, 포스팅 수, 활성 사용자 수, 키워드별 노출 순위 등 상세한 키워드 정보를 제공
- 네이버 키워드 광고: 네이버 광고 플랫폼에서 실시간 검색량, 월간 검색량, 연관 키워드 등을 확인
- 리스닝 마인드: 검색 빅데이터 기반의 인텐트 마케팅 분석 플랫폼
✅ 앱/시장 리포트- 와이즈앱:국내 모바일 앱의 사용량, 결제액, 사용자 수 등을 분석
- 오픈서베이 :소비자 트렌드, 마케팅 조사 리포트 등을 통해 시장 흐름을 분석
<유저 리서치 방법론>
- Key Considerations: 누구를? 무엇을? 왜? 어떻게?
- 유저 리서치는 왜 하는가:
서비스·제품의 현황과 고객 경험 관찰 ➔ 비즈니스 관점에서 개선할 수 있는 방안을 모색하기 위해 - 방법론의 종류:
- 정성 vs 정량
- 사용자의 행동 vs 태도
★ 한쪽에만 치우치지 않고 교차 분석하는 역량이 중요!
실무에서 많이 쓰는 방법 Top 3
정성적: 사용성 테스트 (UT), 사용자 인터뷰
정량적: 설문조사
💯 TIP - 리서치 경험 어필 포인트
맥락과 목적에 대한 고찰
- 리서치를 하게 된 배경
- 리서치 시 가장 고민했던 점
- 새롭게 발견한 점
인사이트 & 레슨런
- 다시 진행한다면 보완·개선하고 싶은 점
- 어떠한 레슨런?
1. 사용자 인터뷰 및 사용성 테스트 (UT)
좋은 참여자 선정 (사전 스크리닝)
- 질문에 깊은 답(퀄리티 높은 답)을 줄 수 있는 사람 선정.
- 객관식 설문: 조건에 맞는 참여자 필터링.
- 사진 응답: 실제 적합도를 증명할 수 있는 자료 수집.
- 사전 미팅(전화/화상): 노쇼 방지, 리마인드, 경험 사전 체크.
규모 및 진행
- 규모: 한 그룹당 4~6명 (응답 포화 현상 고려).
- 진행 프로세스:
- Task(어떤 행동) ➔ 평가할 내용(어떤 기능) ➔ 관찰 포인트(실제 사용성) ➔ 질문 예시(사용성에 대한 평가).
- 주의사항: 대상에 따라 Task 구성을 고려해야 함. (예: 시니어 유저에게는 직관적인 워딩의 상황 제시)
인터뷰 Tip
- 참여자에게 익숙한 언어로 질문.
- 유도 질문 주의: 질문은 Neutral 하게, 답정너 금지.
- 넓은 범위에서 좁은 범위로 질문 확장.
- 미래에 대한 의견 보다는 과거 행동에 대해 질문
e.g. "쓸 거 같나요?" (X) ➔ "써본 적 있나요?" (O) - 구체적인 경험을 회고하도록 유도 (광범위하고 추상적 질문 지양).
- 꼬리 질문: 숨은 맥락, 패턴, 수치를 구체화하여 유효한 인사이트 도출.
리서치 결과 정리 Step
- Step 1. 조사 목적에 초점을 맞춘다. (Back to basics!)
- Step 2. 팩트와 주관으로 분류 (맥락과 이유 찾기).
- Step 3. 공통된 패턴 / 시나리오 확인.
- Step 4. 의외의 반응, 반전 체크.
- Step 5. 의견의 맥락/상황 기안 확인.
- Step 6. 분석 내용을 인사이트 문장화.
- Step 7. 조사 목적에 맞는 시사점 도출.
PM의 자세: 유저 리서치는 주관적인 행위임.
따라서, PM의 주관 = 객관적 근거에 기반한 합리적 해석 이 될 수 있도록 해야함.
- 사용자의 말 ≠ 정답 (단서로 활용).
- ★맥락이 중요★
실제 로그 데이터, 시나리오 재현을 통해 크로스체크.- 관련 부서 참여를 통해 다양한 관점과 현장 경험 이해도 제고.
설문조사 (정량적 방법론)
대상자 정의 및 규모
- 분류: 성별·연령이 아닌 행동 패턴 기준으로 정의. (스크리닝 문항 활용-> 비적합자 걸러내기)
- 규모: 통계적으로 30명 이상 시 유의미하나, 안정적 결과를 위해 최소 단위당 100명 이상 권장.
- 최소 단위: 대상자를 더 세분화하여 나눈 그룹 (예: 20대 여, 20대 남).
질문 작성 원칙
- 완성된 문장 사용 (줄임말, 구체체 X).
- 응답 방법 명료화: 질문은 콕 집어서 구체적인 기준으로 제시. (기타 항목은 필요한 경우만)
- Neutral 톤 유지: 객관적 사실 기반.
- 1문항 1질문!
정량적 방법론 해석
- Step 1. 응답자 수, 유효 응답자 수 집계 ➔ 신뢰도 점검.
- Step 2. 응답 결과 요약:
- 정량: 수치(표, 그래프)로 요약.
- 정성: 반복 키워드, 표현 Categorize.
- Step 3. 핵심 인사이트 요약 (공통 패턴 및 특이사항).
Chapter 1 을 마무리 하며...
질문 - 사용자 인터뷰와 설문조사의 차이는 대면, 비대면 방식의 차이인가? 설문조사도 100% 정량적 응답 결과만 얻는 건 아닌데 경계가 헷갈림.
챕터1에서 배운 유저 리서치 방법론을 체크리스트 형식의 매뉴얼로 만들어 보는 활동을 해보면 좋을 거 같다.
하루를 회고하며...
오랜만에 돌아온 회고 Time...
5점 만점에 3.5 점의 하루를 살았다. 월요일 치곤 나쁘지 않은 듯!
하지만 가장 큰 미스테리는 2시간 18분짜리 강의를 듣는데 왜 4시간이나 걸렸는가 하는 것이다.
심지어 1.5배속으로 들었는데? 왜? 2배가? 걸렸는지? 의문이란 말이다.
그래서 다들 어떤 식으로 강의를 듣는지 물어봤다. 내일은 한나님 스타일은 벤치마킹 해볼 예정이다.
한나님 방식이라 함은, 강의를 멈추지 말고 쭉-- 들은 다음 다시 짚고 넘어가고 싶은 부분을 돌려보는 방식. 공부도 Agile하게.
오늘 들은 스포티파이의 플랫폼PM의 인터뷰 (사실 전부 듣진 못했고 잼미니가 transcript 요약해 준 걸로 같이 공부함😚🤗)가 굉장히 유용했다. 안그래도 요즘 내부 프로덕트 PM에 관심이 커지고 있었는데 보통 PM을 얘기할 땐 customer facing 측면에서 얘기를 하다보니 정보가 부족하다고 느끼던 참이였다. Nils의 인터뷰덕에 내부 프로덕트 PM에 대한 개괄적인 이해를 다질 수 있었다. 특히 엔지니어 출신과 일반 PM 출신이 서로 어떤 장점을 살리고 어떤 부분을 보완하면서 조직을 형성해야하는지에 대한 대목이 인상적이였음. 비단 플랫폼 PM 뿐만 아니라 모든 PM이 다양한 백그라운드를 상호보완하며 시너지를 내는 것이 중요하겠다는 생각을 했다.
...아직은 내부 프로덕트 PM이 되겠다고 100% 결정한 게 아니기 때문에, 만약 내부 PM으로 방향이 정해진다면 포트폴리오에 어떤 사고의 흐름을 담으면 좋을지 나중에 다시 참고하러 와야겠다.
