처음 발표를 준비할 때는 PM의 역할과 도메인을 중심으로 내용을 구성하려고 했다.
개인적으로는 생성형 AI와 협업툴 두 가지 도메인을 떠올렸고, 특히 협업툴은 PM이라는 직무와 가장 밀접한 영역이라고 생각했다.
PM은 다양한 직군과 협업하며 제품을 만들어가는 역할이고, 협업툴은 이러한 과정을 직접적으로 지원하는 서비스이기 때문이다.
그래서 처음에는 협업툴에서 PM이 어떤 역할을 하는지, 그리고 일반 PM과 어떤 차이가 있는지를 중심으로 발표를 준비하려고 했다.
하지만 팀원들과 논의를 하면서 방향이 조금씩 바뀌기 시작했다.
도메인 중심으로 접근하는 것이 아니라, 사용자와 문제를 중심으로 바라봐야 한다는 이야기가 나왔다.
이 과정에서 자연스럽게 질문이 바뀌었다.
협업툴을 사용하는 사람은 누구인지, 그리고 그 사람들이 실제로 어떤 문제를 겪고 있는지에 대한 고민이 시작됐다.
특히 페르소나를 설정하면서 이 변화는 더 명확해졌다.
협업툴을 사용하는 PM이라는 관점에서 보면, 단순한 기능 문제가 아니라 협업 과정에서의 불편함이 보이기 시작했다.
예를 들어, 회의를 진행했지만 기록이 남지 않는 문제,
대화는 있었지만 실제 업무로 이어지지 않는 문제,
여러 툴을 오가면서 흐름이 끊기는 문제 등이 있었다.
이러한 문제들을 보면서 협업툴의 본질은 기능이 아니라 흐름이라는 생각이 들었다.
그래서 협업툴 PM의 역할도 다시 정의하게 되었다.
협업툴 PM은 단순히 채팅 기능이나 파일 공유 기능을 만드는 사람이 아니라, 사람들이 일하고 소통하며 의사결정을 내리는 흐름을 설계하는 사람이라고 생각하게 되었다.
협업툴 역시 단순한 도구가 아니라 대화, 정보, 업무가 하나의 흐름으로 이어지도록 돕는 플랫폼이라는 관점으로 바라보게 되었다.
이번 발표를 준비하면서 느낀 점은, 기획은 기능에서 시작하는 것이 아니라 문제에서 시작해야 한다는 것이었다.
도메인이나 기능 중심으로 접근하면 비슷한 이야기에서 벗어나기 어렵지만, 사용자와 문제를 중심으로 접근하면 더 깊이 있는 고민으로 이어질 수 있다.
결국 PM의 역할은 기능을 만드는 것이 아니라, 사용자의 문제를 이해하고 그 문제를 해결하는 흐름을 설계하는 것이라고 느꼈다.
그리고 협업툴은 이러한 흐름을 가장 잘 드러내는 도메인이라고 생각하게 되었다.