기획자는 어떻게 자신의 역량을 효과적으로 보여줄까?

Question. 기획자로 일하고 있는데, 개발자는 코드로, 디자이너는 포트폴리오로 자신을 증명할 수 있잖아요. 기획자는 뭘로 자신의 역량을 보여줘야 하는지 모르겠어요. 기획자만의 어필 방법이 있을까요?

개발자의 코드와 디자이너의 포트폴리오 — 기획자에게는 무엇이 있을까요?

이 질문에는 한 가지 전제가 숨어 있습니다. '결과물이 보이는 직군은 자신을 증명하기 쉽고, 기획자는 그런 결과물이 없다'는 것입니다.

그런데 정말 그럴까요?

개발자의 코드를 봅시다. 코드 자체를 본다고 그 개발자의 역량을 알 수 있을까요? 사실 코드만 보면 알기 어렵습니다. 그 코드가 어떤 맥락에서 작성되었는지, 어떤 제약 조건 안에서 만들어졌는지, 어떤 문제를 해결하려 했는지를 알아야 역량을 판단할 수 있습니다. 디자이너의 포트폴리오도 마찬가지입니다. 예쁜 화면만 나열하면 좋은 포트폴리오가 아닙니다. 어떤 문제를 풀려고 했고, 왜 이 디자인을 선택했고, 그 결과 어떤 변화가 있었는지를 보여줘야 합니다.

결국 모든 직군의 역량 증명은 같은 구조입니다. 맥락 → 판단 → 실행 → 결과. 기획자도 이 구조를 똑같이 보여줄 수 있습니다. 다만, 보여주는 '형태'가 다를 뿐입니다.

'결과물'과 '결과물의 과정' — 무엇이 더 가치 있는가

Ken Norton(전 Google 제품 부문 파트너)은 좋은 프로덕트 매니저를 채용할 때 무엇을 보는지를 분석합니다. "나는 PM 후보를 면접할 때, 그 사람이 만든 제품이 무엇인지보다 '왜 그런 결정을 했는지'를 묻는다. 제품의 성공은 수많은 요인에 의해 결정되지만, 의사결정의 과정은 그 사람의 사고 방식을 보여준다. 좋은 PM은 데이터와 고객 인사이트를 바탕으로 왜 A가 아닌 B를 선택했는지를 명확하게 설명할 수 있는 사람이다."

(출처: Ken Norton, "How to Hire a Product Manager", 2005)

핵심이 여기에 있습니다. 기획자의 역량은 '무엇을 만들었는가'가 아니라, '왜 그것을 만들었는가'를 설명할 수 있느냐에 달려 있습니다.

기획자에게도 기획 문서가 있습니다. 하지만 기획 문서 자체가 포트폴리오가 되는 것이 아닙니다. 그 기획 문서가 탄생하기까지의 사고 과정이 포트폴리오가 됩니다. 고객 리서치를 통해 어떤 인사이트를 발굴했고, 그 인사이트를 어떻게 기능으로 연결시켰는지. 이 사고 과정이 문서에 디테일하게 드러나면, 그것이 개발자의 코드나 디자이너의 포트폴리오에 필적하는 증거가 됩니다.

보이지 않는 역량 vs 보이는 역량 — 기획자가 기록해야 하는 것들

Scott Berkun(전 Microsoft 프로젝트 매니저, 기술 경영 작가)은 프로젝트 관리 역량의 본질을 이렇게 분석합니다. "프로젝트 매니저의 가장 중요한 역량은 코드를 작성하는 것도, 디자인을 하는 것도 아니다. 서로 다른 관점을 가진 사람들이 하나의 목표를 향해 움직이도록 만드는 것이다. 이 역량은 눈에 보이지 않기 때문에 과소평가되기 쉽다. 하지만 이것이 없으면 아무리 뛰어난 개발자와 디자이너가 있어도 제품은 완성되지 않는다."

