월요일 아침. 당신은 12개의 제품을 운영하는 5인 스튜디오입니다. 세 개는 언젠가 읽어야 할 충돌 알림을 띄우고 있습니다. 두 개는 주말 동안 출시된 경쟁 앱 업데이트로 인해 유지율이 떨어지고 있습니다. 하나는 금요일까지 새로고침해야 하는 스토어 목록이 있어, 그렇지 않으면 추천 슬롯에서 밀려납니다. 47개의 고객 리뷰가 기다리고 있습니다. Game 4에 대한 지출은 어쩐지 30% 증가했습니다. Burak은 로드맵 통화에 대해 묻고 있습니다. 팀원 중 한 명은 Game 7에 대해 묻고 있습니다. 당신의 한 주는 8분 후에 시작됩니다.
이것이 바로 포트폴리오 운영입니다. 아무도 이에 대한 플레이북을 작성하지 않았습니다.
대부분의 운영 조언은 잘못된 형태를 위해 작성되었습니다
운영의 정석(책, 스레드, LinkedIn 게시물)은 당신이 한 가지를 운영한다고 가정합니다. 성장 책임자를 고용하세요. 퍼널 대시보드를 설정하세요. 주간 제품 회의를 운영하세요. 북극성 지표를 선택하세요.
그 어떤 것도 포트폴리오와 접촉하면 살아남지 못합니다.
12개의 제품을 운영하는 5인 스튜디오는 작은 기업이 아닙니다. 규모가 큰 스타트업도 아닙니다. 완전히 다른 운영 형태입니다: 적은 인원, 많은 제품 수, 제품별 얕은 맥락, 제품 간 풍부한 맥락. 인원수 계산은 각 제품에 대한 성장 책임자를 고용할 수 없음을 의미합니다. 제품 수 계산은 각 제품에 대한 주간 제품 회의를 운영할 수 없음을 의미합니다. 어느 한 형태를 위해 만들어진 플레이북은 늘어나고 부서집니다.
대부분의 스튜디오는 다섯 번째 제품쯤에서 이를 발견합니다. 처음 세 개는 관리할 만했습니다. 네 번째는 어려웠습니다. 다섯 번째는 분명히 했습니다: 여기까지 오게 한 프레임워크는 당신을 열 개까지 데려갈 수 없습니다.
이 형태는 아직 정해진 이름이 없습니다. 일부 운영자들은 이를 포트폴리오라고 부릅니다. 일부는 지주회사라고 부릅니다. 대부분은 그저 "우리는 여러 가지를 운영한다"고 부릅니다. 무엇이라고 부르든, 운영 규율은 그 자체의 것입니다(포트폴리오 운영), 그리고 대부분은 글을 쓸 시간이 없는 운영자들의 머릿속에 존재하기 때문에 작성되지 않았습니다.
이 게시물은 이를 기록하기 시작하려는 시도입니다. 구체적으로: 단일 제품 플레이북이 실패하는 다섯 가지 지점 다중 제품 스튜디오, 그리고 대신 무엇을 해야 하는지.
다섯 가지 실패 모드
1. 수동 스캔은 월요일 아침 시간을 잡아먹습니다
첫 번째 실패는 가장 쉽게 발견되지만 가장 고치기 어렵습니다. 매일 아침, 팀원 중 누군가는 모든 제품을 스캔합니다. 충돌 대시보드. 앱 스토어 리뷰. 지출 보고서. 참여 패널. 고객 지원 받은 편지함.
제품 하나일 때는 창업자의 업무이며 30분이 걸립니다. 제품 다섯 개일 때는 여전히 창업자의 업무이며 세 시간이 걸립니다. 제품 열두 개일 때는 더 이상 이 작업이 이루어지지 않으며, 스튜디오는 고객 티켓을 통해 실제 문제들을 알게 됩니다.
수동 포트폴리오 스캔은 확장되지 않습니다. 운영자가 서툴러서가 아니라, 작업이 본질적으로 제품 수에 비례하고 운영자는 한 명이기 때문입니다. 대시보드로 시간을 벌 수는 있지만, 열두 개의 제품 알림 중 어떤 것이 실제로 중요한지 알아야 하는 상황에서 대시보드만으로는 벗어날 수 없습니다.
필요한 작업은 신호 분류이며, 운영자가 대시보드를 열기 전이 아니라 그 전에 이루어져야 합니다.
2. 제품 간 교훈이 사라집니다
여러 제품을 운영한 지 석 달이 지나면, 똑같은 고통스러운 대화를 두 번 하게 될 것입니다. 팀원 중 누군가가 Game 4에서 문제를 제기하고, 오래 근무한 팀원이 "이거 App 2에서 지난 3월에 해결했어요"라고 말합니다. 그러면 모두가 실제 해결책이 무엇이었는지 아무도 기억하지 못한다는 것을 깨닫습니다.
단일 제품 조직은 위키와 런북으로 이를 해결합니다. 포트폴리오 스튜디오는 그럴 수 없습니다. 관련 교훈이 다른 제품의 맥락 속에 묻혀 있기 때문입니다. Game 4의 런북에는 그 내용이 없습니다. App 2의 런북에는 있지만, App 2 리더만 그 런북을 읽습니다. 제품 간의 기억은 누구의 머리에도 확실하게 남아있지 않습니다.
해결책은 더 큰 위키가 아닙니다. 해결책은 제도적 기억 입니다. 제품별로 구조화되어 있지만 제품 간에 읽을 수 있어야 합니다. Game 4의 문제와 App 2의 해결책은 기본적으로 누구도 재포맷할 필요 없이 같은 형식으로 같은 장소에 있어야 합니다.
3. 의사 결정 시점이 지연됩니다
모든 다중 제품 스튜디오에는 똑같은 백로그가 있습니다. 지난 화요일에 했어야 할 결정들이 아직 이루어지지 않은 것입니다. 몇 주 전에 조정했어야 할 Game 4의 입찰 하한선. App 7의 스토어 목록 새로 고침. 아무도 포크하는 것을 기억하지 못한 Game 11의 유지율 테스트.
스튜디오에 판단력이 부족한 것이 아닙니다. 결정할 시점이 부족한 것입니다. 맥락이 준비되어 있다면 10분이면 될 통화가 두 시간의 준비 시간을 필요로 하므로 미뤄집니다. 충분히 미뤄지면, 아예 이루어지지 않게 됩니다.
필요한 것은 의사 결정 주기입니다. 각 제품에 대해 특정 결정이 예측 가능한 리듬으로, 맥락이 이미 준비된 상태에서 이루어지도록 보장하는 것입니다. 회의 일정이 아니라, 그 시점이 준비된 상태로 도래할 것이라는 계약입니다.
4. 교차 기능적 맥락이 파편화됩니다
작은 스튜디오에서 "교차 기능적"이라는 것은 다른 팀을 의미하지 않습니다. 세 가지 역할을 수행하는 동일한 세 명의 사람을 의미합니다. 광고를 운영하는 사람이 스토어 목록도 운영하고 라이브 운영도 합니다. 그들은 어긋나지 않습니다. 그들은 자기 자신과 위상이 어긋나 있습니다.
문제는 운영 표면입니다. 광고 지출은 한 도구에 있습니다. 스토어 목록은 다른 도구에 있습니다. 라이브 운영 문서는 세 번째 도구에 있습니다. 각각은 같은 날 같은 제품에 대해 다른 이야기를 합니다. 운영자만이 그것들이 같은 제품이라는 것을 인지하는 유일한 존재입니다.
교차 기능 컨텍스트 포트폴리오 스튜디오에서는 더 나은 회의에 관한 것이 아닙니다. 동일한 사람이 세 가지 다른 역할에서 읽을 수 있는 단일 제품별 기록에 관한 것입니다. "오늘 Game 4에 무슨 일이 일어나고 있나요?"라는 질문이 있을 때, 조립해야 할 세 가지 답변이 아니라 읽을 단 하나의 답변이 있어야 합니다.
5. 성장 루프가 조용히 쇠퇴합니다
포트폴리오 운영에서 가장 값비싼 실패는 아무도 알아차리지 못하는 것입니다. 성장 루프가 출시되어 2주 동안 작동하다가 표류합니다. 첫 번째 코호트 이후에 포크되었어야 할 유지율 테스트는 결코 포크되지 않습니다. 3월에 조정된 수익화 곡선은 6월까지 기본값으로 돌아갑니다. 아무도 잘못한 것이 없습니다. 심지어 아무도 잘못된 일을 하고 있지 않습니다. 루프가 유지되지 않을 뿐입니다.
단일 제품 운영에서는 창업자가 기억합니다. 포트폴리오 운영에서는 창업자가 기억해야 할 다른 열한 가지가 있습니다.
스스로 작동하는 성장 루프 스스로 작동하는 성장 루프 는 시스템이 인지하고 유지하는 루프입니다. 루프가 약화될 때, 가정이 변경될 때, 분기해야 할 때 이를 알려줍니다. 운영자는 여전히 결정합니다. 시스템은 결정의 순간을 놓치지 않도록 합니다.
실제로 작동하는 것
다섯 가지 실패 모드에 대한 해결책은 다섯 가지 개별 도구가 아닙니다. 이는 다른 표면에 적용된 동일한 근본적인 변화입니다. 12개 이상의 제품을 운영하며 살아남은 대부분의 다중 제품 스튜디오는 보통 고통스럽게 이 중 일부를 스스로 알아냈습니다. 여기 더 짧은 버전이 있습니다.
1. 단위는 회사가 아닌 제품입니다.
대부분의 운영 도구는 회사 작업 공간을 기본으로 합니다: 하나의 지식 기반, 하나의 채널, 하나의 대시보드. 다중 제품 스튜디오에는 이것이 잘못된 기본값입니다. 기억의 표준 단위는 제품이어야 합니다. 게임 4는 자체 결정 기록, 자체 신호 로그, 자체 컨텍스트 저장소를 가집니다. 포트폴리오는 필요할 때 이들을 읽지만, 단위는 제품입니다.
이것이 바로 제품별 메모리. 당연하게 들리지만, 거의 모든 상용 도구는 이를 기본으로 하지 않습니다.
2. 결정은 문서가 아닌 일급 객체입니다.
대부분의 도구는 무엇이 만들어졌는지 기록합니다. 필요한 것은 왜 만들어졌는지, 어떤 신호가 호출을 촉발했는지, 무엇이 고려되고 거부되었는지도 포함됩니다. 결정 기록 은 문서가 아닙니다. 운영자가 잊어버려도 살아남는 구조화된 아티팩트입니다.
테스트: 지금부터 3개월 후, 새로운 팀원이 게임 4의 기록을 읽고 당시 운영자의 추론을 재구성할 수 있을까요? 그렇다면 기록은 제 역할을 하는 것입니다. 그렇지 않다면, 스튜디오는 같은 교훈을 두 번 배우게 될 것입니다.
3. 역량보다 주기.
채용으로 포트폴리오 운영 문제를 해결할 수는 없습니다. 필요한 결정이 스튜디오가 유지할 수 있는 리듬에 맞춰 이루어지도록 함으로써 해결할 수 있습니다. 결정 주기 가 계약입니다. 스튜디오의 임무는 이를 지키는 것입니다.
4. 일반 비서가 아닌 전문 에이전트.
AI 도구가 등장했을 때, 모든 것에 대해 하나의 일반 비서에게 묻고 싶은 유혹이 있었습니다. 실제 스튜디오에서는 월요일 아침을 넘기지 못했습니다. 작동하는 것은 전문 에이전트입니다: 운영 기능당 하나씩, 범위가 지정된 메모리와 단일 작업을 가집니다. 충돌 보고서를 모니터링하는 에이전트는 카피를 작성하려고 하지 않습니다. 스토어 목록을 모니터링하는 에이전트는 수익화 변경을 제안하지 않습니다.
범위는 신뢰 메커니즘입니다. 하나의 기능에 대한 완전한 메모리를 가진 전문 에이전트는 감사, 보정 및 되돌리기가 가능합니다. 모든 것을 가진 일반 에이전트는 불가능합니다.
5. 포트폴리오 전반에 걸친 하나의 운영 마인드.
위의 다섯 가지는 모두 한곳에 있어야만 작동합니다. 그렇지 않으면 12개의 대시보드를 12개의 더 나은 대시보드로 교체한 것에 불과합니다. 이 작업의 핵심은 하나의 운영 마인드: 모든 제품을 읽는 동일한 두뇌, 모든 라인에서 작동하는 동일한 에이전트, 더 이상 운영자가 유일한 통합 계층이 아닌 것입니다.
Qualia에 대한 참고 사항
이것이 우리가 Qualia를 구축하는 데 사용하는 플레이북입니다. 이 제품은 AI COO 포트폴리오 운영자를 위한 것입니다: 3-20개의 라이브 게임 또는 앱을 운영하는 2-10명 규모의 소규모 스튜디오. 아키텍처는 제품별 메모리, 전문 에이전트, 그리고 공유 포트폴리오 두뇌로 구성됩니다. 기본값은 human-in-the-loop입니다. 우리가 스스로를 평가하는 지표는 운영자 지루함입니다: Qualia 화면을 읽는 창업자가 하품을 한다면, 그 화면은 잘못된 것입니다.
우리는 초기 단계입니다. 고객은 두 명입니다. 설정 시간은 30분입니다. 만약 다중 제품 스튜디오를 운영하고 있고 위의 실패 모드 중 어느 하나라도 당신의 한 주를 잡아먹고 있다면, 우리는 대화하고 싶습니다. 데모 예약.
이것이 쓰여지지 않은 이유
대부분의 플레이북은 한 가지를 확장한다고 가정합니다. 포트폴리오 운영자는 다양성에 맞서 확장합니다: 더 많은 제품, 동일한 인력, 제품별 Slack 없음. 작업이 다릅니다. 따라서 도구도 달라야 합니다. 그리고 플레이북도 마찬가지입니다.
우리가 놓친 버전들을 찾으셨다면, 알려주세요.
작성자 Doğan Turan, Qualia 공동 창립자 ·