베를린 PM 이직기#4. 프로덕트 매니저 과제 면접!
대망의 과제 면접. 그 고통의 시간과 프리젠테이션 후 밀려오는 질문들
베를린PM이직기#3.2차PM면접-답변 편에 이어서 작성하는 네 번째 이직기이다.
2차 피엠 면접까지 무사히 넘어갔다면, 다음은 바로 과제 면접의 단계다.
가장 고통스럽고 힘든 단계다. 적어도 나에겐 그랬다.
과제 면접은 사실 말이 1단계지 실질적으로는 2단계라고 생각해야 한다. 첫 번째는 과제를 해서 제출하는 단계 두 번째는 과제를 제출한 후에 과제를 프레젠테이션 / 설명하면서 질문에 답하는 면접이다.
어떤 회사는 과제를 검토 후 면접을 잡기도 하고, 어떤 회사는 과제 제출하는 날 다음날을 바로 면접 날로 잡아버리기도 했다.
한국도 점점 과제 면접이 많아지는 추세인 것 같은데 솔직히 말하면 과제 면접 있는 회사는 웬만하면 거르고 싶은 마음도 있다. 왜냐하면 과제에는 엄청난 시간을 투자해야 하기 때문. 트레이드오프(Trade-off)로 생각하면 내가 A라는 회사의 과제를 제대로 하기 위해서는 B, C, D 회사는 상대적으로 리서치하고 준비할 시간이 물리적으로 부족하고, 과제를 동시에 두 개 이상의 회사를 같은 시간 내에 하는 건 솔직히 거의 불가능하다.
과제를 위한 시간 분배는 어떻게 하면 좋을까?
보통은 1주, 짧게 주면 3일 정도로 과제할 시간을 주고, 지금 메일을 받은 시간으로부터 3일 후, 혹은 1주일 후에 회신으로 과제를 제출하면 된다고 안내한다. 그리고 과제에 궁금한 점이나 잘 이해가 가지 않는 부분이 있으면 언제든 메일로 문의를 달라고 한다.
일주일의 시간을 준다고 했을 때 나는 아래와 같이 시간을 나누어 썼다.
1일 차: 과제 제대로 이해, 빠르게 리서치 후 질문할 것 정리해서 보내기
2일 차: 과제를 중심으로 리서치, 특정 프로덕트라면 그 프로덕트, 회사 비전, 발간된 보고서 등 리서치
3일 차: 리서치 계속. 피피티의 구조 잡기, 사용자 조사를 위한 준비
4일 차: 사용자 조사, 인사이트, 아이디어 등 정리
5일 차: 큰 단의 내용 피피티로 작성
6일 차: 디테일한 내용 피피티로 작성, 주변 프로덕트 매니저, 외국계나 해외 기업에서 일하는 PM에게 피드백 요청
7일 차: 머리 쥐어뜯으며 다시 고치고 장표 스타일, 도표, 그래프 등 마무리. 스펠링/문법 체크.
자, 이제 본격 과제를 해보자...!
1단계: 과제 제대로 이해하기
과제를 파악하는데만 꼬박 1일이 소요되고, 최대한 빠르게 질문을 정리해서 보낸다. 이전 글에서도 언급했지만 'Clearifying questions'는 언제나 중요하다.
예를 들면 ABC라는 서비스를 '개선하라'라고 과제가 나온다면 아래와 같이 질문할 수 있겠다.
예) 과제에서 ~~를 개선하라고 했는데 개선의 범주와 개선의 기준에 대해 궁금하다. 범주는 신규 비즈니스 아이디어의 도입/디자인의 개선 같은 것 까지 포함하는 것인지 그것을 내가 자유롭게 규정하길 원하는지? 또한 개선이 기준이 '수익' 증진인지, '유저수'의 증가인지 아니면 key metric(성공 지표)를 내가 규정해서 진행하길 원하는지 궁금하다.
물론, 실제로 내가 받았던 과제는 저런 식으로 무책임하게 던져주지 않았다. 과제만 1-2페이지를 차지할 정도로 상당히 자세했고, 목표가 무엇인지 얼마 정도의 분량을 원하는지 등이 상세하게 기재되어 있었다.
2단계: 과제 구조 짜기 / 내용 기술하기
사실 구조 잡는 게 먼저인지 리서치가 먼저인지는 잘 모르겠지만, 일단 나는 대략적인 구조를 좀 잡아놓고 리서치를 하면서 디테일하게 더 잡아나가는 편이다.
*참고로 과제를 줄 때 아예 구조를 이런 식으로 하라고 잡아주는 회사도 있었다.
과제를 많이 해본 건 아니고 총 4군데의 회사의 과제를 해보았는데 대략적으로 이런 구조가 가장 일반적이라고 생각한다.
1. Product Vision & Goal & Strategy of this year/quarter
내가 과제를 할 때 다루는 프로덕의 비전, 목표, 이번 해나 분기의 전략을 먼저 정의해 준다.
이건 어느 정도 리서치를 하면서 나오기도 하고, 리서치로 찾을 수 없다면 어느 정도 한 리서치를 바탕으로 내가 임의로 정하기도 한다. (실제 있는 프로 덕이 아니라면 내가 임의로 정한다.)
2. Discover Problems
어떤 문제들을 발견했는지를 3-4장에 걸쳐 다룬다. 이 과정에서 유저 리서치, 서베이, 유저 인터뷰, 기사 분석, 논문 분석, 통계 분석 등 여러 가지의 정성/정량적인 자료를 활용하고 어떤 문제를 발견했는지 굵직하게 2-3가지로 추려서 말한다.
3. Probelm Statement & Opportunity Hypothesis
찾은 문제들 중 어떤 문제를 가장 우선시할 것인지를 1번을 고려하여 정한 후, 문제를 정확히 정의한다.
문제 정의는 여러 가지로 할 수 있지만 나는 명확한 문제 정의를 위해 아래의 구조를 활용했다. (그리고 이건 면접 보는 피엠들이 엄청 좋아했다. 문제가 명확하게 정의된다고 생각한 것 같다)
문제 정의 구조의 예시문제를 명확하게 정의했다면 '기회 가설 - Opportunity Hypothesis'를 세운다. 말이 어려운데 그냥 쉽게 말하면 이 문제를 해결해서 어떤 변화를 가져오고 그것이 결국 어떤 결과를 낳을 것인지를 명확하게 정의하는 것이다.
틴더라는 데이팅 플랫폼을 예를 든다면 아래와 같이 기회 가설을 세울 수 있다.
만약 틴더를 '좀 더 진지한 플랫폼으로 변화시킨다면 (가설)'
'젠 Z (20대 제너레이션)을 넘어 직장인 밀레니얼 제너레이션을 유입시킬 것이며' (변화)
결국 '틴더 유료 서비스의 사용이 증가할 것이다' (수익 증대의 목표라는 결과)
*여기서 큰 단의 '성공 지표'를 정의해도 좋다.
**여기서는 UI 어디를 어떻게 뜯어고치면 수준의 너무 작은 이야기를 하지 않길 바란다. 그건 나중에 솔루션을 이야기할 때 자연스럽게 따라 나오는 작은 디테일이다.
4. Ideas / Prioritization
가장 우선시하는 문제를 규정했고, 그 문제를 해결하여 얻고 싶은 결과를 정의했다. 그러면 이를 위한 실질적인 아이디어들을 마음껏 뿜어내 보자!
여기서 크고 작은 아이디어 2-3개를 보여주면 되는데, 너무 디테일하고, 너무 많아도 안 좋으니 1개는 안전한 것, 1개는 좀 더 창의적인 것, 1개는 큰 단의 전략적인 것 이런 식으로 '내가 다방면으로 아이디어를 낼 수 있음'을 보여주면 좋다고 생각한다.
위 예시처럼 나는 아이디어 1개당 1장의 프레젠테이션을 할애해서 아이디어를 1 문장으로 구사하고, 손그림이나 간단한 유아이 스케치로 아이디어를 직관적으로 이해할 수 있게 보여주었다.
아이디어 2-3개 중에 1가지를 우선순위화 (prioritization) 한다. 그 이유는 1번에서 정의한 전략, 문제 해결 가능성, 현실성, 임팩트 등을 고려해서 정한다. 그리고 그 이유는 잘 설명해주면 좋을 것 같다.
결국 프로덕트 매니저의 역할의 큰 것 중 하나는 언제 무엇을 개발하도록 결정하는 우선순위 결정 능력이라고 생각하기 때문이다.
5. Idea Validation
이제 내가 우선순위로 뽑은 아이디어를 '검증'한다.
1) 개발 가능성 검증 Technical feasibility
Time and resources – how much time and resources we want to assign for this project?
• Component - how to get POI data? Do we have enough ‘Things to Do (activities)’ deals?
• Architectural change – feasibility of the harmonized search form?
• Dependencies involved in building – how the current ‘Weekend’ feature will be impacted?
• Performance level – by providing POI, will the map perform well?
• Scalability – is this scalable to be bigger product feature?
• Cost – do we have enough budget to build and deliver this, until we reach our goal?
• Measurable (trackable) – do we have tools implemented to track and measure the performance of testing? Ex. Elastic, GA, Dashmore, Tableau
2) 비즈니스, 시장 검증 Business / Market Viability
- 가치 제안을 검증 Evaluate the value proposition : 고객에게 어떤 가치를 제공하고, 경쟁자와 어떻게 차별화할 것인가? (Value proposition canvas, competitor analysis 등의 방법론 / 툴을 이용하도록 하자)
- 마켓(시장)의 수요를 검증 Measure the market demand : 얼마나 시장이 이것에 대한 수요가 있는가?
- 영향력 검증 : Estimate the measurable impact – 신규 고객 유치? 수익? 브랜드 이미지? 내부 인프라 개선?
- 이해 관계자들과 프로토 타입으로 검증 Have a Walkthrough session with the stakeholders (with product prototype) : 세일즈, 마케팅, 대표와 임원들, 지역 매니저들, 고객 관리팀, 법률팀 등등, 사내의 이해 관계자들과 프로토타입으로 설명하고 피드백을 들으며 검증하는 세션을 가질 것이라고 말한다.
3) 사용성 검증 Usability
정량적 정성적 사용성을 어떻게 검증할 것인지 설명한다.
5. Raodmap / MVP & Phases
이제 이상적으로 전달하고픈 아이디어(기능)를 정의했으므로 실질적으로 어떻게 MVP를 이에 대해 정의하고 로드맵을 짤지를 보여준다. 대략적인 몇 달간의 로드맵을 짜서 보여줘도 좋을 것 같다.
나는 큰 단의 기능을 조금 쪼갠다음 디자인/프런트 앤드 개발/데이터베이스 구축/API 개발/QA로 분리해서 대략적인 로드맵을 짜서 보여주었다.
6. Definition of Done & Metrics
마지막으로 DoD라고 부르는 Deifinitaion of Done을 규정해주고, 개발 후에는 어떻게 테스팅하여 실험할 것인지, 어떤 핵심 지표 / 서브 지표 / 카운터 지표를 트래킹 할 것인지 정의해준다.
추가로 어떻게 이 프로젝트를 평가할 것인지 기준을 제시해 주어도 좋다.
만약 위 1-6까지 중에 잘 모르는 용어나 내용이 있다면 구글링 하면서 공부하면 된다. 사실 나는 과제하면서 배운 게 너무 많다... 깨깽.. 이렇게 모르는 것이 많을 수가...
그리고 1-6은 내 기준에서 일반적으로 구조가 저렇다고 작성한 것이기 때문에 과제에 따라 조금씩 당연히 변경해야 하고 회사마다 조금 다르게 작성해야 할 것 같다.
3단계: 프레젠테이션 연습/예상 질문 대비하기
과제를 프레젠테이션하기 위한 연습을 한다. 스크립트는 미리 적어둬도 좋지만, 그걸 보고 읽으면 듣는 사람의 집중력이 떨어지기 때문에 더듬거려도 직접 그냥 피피티를 보면서 말하는 것이 낫다.
예상 질문들을 피티 하면서 생각나는 대로 적고 대답해 본다.
자, 이제 프레젠테이션 면접이다.
보통 과제 면접은 1시간-1시간 반으로 이루어지고 과제 설명은 15-20분으로 짧게 해 주길 원한다. 왜냐하면 면접자들이 대부분 과제를 꼼꼼하게 정독하고 오기 때문이다. 그래서 자기들이 읽으면서 이해하지 못하는 부분을 빠르게 질문하고 답변받길 원한다.
사실 이미 2단계의 피엠 면접을 통과했다면 이건 이미 충분히 많이 리서치하고 고민한 결과에 대해 질문하는 부분이기 때문에, 막상 면접이 그렇게까지 힘들진 않다. 과제를 하는 것이 훨씬 힘들 뿐...
과제 면접 결과는 대부분 빠르게 나온다. 모 아니면 도라서 그런가. 과제 면접까지 통과했다면 사실 거의 고지가 눈앞에 있다고 보면 된다.
다음은 마지막 관문 (실제로 미팅이 2-3개의 세션으로 쪼개질 수는 있지만 그래도 단계적으로는 거의 마지막이다) VP, CPO, CTP 등과 만나기, 그리고 함께 일할 팀과 만나기만 남았다.
작가 링크트리: https://linktr.ee/nomadyun
유투브: '노마드 윤실장'을 검색해 주세요 :)