(출처: Scott Berkun, 『Making Things Happen: Mastering Project Management』, O'Reilly Media, 2008)

기획자가 어필하기 어렵다고 느끼는 이유가 바로 여기에 있습니다. 기획자의 핵심 역량 — 커뮤니케이션, 갈등 해소, 우선순위 판단, 일정 관리 — 은 눈에 보이지 않는 역량입니다. 개발자의 코드처럼 파일로 존재하지 않고, 디자이너의 화면처럼 시각적으로 드러나지 않습니다.

그래서 기획자에게 '기록'이 더 중요합니다. 일을 할 때, 결과물이 남는 형태의 일을 하는 것이 좋습니다.

의사결정 기록. 왜 이 기능을 먼저 만들기로 했는가. 세 가지 옵션 중 왜 이것을 선택했는가. 어떤 데이터를 근거로 판단했는가. 이런 의사결정의 과정을 문서로 남기세요.

갈등 해소 기록. 개발자가 이렇게 하고 싶었고, 디자이너가 저렇게 하고 싶었을 때, 내가 어떤 커뮤니케이션을 통해 합의점을 찾았는가. 팀 내 갈등을 어떻게 해결했는가. 이것이 기획자만의 역량입니다.

프로세스 기록. 프로젝트의 시작부터 끝까지, 어떤 단계를 거쳤는가. 시간을 어떻게 줄였는가. 기간을 정하고 완수하기 위해 무엇을 했는가. 이 과정 하나하나가 기획자의 포트폴리오가 됩니다.

상위 1%의 기획자가 다른 점

Lenny Rachitsky(전 Airbnb 프로덕트 매니저, 테크 뉴스레터 저자)는 뛰어난 프로덕트 매니저를 구분하는 요소를 분석합니다. "최고의 PM은 두 가지를 동시에 잘한다. 첫째, 고객의 문제를 깊이 이해한다. 둘째, 그 이해를 팀이 실행할 수 있는 형태로 번역한다. 많은 PM이 첫 번째만 하거나 두 번째만 한다. 고객의 목소리를 듣지만 그것을 제품으로 연결하지 못하거나, 기능은 잘 정의하지만 고객이 진짜 원하는 것과 동떨어져 있거나. 둘 다 잘하는 PM은 드물고, 그래서 가치가 있다."

(출처: Lenny Rachitsky, "What Differentiates the Top 1% of Product Managers from the Top 10%", Lenny's Newsletter, 2023)

여기서 기획자가 어필할 수 있는 핵심이 드러납니다. 고객 리서치 → 인사이트 발굴 → 기능 연결. 이 세 단계의 사고 과정을 구체적으로 보여줄 수 있으면, 그것이 기획자의 가장 강력한 포트폴리오입니다.

특히 초기 스타트업에서 기획자의 역할은 더 넓습니다. 한 팀에 기획, 디자인, 개발 세 사람이 있을 때, 초기 스타트업에서는 기획자가 대표의 역할도 같이 합니다. 프로덕트를 만들자고 했는데 개발자가 하고 싶은 대로 개발하고, 디자이너가 하고 싶은 대로 디자인하면 배가 산으로 갑니다. 그래서 기획자는 프로덕트 매니징을 함께 하게 됩니다.

이것은 기획자에게 불리한 것이 아니라, 오히려 유리한 것입니다. 기획, 매니지먼트, 고객 리서치, 커뮤니케이션을 모두 경험하기 때문에, 기록할 것이 훨씬 더 풍부합니다.

기획자의 포트폴리오는 '스토리'입니다

정리하면 이렇습니다. 기획자가 자신의 역량을 보여주는 방법은, 프로젝트의 시작부터 끝까지에 대한 스토리텔링입니다.

프로덕트를 만든 의도는 무엇이었는가. 고객을 어떻게 정의했는가. 고객 획득을 위해 어떤 방법을 시도했는가. 팀 내에서 어떤 역할을 했는가. 어떤 갈등이 있었고 어떻게 해결했는가. 결과는 어떠했는가.

이것 하나하나를 디테일하게 정리해두면, 그것이 굉장한 포트폴리오가 됩니다. 개발자의 GitHub보다, 디자이너의 Behance보다 더 강력할 수 있습니다. 왜냐하면, 이 스토리는 단순히 '무엇을 했는가'를 넘어 '어떻게 생각하고 결정했는가'를 보여주기 때문입니다.

일하는 과정들을 기록하세요. 결과물이 남을 수 있도록 하세요. 기획자의 결과물은 코드나 디자인이 아닙니다. 기획자의 결과물은, 좋은 제품이 만들어지기까지의 과정 그 자체입니다.

하나쯤 있으면 두려울 게 없는 든든한 내 편이 되어, 함께 고민하겠습니다.

함께 읽으면 좋은 글

• 서비스 기획자가 왜 비즈니스를 공부해야 하나요?
• 문과생은 IT 업계에서 어떤 역할을 할 수 있나요?
• 스타트업형 인재는 어떤 사람일까?

---

참고 자료

• Ken Norton, "How to Hire a Product Manager", 2005
• Scott Berkun, 『Making Things Happen: Mastering Project Management』, O'Reilly Media, 2008
• Lenny Rachitsky, "What Differentiates the Top 1% of Product Managers from the Top 10%", Lenny's Newsletter, 2023