"훌륭한" 프로덕트 매니저, 혹은 불가능한 프로덕트 매니저

훌륭한 프로덕트 매니저란 무엇일까요? Shreyas Doshi가 트위터에서 제시한 훌륭한 프로덕트 매니저의 요건 목록을 소개합니다:

• 훌륭한 PM은 지속적으로 회사의 성장 궤도를 개선합니다.
• 훌륭한 PM은 상황에 따라 정량적, 정성적 데이터를 능숙하게 조합합니다.
• 훌륭한 PM은 자신의 분야에서 세계적인 전문가가 됩니다. 새로운 분야에서는 기존의 전문가들에게 조언을 구하면서 이 과정을 시작합니다.
• 훌륭한 PM은 다양한 사용자 조사 방법을 통해 어떤 제품을 만들어야 할지 정보를 얻습니다.
• 훌륭한 PM은 고객이 말하지 않는 부분도 듣고, 산업이 나아갈 방향을 예측하여 제품 가설을 개발합니다.
• 훌륭한 PM은 단순한 동의(buy-in) 이상이 필요함을 알고, 열정과 소유의식을 통해 훌륭한 제품을 만듭니다. 팀 전체가 창의적인 아이디어를 낼 수 있도록 토론을 이끕니다.
• 훌륭한 PM은 높은 영향력을 가진 업무에 집중합니다.
• 훌륭한 PM은 드물게 제품이 실패할 경우, 자신의 접근 방식을 개선할 뿐만 아니라 그 교훈을 회사 전체에 공유합니다.
• 훌륭한 PM은 적응력이 뛰어나며 팀의 필요에 맞게 도구, 프로세스, 워크플로우를 조정합니다.
• 훌륭한 PM은 문제 예방에 능숙하며, 어떤 문제를 예방하고, 해결하고, 해결하지 않을지 분별합니다.
• 훌륭한 PM은 회사의 제품 정신을 다듬고, 결함을 발견하여 수정한 뒤 이를 따르고 전파합니다.
• 훌륭한 PM은 직급이나 경력 사다리가 완벽하지 않음을 이해하며, 실질적인 역량과 영향에 더 집중합니다.
• 훌륭한 PM은 업무 프로젝트를 통해 배우지만, 자기계발에 대한 호기심과 열정 덕분에 개인 시간에도 더 많이 배웁니다.
• 훌륭한 PM은 궁극적으로 사용자와 비즈니스에 최선인 결정을 내립니다.
• 훌륭한 PM은 제품 전략이 최적화되었는지 확인합니다.
• 훌륭한 PM은 열심히 일하지만 거의 압도당하지 않습니다.

마지막 항목은 다소 웃깁니다. "압도당하지 않으면서 개인 시간에 자신의 분야를 더 많이 배우라"니요.

이런 목록에는 항상 "예외"가 포함되기 마련입니다. 예를 들어, "마지막 규칙은: 자신이 무엇을 하는지 안다면 어떤 규칙도 깨도 된다." 이번 경우에는 31번째 트윗이 그렇습니다.

실제로 매우 소수의 PM만이 훌륭한 PM입니다.
그리고 제가 아는 훌륭한 PM 중에서도 위의 모든 항목을 항상 수행하는 사람은 없습니다.
왜냐하면 훌륭한 PM은 이러한 아이디어를 계율이 아닌 이정표로 바라보기 때문입니다.

자, 이제 수십 가지를 초인적으로 잘하는 사람이 될 수 있다면 어떻게 해야 할까요?

저는 WP Engine에서 다음의 프레임워크를 사용해 이 질문에 답했습니다. 이 프레임워크를 통해 전체 팀이 신화적인 "훌륭한 PM"의 역할을 함께 구성하지만, 실제로는 훌륭하지만 현실적인 사람들이 그 역할을 해내는 것입니다.

PM의 역할: 무엇을 만들지 결정하는 것

회사마다 "프로덕트 매니저"의 역할과 범위는 다르지만, 그 역할의 핵심은 무엇을 만들지 결정하는 것입니다.

