9.0 스케일 (Scale)의 의미
스케일 (Scale) 단계는 B2B 엔터프라이즈 기업이 작동하는 엔진(engine) — 즉, 반복 가능한 쐐기 (wedge), 예측 가능한 수요 시스템 (demand system), 지속적으로 계약을 성사시키는 영업 방식 (sales motion), 그리고 영웅적인 개입 없이도 유지되고 확장되는 고객 기반 — 을 구축했을 때 시작되며, 회사가 다중 제품 깊이 (multi-product depth)를 가진 카테고리 리더가 되거나, 더 이상의 복리 성장을 방해하는 구조적 한계 (structural ceiling)에 부딪혔을 때 종료됩니다. 대부분의 기업은 연간 반복 매출 (ARR) 2,000만 달러에서 3,000만 달러 사이에서 이 단계에 진입합니다. 대부분은 1억 달러에서 2억 달러 사이에서 이 단계를 벗어납니다. 이 탈출(exit)은 매출 숫자로 정의되지 않습니다. 회사가 자신의 엔진을 향후 10년 동안 회사를 이끌어갈 수 있는 시스템으로 복리 성장시켰는지, 아니면 단순히 기존 엔진의 한계가 보일 때까지 규모를 키웠는지에 따라 정의됩니다.
이 단계는 CPMO 역할이 가장 어려운 단계입니다. 그 이유는 구조적입니다. 창업 (Founding), 쐐기 (Wedge), 엔진 (Engine) 단계에서 CPMO는 주로 그린필드 (greenfield) — 즉, 이전에 존재하지 않았던 것들을 구축하는 것 — 에서 활동합니다. 스케일 (Scale) 단계에서 CPMO는 이미 설치된 지형 (installed terrain) — 즉, 엔진 (Engine) 단계에서 구축된 시스템이 이제 생산 단계에 있고, 팀은 커졌으며, 고객 기반은 상당해졌고, 모든 변화가 이미 존재하는 것들의 관성 (inertia)을 고려해야 하는 환경 — 에서 활동합니다. 업무는 건설 (construction)에서 진화 (evolution)로 전환되며, 진화는 건설보다 더 어렵습니다. 변화의 비용은 더 높고 이점은 즉각적으로 보이지 않기 때문입니다.
또한 이 단계는 대부분의 CPMO가 실패하는 단계이기도 합니다. 실패는 좀처럼 무능함의 형태로 나타나지 않습니다. 그것은 이미 다음 단계로 넘어간 기업에서 이전 단계에 적합한 일을 하고 있는 CPMO의 모습으로 나타납니다. 수요 시스템 (demand system)을 구축했던 엔진 (Engine) 단계의 CPMO는, 업무가 카테고리 구축 (category construction) 및 포트폴리오 전략 (portfolio strategy)으로 전환되었음에도 불구하고 스케일 (Scale) 단계에서 계속해서 수요 시스템 최적화에만 집중하게 됩니다.

Engine 단계에서 Shape 단계를 굳건히 지켜냈던 제품 중심의 CPMO (Chief Product Management Officer)는, 업무의 중심이 플랫폼 아키텍처 (platform architecture)와 생태계 포지셔닝 (ecosystem positioning)으로 전환된 Scale 단계에서도 여전히 개별 로드맵 호출 (roadmap calls)에만 집중합니다. 이러한 실패는 실시간으로는 보이지 않지만 사후에는 명백히 드러나며, 이는 경영진의 실패 모드 (failure mode)가 가질 수 있는 가장 위험한 속성들의 조합입니다.

대부분의 CPMO가 왜 이 단계에서 실패하는지를 다루는 이 장의 9.6절은, 현재 CPMO 직무를 수행 중인 이들을 위한 플레이북 (playbook)에서 가장 중요한 섹션입니다. 그 앞의 다섯 섹션은 이러한 실패가 왜 발생하는지 읽어낼 수 있도록 맥락을 설정합니다.

