도대체 PM과 PO는 어떻게 다른가
po에게 가장 중요한 능력은 무엇일까?
디자인 나침반님의 칼럼을 읽고 인사이트를 얻어 쓴 글
1. 프로덕트 디자인, 프로덕트 오너라는 새로운 직군이 탄생하면서 기존의 uxui 디자이너, 프로젝트 매니저 (pm)와 도대체! 무엇이! 어떻게! 다른지는 언제나 화두였다. 한 가지 확실한 결론은 회사마다 부여된 역할이 다르다는 점이다.
2. 나에게 있어 pm은 주로 에이전시나 si 업체에서 클라이언트의 요구 사항과 작업자의 업무 상황을 이어주는 딜리버리 역할을 하는 잡이고 (모든 것은 정해져 있고, 어떻게 해야 할지에 대해 소통한다), po는 스타트업에서 사업과 제품을 이어주는 중간 역할자다 (모든 것이 정해져 있지는 않고, 어떻게 해야 할지에 대해 소통한다). pm의 최종 보스가 클라이언트(혹은 대표)라면 po의 최종 보스는 유저다. 내가 누구를 위해 일하고 있는가, 스스로 질문했을 때 답이 전자라면 매니저이고 후자라면 오너라 할 수 있겠다. 둘의 공통점은 이상과 현실을 이어주는 '중간 다리'라는 점이다.
3. pm에게 가장 중요한 능력은 소통 능력이다. 클라이언트가 중요하게 생각하는 것을 캐치하고 작업자의 애로 사항을 발견하여 '적절하게' 조율한다. 중요한 건 질문과 공감 능력이다. 반면 po에게 가장 중요한 능력은 상상력이다. 회사가 가고자 하는 방향에 제품을 '구체적으로' 일치시켜야 한다. 풀고 싶은 문제에 대한 스토리 (미션과 비전)를 들었을 때 제품의 구체적인 모습이 머릿속에서 그려져야 한다. 실제로 내가 그렇다.
4. 누군가에게 문제를 듣는 순간 (그것이 나에게도 제법 흥미로운 문제라면) 머릿속에서 청취와 동시에 해결 방법이 떠오른다. 디자이너기 때문에 주로 화면과 레이아웃 형태로 아 그 문제는 이런 방식으로 풀 수 있겠다 등이 떠오르고, 상상력을 갖춘 디자이너가 프로덕트 오너가 되면 how를 비교적 적은 리소스로 빠르게 풀어낼 수 있는 장점이 있다. 유데미 강의 피그마로 기획과 디자인을 동시에 하는 mvp 제작 프로세스
5. 예를 들어 대표가 이런 이런 문제를 해결하고 싶어라고 말했을 때 디자이너 출신 po는 해결책을 바로 화면으로 그려버리는 식이다. 기획자도 필요 없고, 와이어프레임도 필요 없다. 간단한 컴포넌트 세트만 있으면 일주일 안에 핵심 가설 flow가 디자인된다. 가끔은 내가 대표이자 po가 될 때도 있는데, 그럴 때 나는 무아지경으로 날아가버린다 ㅋㅋ 디자인이 너무 재밌어. (물론... 디자인 때려치우려고 퇴사한 게 맞습니다만)
6. 대표가 사업과 기획(why)을 담당하고, 디자이너 출신 po가 기획과 디자인을 담당하므로 (how+what)가 아주 빠르게 정렬된다. 단, 대표도 시각화 혹은 문서로 기획할 수 있어야 한다.
출처 : 디자인 나침반7. 아래 글은 내 첫 번째 프로덕트 오너 도전기다. 이때의 시행착오를 발판 삼아 po가 무슨 일을 해야 하는지 더 정확히 알게 되었다.
첫째 - po에게는 어느 정도 사업에 관여할 수 있는 권한이 부여된다라고 설명했지만, 망하고 나서는 깨달았다. 프로덕트 오너는 사업에 관여하는 사람이 아니다. 사업을 이끌어 나가는 역할은 대표 고유의 롤이자 능력이다. po나 팀원들이 바텀업으로 사업과 회사의 미션, 비전 등에 관여하고 있다면 그 역할을 해야 할 사람이 충분하게 능력 발휘를 하지 못하고 있다는 소리와 같다. 애자일과 린 스타트업의 이름을 팔아 책임과 권한이 분산된 동아리가 돼서는 안된다. 그것은 애자일도 아니다.
둘째 - po의 역할은 how를 만들어내는 사람이다.
이상과 현실 사이에서 '되는 방법'을 생각하는 사람. 물론 개발자 출신이 프로덕트 오너 역할을 잘 해낼 수도 있다. 그러나 유저의 관점에서 되는 방법을 상상하는 일을 주구장창 해 온 직군은 역시 uiux, 제품 디자이너다.
8. 최근 나는 프로덕트 오너로서 내 역할을 잘하고 있는지, 팀워크가 좋은지, 내가 내 역할을 더 잘하려면 무엇을 해야 하는지 고민을 계속하고 있다. 백로그에서 우선순위를 설정하고 스프린트 돌리는 게 프로덕트 오너의 메인 역할인가? 제품 큐에이를 열심히 하는 게 프로덕트 오너가 할 일인가? 팀원들의 애로사항을 잘 청취 하는 것이 역할인가? 나는 메이커들이 왜 나만큼의 열정과 why 의식을 가지고 일하지 않는지, 그들에게 동기부여를 하려면 어떻게 해야 하는지가 고민이었다. why-how-what을 조직원들에게 일치시켜 주는 일이 프로덕트 오너가 해야 할 가장 중요한 일이 아닐까? 스프린트 돌리면서 '공유'를 빙자한 주입을 해야겠다 마음먹던 찰나,
출처 : 디자인 나침반9. 어쩌면 내 기대치가 너무나 말도 안 되게 높을 수 있다는 것을 깨달았다. 팀원들이 나만큼 문제의식을 가지고 기획에도 참여하길 바랐다. (특히 개발팀이 ㅋㅋ) 내 머릿속에 있는 환상 속의 초기 스타트업 모습이다. 사실 팀원들은 알아서 자기 역할에 잘 정렬되어 있을지도 모른다. 모두들 일을 하는 이유와 몰입도가 각자의 영역에서 다를 수밖에 없고, 개발팀은 개발에만 몰입돼도 그들의 역할은 충분히 한 것이다. 왜 why에 대해 질문을 갖지 않으세요~?라고 강요 할 수는 없는 노릇이다. 태스크 하나를 던졌을 때 집요하게 질문하고 의심하는 태도도 초기 스타트업에는 독약이다. 모르겠으면 그냥 고 -!! 일단 하고 생각해!!
10. 나 또한 디자이너로서 how를 만들어내는 역할을 잘하고 있으니, 결론은 팀원을 믿고, 조직 써클 정렬을 잊을만할 때쯤 상기시키며 앞으로 나아가는 수밖에 없다는 것을 깨달았다. 깨달음의 기록 끗 - *
