El manual no escrito para gestionar 12 apps con 5 personas

Lunes por la mañana. Eres un estudio de cinco personas con doce productos activos. Tres están lanzando alertas de errores que tendrás que revisar en algún momento. Dos están perdiendo retención frente a la actualización de una app de la competencia lanzada el fin de semana. Una tiene una ficha de tienda que necesita actualizarse antes del viernes o perderá el espacio destacado. Hay 47 reseñas de clientes pendientes. El gasto en Game 4 ha subido de alguna manera un 30%. Burak pregunta por una llamada sobre el roadmap. Alguien del equipo pregunta por Game 7. Tu semana empieza en ocho minutos.

Esto es operaciones de cartera. Nadie ha escrito el manual para esto.

La mayoría de los consejos de operaciones se escribieron para la estructura equivocada

El canon de las operaciones (los libros, los hilos, las publicaciones en LinkedIn) asume que diriges una sola cosa. Contrata a un head of growth. Configura tu panel de embudo. Dirige tu comité semanal de producto. Elige una métrica North Star.

Nada de eso sobrevive al contacto con un portafolio.

Un estudio de cinco personas que gestiona doce productos no es una gran empresa en miniatura. No es una startup a escala. Es una estructura operativa totalmente distinta: plantilla reducida, alto número de productos, contexto individual superficial y un rico contexto transversal. Las matemáticas de la plantilla impiden contratar a un head of growth para cada producto. Las matemáticas del catálogo de productos impiden organizar un comité semanal de producto para cada uno. Los manuales diseñados para cualquiera de esas dos estructuras se tensan y se rompen.

La mayoría de los estudios descubren esto hacia su quinto producto. Los tres primeros parecían manejables. El cuarto fue difícil. El quinto lo dejó claro: el marco que te trajo hasta aquí no te llevará a diez.

Este modelo aún no tiene un nombre definitivo. Algunos operadores lo llaman cartera. Otros lo llaman holdco. La mayoría simplemente dice "llevamos un montón de cosas". Lo llames como lo llames, la disciplina operativa es un mundo aparte (operaciones de cartera), y la mayor parte no está escrita porque reside en la cabeza de operadores que no tienen tiempo para escribir.

Este artículo es un intento de empezar a plasmarlo por escrito. En concreto: los cinco puntos en los que los manuales para un único producto fallan a los estudios multiproducto, y qué hacer en su lugar.

Los cinco modos de fallo

1. La revisión manual devora la mañana del lunes

El primer fallo es el más fácil de detectar y el más difícil de solucionar. Cada mañana, alguien del equipo revisa cada producto. Paneles de caídas. Reseñas en las tiendas de apps. Informes de gasto. Paneles de engagement. Bandeja de entrada de soporte al cliente.

En el producto uno, es trabajo del fundador y lleva treinta minutos. En el producto cinco, sigue siendo trabajo del fundador y lleva tres horas. En el producto doce, ya no se hace, y el estudio se entera de los incendios reales a través de los tickets de los clientes.

La revisión manual de un portafolio no escala. No porque los operadores lo hagan mal, sino porque el trabajo es intrínsecamente lineal respecto al número de productos y el operador es una sola persona. Puedes ganar algo de tiempo con paneles de control, pero ningún panel te librará de tener que saber cuál de las alertas de doce productos importa de verdad.

El trabajo que debe hacerse es el triaje de señales, y tiene que ocurrir antes de que el operador abra el panel de control, no después.

2. Los aprendizajes se pierden entre productos

A los tres meses de gestionar múltiples productos, tendrás la misma dolorosa conversación dos veces: alguien del equipo plantea un problema en Game 4 y un compañero con más antigüedad dice "esto ya lo solucionamos en App 2 el pasado marzo". Entonces todos se dan cuenta de que nadie recuerda cuál fue realmente la solución.

Las organizaciones con un solo producto resuelven esto con wikis y runbooks. Los estudios de cartera no pueden, porque el aprendizaje relevante está enterrado en el contexto de un producto distinto. El runbook de Game 4 no lo contiene. El runbook de App 2 sí, pero solo el responsable de App 2 lo lee. La memoria cruzada entre productos no vive de forma fiable en la cabeza de nadie.

La solución no es una wiki más grande. La solución es memoria institucional estructurada por producto pero legible entre productos. El problema de Game 4 y la solución de App 2 deben tener la misma forma, en el mismo lugar, por defecto, sin que nadie tenga que reformatearlos.

3. Los momentos de decisión se escapan

Todo estudio multiproducto tiene el mismo backlog: decisiones que debieron tomarse el martes pasado y no se tomaron. El precio mínimo de puja en Game 4 que debió ajustarse hace semanas. La actualización de la ficha de tienda en App 7. La prueba de retención en Game 11 de la que nadie se acordó de bifurcar.

Al estudio no le falta criterio. Le faltan momentos. La llamada que tomaría diez minutos si el contexto estuviera listo requiere dos horas de preparación, así que se pospone. Si se pospone suficientes veces, deja de ocurrir.

Lo que se necesita es un cadencia de decisiones: una garantía de que, para cada producto, ciertas decisiones ocurran con un ritmo predecible, con el contexto ya recopilado. No un calendario de reuniones, sino el contrato de que el momento llegará preparado.

4. El contexto multifuncional se fragmenta

En un estudio pequeño, "multifuncional" no significa equipos diferentes. Significa que las mismas tres personas desempeñan tres roles distintos. Quien gestiona los anuncios también gestiona la ficha de tienda y las live-ops. No están desalineados; están desfasados consigo mismos.