"전략"과 "고객 연구"가 프로덕트 매니지먼트의 입력 요소로, "Scrum 프로덕트 오너십"과 "조정 및 커뮤니케이션"이 실행 활동으로 작용하며, 그 중심 목표는 무엇을 만들지 결정하는 것입니다.

과거로 돌아보면 장기적인 비전과 전략, 그리고 고객에 대한 깊고 변화하는 이해가 결정의 중요한 입력 요소입니다. 이 요소들은 프로덕트 매니지먼트의 일부이며, 이들이 없으면 좋은 결정을 내릴 수 없습니다.

미래를 바라보면, 제품을 만들고 고객에게 전달하는 실행이 있습니다. 이는 엔지니어링의 복잡한 실행과 마케팅, 영업, 고객 서비스, 외부 파트너와의 조정 노력을 포함하여 고객에게 전체 경험을 제공하는 것을 의미합니다. 이 모든 것도 프로덕트 매니지먼트의 일부입니다.

이 분류가 자의적이라고 주장할 수도 있지만, 제 경험상 이 분류는 채용, 경력 개발, PM 조직 설계에 있어 특히 실용적이며 다른 역할 분해 방식과도 호환됩니다.

프로덕트 매니지먼트의 네 가지 역할

전략가

• "우리의 지속 가능한 강점을 시장의 기회에 어떻게 적용하여 성공할 것인가?"라는 질문에 대한 답을 분석하고, 구상하고, 소통하며, 업데이트합니다.
• 수년 후 성공했을 때 우리의 모습은 어떤지 상상하고, 그 성공을 이루기 위해 가장 중요한 도전 과제가 무엇인지 파악합니다.
• 구체적으로, 앞으로 몇 년간 그 도전 과제를 극복하기 위해 무엇을 해야 할지 결정합니다.
• 경쟁 분석, 시장 분석, 고객 분석을 수행합니다.
• 집중해야 할 몇 가지 핵심 페르소나를 결정합니다.
• 혼란스러운 데이터를 내부 강점, 외부 도전 과제, 시장 기회에 대한 명확한 식별로 정제합니다.
• 제품의 가치를 극대화하여 가격과 지불 의향을 높이기 위해 제품을 포지셔닝합니다.
• 장기적인 결과를 이끌어낼 수 있는 적절한 고수준 지표를 선택합니다. 모든 중요한 요소가 숫자로 나타나지 않는다는 점과, 매출과 유지율은 훌륭한 전략과 실행의 결과이지 그것 자체가 전략이나 운영 목표는 아니라는 점을 인식합니다.
• 수년에 걸쳐 영향을 미칠 결정을 내리기 위한 용기를 가지고, 90%의 아이디어를 "아니오"라고 말할 수 있어야 하며, 그로 인해 정확히 올바른 아이디어에 "예"라고 말할 수 있어야 합니다.

고객 전문가

• 고객의 말을 단순히 듣는 것이 아니라 그들의 근본적인 필요, 동기, 심지어 감정까지 이해합니다.
• 고객이 이름 붙일 줄 아는 기능을 주문받는 것이 아니라, 그들이 너무나 걱정해서 기꺼이 돈을 지불하고라도 줄이고 싶어하는 걱정을 찾아내거나, 궁극적인 목표를 달성하기 위해 필요한 결과를 파악합니다.
• 단순히 그것을 파악하는 것을 넘어서, 이를 파악하고 싶어하는 열정을 가집니다.
• 명확한 정량적 데이터가 없어도 특히 유용할 기능을 감지할 수 있는 "감각"을 가지며, 단순한 사용자 경험(UX)과 고객을 열렬한 지지자로 만드는 즐거운 UX의 미묘한 차이를 구별합니다.
• 이러한 통찰을 구체적인 기능 아이디어나 만들고 싶은 사용 사례로 전환하여 고객을 영웅으로 만듭니다.

스크럼 프로덕트 오너

