ProductOps에 대한 올바른 이해
Product 조직 확장의 문제와 해결에 대하여
백그라운드.
요즘 심심치 않게 Product Ops라는 단어가 보인다. 관련 콘텐츠들을 살펴보니 Product 조직의 본질적인 고민과 맞닿은 맥락들이 있어 한번 정리해 보는 게 좋겠다고 생각했다.
온라인 Product를 만드는 조직을 경험했다면, DevOps라는 들어봤을 것이다. 도구/표준화/자동화 등을 통해 개발 운영의 생산성을 높이고, 엔지니어들이 문제해결에 집중할 수 있도록 도와준다. 지난 10년 전부터 SW 수요가 폭증하면서 개발 운영 환경이 워낙 중요하다 보니 DevOps가 중요해졌다(특히 Product 중심 회사는 개발 생산성이 회사 성장에 치명적인 경우도 많고) 이제 Product 운영환경도 마찬가지인 것일까? 이제 빨리 생산하고 선점하는 것보다는 운영 생산성이 승부처가 된 것일까?
어쨌거나 개인적으로도 Product 조직을 구성하고 확장하고 변화관리를 할 때, 항상 아래와 같은 고민들이 징그럽게 따라다녔다.
Product의 규모와 팀이 확장되어 가며 생기는 문제들(표준화/통합, 프로세스, 커뮤니케이션, 늘어나는 Day-to-Day Task들)은 누가/어찌 처리할 것인가?
고객의 정량적/정성적 인사이트는 누가 수집하는가? PM들이 일일이 다 챙길 수도 없고, 고객을 대면하는 부서도 있는데, 어떻게 수집되고 통합되는가?
우리 Product 운영을 위한 도구/방법론은 무엇이 적합하고, 누가/어떻게 적용/변화관리하는가?
Product 릴리즈에 대한 공유, 전파, 교육, 정리는 누가 하나?
Product Ops라는 용어를 Trigger 삼아, Product 조직을 Scaling 할 때 해결해야 할 문제들에 대해 올바른 관점을 가져보자.
Product Ops가 대체 뭔지 일단 짚어보자
우선, 아래 조직이나 팀은 Product Ops의 본질적인 범위가 아니다.
주어진 요구사항을 처리하면 되는 IT팀이나, 아직 최적화를 논하기에는 작은 팀/초기단계이거나, 기능조직으로 세분화/안정화되어 운영상 고민이 없는 팀
고객을 직접 마주하거나(Sales Account, Customer Success), 고유한 기능이 있는 역할(Product Marketer, Data Analyst)의 역할. (물론 이런 역할을 확장/통합하여 Product Ops가 될 수는 있지만.. 우선 제외)
반대로 말하면, Product 규모가 빠르게 확장되어 곧곧에 시한폭탄이 많다거나, 도메인/스쿼드가 복수 또는 Product가 복수라서 중구난방이거나, Product Manager들이 번아웃되었거나 하는 등이 문제인 조직이 해당된다.
Product Ops의 주요 역할은 대개 아래와 같이 정의되고 있다. (다만, 조직의 상황마다 다르다고 한다)
시장과 고객에 대한 정량적/정성적 인사이트 수집
Product Management 체계화를 위한 도구와 프레임워크
Product Day-to-Day Task를 처리: 릴리즈, 교육, 버그 정리 등
요약하면 위와 같고, 아래와 같은 차트도 참고!
Product Ops의 역할, Damith De Silva 링크드인
Product Ops가 하는일, 출처: productled.com합쳐놓으니 애매한 것 같으면서도, 하나 하나 보면 "저거 중요한데 늘 고민이야"라는 생각이 동시에 든다.
그러고 보면 Product 조직에는 제3의 누군가가 있다
Product 구루, Marty Cagan에 따르면 Product 조직은 기본적으로 Maker(Product Manager/디자이너/ 엔지니어/UX리서처/데이터분석가 등)와 Manager(이들의 리더들)로 구성된다.
그런데 "Process People"이라고 통칭하는 제3의 역할들도 계속 생겨나고 있다. Product를 만드는 사람들이 아닌, "Process"를 다루는 사람들이다. Scrum Master, Agile Coach, Program Manager, Project Manager도 해당된다고 봐도 되겠다. [*참고로 Marty는 Product Owner 또한 Scrum Framework의 정의상 Maker로 보지는 않아서 이 분류로 넣었는데, 본 글에서는 그냥 제외해 두었다.]
그리고 최근에는 새로운 용어인"ProductOps"라는 역할이 확산되고 있다(DevOps를 절묘하게 벤치마크하여서) 이 역할이 우리 조직에 왜 필요하고 무슨 문제를 해결하려는 건지가 매우 분명해야 한다고 하는데, 나도 동의한다.
1) 우선 프로세스/운영을 다루는 건 복잡하고 까다로운 문제다. 어떠한 방법론이나 특정한 역할이 이 복잡 다난한 문제를 쉽게 해결해 줄 것 같은 믿음을 절대로 가지면 안 된다.
2) 특히, 리더가 해야 할 일을 회피하거나 떠넘기는 게 아닌가 먼저 생각해봐야 한다. 비즈니스 목표를 달성하는 데 있어 조직의 협업/확장성/병목을 파악하고 해결하며, 구성원을 코칭하는 것은 리더의 역할이다. 도움이 필요하거나 상황적인 이슈가 있으면 모를까.. Scaling의 깊은 고민과 해결을 떠넘기면 안 된다.
나도 조직 내 Process People의 역할을 체감한 적도 있고, 어느 순간 사라지기도 하고, Manager들끼리 프로세스/병목의 문제를 머리 맞대고 치열하게 고민하고 풀어보기도 했었다. 정답은 없다.
분명한 건 Product를 확장하고 운영하는 데 있어 무엇이 본질적인 문제인지, 원인이 뭔지, 어떤 해결방안이 있을지 깊이 이해하고 고민해야 한다는 점이다. 그리고 해결을 위해 치열하게 시도해봐야 한다. 어떤 문제를 누군가에 의존해서 내 맘같이 깔끔하고 시원하게 해결된 적이 있던가.. 그럴싸한 프로세스부터 찾고 적당한 역할/사람부터 찾아서는 안된다(그렇지만 이것 또한 매우 어려운 일인 것도 사실이다. 특히 Product 조직의 리더십들이 이런 문제를 풀기에는 경험이 적다. 그리고 그들은 매우 바쁘다. 그래서 평소에도 계속 고민하고, 치열하게 부딪혀야 한다. (Product leadership is very hard..)
본질은 Product 조직 Scaling의 문제
결국 문제의 본질은 Scaling이다. 작은 조직, 단일팀일 때는 발생하지 않는다. Product가 커지고 조직이 확장되면서 생겨나는 문제다(기능조직으로 완전히 세분화하지 않는 이상은)
1) 통합과 연결의 문제
제품이 빠르게 성장하고 조직이 확대되면서, 여러 개의 도메인으로 스쿼드가 나눠지거나 아니면 멀티 프로덕트가 생긴다. 그리고 소위 중구난방이 된다. 성장의 대가, 불가피한 부채다(시리즈 A~C 스타트업들의 기업리뷰를 보면 체계가 없다는 답변 투성이다)
다만 이대로 계속 갈 수는 없기에, 프로세스/도구/정보통합/커뮤니케이션의 문제들을 해결해야 한다. 예를 들어, A스쿼드와 B스쿼드가 전혀 다른 방식으로 일을 하고 있다거나, 서로 협업해서 업무가 되어야 하는데 비효율이 계속 생기거나, 새로 도입한 도구가 제대로 적용이 안되어 아직도 비효율적으로 업무를 하고 있다거나, 중요한 Product 이슈/릴리즈 정보가 공유가 안된다거나 하는 등의 문제들.
Scrum에서는 대규모 조직을 위한 SAFe 같은 방법론을 제시하고 있으나, 도움이 되는 Framework일 뿐이고, 문제가 그냥 해결되지 않는다. 논리와 마케팅으로 무장해서 그럴싸해 보이는 경우가 많다는 것이다(Marty는 Top Tech 기업에서 SAFe 방법을 쓰는 경우를 본 적이 없다고 할 정도로.. 비판적이다)
2) Product Manager 업무과부하의 문제
Product Manager의 역할은 회사마다 너무 다르겠으나, 가장 핵심 역할은 "Do the right things right"이다. 우리 Product가 목표달성과 고객 문제해결을 위해 해야 할 일들을 치열하게 선정 및 우선순위화하고, 그게 제대로 실행되도록 이끄는 것이다. 이것만 잘하는 것도 너무너무 어렵고 바쁘다.
근데 뭘 더 하라고? 누군가 그랬다. Product Manager가 하는 일? 개발, 디자인 빼고 다하는 거라고. 업무 프로세스 개선? 업무도구 검토? 버그수집 및 관리? 릴리즈 리포팅? VOC 분석? 지역별 시장조사? 이런 것까지 하라니.. 나는 Product Manager 지, Peocess/People Manager가 아니란 말이다. 내 커리어에 도움도 안 되는 거 같고.
이런 건 리더가 좀 안 챙겨주는 건지. 근데 리더도 이러한 문제해결에는 직접적인 경험이 없다.
출처: 이렇게 되면 안되는데. Productled.com3) 기업내부 / 외부에 문어발처럼 확장되는 Product 운영 환경
Product에 많은 분석 도구들이 있다. Business Analyst, UX 리서치, CS, 마케팅, 세일즈 등 많은 부서들이 제각각 정량적인 데이터수집, 그리고 정성적인 고객 VOC를 수집하고 분석한다. 참여자들과 도구가 많아져 좋은 것도 있지만, 이걸 Product Insight로 정리하고 요약하려면 어떻게 해야 하나
노션에 문서와 프로젝트 관리를 더 잘해야 하는데, 이건 누가 할 수 있는 건가? 그리고 팀이 커져서 이제 Task 관리는 Jira를 사용하기로 했다. 이건 누가 도입하고 매뉴얼화하고 변화관리하는가
우리 Product는 고객용과 사업자용이 있다. 그리고 사업자들은 국내외 20개 도시에서 서비스를 사용하고 있다. Product Manager는 각 도시의 특성에 따른 VOC를 어떻게 수집하고 인사이트를 얻을 수 있을까
이렇게 복잡한 Tech Stack에서.. 고객 인사이트는 어떻게 통합되는가. 출처: productled그러면 이러한 문제들은 어떤 관점으로 접근하는 것이 바람직할까?
1) 통합과 복잡성의 문제
노련한 Group Product Manager(or Program Manager)나 Product Head를 통해 문제를 해결한다. 이들이 문제를 직접 파악하고 깊이 이해해야 한다. 그리고 이 문제해결이 매우 중요하고 해결하는데 리더십의 자원만으로 부족하다면 "Product Ops" 역할을 만들어볼 수 있겠다.
충분히 시도하지 않았거나 아직 규모가 그리 크지 않은데도 PMO 모델, SAFe, Product Ops 등 역할이나 방법론을 도입하는 것보다는, 이러한 대안들은 차근차근 고민하는 게 좋겠다.
2) Product Manager 업무과부하의 문제
Product Manager가 제품의 기회를 발견하고 고객에게 빠르게 전달할 수 있도록, 리더십이 병목의 이슈를 적극적으로 파악하고 해결해야 한다. 특히 정량적/정성적인 시장과 고객의 인사이트를 빠르게 얻게 하는 것, Product가 내부/외부에 효과적으로 전파되는 일 등은 매우 중요하다.
그 외 각종 Day-to-Day 업무가 많기 때문에, Associate Product Manager로 나누거나 Product Opration Manager를 두는 것도 나는 현실적인 안이라고 본다. 실제 Stripe나 우버에서는 Product Manager와 Product Ops Manager를 1:1로 매칭하는 모델을 시도했다고도 한다. 개인적으로는 지원팀, 전략팀 등과 같은 동떨어진 팀을 만드는 것보다는 낫다고 생각한다. 다만 쿠팡이나 토스처럼 Product Owner와 Product Manager 역할을 같이 사용하는 건 스탠더드에 맞지 않는 접근이라고 생각한다(내부적인 사정과 탄탄한 논리가 있기야 하겠지만..)
3) 문어발처럼 확장되는 운영환경
결국 Product와 내부고객 및 외부고객을 연결하는 일이다. 이 연결을 위해 필요한 프로세스, 도구, 커뮤니케이션을 다루는 것을 말한다. 이러한 업무를 위해 보통 서비스운영, 고객경험팀이 따로 존재하기도 한다.
이러한 연결의 문제해결은 기본적으로 해당팀에서 프로세스를 만들고 도구를 도입하고 커뮤니케이션을 촉진하도록 시도해야 한다(최근 몇 년간 CX분야에서 이러한 업무확장에 대한 교육과 전파가 많이 이루어지고 있는 것 같기도 하다) 그래서 서비스운영/고객경험팀에 Process를 기획하고 변화시킬 수 있는 노련한 시니어가 반드시 있어야 한다. 이런 사람들을 Product Ops Manager라고 할 수도 있겠다. 그리고 리더십의 적극적인 지원이 필요하다.
Summary & Key Takeways
ProductOps 역할은 조직마다 다르다고 한다. 결국 그 조직이 확장하는데 해결해야 할 가진 중요한 문제가 무엇이냐에 따라 역할이 정의된다는 얘기다.
그리고 아래와 같은 순서로 접근 것이 올바른 관점이라고 생각한다.
1. 아래와 같은 상황이라면 Product Ops의 역할에 관심을 가질 수 있겠다.
1) Product 확장이 빠르게 되고 있고 Product Manager가 부족한 상황
2) 도메인이나 Product가 복수로 나눠져 있거나,
3) SaaS 프로덕트를 판매하는(Product에 마케팅/세일즈/CS 기능이 매우 강하게 의존되어 있는) B2B 회사
2. 단순히 "운영 체계가 없다" "리소스가 부족하다" "프로세스가 부재하다"와 같은 추상적인 이슈가 아니라, 구체적인 문제를 정의한다.
- 프로세스/정보/도구 통합의 문제, Product Manager 과부하의 문제, 운영 환경의 광범위한 확대 등
- 그리고 각각의 문제는 분리하여 별도로 해결한다. 각 영역을 담당하는 리더를 중심으로
3. 다음의 단계로 문제를 해결한다
1) 우선은 리더십이 문제를 직접 파악하고, 그게 얼마나 중요하고 장기적인 문제인지 판단한다.
2) 그리고 문제해결을 위해 사람이 필요한 경우, 노련한 내부 선수로 먼저 시도한다.
3) 지속적으로 관리/개선되어야 할 문제인 경우, 역할을 정의한다.
4) 단 이때에도 Program Manager, Associate Product Manager, Product Opreation Lead 등 문제해결에 초점을 둔 타이틀이 좋겠다. ProductOps처럼 포괄적이고 괜히 Fancy 한 용어 말고.
Product 운영이라는 것이 워낙 맥락이 다양하여 일반화/체계화되기 힘든 것 같다. 마치 ProductOps의 정의처럼. 그럼에도 올바른 관점을 가지기 위해서 문제해결의 사례를 탐구하고 방법을 소개하는 일들은 계속되어야힌다. Product 성장을 위해 고군분투하는 모든 Product 팀의 시행착오를 줄이기 위해.
레퍼런스