El problema es la superficie operativa. El gasto publicitario reside en una herramienta. La ficha de tienda, en otra. El documento de live-ops, en una tercera. Cada uno cuenta una historia distinta sobre el mismo producto en el mismo día. El operador es lo único consciente de que se trata del mismo producto.

Contexto interfuncional en un estudio de cartera no consiste en tener mejores reuniones. Se trata de un único registro por producto que la misma persona puede leer desde tres roles distintos. Cuando la pregunta es "¿qué pasa hoy con Game 4?", debería haber una sola respuesta que leer, no tres que ensamblar.

5. Los bucles de crecimiento decaen en silencio

El fallo más costoso en las operaciones de cartera es el que nadie nota. Se lanza un growth loop, funciona durante dos semanas y luego se desvía. La prueba de retención que debía bifurcarse tras la primera cohorte nunca se bifurca. La curva de monetización ajustada en marzo vuelve a sus valores predeterminados en junio. Nadie se equivoca; nadie está haciendo nada mal. Simplemente no se está manteniendo el bucle.

En las operaciones monoproducto, el fundador se acuerda. En las de cartera, el fundador tiene otras once cosas que recordar.

Una bucle de crecimiento autónomo es aquel del que el sistema mantiene la trazabilidad: detecta cuándo el bucle decae, cuándo sus supuestos han cambiado, cuándo necesita bifurcarse. El operador sigue decidiendo. El sistema se asegura de que el momento de decidir no se escape.

Qué funciona realmente

Las soluciones para los cinco modos de fallo no son cinco herramientas independientes. Son el mismo cambio de fondo, aplicado a distintas superficies. La mayoría de los estudios multiproducto que logran sobrevivir más allá de los doce productos han descubierto alguna versión de esto por su cuenta, normalmente a base de golpes. Esta es la versión resumida.

1. La unidad es el producto, no la empresa.

La mayoría de las herramientas operativas se configuran por defecto para el espacio de trabajo de una empresa: una base de conocimiento, un canal, un panel de control. Para los estudios multiproducto este es el valor por defecto erróneo. La unidad canónica de memoria debe ser el producto. Game 4 tiene su propio registro de decisiones, su propio registro de señales y su propio almacén de contexto. La cartera los consulta de forma transversal cuando lo necesita, pero la unidad es el producto.

Esto es la memoria por producto. Parece obvio; casi ninguna herramienta prediseñada lo hace por defecto.

2. Las decisiones son entidades de primer nivel, no documentos.

La mayoría de las herramientas registran lo que se hizo. Lo que se necesita también es por qué se hizo, qué señal motivó la decisión y qué se consideró y descartó. Un registro de decisiones no es un documento. Es un artefacto estructurado que sobrevive al olvido del operador.

La prueba: de aquí a tres meses, ¿puede un nuevo compañero leer el registro de Game 4 y reconstruir el razonamiento del operador en el momento de tomar la decisión? Si es así, el registro cumple su cometido. Si no, el estudio volverá a aprender la misma lección.

3. Cadencia sobre capacidad.

No resolverás las operaciones del portfolio contratando. Lo resolverás asegurándote de que las decisiones que deben tomarse se tomen al ritmo que el estudio pueda sostener. Cadencia de decisión es el contrato. El trabajo del estudio es cumplirlo.

4. Agentes especialistas, no asistentes generales.

La tentación, cuando aparecieron las herramientas de IA, fue preguntarle a un asistente general sobre todo. Eso no sobrevivió a un lunes por la mañana en un estudio real. Lo que funciona son agentes especialistas: uno por función operativa, con memoria acotada y una única tarea. El que supervisa los informes de fallos no intenta redactar copy. El que monitoriza las fichas de tienda no propone cambios de monetización.

El alcance es el mecanismo de confianza. Un agente especialista con memoria completa de una función se puede auditar, calibrar y revertir. Un agente general con todo no puede.

5. Una sola mente operativa en todo el portfolio.

Los cinco puntos anteriores solo funcionan si residen en el mismo lugar. De lo contrario, solo habrás sustituido doce paneles de control por doce paneles mejores. El objetivo del trabajo es una sola mente operativa: el mismo cerebro leyendo cada producto, los mismos agentes actuando en cada línea, y el operador dejando de ser la única capa de integración.

Una nota sobre Qualia

Este es el playbook con el que estamos construyendo Qualia. El producto es el AI COO para operadores de portfolio: pequeños estudios de 2 a 10 personas que gestionan de 3 a 20 juegos o aplicaciones activos. La arquitectura es memoria por producto más agentes especialistas más un cerebro de portfolio compartido. Por defecto es human-in-the-loop. La métrica con la que nos evaluamos es el aburrimiento del operador: si un fundador bosteza al leer una pantalla de Qualia, la pantalla está mal.

Estamos en una fase inicial. Dos clientes. Configuración en 30 minutos. Si diriges un estudio multiproducto y cualquiera de los modos de fallo anteriores te está consumiendo la semana, nos gustaría hablar. Reservar una demo.

Por qué esto no está escrito

La mayoría de los playbooks asumen que estás escalando una sola cosa. Los operadores de portfolios escalan frente a la multiplicidad: más productos, el mismo equipo, sin margen por producto. El trabajo es distinto. Por tanto, las herramientas también deben serlo. Y el playbook también.

Si has encontrado variantes de esto que hayamos pasado por alto, queremos escucharlas.