• 초보자에게는 다소 모호하게 들릴 수 있지만, 스크럼 "프로덕트 오너"는 작업 백로그를 소유하며, 이를 실행하기 위해 엔지니어링 팀과 협력합니다.
• 작업의 시작부터 끝까지 책임을 지며, 에픽을 스토리로 분해하고, 고객을 위한 혁신을 다른 팀의 요청과 회사의 더 큰 필요와 조율하며 우선순위를 정하고 일정을 조정합니다.
• 엔지니어링 팀과 긴밀하게 협력하여 "가장 가치 있는 것(그 의미가 무엇이든)을 가장 적은 시간(또는 위험) 안에" 달성하기 위해 퍼즐을 함께 풀어갑니다.
• 스토리 포인트와 속도, 회고를 활용하여 팀 전체가 건설적인 자기 성찰과 개선을 이룰 수 있도록 하며, "자기 관리"의 책임을 다합니다.
• 최대한 많은 가치를 전달할 수 있도록 노력하지만, 과도한 열정이 번아웃으로 이어지지 않도록 실용적이고 축하하는 분위기를 유지합니다.
• 제품과 팀에 대한 통제력을 가집니다.

조율자

• Geoffrey Moore가 정의한 대로 전체 제품(Whole Product)을 전달하는 것은 단순히 작동하는 코드만 제공하는 것이 아니라, 다른 부서들이 역할을 다 할 수 있도록 돕는 것을 의미합니다.
• 마케팅 팀이 주목을 끌고 호기심을 유발할 수 있도록 지원하며, 영업 팀이 잠재 고객(리드)을 실제 판매로 전환할 수 있도록 돕고, 고객 서비스 팀이 고객을 좋은 시기와 어려운 시기 모두에서 지원할 수 있도록 합니다.
• PR과 이벤트를 담당하는 Marcomm 팀, 고객을 대신해 활동하는 외부 통합업체와 컨설턴트들이 원활하게 활동할 수 있도록 지원합니다.
• 상태를 추적하고 소통하며, 좋은 소식과 도전 과제를 공유하고, 승리를 축하하고 어려움을 명확하게 설명합니다.
• 팀이 극복해야 할 사항을 명확히 알고 있음을 이해시키며, 이를 통해 이해 관계자들에게 팀이 상황을 완전히 장악하고 있다는 안심을 줍니다.
• 회의를 효과적으로 운영하며, 명확한 목표와 논의가 전략을 어떻게 지원할 것인지 설정하고, 참석자들이 준비하여 동기화된 시간을 효과적으로 사용할 수 있도록 합니다.
• 가끔은 전체 회사와의 회의에서 영감을 주는 발표를 통해 모두가 우리가 함께 이루고 있는 일에 대해 흥미를 느끼게 하고, 제품에 직접 참여하는 팀들이 자부심을 느끼고 인정받는 기회를 제공합니다.

결론은, "훌륭한 PM은 이 모든 것을 완벽하게 수행해야 한다"는 것이 아닙니다.

오히려 정확히 그 반대입니다.

하나의 분야에서 탁월함, 또 하나에서 잘함

제 경험과 몇몇 대화 상대들의 경험에 따르면, 위의 역할에 관한 일반적인 규칙이 있습니다:

"훌륭한 PM"은 한 분야에서 탁월하고,
적어도 다른 한 분야에서는 잘하며,
두 개 이상의 분야를 모두 수행할 시간은 없습니다.

훌륭한 PM의 언어를 사용하자면, 네 가지 역할 중 하나에서 최상급이 되도록 노력하고, 다른 하나에서는 꽤 잘하기 위해 노력해야 합니다.

저는 이 네 가지 역할 구분이 실제 사람들의 강점과 능력에 잘 맞아떨어진다고 생각합니다. 천성인지 배경인지, 본능인지 경험인지와 관계없이, 각각의 역할에 대해 특정 분야에서 거의 모든 구성 요소에 탁월한 사람을 쉽게 떠올릴 수 있습니다. 반면, 다른 분야에서는 다양한 수준의 능력을 갖추거나 부족한 사람도 있고, 어떤 분야에서는 완전히 맞지 않는 성향이나 열망을 가진 사람도 있습니다. 이 네 가지 "버킷"은 능력과 성향의 자연스러운 구분처럼 보입니다.