9.1 Scale 단계에서 CPMO의 역할
Scale 단계에서의 역할은 Engine을 향후 10년 동안 회사를 이끌어갈 수 있는 시스템으로 복리 증식 (compound)시키는 것입니다.
이 표현 방식은 매우 중요합니다. Engine 단계는 엔진을 구축 (build)했습니다. Scale 단계는 이를 복리 증식 (compound)시킵니다. 복리 증식은 구축과는 다른 종류의 작업입니다. 구축에는 엔지니어링 본능 (engineering instinct), 고객 친밀도 (customer intimacy), 그리고 불완전한 것을 출시할 용기가 필요합니다. 반면 복리 증식에는 아키텍처적 판단력 (architectural judgment), 전략적 인내 (strategic patience), 그리고 분기 단위가 아닌 수년에 걸쳐 보상을 가져다줄 대상에 투자할 용기가 필요합니다. 이전 단계에서 엔진을 구축했던 CPMO가 이번 단계에서 이를 복리 증식시키기에 항상 적합한 인물인 것은 아니며, 동일한 경영진이 이러한 전환을 해낼 수 있는지 여부는 CEO와 이사회가 직면하는 가장 중대한 인사 결정 중 하나입니다.

구체적으로, Scale 단계에서의 CPMO 기능은 일곱 가지 일을 병렬로 수행합니다. 각 작업은 Engine 단계의 전임 작업들보다 더 아키텍처적입니다.
첫 번째는 카테고리 구축 (category construction)입니다. Engine 단계에서 회사는 기존 경쟁자들에 맞서 기존 카테고리에 제품을 판매했습니다. Scale 단계에서 회사는 하나의 카테고리를 정의할 수 있는 규모 (volume), 레퍼런스 기반 (reference base), 그리고 애널리스트로서의 입지 (analyst standing)를 갖추게 됩니다. 즉, 문제 영역 (problem space)을 다르게 명명하고, 구매자가 사용할 평가 기준을 설정하며, 스스로가 명명한 카테고리의 자연스러운 리더로 포지셔닝하는 것입니다.

이 작업은 수년에 걸쳐 진행되며, 매우 공개적이고, 한 번 실행되면 대체로 되돌릴 수 없습니다. 스케일 (Scale) 단계에서 카테고리를 성공적으로 구축한 기업들 — 2000년대 초반 CRM을 구축한 Salesforce, 2010년대 후반 데이터 클라우드를 구축한 Snowflake, 지난 20년 동안 인바운드 마케팅 (inbound marketing)을 구축한 HubSpot — 은 회사가 존재하는 내내 복리로 쌓이는 해자 (moats)를 만들어냅니다. 카테고리 구축에 실패한 기업들은 타인의 카테고리 내에서 하나의 기능 (features)으로 남게 되며, 더 저렴하거나 더 빠른 대안들과 구별되지 않게 됩니다.

두 번째는 포트폴리오 아키텍처 (portfolio architecture)입니다. 엔진 (Engine) 단계에서 회사는 하나의 제품을 가졌으며, 아마도 에디션 (editions)이나 모듈 (modules) 정도가 있었을 것입니다. 스케일 (Scale) 단계에서는 멀티 제품 전략 (multi-product strategy) 문제가 실질적으로 부상합니다. 회사는 내부 개발, 인수, 또는 파트너십을 통해 인접 제품으로 확장해야 할까요? 제품을 개별적으로 판매해야 할까요, 번들 (bundled)로 묶어야 할까요, 아니면 플랫폼화 (platformed)해야 할까요? 관리해야 할 제품이 하나 이상일 때 가격 책정 (pricing), 패키징 (packaging), 포지셔닝 (positioning)은 어떻게 조직되어야 할까요? 이러한 결정들은 CPMO 레벨의 결정입니다. 제품 부사장 (VP of Product)이 혼자 내리기에는 너무 전략적이고, 최고 영업 책임자 (CRO)가 주도하기에는 너무 제품 중심적이며, 최고 기술 책임자 (CTO)가 소유하기에는 너무 상업적입니다. CPMO는 이러한 결정들이 닿는 모든 영역을 아우르는 권한을 가진 임원이자, 그 해답들을 통합하는 루프 (loop)를 가진 임원입니다.

세 번째는 운영 체제 (operating system)의 제도화입니다. 엔진 (Engine) 단계에서 유기적으로 나타났던 리듬 (cadences), 의사 결정권 (decision rights), 검토 메커니즘 (review mechanisms)은 스케일 (Scale) 단계에서 더 공식적이고, 더 문서화되며, 더 지속 가능한 경영 운영 체제로 명문화됩니다. 공식화의 이유는 관료적인 본능이 아니라 운영상의 필요성 때문입니다. 70명 규모의 스케일에서는 CPMO가 개인적인 관계와 인접 관리를 통해 시스템을 운영할 수 있습니다. 300명 규모의 스케일에서는 시스템이 문서화된 프로토콜 (protocols), 명시된 의사 결정권, 그리고 명확한 검토 메커니즘을 통해 작동해야 합니다. 왜냐하면 CPMO는 더 이상 실무를 수행하는 모든 사람과 한두 단계의 거리 안에 있지 않으며, 통합은 개인적인 근접성만으로는 운영될 수 없기 때문입니다.

