나는 무슨 서비스를 하는지, 무슨 문서를 쓰는지로 PM의 일을 정의하고 싶지 않다. 기획서를 쓴다, 스펙을 정리한다, 지표를 본다. 그건 PM이 무엇을 하는지일 뿐이다. 나는 그것보다, 그 일의 밑에 뭐가 깔려 있는지가 더 중요하다고 생각한다.
PM이라는 직군의 정의&워크플로우를, 오늘의 나는 (앞으로 바뀔 수도 있으니) 이렇게 내린다.
기회를 포착하고(단서를 찾아) 주장을 세우고, 논리를 덧붙여 설득하고, 설득이 되면 그걸 되게 만들고, 될 때까지 하는 사람. 되게 만든 그것을 성공이라 부른다. 이게 오늘 내가 내린 정의다. 도메인이 바뀌어도, 다루는 문서가 바뀌어도 이 정의는 안 바뀐다.
그런데 이것도 결국 무엇을 하는지의 나열이다. 단서를 찾고, 설득하고, 되게 만들고. 결국 행동의 나열이다. 왜 단서를 찾고, 무엇을 되게 만드는가. 그 모든 행동이 어떤 바닥에서 시작된것인지. 이 글은 그 foundation 밑바닥에 있는 나의 생각을 정리한 것이다.
PM은 크게 두 개의 시선을 가지고 있다.
PM은 유저와 가장 맞닿는 사람이다. 유저가 어디서 불편함을 느끼는지 좋아하는지 뭘 원하는지 유저를 가장 가까이서 맞닿으며 소통한다.
그런데 PM은 동시에 전체 사업의 구조를 그리는 사람이기도 하다. 이 서비스가 어떻게 굴러가고, 어디서 돈이 돌고, 어떻게 스스로 커지는지. 결국 사업이 돌아가야 서비스를 지속할 수 있는 것. 그 큰 그림도 PM이 그린다.
대부분의 구조는 비즈니스 임팩트를 위함이다
사업 구조를 그리는 건 필요한 일이다. 회사는 임팩트를 원한다. 마케팅 없이도 유저가 자생적으로 도는 구조, 서비스가 스스로 굴러가는 구조. 그걸 만들려고 구조를 설계한다. 여기까진 아무 문제가 없다.
그런데 그 구조는 임팩트에서 출발했다. 유저 효용에서 출발한 게 아니다.
유저가 이걸 원한다.에서 나온 게 아니라, 이 임팩트를 내려면 이게 있어야 한다.에서 역산을 할 수 있다.
구조는 완벽하게 짜였는데, 정작 유저한테는 아무 효용이 없을 수 있다.
여기서 흔한 착각, 실수들이 있다.
회사는 임팩트를 좇고, 나는 유저를 지킨다. 마치 잘못된 구조를 밖에서 감시하는 사람인 것처럼. 아니다. 유저의 경험의 설계도, 구조를 그리는 사람이 나다.
혹은 내가 임팩트를 좇아 구조를 그린다. 여기서 유저가 이쪽으로 흐르고, 저기서 트래픽이 돌고. 구조가 아름다워질수록 나는 그 안에 빠져들때도 있다. 실제로 유저가 그렇게 느껴서 이 구조가 작동할 수 있는 구조인가? 라는 것이 고려되지 않으면 의미없는 구조니까.
그때 세워야 하는 날
그래서 날을 세워야 한다. 구조를 그리다가 멈추고 물어야 한다.
내가 지금 되게 만들려는 이것, 유저가 진짜 원하는 건가?
예를들어 이 지표를 올리려면 가입 과정에 단계를 하나 더 넣으면 된다. 숫자상으로는 맞다. 그런데 유저가 그 단계를 원해서 여기 온 걸까? 그 단계 하나가 유저한테 무슨 효용을 주나. 아무것도 안 준다면, 그건 지표를 위해 서비스의 이익을 위해 유저의 경험을 방해하는 것이다. 물론 유저를 10000% 만족시키며 서비스의 이익을 0을 만드는건 사업이 아니다. 난 그렇게 생각한다.
처음 말했던 PM의 행동 정의. 기회를 찾고 주장을 만들고 논리를 세워 일이 되게 만드는 것. 단서는 유저에게 있다. 회의실이 아니라. 회의실 안에 있는 사람이 유저일 경우도 있다. 하지만 대개는 아니다. 되게 만드는 것도 결국 유저한테 효용 있는 걸 되게 만드는 거다. PM은 진짜 유저한테 효용을, 될 때까지 되게 만드는 사람이다.
증명된 게 없으면, 목소리가 넘친다
검증할 게 없다는 건 뒤집으면 이런 뜻이다. 아무것도 증명되지 않았다.
이건 초기 서비스만의 얘기가 아니다. 성숙한 서비스에도 증명 안 된 결정은 늘 있다. 신기능, 그 서비스에서 시도해보지 않은 것들, 신사업 등. 데이터가 아직 없는 자리는 어디에나 있다. 증명된 게 없으면 누구 말이든 다 그럴듯해진다. 대표의 목소리, 투자자의 목소리, 옆 팀의 목소리, 시장이 이렇다더라 하는 목소리. 반박할 데이터가 없으니, 제일 센 목소리나 제일 그럴듯한 목소리가 이긴다.
이때 필요한 게 축이다. 데이터가 못 잡아주는 걸 축이 잡아줘야 한다. 축이 없으면 매번 목소리 크기 싸움이 되고, 축(기준)이 있으면 판단할 수 있다.
우리는 유저에게 어떤 경험을 주고 있는가?
구조는 그려야 한다.
그 구조가 유저 효용을 위해 있는지,
프로덕트를 만들어내는 내가 스스로 확인하는 것.
프로덕트를 만드는 사람이 구조를 그리는 손과 유저의 목소리를 듣고 바라보는 눈을 가지고 있어야한다. 이 둘을 같이 들고 있으면, 구조는 유저 효용을 위해 작동한다
PM이 잊지 말아야 하는 것
PM은 사업 구조를 그리는 사람이다. 동시에 유저와 가장 맞닿아 있는 사람이다.
구조를 그리다 보면 유저를 잊는다. 임팩트가 눈앞에 있고 구조가 이상적일 경우가 많다. 그림이 아름다울 것이다. 증명된 게 없을 때는 제일 큰 목소리에 말리기도 쉽다.
구조를 그리는 손과, 유저를 보는 눈을 같이 드는 것. 그리고 그 눈이 흔들리지 않게, 유저에게서 답을 찾아가야하는걸 잊지않는것. 그 모든 행동의 바닥엔 유저다. 그게 PM이 잊지 말아야 하는 것이다.