이 포스팅은 2개의 글로 구성된 시리즈 중 2번째 글입니다. 이전 글을 읽으려면 “샌프란시스코 테크 업계 인터뷰 1: Facebook, Fivestars”로 이동하세요.
안녕하세요, 스포카 프로덕트 매니저 옥지혜입니다.
제품을 담당하는 팀이 일하는 방식은 제품 그 자체에 영향을 줍니다. 어떠한 기능을 어떤 주기로 사용자에 배포할 것이냐에 대한 결정을 하는 과정이기 때문입니다. 그뿐만 아니라 정성적인 차원에서 새로운 기능을 개발하거나 운영하는 일 등을 조직이 어떻게 평가하느냐에 따라 작업자의 업무 만족도와 작업물의 품질에도 영향을 미칩니다.
구태의연한 말이지만 테크 업계에서 일하는 방식에 있어 정답은 없습니다. 제품과 조직은 끊임없이 변화하고 이에 맞추어 일하는 방식도 바뀌어야 하므로 지난해에 불합리하다고 여기던 방식이 올해는 검토해 볼 만한 것이 될 수도 있습니다. 일하는 방식 그 자체도 협의를 거쳐 지속적으로 개선하는 과정이 필요합니다.
일하는 방식과 함께 제품과 조직마다 프로덕트 매니저의 역할과 권한도 바뀝니다. 비즈니스에 제품이 기여하는 정도에서부터 조직 내 이해관계자와의 관계까지 제품과 조직의 모든 요소가 프로덕트 매니저가 일하는 방식에 영향을 미칩니다. 스포카 프로덕트 매니저의 경우, 서비스 백로그 관리의 역할도 담당하기 때문에 유동적으로 일하는 방식에 따른 결과는 제품에 다시금 반영됩니다.
이번 샌프란시스코 테크 업계 인터뷰는 위와 같은 가정하에 ‘스포카는 앞으로 어떤 방식으로 일할 것인가’라는 질문에 대한 참고할 사례를 수집하기 위하여 진행하였습니다. 닭과 계란 문제일 수 있지만, 이것은 ‘스포카는 어떤 제품을 만들고자 하는가’하는 고민과 맞닿아 있습니다.
인터뷰는 총 5회에 걸쳐 아래의 PM 분들과 진행하었습니다. 흔쾌히 인터뷰에 응해 주신 모든 분께 감사드립니다. 각 인터뷰이와 나눈 이야기 중 인상적이었던 부분을 발췌하여 2개의 포스팅에 걸쳐 공유하겠습니다.
- Stephanie Shum(Director Product Management at Facebook)
- David Park (Refereum COO)
- Michael Hsu (Product Manager at FiveStars)
- Chris Nguyen (VP Product at Bleacher Report)
- 홍성철 (Product Manager at Udemy)
- 정대영 (Product Manager at Intuit)
Chris Nguyen (VP Product at Bleacher Report)
현재 담당하고 있는 팀은 어떻게 구성되어 있나요?
C: 초기에는 직무 단위로 팀을 구성하였다. 현재는 전략에 맞도록 제품 단위의 스쿼드로 구성을 변경했다. 제품 팀은 전체적으로 디렉터 2명, 시니어 PM 2명, 주니어 PM 2명과 디자이너 7명으로 구성되어 있다. PM 1명 당 디자이너 1.5명의 비율을 유지하려고 한다. 보다 구체적인 수준으로 아이디어를 디벨롭하기 위해서이다. 엔지니어는 50명 규모로까지 충원하는 것을 목표로 하고 있다.
PM은 팀에서 어떤 역할을 하나요?
C: 스프린트를 안정적으로 운영하기 위해서 말 그대로 할 수 있는 일은 모두 도맡아서 했다. 점차로 팀이 커지면서 제품과 팀이 어떤 우선순위를 가지고 움직일지 트래킹하는 데에 집중하려고 노력했다. 우선순위를 지킬 수 있도록 스프린트를 계획하고 계획대로 일이 진행될 수 있도록 챙기는 역할에 집중했다. 실제 배포를 위한 역할이 이와 같다면, 서비스 전략 관점에서는 중요한 결정사항이 타당했는가에 대하여 결정 이후에도 자주 점검했다. 또 제품 팀의 KPI를 정확하게 측정하고 제품 팀에서 하는 모든 일이 KPI를 달성하였는지 검토했다.
PM으로서 제품 팀에 동기부여를 어떻게 하나요?
C: PM의 가장 중요한 역할 중 하나는 ‘왜 이 일을 해야 하는가’에 대하여 끊임없이 설명하는 것이다. 목표와 이를 달성하기 위해 해야 하는 일을 문서화하고 이것이 실제로 팀에서 할 수 있는 일이라는 것을 다양한 방식으로 팀에 전파한다. PM이 주로 조직과 제품에 대한 다양한 정보를 취득하게 되므로 팀 내에 이를 지속적으로 공유하는 것 역시 중요하다. (운영 업무에 대한 동기부여는 어떻게 하나요?) 서비스가 성장하고 시간이 흐를수록 기술 부채가 쌓이기 마련이다. 신규 기능에 대한 요구사항과 기술 부채 삭감을 위한 작업의 무게를 맞추는 역할도 PM의 몫이다. 팀에서 담당하는 가시화되지 않는 업무를 지적하여 마땅한 보상을 받게 하는 것이 좋은 방법이라고 생각한다.
홍성철 (Product Manager at Udemy)
PM의 역할 중 무엇이 가장 중요할까요?
홍: PM은 완성도 있는 제품을 제때 배포할 수 있는지가 가장 중요하다. Udemy의 경우, 서비스에 기술적인 오류가 있을 때 책임을 PM이 지게 하여 제품의 기술적인 영역에 집중하도록 유도한다. PM은 제품의 연 단위 목표를 수립하고 분기 단위로 쪼개진 목표를 실제로 달성할 수 있도록 2주 단위 스프린트를 운영하는 사람이다. (제품 팀이 목표지향적으로 일하기 위해 어떤 장치를 두나요?) 모든 기능의 제안은 원 페이지 기획서로 시작한다. 이 기획서에 해당 기능을 왜 지금 만들어야 하는지에 관해서 설명하게 한다. 이외에도 반드시 팀 비전과 목표에 각각의 기능이 어떻게 기여하는지도 적도록 요청한다. 기능을 제안하는 모든 팀은 이 문서를 작성하여 그것을 기반으로 백로그 조정을 진행한다.
유관부서 요구사항의 우선순위 조율과 디벨롭에 있어서 팁이 있나요?
홍: 기능을 제안한 배경이 되는 문제를 명확하게 정의해야 불필요한 커뮤니케이션을 줄일 수 있다. 아울러 특정 기능의 진행 우선순위를 높이면서 다른 기능의 우선순위가 내려간다는 점을 강조하여야 한다. 모든 커뮤니케이션의 기본은 그것이 협상의 성격을 띤다는 점이다. 개발 팀과의 커뮤니케이션도 협상이다. 이를테면 커뮤니케이션 스킬이 뛰어난 프로그래머와 협업하는 경우, 어떠한 예외 케이스가 있는지와 이에 대하여 대응할 때 검토할 수 있는 옵션을 제시할 수 있어 효과적으로 일할 수 있다. 개발 팀 외부 조직은 제품의 기술적인 영역에 직접 관여할 수 없다. 따라서 어떤 프로그래머가 개발 팀의 리더인지에 따라 협의 결과에 큰 차이를 가져올 수 있다.
컴퓨터 공학에 대한 사전 지식의 유무 또는 한국인이라는 점이 샌프란시스코에서 PM으로 일하는 데 영향을 미친다고 생각하나요?
홍: 재학 중에 시스템 디자인 엔지니어링을 배웠다. PM으로서의 업무 경험이 쌓이면서 테크니컬 배경 유무에 따른 차이가 갈수록 작아진다. 경력 초반에 개발 팀의 업무에 공감할 수 있는 범위와 정도의 차이에 영향을 주었고 시간이 갈수록 차이가 작아졌다. 모바일 앱 시장 초기 단계에는 빠른 출시가 중요하므로 공학 배경이 있는 사람을 업계에서 선호했다. 시장 성숙도가 올라가면서 현재는 트렌드가 바뀌었다. 샌프란시스코에 일하는 한국인 PM은 MBA 출신이 대다수이고 다양한 문화적 배경을 가진 사람이 업계에 많으므로 이 또한 크게 문제는 되지 않는다. 적극적인 태도와 뛰어난 업무 능력이 있다면 적응하는 데에 어려움은 없다고 생각한다.
정대영 (Product Manager at Intuit)
기능에 대한 요구사항은 어떻게 발굴하나요?
정: 발의하는 주체에 따라 크게 2가지 카테고리로 구분할 수 있다. 외부에서 발생하는 요구사항의 경우, 사용자의 제안 또는 리서치를 통해 발굴할 수 있다. 내부에서 발생하는 요구사항의 경우, 사용자 관점에서 서비스 개선사항을 직접 찾아낸다. 이후에 프로젝트를 만들고 프로토타이핑하여 A/B 테스트를 진행한다. 제품 팀 - PM, 디자이너, 엔지니어 - 모두 개선사항을 찾는 과정에 참여한다. 제품의 목표는 탑다운으로 제시될 수 있으나 실제 액션 아이템에 대한 결정은 실무 단에서 가장 비즈니스 임팩트를 줄 수 있는 기능을 정한다. 기존 백로그의 우선순위에 영향을 주는 기능 요구사항이 있을 경우, 명확한 기준을 근거로 투명한 의사결정을 거쳐 우선순위를 결정한다. 이는 모든 요구사항이 협상 과정이라는 것을 강조한다는 점에서 유의미하다.
사내에서 제품 팀 또는 제품에 대한 피드백은 어떻게 받나요?
정: 모든 임원진이 참석하여 제품에 대한 피드백을 주는 미팅이 있다. 서비스에 대한 내부 피드백을 정확하게 받을 수 있는 계기가 된다. 이 회의를 통해 전략 미팅이 시작되기도 하며 구체적인 프로젝트 협의를 진행하는 미팅이 이어지기도 한다. 각기 다른 제품을 담당하는 PM이 모두 모이는 미팅도 있다. 미팅 이전에 어떤 피드백을 받고 싶은지에 대해 사전 요청을 하기도 한다. 반드시 ‘애자일’ 하게 일하는 방식이 옳다고는 생각하지 않는다. 방법론보다는 데이터 기반의 피드백과, 일반적인 경험에 대한 언급보다는 명확하고 직관적으로 상대방에게 구체적인 피드백을 주는 것이 중요하다.
제품 팀이 목표에 집중할 수 있도록 PM으로서 어떤 역할을 하시나요?
정: 비즈니스 목표와 제품 팀의 목표가 서로 연관되어야 하는 것은 당연하다. 다만 기술 부채 문제처럼 비즈니스 목표에서 포함하지 않는 제품 팀의 목표가 있을 수 있고, 이 또한 협상의 대상이다. 기술 부채의 범위와 정도에 따라 서비스 자체에 영향을 미칠 수 있기 때문이다. 이러한 문제를 해결하기 위해서 Hack day를 운영한다. 제품 팀이 특정 문제를 해결하기 위해, 정해진 시간 동안 다른 업무를 진행하지 않고 그 문제에만 집중할 수 있도록 유도하는 방식이다. 또한 PM은 업무 우선순위를 정함에 있어 신규 기능과 기존 기능 버그 패치를 함께 조율한다. 제품의 퀄리티는 제품 팀 또는 개발 팀만의 책임이 아니고 전사의 책임이다. 테스트와 클린업의 중요성에 대해 전사적인 공감대 형성이 필요하다.
총 5회에 걸친 인터뷰를 통해 얻을 수 있는 인사이트를 요약 하자면 다음과 같습니다.
- 비즈니스 목표와 제품 팀 목표가 연관될 수 있도록 업무 방식을 관리해야 한다.
- 요구사항 간의 우선순위를 조율하는 것은 협상의 과정이다. 협상의 주된 기준은 비즈니스 임팩트에의 기여도이며 기술 부채와 같이 가시화되지 않는 기준도 PM이 검토하여 반영해야 한다.
- 제품 팀 자체도 제품이다. 팀원의 피드백을 취합해서 효과적인 동시에 행복하게 일할 수 있도록 업무 방식을 개선해 나가야 한다.
스포카에서는 위와 같은 인사이트를 기반으로 스포카 크리에이터(스포카 제품 팀)의 업무 방식을 지속적으로 개선하고 있습니다. 스포카 크리에이터는 우선 서비스 품질 차원의 기술적인 목표를 관리합니다. 동시에 제품이 비즈니스에 어떻게 기여하는지를 확인하고 보다 큰 임팩트를 낼 수 있는 기능을 탐색합니다. 이 결과로 제품에서 발생하는 매출 지표 혹은 이에 기여하는 부가 지표를 관리합니다. 아울러 제품 팀 외 유관부서의 요구사항을 취합하는 채널을 일원화하고, 스프린트를 구성하는 회의에서 이를 발의받아 우선순위를 정합니다. 이러한 협의체는 스포카 크리에이터가 가장 효과적으로 비즈니스와 제품에 기여할 수 있도록 업무를 조율하는 역할을 합니다.
마지막으로 스포카 크리에이터는 분기 단위로 동료 간 리뷰 및 조직장과의 면담을 거쳐 팀의 컨디션을 체크합니다. 피드백을 통해 각 팀원은 보다 성장할 수 있는 기회를 확인할 수 있습니다. 조직 차원에서는 각 팀원이 비즈니스 또는 제품의 목표에 대해 얼마나 공감하는지를 확인하고 기여하고자 하는 업무를 파악하여 팀이 보다 효과적으로 일할 수 있도록 조직 구성을 변경하기도 합니다.
스포카 크리에이터는 개인의 성장이 팀의 성장으로 이어지고 이는 곧 제품의 경쟁력과 연결된다고 믿습니다. 스포카와 함께 성장하실 수 있는 분은 언제나 환영합니다.
