Un despliegue de 90 días para un equipo de medios AI-native es una etapa del ciclo de vida de la campaña rediseñada de principio a fin, no cinco etapas empezadas. Los días 1–30 arreglan la restricción y hacen un brief legible por máquina; los días 31–60 ejecutan esa etapa con el modelo produciendo la primera pasada y construyen el estándar de revisión; los días 61–90 miden y deciden, con evidencia, si ampliar.
He visto equipos intentar volverse AI-native en un trimestre comprando herramientas y dando talleres, y he visto equipos hacerlo reconstruyendo en silencio un flujo de trabajo y dejando que el resultado argumentara por el siguiente. El segundo grupo es más pequeño y llega más lejos. Esta es la forma de esos 90 días, escrita como yo la secuenciaría para un equipo real con una carga de cliente real.
Por qué 90 días y una etapa
El calendario no es arbitrario y el alcance no es tímido. Es la unidad más pequeña que puede producir evidencia fiable.
Noventa días son suficientes para ejecutar una etapa durante varios ciclos reales —varios informes semanales, varias campañas, varios briefs— así que el resultado no es una demo en una buena semana. Es lo bastante corto para quedarse en proyecto en vez de programa de transformación, lo que importa porque los programas de transformación pierden su financiación antes de producir algo.
Una etapa es la unidad porque el problema del desfile castiga el rediseño parcial. Arregla una etapa y deja a sus vecinas, y la ganancia se filtra por el lado. Pero rediseñar una etapa del todo prueba el método y te da el caso interno para la siguiente, que vale más que cinco pilotos a medias.
Días 1–30: elige la restricción, arregla el brief
El primer mes es diagnóstico y diseño, no herramientas.
Elige la etapa que la campaña sigue esperando al final —normalmente reporting, research o el brief. Luego escribe cómo es «bueno» para esa etapa y haz el input legible por máquina. Si es el brief, eso significa la dirección, la audiencia, las reglas de marca y la métrica de éxito en una forma que tanto una persona como un flujo de trabajo puedan usar. Si es el reporting, significa las fuentes de datos, la unión y el umbral de anomalía definidos de antemano.
La salida del mes uno no es un sistema en marcha. Es un diseño de una página: la etapa, el dueño, el input legible por máquina, el estándar y la medida que usarás para juzgar el éxito. Si no puedes escribir eso en una página, la etapa es demasiado grande —divídela.
Días 31–60: ejecútala y construye el estándar
El segundo mes es donde el flujo de trabajo realmente corre, y donde el estándar de revisión se construye a las duras.
Ejecuta la etapa con el modelo produciendo la primera pasada: genera la narrativa del informe, la síntesis de research o las opciones de plan, y una persona revisa contra el estándar. Espera que las dos primeras semanas sean ásperas —el brief será más vago de lo que pensabas, y la revisión atrapará cosas que el estándar no anticipó. Ese es el punto de ejecutarlo sobre trabajo real en vez de una campaña de prueba.
El entregable del mes dos es un estándar que funciona: qué se comprueba automáticamente, qué tiene que ver un humano y qué pasa con las excepciones. Escríbelo, porque un estándar de revisión que vive en la cabeza de una persona no es un estándar, es un cuello de botella. Es también el mes en que aprendes cuánta capacidad de revisión necesita de verdad la etapa —casi siempre más de la que asumía el primer plan.
Días 61–90: mide y luego decide
El tercer mes es medición y una decisión, y es la parte que los equipos impacientes se saltan.
Compara la etapa antes y después en dos cosas: tiempo de ciclo y calidad. ¿El trabajo terminó de verdad antes, y subió la tasa de error o de retrabajo? Una etapa más rápida con más errores no es una victoria; es riesgo que todavía no has pagado. Una etapa más rápida con calidad plana o mejor es la evidencia que necesitas para ampliar.
Luego toma una de tres decisiones, con honestidad. Si las cifras son buenas, coge la siguiente etapa —pero una a la vez, con el mismo diseño. Si las cifras son mixtas, arregla el estándar o el brief antes de ampliar, porque el método es sólido y la ejecución no. Si las cifras son malas y no puedes decir por qué, para y escribe lo que aprendiste; eso es más barato que escalar un flujo de trabajo roto.
Las tres fases de un vistazo
| Fase | Objetivo | Salida principal | Señal de éxito |
|---|---|---|---|
| Días 1–30 | Diagnosticar y diseñar | Diseño de una página: etapa, dueño, input, estándar | Puedes describir la etapa y su medida en una página |
| Días 31–60 | Ejecutar y estandarizar | Un estándar de revisión escrito y funcional | La etapa corre sobre trabajo real sin heroicidades |
| Días 61–90 | Medir y decidir | Evidencia sobre tiempo de ciclo y calidad | Una decisión defendible de ampliar, arreglar o parar |
La columna de señales es la parte a la que atenerte. Cada fase tiene una pregunta que te dice si avanzar, y ninguna es «¿se sintió como progreso?».
Las trampas que matan los despliegues
Hervir el océano. El equipo rediseña tres etapas a la vez porque todas duelen. El problema del desfile garantiza que las restricciones se queden donde están y que el esfuerzo se disperse demasiado para probar nada. Una etapa.
Herramientas primero. El despliegue empieza por una lista de compras en vez de un diagnóstico de flujo de trabajo. Acabas con un equipo AI-assisted y una factura de software más grande, que es el fallo que describe la distinción AI-native vs AI-assisted. Las herramientas están aguas abajo del diseño.
Sin dueño nombrado. Un despliegue que pertenece a «el equipo» no pertenece a nadie. Una persona es dueña de la etapa, el estándar y la evidencia, y esa persona tiene la autoridad de cambiar cómo corre la etapa.
Saltarse el estándar. El equipo automatiza la salida y mantiene la revisión informal. Eso funciona justo hasta el primer error que llega a un cliente, y entonces el despliegue pierde a su patrocinador. Define el estándar antes de escalar el volumen.
Quién debería dirigirlo
Necesitas un patrocinador sénior y un equipo dispuesto a ser el piloto. El patrocinador protege los 90 días de que los saqueen para otro trabajo; el equipo piloto hace el rediseño sobre campañas reales. No necesitas alineación de toda la organización antes de empezar —esperarla es una forma habitual de pasar un año en diapositivas— y no necesitas un equipo de ingeniería salvo que una integración real se pague sola.
El equipo piloto debería tener al operador que es dueño del trabajo, una persona que se tome los datos en serio y un revisor que te diga con honestidad cuándo la salida no es lo bastante buena. Ese último rol es fácil de olvidar y es el que mantiene honesto al despliegue.
Cómo es el éxito a los 90 días
Al final del trimestre, el éxito es deliberadamente modesto e inusualmente sólido: una etapa corre AI-native sobre trabajo real, con un estándar escrito y un dueño nombrado; puedes mostrar el tiempo de ciclo que ahorró y la calidad que mantuvo; y tienes una razón defendible para coger la siguiente etapa.
Eso no es una transformación. Es un prototipo funcional de una, y vale más que una hoja de ruta, porque es evidencia en vez de intención. La guía de Ejecución es el mapa completo en el que se sitúa este despliegue, y el carril para líderes de equipo secuencia las etapas después de la primera.
FAQ
¿Por qué 90 días y no 30 o 180?
Treinta días son demasiado cortos para ejecutar una etapa durante varios ciclos reales, así que el resultado es una demo en vez de evidencia. Ciento ochenta días convierten el trabajo en un programa que pierde impulso y financiación. Noventa días son la unidad más pequeña que produce prueba fiable.
¿Tenemos que elegir la etapa más difícil primero?
No —elige la restricción, que es la etapa en la que la campaña termina esperando. Normalmente es reporting, research o el brief, no algo glamuroso. La restricción es donde vive el tiempo de ciclo, y arreglarla es lo que hace el caso para el resto.
¿Y si el piloto falla?
Un piloto fallido que produce una razón honesta es más barato que un flujo de trabajo escalado que no puedes explicar. Escribe qué se equivocó en la etapa, el brief o el estándar, arréglalo, y ejecuta de nuevo los 90 días sobre la misma etapa. El método es sólido; la mayoría de los fallos son de ejecución, no de concepto.
¿Quién es dueño del despliegue?
Un patrocinador sénior y un dueño nombrado para la etapa. El patrocinador protege el tiempo; el dueño posee el estándar y la evidencia. Un despliegue que pertenece a «el equipo» no pertenece a nadie y será saqueado para otro trabajo en un mes.
La versión corta
Un despliegue AI-native de 90 días es una etapa rediseñada de principio a fin: diagnostica y diseña el brief en los días 1–30, ejecútala y construye el estándar de revisión en los días 31–60, mide y decide en los días 61–90. Una etapa, un dueño, evidencia antes de ampliar. Las trampas son hervir el océano, empezar por las herramientas, no tener dueño y saltarse el estándar. La guía de Ejecución es el mapa más amplio.
He dirigido despliegues que intentaban demasiado y despliegues que hacían demasiado poco, y los que funcionaron fueron siempre los que probaron una cosa bien antes de tocar la siguiente.
Si tu equipo está planeando un despliegue, me gustaría saber qué etapa elegiste y por qué —esa elección suele predecir si aguantará.
Un abrazo, Chandler
Este artículo está disponible en español, pero los materiales del curso (videos, plantillas y guías complementarias) están en inglés y japonés; este sitio está disponible en 13 idiomas.