저는 네 가지 모두에 탁월한 마법의 유니콘이 존재한다고 믿지 않습니다. 하지만 그런 유니콘이 존재한다고 가정하고, 고용했다고 하더라도 모든 분야에서 훌륭한 실행을 하는 것이 물리적으로 가능할까요? 뛰어난 업무를 수행하는 데 걸리는 시간을 합해 보면 불가능하다는 것이 명백합니다.

전략은 지속적입니다 — 시장이 변화하고, 경쟁자가 변하고, 고객이 변하며, 새로운 데이터가 나타납니다(이는 일반적으로 상당한 시간을 들여야만 얻을 수 있습니다). 전략의 한 사이클을 마무리할 때마다 아직 해결하지 못한 여덟 가지 과제가 남아있습니다. 고객 발견에는 많은 시간이 필요합니다 — 인터뷰를 예약하고 진행하며, 결과를 모으고, 들은 내용을 맵핑하며, 활동이나 기회 또는 사용 사례를 우선순위로 지정하고, 데이터로 가정을 (반)증명하려고 노력합니다. 프로덕트 오너 역할을 맡으려면 매주 스크럼 세레모니를 진행하고 훌륭한 스토리를 작성하는 데 최소 20시간이 필요합니다. 여러 부서의 여러 팀을 프로그램 관리한 사람이라면 스케줄링, 조직화, 조율, 상태 업데이트, 데이터 수집, 회의 준비에 많은 시간이 걸린다는 것을 알 것입니다. 뛰어난 기술을 가지고 있어도 모든 일을 완벽하게 할 시간은 없습니다.

우리는 새로운 초인종을 길러낼 수 없습니다. 현재 우리가 가진 사람들로 조직을 운영해야 합니다.
— Peter Drucker

한 사람이 모든 역할을 수행할 수는 없지만, 전체 프로덕트 팀에서는 네 가지 역할 모두에서 탁월함이 필요합니다. 따라서 프로덕트 조직의 관리자는 단순한 "관리자"가 아니라 "조직 설계자"로서 의도적인 채용을 통해 이 결과를 만들어 내야 합니다.

"프로덕트 매니저"라는 타이틀 외에도 이러한 역할을 자주 발견할 수 있습니다. Program Manager는 종종 커뮤니케이션과 협업을 담당하며, 만약 이 역할이 불필요하다고 생각한다면 이는 그 역할을 훌륭하게 수행하는 사람과 일해보지 않았기 때문일 수도 있습니다. Product Marketing은 종종 마케팅, 영업, 지원 활성화를 담당하며 이는 CTO 밑이 아니라 CMO 밑에 있을 수 있습니다. 고객 접촉이 거의 없는 고도로 기술적인 백엔드 팀의 경우, 사교적인 엔지니어나 아키텍트가 훌륭한 프로덕트 오너가 될 수 있습니다. 성숙한 조직에서는 UX 리서치 팀이 고객 분석 전문가로서 데이터 기반 페르소나를 구축하고, 인터뷰를 기획하며, 결과를 모으고, 여러 프로덕트 팀 간에 인사이트를 공유합니다.

조직 설계자로서, 당신의 역할은 모든 분야에서 탁월함을 조립하는 것입니다. 여기에 약간의 개선만 있어도 큰 영향을 미칠 수 있습니다. 왜냐하면 많은 조직이 어디에서도 탁월함을 갖추고 있지 않기 때문입니다. 직원의 95%가 전략을 이해하지 못하거나 그 속에서 자신의 역할을 모른다고 불평합니다. PM 역할을 맡은 창립자는 체계적인 고객 분석보다는 본능에 의존하며 운영하는 경우가 많습니다. 엔지니어링 팀은 명확하지 않거나 설명이 부족한 스토리에 불만을 갖고, 엔지니어는 제품에 대해 알고 있는 사실과 영업에서 전화로 주장하는 내용의 차이에 놀라곤 합니다. 고객 서비스 팀 또한 제품에 대해 알고 있는 사실과 엔지니어링이 "잘 끝냈다"고 생각하는 부분 사이의 차이에 놀라는 경우가 많습니다.

유니콘을 찾기보다는, 이보다 더 실용적인 접근 방식을 경력이나 팀 설계에 활용하십시오.