네 번째는 복리 효과를 내는 표면(compounding surfaces)에 대한 브랜드 및 카테고리 투자입니다. Engine 단계에서 브랜드는 업무의 결과로 나타나는 하류(downstream)의 결과물이었습니다. 하지만 Scale 단계에서는 브랜드에 직접적으로 투자해야 합니다. 즉, 카테고리 리더십을 확립하는 경영진의 관점(executive points of view), Magic Quadrant(매직 쿼드런트) 위치를 결정짓는 애널리스트 관계, 수년에 걸쳐 복리로 쌓이는 공개적 산출물(도서, 컨퍼런스, 오픈 소스 출시, 연구 보고서), 그리고 카테고리를 정의하는 내러티브(narratives)의 의도적인 구축을 통해 투자해야 합니다. 이러한 투자는 대부분의 Scale 단계 기업에서 가장 중요함에도 불구하고 자금이 부족한 항목입니다. 왜냐하면 그 수익은 단기적으로는 보이지 않지만, 장기적으로는 압도적이기 때문입니다. Scale 단계에서 이 계층에 대한 투자를 소홀히 하는 CPMO는 운영적으로는 건강하지만 구조적으로는 취약한 회사를 만들게 됩니다.

다섯 번째는 글로벌 확장(international expansion)입니다. Scale 단계에 있는 대부분의 B2B 엔터프라이즈 기업은 자국 외 시장 매출에 대해 처음으로 본격적인 약속을 하게 됩니다. 이 작업은 단순한 마케팅 번역 작업 그 이상입니다. 여기에는 지역별 ICP(Ideal Customer Profile, 이상적 고객 프로필)의 차이, 규제 차이, 파트너 채널의 차이, 가격 현지화, 대규모 언어 및 콘텐츠 제작, 그리고 글로벌 일관성을 해치지 않으면서 조직 구조가 어떻게 지역적 책임(regional accountability)을 수용할 것인가에 대한 문제가 포함됩니다. 이 확장의 제품 및 마케팅 구성 요소에 대해서는 CPMO가 책임을 지며, 영업 구성 요소에 대해서는 CRO가 책임을 집니다. 이 두 역할 사이의 경계 관리(boundary management)는 이 단계에서 반복적으로 발생하는 마찰의 원인이 됩니다.

여섯 번째는 플랫폼 및 생태계 역학(platform and ecosystem dynamics)의 의도적인 관리입니다. Scale 단계에서 회사의 제품은 점점 더 플랫폼이 되어갑니다. 즉, 고객에 의해 사용되고, 파트너에 의해 통합되며, 개발자에 의해 확장되고, 보완적인 제품 및 서비스의 생태계에 의해 둘러싸이게 됩니다. 생태계의 건전성은 CPMO의 관심사입니다. 왜냐하면 생태계가 제품의 중력(gravitational pull), 경쟁적 해자(competitive moat), 그리고 카테고리 내 위치의 장기적인 방어력을 형성하기 때문입니다.

API 성숙도 (API maturity), 파트너 프로그램 (partner programs), 개발자 경험 (developer experience), 그리고 마켓플레이스 경제 (marketplace economics)를 통해 생태계 건강성에 의도적으로 투자하는 기업들은 순수한 제품 투자만으로는 복제할 수 없는 해자 (moats)를 만들어냅니다.

일곱 번째는 가장 조용하지만 중대한 영향을 미치는 요소입니다. 바로 회사의 제품 및 마케팅 역량 (product and marketing capability) 자체를 전략적 자산으로 구축하는 것입니다. 스케일 (Scale) 단계에서 CPMO (Chief Product and Marketing Officer) 기능은 그 자체로 하나의 제도적 역량 (institutional capability)입니다. 해당 기능의 프로세스, 인재 밀도 (talent density), 그리고 복리로 쌓이는 학습 (compounding learning)은 그 어떤 개별 제품 기능보다도 복제하기 어려운 경쟁 우위가 됩니다. 의도적인 채용, 내부 개발, 인재 순환 (talent rotations), 그리고 제도적 지식 (institutional knowledge)의 구축을 통해 이 역량에 투자하는 기업들은, 운영 지표 (operating metrics) 상으로는 나타나지만 그 근원을 추적하기는 매우 어려운 방식으로 동종 업계 기업들을 능가하는 CPMO 기능을 만들어냅니다.