협업툴 도메인 스터디: PM 관점에서 사용자 중심으로의 전환
이번 스터디에서는 처음에 협업툴 도메인과 PM 역할을 중심으로 발표를 준비했습니다.
협업툴이 무엇인지 정의하고, 그 안에서 PM이 어떤 역할을 하는지 정리하는 방향이었습니다.
하지만 정리하면서 한 가지 고민이 생겼습니다.
이 방향으로 가면 결국 일반적인 PM 설명과 크게 다르지 않다는 점이었습니다.
1. 방향에 대한 고민
처음에는 PM의 역할을 중심으로 내용을 구성했지만,
이 방식은 누구나 알고 있는 이야기로 흐를 가능성이 크다고 느꼈습니다.
그래서 저는 이렇게 생각했습니다.
“PM을 설명하는 것보다, 사용자의 문제를 보여주는 게 더 중요하지 않을까?”
2. 사용자 중심으로의 전환
이 고민을 바탕으로 발표 방향을 사용자 중심으로 전환해야겠다고 판단했습니다.
특히 협업툴은
- 여러 사람이 함께 사용하는 서비스이고
- 실제 업무 흐름 속에서 사용되기 때문에
👉 사용자의 불편함과 문제 상황이 더 중요하게 드러나는 도메인이라고 생각했습니다.
3. 페르소나와 문제 정의
그래서 저는 페르소나를 먼저 설정하고,
그 사람이 겪는 문제를 중심으로 흐름을 구성하는 것이 자연스럽다고 생각했습니다.
예를 들어,
- 협업툴을 사용하는 PM
- 실제 업무 중 발생하는 불편함
이런 요소를 통해 단순한 기능 설명이 아니라
👉 “왜 이 기능이 필요한지”를 설명할 수 있다고 보았습니다.
4. 문제 → 해결 구조의 중요성
특히 협업툴에서는 다음 구조가 중요하다고 느꼈습니다.
- 사용자 문제 발생
- 협업 과정에서 비효율 발생
- 이를 해결하기 위한 기능 또는 구조 설계
예를 들어,
회의 기록이 남지 않아 불편한 상황이 있다면
→ 기록 기능을 추가하거나 협업 흐름을 개선하는 방향으로 이어질 수 있습니다.
이처럼 협업툴은 단순 기능이 아니라
👉 업무 흐름 자체를 개선하는 방식으로 문제를 해결하는 서비스라고 생각했습니다.
5. 구조에 대한 생각
또한 발표 흐름에서도
단순히 정보를 나열하기보다는,
- 문제 상황을 먼저 보여주고
- 그 다음 해결 방식을 설명하는 구조가
👉 훨씬 자연스럽고 설득력 있다고 판단했습니다.
6. 느낀 점
이번 과정을 통해 제가 가장 크게 느낀 점은 하나였습니다.
PM은 기능을 만드는 사람이 아니라,
사용자의 문제를 정의하고 해결 방향을 설계하는 역할이라는 것
그리고 협업툴은
이 과정을 가장 잘 보여줄 수 있는 도메인이라고 생각했습니다.
마무리
결국 이번 스터디는
PM의 역할을 단순히 정리하는 것을 넘어서,
👉 사용자의 문제를 중심으로 서비스와 PM을 이해하는 방향으로 발전한 과정이었습니다.
이 경험을 통해
앞으로도 기능이 아닌 문제 중심으로 사고하는 것이 중요하다는 것을 다시 한 번 느끼게 되었습니다.
