디자이너, 개발자가 일하고 싶은 프로덕트 매니저가 되자
제품을 함께하는 팀원이 누구인지, 어떻게 협업할지 알아보기
-
프로덕트 매니저에게 중요한 커뮤니케이션 원칙
앞선 글처럼 프로덕트 매니저는 제품을 만드는 과정 전체에 관여하며 다양한 구성원들과 협업을 한다. 따라서 업무의 상당 부분이 커뮤니케이션이며, 이를 매끄럽고 효율적으로 처리하는 게 중요하다. 그렇지 않으면 본인뿐만 아니라 팀원들의 리소스를 깎아 먹는 일이 쉽게 발생한다.
예를 들어 제품 요구사항을 제대로 전달하지 못하면 조직에게 '승용차'가 필요한데 '오토바이'를 제작하는 상황이 발생한다. 따라서 디자이너, 엔지니어에게 요구사항을 설명할 때에는 3자가 동일하게 이해하고 있는지를 명확히 확인해둬야 한다. 주요한 이해관계자를 생략하고 요구사항을 확정 지으면 뒤늦게 추가 요청이 발생하거나 제품 방향성을 재검토해야 하는 상황도 발생한다. 한참 진행 중인 개발을 멈추고 다시 시작하는 비효율을 만든다. 따라서 제품과 연관된 사람이 누구인지를 파악하고 의사결정 과정에 참여시켜야 한다.
-
제품을 만드는데 함께하는 사람들
프로덕트 매니저가 제품을 만드는데 협업할 사람들은 누구일까? 제품 내부, 외부로 나누어볼 수 있다. 내부는 실제 제품을 구현하는데 참여하는 구성원을 말한다. 제품 디자이너, 백엔드/프런트엔드 엔지니어, 데이터 분석가, QA 테스터가 해당된다. 외부는 제품을 직접 구현하지 않지만 연관된 구성원을 말한다. 즉, 실무에서 제품을 운영하거나, 제품으로 고객/파트너와 소통하거나, 법무/재무 이슈를 알아야 하는 사람들이다. 고객센터, 마케터, MD, 정보 보안 담당, 재무 담당자 등이 해당된다. 함께 일하는 사람들을 파악했다면, 어떻게 협업하면 좋을지를 알아보자.
제품 내부, 외부로 다양한 구성원과 소통하는 프로덕트 매니저-
제품 디자이너와 어떻게 일하면 좋을까?
프로덕트 매니저는 제품의 UX/UI를 도출할 때 디자이너와 긴밀하게 협업한다. 이들은 제품 요구사항을 와이어프레임으로 구현하고, 프런트엔드 개발을 위한 디자인 가이드를 제작한다. 개발 산출물은 코드로 이루어져 이해하기 어렵지만, 디자인 산출물은 눈에 보이니 간섭의 여지가 많다. 디자인이 본인의 취향과 다르다고 버튼 컬러, 스타일 등에 세세한 피드백을 하기 쉽다. 이러한 커뮤니케이션은 프로덕트 매니저로서의 정체성, 디자이너와의 협업 관계를 모호하게 한다.
디자이너는 고객들이 직관적으로 느끼고 사용하기 편리한 방법이 무엇일지 경험과 식견을 갖춘 전문가이다. 이를 염두하고 디자인과 연관된 결정을 존중해야 한다. 그 대신 디자인 산출물을 다른 관점에서 분석할 수 있어야 한다. 디자인 산출물이 제품의 방향성과 일치하였는지, 전체 플로우를 감안할 때 어색함은 없는지, 문제의 핵심 원인을 정확히 해결하고 있는지, 고객들이 편리하고 직관적으로 받아들일지 피드백을 줘야 한다. 프로덕트 매니저는 UX/UI를 넘어 고객/기술/비즈니스 관점에서 제품 전체를 바라봐야 하기 때문이다.
또한, 디자이너가 올바른 결정을 내리도록 돕는 것도 필요하다. 예를 들면 상품 페이지에서 문의하기 버튼을 얼마나 강조해서 보여줄지 판단하기 어렵다면, 제품 내에서 연관된 영역의 클릭률을 찾아 판단 근거로 제공해준다. 새로 노출할 광고 영역에 표시할 타이틀이 필요하다면, 프로덕트 매니저는 광고 운영 담당자, 카피라이터와 협의해 타이틀을 정해줄 수 있어야 한다.
-
제품 엔지니어와 어떻게 일하면 좋을까?
제품 개발은 크게 백엔드, 프런트엔드로 나뉜다. 백엔드는 제품에 필요한 DB(Database)와 프런트엔드와 데이터를 송수신할 API(Application Programming Interface)를 설계한다. 특정 기간 많은 접속량이 예상된다면 서버 인프라를 관리해 트래픽을 안정성 있게 처리하는 작업도 수행한다. 프런트엔드는 디자인 가이드를 기반으로 웹/앱의 UI 및 동작 방식을 구현한다. API로 받은 데이터를 화면에 출력하거나, 유저가 입력한 데이터를 API로 보낸다. 유저 행동 분석이 필요하다면 화면의 컴포넌트 별로 로그(Log)를 심기도 한다.
엔지니어와 잘 소통하기 위해서는 이들이 어떻게 일을 하는지 살펴야 한다. 프로덕트 매니저에게 요구사항을 전달받으면, 전체 로직을 기반으로 발생 가능한 케이스를 검토한다. 제품의 품질을 높이기 위해 오류를 최소화해야 하기 때문이다. 이후 어떤 구조로 제품을 설계할지 결정하고 코드를 작성한다. 따라서 프로덕트 매니저는 요구사항을 작성할 때 전체 플로우와 다양한 Use Case를 고민해보는 게 필요하다.
개발 일정을 정할 때에도 담당 엔지니어와의 충분한 협의가 필요하다. 제품 개발에 필요한 리소스가 어느 정도 일지, 현재 할당된 테스크들을 고려했을 때 언제쯤 작업을 시작할 수 있을지 확인해야 한다. 이를 조직에서 중요하게 생각하는 일정과 감안하여 최종 개발 일정을 결정해야 한다. 엔지니어에게 너무 부담을 줘서는 안 되지만, 그렇다고 제품 로드맵에 차질이 생기지 않는 적정선을 찾아야 한다.
마지막으로 엔지니어의 설명을 제대로 이해하지 못한 채 중복된 커뮤니케이션을 만들지 않아야 한다. 따라서 기본적인 제품 개발 용어와 개념을 익혀두는 게 좋다. 능숙한 프로덕트 매니저는 커뮤니케이션을 효율적으로 하는 수준을 넘어 더 좋은 방안을 제시하기도 한다.
-
제품과 연관된 이해관계자와 충분히 소통한다
개발을 시작한 이후로는 수정사항을 최소화하는 게 중요하다. 따라서 요구사항을 작성할 때에 주요한 의사결정권자, 이해관계자가 누구인지를 파악하는 게 중요하다. 미리 미팅 자리를 만들어 현재 만들려는 제품이 무엇인지를 설명하고, 관련 피드백을 수집해두는 게 좋다.
예를 들면 신규 결제수단을 추가할 때에 고객센터 담당자에게 관련 내용을 공유해야 한다. 고객들이 관련 문의를 하거나 문제가 발생했을 때 대처해야 하기 때문이다. 유저의 위치정보를 활용하는 제품이라면 개인정보 보안 담당자에게 예상되는 이슈가 있는지를 확인해야 한다. 조직 내 다른 제품에도 영향을 줄 수 있는 상황이라면 담당 프로덕트 매니저, 의사결정권자가 충분히 인지하고 있는지를 확인해야 한다.
프로덕트 매니저. 조금 더 알고 싶으세요?
클래스 101에서 커리어 강의를 오픈했어요. 프로덕트 매니저 직무 탐색, 고객/사업/기술을 이해하는법, 제품문제를 분석하고 해결하는법, 제품 출시 관리 및 커뮤니케이션까지 그간 쌓아온 경험을 꾹꾹 눌러담았어요.
클래스 보러가기
