좋은 PM은 기능이 아니라 문제를 기획한다 (문제 정의 템플릿 제공)

"이 기능, 왜 만드세요?"

PM으로 첫발을 내딛던 시절, 저는 야심 차게 준비한 기획안을 들고 기획 리뷰에 참석했습니다. 기능 하나하나를 공들여 설계한 기획서를 보며 '이 정도면 완벽하다'고 자신했죠. 그런데 날카로운 질문이 날아왔습니다.

OO님, 그래서 이 기능 왜 만들어요?

준비한 답변을 하려 했지만, 제 말을 끊고 다시 물으셨습니다.

아니, 그게 아니라. 이 기능이 해결하려는 진짜 문제가 뭐냐고요. 

그리고 그 문제를 해결하는 방법이 왜 꼭 이 기능이어야 해요?

머리가 띵했습니다. 저는 '사용자가 원하는 기능'이 가장 중요하다는 생각에 사로잡혀, '문제'보다 '기능'에만 집중하고 있었던 겁니다. 그 날의 피드백을 통해 깨달았습니다. 진정한 PM의 역할은 단순히 기능을 만드는 사람이 아니라, 문제를 정의하는 사람이라는 것을요.

이 글은 〈IT 회사에서 주니어 PM으로 살아남기〉 시리즈의 두 번째 글입니다. PM의 중요한 역량 중 하나인 문제를 정의하고, 해결 방법을 구조화하는 방법을 다룹니다. PM에게 가장 중요한 스킬은 기능을 기획하는 것 보다는, '어떤 문제를 어떻게 해결할지'를 아는 것입니다. 이번 글에서는 문제를 기획할 때 가장 중요한 접근 방법을 소개합니다.

기획의 출발점: 사용자가 겪는 문제를 파고드는 것

흔히 PM이라고 하면 '기획서'부터 떠올립니다. 화려한 PPT와 완벽하게 정리된 기능 목록, 꼼꼼하게 짜인 와이어프레임 등 시각적으로 멋진 결과물이 기획의 전부라고 생각하기 쉽죠. 하지만 이런 멋진 기획서는 사실 기획의 '극히 일부분'일 뿐입니다. 가장 중요한 핵심을 나타내지는 않죠.