포트폴리오에 결과물만 넣으면 안 읽힙니다

포트폴리오를 보면 대부분 결과물이 먼저 나옵니다. 완성된 화면, 출시한 기능, 올라간 지표. 읽는 쪽은 그것을 보고 "잘 만들었네"까지는 갑니다. 그런데 거기서 멈춥니다. 이 사람이 우리 회사에서도 같은 것을 할 수 있는지가 안 보이기 때문입니다.

결과물은 그 회사의 제약 안에서 나온 것입니다. 제약이 안 적히면 결과물만으로는 판단이 안 섭니다.

넣어야 하는 네 가지

1. 1그때 무엇이 문제였는지. 그리고 그 문제를 본인이 발견했는지 받았는지
2. 2고려했다가 버린 선택지와 버린 이유. 이게 가장 안 쓰이고 가장 잘 읽힙니다
3. 3본인이 한 것과 팀이 한 것의 구분. "제가 방향을 잡고 구현은 개발팀이 했습니다"가 감점이 아닙니다
4. 4숫자가 있다면 그 숫자의 규모. 전환율 5퍼센트 개선은 사용자 천 명과 이백만 명에서 완전히 다른 일입니다

빼도 되는 것

• 도구 나열. 쓸 줄 안다는 것은 어느 프로젝트에서 무엇에 썼는지가 있어야 증거가 됩니다
• 회사 소개. 읽는 쪽은 그 회사를 이미 알거나 검색하면 됩니다
• 과정 전체를 시간순으로 나열한 것. 읽는 쪽은 판단한 지점만 궁금합니다
• "열정을 가지고 임했습니다" 류. 물어보면 전원이 같은 답을 합니다

실패한 것을 넣는 게 낫습니다

성공 사례만 있는 포트폴리오는 두 가지로 읽힙니다. 운이 좋았거나, 실패한 것을 숨겼거나. 어느 쪽도 좋지 않습니다.

가설이 틀린 것으로 나온 실험 하나와 거기서 무엇을 바꿨는지를 넣으면 그 사람이 어떻게 판단하는지가 드러납니다. 그로스 직무에서는 특히 그렇습니다. 실패한 실험이 없으면 실험을 안 한 것으로 읽힙니다.

안 만들기로 한 것도 성과입니다

프로덕트 쪽이라면 출시 목록보다 잘라낸 것이 강합니다. 무엇을 안 만들기로 했고 그 판단의 근거가 무엇이었는지요. 만드는 것은 누구나 하지만 자르는 것은 판단이 필요합니다.

한 줄 요약

포트폴리오는 무엇을 만들었는지의 목록이 아니라 어떻게 정했는지의 기록입니다. 읽는 쪽은 결과물이 아니라 판단을 삽니다.