Q.047 PM은 어디까지 관여해야 하나요?
[Chapter 2. 일하는 방식] 어떻게 생각하고 행동하나요?
PM 커리어 150문 150답 내용 발췌PM 일을 하다 보면 업무나 의사결정의 경계가 애매할 때가 많다. "이건 디자이너가 결정할 일인가, 내가 결정할 일인가?", "개발 방식까지 관여해야 하나?" 같은 고민이 생긴다. PM은 모든 세부사항까지 컨트롤하지 않는다. 물론 회사마다 PM이 세부사항까지 컨트롤해야 할 수도 있다. 하지만 어떤 결정이 왜 내려졌는지, 그 결과가 사용자나 팀에 어떤 영향을 미치는지는 알고 있어야 한다.
1. PM은 모든 세부사항까지 컨트롤하지 않는다
PM은 모든 세부사항까지 컨트롤하지 않는다. (물론 회사마다 PM이 세부사항까지 컨트롤해야 할 수도 있기는 하다) 하지만 어떤 결정이 왜 내려졌는지, 그 결과가 사용자나 팀에 어떤 영향을 미치는지는 알고 있어야 한다.
예를 들어 디자이너가 버튼 색상을 선택할 때, PM이 "이 색으로 해주세요"라고 지시할 필요는 없다. 하지만 "이 버튼은 사용자가 가장 많이 클릭하는 버튼이니까 눈에 잘 띄어야 해요"라는 맥락은 전달해야 한다. 디자이너는 그 맥락을 이해하고 최선의 디자인을 만든다.
실제로 한 PM은 "처음엔 디자인 디테일까지 다 관여하려고 했는데, 디자이너가 '제가 전문가인데 왜 이렇게까지 지시하세요?'라고 하더라. 그 이후로는 '왜 이 기능이 필요한지', '사용자가 어떤 행동을 해야 하는지'만 명확히 전달하고, 디자인은 디자이너에게 맡겼다. 오히려 결과물이 더 좋아졌다"라고 했다.
2. 기능 하나가 비즈니스에 어떤 효과를 줄지 고민해야 한다
PM의 역할은 "왜"와 "무엇"을 정의하는 것이다. "어떻게"는 각 직군의 전문가에게 맡긴다. 기능 하나가 비즈니스에 어떤 효과를 줄지, 디자인 방향이 어떤 목표를 위한 것인지 등을 질문하고 연결해야 한다.
예를 들어 개발자가 "이 기능을 A 방식으로 구현할까요, B 방식으로 구현할까요?"라고 물으면, PM은 기술적 세부사항을 다 이해하지 못해도 "사용자가 3초 안에 결과를 볼 수 있어야 한다"는 요구사항을 명확히 전달할 수 있다. 개발자는 그 요구사항을 만족하는 최선의 방식을 선택한다. 물론 협업하기 좋은 개발자는 A방식과 B방식의 차이점과 각자의 장단점까지 말해주기도 한다. 그때는 더 나은 결정을 하는데 도움을 받을 수도 있을 것이다.
백엔드 PM으로 첫 커리어를 시작하게 된 PM 한 명은 개발자가 '이 기능을 Redis로 캐싱할까요, DB에서 바로 조회할까요?'라는 질문을 들었는데, 기술적으로는 잘 몰랐다고 한다. 대신 '사용자가 버튼을 누르면 1초 안에 결과가 나와야 한다'라고 요구사항을 명확히 했고, 개발자가 최적의 방법을 선택했다고 했다.
3. 전체 그림과 방향성은 PM이 책임져야 하는 영역이다
PM은 실행의 주체는 아닐 수 있지만, 전체 그림과 방향성은 책임져야 한다. "이 기능이 왜 필요한가", "이게 우리 제품 전체에서 어떤 의미인가", "사용자에게 어떤 가치를 주는가"를 명확히 하고, 팀 전체가 같은 방향을 보도록 조율하는 게 PM의 역할이다.
예를 들어 디자이너가 화면을 만들고, 개발자가 코드를 짜고, 마케터가 사용자를 데려오는 동안, PM은 "우리가 지금 만드는 게 사용자 문제를 제대로 해결하고 있는가", "비즈니스 목표와 맞는가"를 계속 점검한다. 세부사항은 각 전문가에게 맡기되, 전체 방향은 PM이 책임진다.
PM은 모든 세부사항까지 관여하지 않는다. 하지만 "왜 이 결정을 내렸는가", "이게 사용자와 비즈니스에 어떤 영향을 주는가"는 항상 알고 있어야 한다. 디자이너, 개발자, 마케터는 각자의 전문성을 발휘하고, PM은 전체 방향과 맥락을 책임진다. 세부사항은 맡기되 큰 그림은 놓치지 않는 게 PM의 역할이다.
* 전체 내용을 정리한 전자책은 아래에서 확인할 수 있습니다.
* 관련 실제 합격 포트폴리오를 확인하고 싶으시다면 아래에서 확인할 수 있습니다.