서류 광탈러가 서류 합격률 80%이 된 포트폴리오 작성법
최근 스타트업 씬을 포함한 모든 곳에 겨울이 왔다는 것을 알고 있을 것이다.
공격적으로 채용을 하던 스타트업들은 채용 공고를 내렸고, 지금은 이직보다 회사에서 버티는 것이 낫다는 이야기가 나오고 있다.
이 시기에 이직을 하려면 더욱더 나의 강점과 경험을 잘 표현할 수 있는 포트폴리오가 중요하다. 뭐 사실 늘 중요하지만..
(왜 이직을 하게 됐는지는 나중에 기회가 된다면 풀겠음)
이직을 하기 위해 1년 3개월 전에 멈춰 있는 포트폴리오를 열었다.
이전 포트폴리오의 합격률이 30%였다면, 새로 정리한 포트폴리오로는 합격률 80%의 변화를 만들어냈다.
(토스, 원티드 등 회사들의 채용 프로세스 2차까지 진행했음)
포트폴리오를 작성하면서 맨 땅에 헤딩하는 막막함을 경험했었다.
아마 많은 이들이 그럴 것이라 생각해서, 기획자와 PM은 어떻게 포트폴리오를 작성해야 하는지 나의 경험을 기반으로 정리해보려 한다.
** 이 글은 본인의 경험이므로 정답이 아닙니다.
1) 소개 (제 기준이며 필수 항목들이 아닙니다. 참고만 하시되, 입력 여부는 본인이 판단해주세요)
2) 프로젝트
프로젝트 표지
- 서비스 간략 소개, 서비스 중인 제품 (e.g. 웹서비스, 앱서비스, 어드민)
프로젝트명, 간략 소개, 기간, 기여도, 참여 인원
- 기여도 측정은 어떻게 하지..? 모든 프로젝트들은 디자이너, 개발자, QA와 함께했는데?
- 측정이 애매한 것들은 수행한 역할에 대한 기여도를 썼다. (e.g. 문제 정의, 솔루션 도출, PRD 작성 100%)
배경 설명
- 당시 어떤 지표를 중요하게 봤는지, 시장에 어떤 변화가 있었는지 등
- 읽는 사람은 내가 만든 서비스와 몸 담았던 회사에 대한 이해가 없다! 아예 빵이다! 에서부터 시작
어떻게 문제라는 것을 인식했는가? 그게 문제라는 근거는 무엇인가?
- 조상님이 꿈에서 이게 문제니 이 데이터를 한 번 봐보거라! 한 것이 아닐테니.. (..그랬으면 좋겠다)
- 어떤 지표를 높이려는 상황에서 X 데이터의 수치를 확인했다거나, A라는 액션을 한 고객들이 Y 행동 패턴을 보였다거나, 유저 인터뷰를 통해 도출했거나 등
도출한 문제 요약 > 해당 문제를 해결할 수 있는 솔루션
(이미지는 예시입니다. 작성 시 뾰족하게 문제점을 도출하고 그걸 해결할 수 있는 솔루션을 작성해야 함)
- 어떤 근거로 문제를 인식했고, 정량/정성 데이터를 통해 문제점을 도출한 후에 그 문제를 해결할 수 있는 솔루션을 작성
- 이 때, 복합적인 문제가 엉켜있더라도 가장 큰 문제를 잘 뽑아내서 딱 그것을 해결할 수 있는 솔루션을 작성해야함
- 이 솔루션을 통해 어떤 지표를 개선하려고 했는지 작성
성과
- 솔루션을 통해 어떤 변화가 있었는지 AS-IS / TO-BE를 비교해서 보여주면 베스트 (항상 고려할 것은, 이 포트폴리오를 읽는 사람은 내가 한 프로젝트에 대한 이해가 낮으므로 친절하지만 간결한 설명과 직관적 비교가 필요)
- 해당 프로젝트의 성과 작성 (프로젝트 진행 시 잡았던 goal 기준)
- Lesson Learned 내용이 있다면 짧게 작성하는 것도 좋음 (무지성으로 서비스를 만드는 사람이 아니라 항상 learning by doing하는 사람이라는 것을 전달할 수 있음)
1) 모든 것은 문제 인식 > 문제 정의 > 솔루션 > 성과 + 데이터
- 어떻게 문제를 인식했는지? (지속적인 인터뷰, 데이터 트래킹, Objective 달성을 위해 디깅했다던지..)
- 인식 후 문제를 뾰족하게 + 맞는 방향으로 정의했는지 고민의 과정이 드러나야 함
- 정의한 문제에서 벗어나지 않는 솔루션을 도출했는지! (이걸 못하면 무맥락 포트폴리오가 됨)
잘못된 케이스
조금 과장된 예를 들면, 상품 클릭수 감소하는 것이 문제인데 솔루션이 홈개편이다? 이런식
잘 된 케이스
문제 인식 : 상품 클릭수가 감소했다.
분석 : 여러 가지 데이터를 살펴보니, 후기가 없는 상품군의 클릭 비율이 낮다.
가설 : 후기 유무가 상품 클릭에 영향을 줄 것이다.
솔루션 : 리스트에서 후기 개수를 없애고 a/b test를 진행한다.
성과 : 후기 개수를 없앤 안의 상품 클릭률이 N% 높다.
물론 내 머릿속에는 여러 가지 근거 데이터와 문제가 들어있지만, 포트폴리오는 내 설명을 덧붙이는 것이 아니라 온전히 문서로만 나의 경험을 보여주는 것이므로 간결하고 명확하게 연결되어야 한다.
2) 왜 문제라고 생각했는가?
- 진행한 프로젝트 중 탑다운으로 진행한 것도 있을것이고, 바텀업으로 진행한 것도 있을 것이다. 여기서 중요한 것은 '탑다운으로 내려와서 그냥 했다'는 절!대! 안 된다는 것이다.
- 의사 결정자들이 어떤 의도로 해당 프로젝트를 탑다운으로 내렸는지 알고 있을 것이다. (아마 모든 기획자, PM이라면 이걸 모르고 그냥 일을 하지는 않을 것이라 믿는다) 그 내용을 바탕으로 당시의 문제와 이것을 통해 어떻게 해결하려고 했는지 작성한다.
- 나의 경우, IR을 위해 투자사에 어필해야하는 기능이 있었고 그것이 탑다운으로 내려온 프로젝트였다. 이 때에는 문제 인식의 '문제'보다 배경 설명에 조금 더 풀어넣었다.
3) 그래서 문제가 뭐였고, 솔루션은 무엇인지 / 왜 그 솔루션으로 결정했는지 맥락과 인과관계!
- 유저 인터뷰 내용을 넣거나 데이터가 있다면 정량적 데이터를 넣는다.
(분명 데이터 없이 직관으로 한 것도 있을 것이다. 맥락을 잘 풀어야 한다.)
- 여기서 중요한 것은 문제와 솔루션의 인과 관계가 맞는가?이다. 아마 문제는 A였는데, 여러 문제가 결합되어 A가 아닌 B라는 솔루션으로 진행하는 경우도 많을 것이다. 포트폴리오에서는 이런 오류가 없도록 문제-솔루션을 잘 정의해야 한다.
- 정의한 문제를 솔루션으로 해결했을 때 어떤 지표를 보고자 했는지 작성한다.
- 면접관으로 인터뷰에 참여하며 느낀 것은, 회사마다 문제를 해결하는 방식이 다르고 환경의 제약이 있었기 때문에 면접관이 생각하는 best 솔루션과 다를 수 있다는 것이다. 이 솔루션이 정답이냐 틀렸냐가 아니라, 어떻게 정의하고 어떤 논리로 풀어나갔는지가 잘 드러나야 한다.
본인이 진행한 프로젝트에 따라 구성은 달라질 수 있지만, 내 경우, '배경 설명 > 문제 인식 및 원인 분석 > 문제점 도출 > 문제점에 따른 솔루션 도출 > 성과 순으로 정리했다.
figma로 작업했는데 굳이 figma로 할 필요는 없어보인다.
익숙하지 않으면 손이 더 많이감.. (키노트로 할걸..)
디자인은 깔끔하게, 한 화면에 너무 많은 정보를 담지 않았다.
내가 만든 서비스가 무슨 서비스인지, 내가 어떤 사람인지 아예 모르는 사람이 읽었을 때에도 훅- 읽을 수 있도록 맥락을 잘 연결하는 것에 집중했다.
레이아웃은 비핸스의 작업물들을 조금 참고했는데 똥손인 나로서는 '예쁜' 포트폴리오는 어렵더라.
이쁘게 만들고 싶다면 주변의 디자이너에게 레이아웃 정도만 부탁을 해보는 것도 방법이다.
하지만 중요한 것은 '예쁜'것이 아니라 '깔끔함과 내용'이라는 것을 잊지 마시길!
진짜진짜 꼭!
부끄러울 수 있지만 서류 탈락하는 것보다 낫다.
나의 포트폴리오 ver.1을 아는 디자이너 동생에게 보여주고 피드백을 받았는데 엄청난 부끄러움을 느꼈었다. (맥락이 없었음)
그 덕분에 문제점을 인식했고 그 부분을 보완함으로써 서류 합격률 80%의 포트폴리오를 만들 수 있었다고 생각한다.
덧)
이 글을 읽고 나서도 감이 잘 안 잡히는 분들이 있을 것 같습니다.
1~3년차 주니어 분들 대상, 본인 포트폴리오 내용/구성 등을 어떻게 해야 할지 막막한 분들이 있다면 부족한 실력이지만 먼저 경험한 것들을 바탕으로 피드백 드릴 수 있습니다.
댓글로 말씀주세요.