El dot de ChatGPT como product manager: objetivos, tareas y múltiples hilos

Qué es un dot y por qué no es otro chatbot

Un dot es un agente personal de ChatGPT pensado para mantener una responsabilidad a lo largo del tiempo. Puede seguir progreso entre conversaciones, investigar información conectada, decidir cuándo retomar trabajo y delegar tareas a agentes en segundo plano. También puede iniciar hilos cloud separados y crear o continuar tareas de ChatGPT Work o Codex en un computador conectado.

Esa descripción se parece más a un coordinador que a una caja de chat. La conversación principal conserva prioridades, decisiones y excepciones. Los hilos delegados realizan trabajo acotado. El dot reúne resultados, detecta cambios y vuelve a la persona cuando necesita juicio o autorización.

No todas las cuentas o espacios tendrán las mismas conexiones habilitadas. La capacidad real depende de los plugins, permisos, computadores y entornos de Codex configurados para esa cuenta. Diseña el proceso con lo que la interfaz confirme, no con una lista teórica de posibilidades.

Chat, Work, Codex y dot cumplen funciones distintas

Chat sirve para conversar, explicar, idear o redactar en el momento. ChatGPT Work sirve para delegar una tarea de investigación, análisis o creación de un archivo, ahora o con una programación. Codex trabaja directamente con repositorios, pruebas y herramientas de desarrollo. El dot mantiene una responsabilidad continua y puede coordinar trabajo en esas superficies.

La distinción evita enviar todo al mismo hilo. Una consulta breve puede quedarse en Chat. Un análisis de competidores puede ir a Work. Una migración de base de datos pertenece a Codex. El dot mantiene el mapa: por qué existen esas tareas, qué decisión alimentan y qué resultado debe volver al plan del producto.

Pensarlo como product manager no significa que sustituya al cargo. Significa usarlo para las partes mecánicas de la coordinación: mantener lista de riesgos, comprobar dependencias, preparar documentos, abrir tareas y traer decisiones pendientes. La estrategia, la responsabilidad frente al negocio y los juicios sobre personas siguen siendo humanos.

Empieza con una responsabilidad, no con un prompt gigante

Una responsabilidad útil tiene cinco piezas.

Resultado. Qué debe mantenerse verdadero, por ejemplo “el lanzamiento conserva una fecha realista y cada bloqueo tiene dueño”.

Fuentes. Qué documentos, canales, repositorios o tableros representan la realidad.

Cadencia. Cuándo revisar cambios y qué eventos justifican despertar.

Escalamiento. Qué decisiones debe traer y qué información puede actualizar sin interrumpir.

Límites. Qué acciones sólo puede preparar, cuáles requieren aprobación y cuáles no debe realizar.

Un ejemplo completo sería: “Mantén el lanzamiento de la versión móvil al día. Usa el plan, los issues del repositorio y el canal de QA. Avísame sólo si una fecha está en riesgo, falta un dueño o una decisión bloquea más de un día. Puedes actualizar el checklist y crear borradores; no envíes mensajes externos ni cambies producción sin mi aprobación”.

Esa instrucción es más pequeña que una especificación total, pero contiene el contrato que permite decidir los siguientes pasos.

Convierte objetivos amplios en resultados verificables

“Haz crecer el producto” es demasiado amplio incluso para un orquestador. Conserva la ambición, pero divídela en resultados que puedan comprobarse. Por ejemplo: entender la activación, reducir el tiempo hasta el primer valor, eliminar tres bloqueos del onboarding y preparar un experimento con criterio de éxito.

Cada resultado puede vivir en una tarea distinta. El dot mantiene las dependencias y la prioridad. Para trabajo de Codex que requiere varias iteraciones, un Goal añade un contrato persistente dentro de ese hilo. La documentación de OpenAI define un Goal como un objetivo asociado al hilo, con condición de término, restricciones, presupuesto y verificación por evidencia.

La frontera es importante. El dot puede coordinar una responsabilidad que abarca marketing, datos y desarrollo. Un Goal de Codex pertenece al hilo donde viven los archivos, comandos y pruebas de una parte técnica. No conviertas un objetivo de negocio en un bucle infinito de código. Define qué estado final demostrará el avance y cuándo debe volver al dot.

Un objetivo norte se descompone en hitos y en hilos paralelos de investigación, producto, implementación, calidad y comunicación.

Cuándo abrir un hilo nuevo y cuándo continuar uno existente

Abre un hilo nuevo cuando cambia el artefacto, el entorno, el responsable o el criterio de término. Una investigación de usuarios y una corrección del checkout producen evidencia distinta y merecen conversaciones separadas. Continúa un hilo cuando el nuevo pedido depende de decisiones, archivos o resultados que ya están allí.

Un hilo delegado recibe instrucciones y contexto para ese trabajo, pero no hereda automáticamente cada conversación que tuviste con el dot. Por eso el mensaje de delegación debe incluir el objetivo, las fuentes, las restricciones, la salida esperada y la forma de comprobarla.

Evita abrir hilos para cada microtarea. El exceso fragmenta contexto y obliga a reconstruir decisiones. Una regla práctica es abrir un hilo por resultado auditable. Dentro de ese hilo, el agente puede ejecutar varios pasos mientras el criterio de término siga siendo el mismo.

Cómo orquestar varios hilos sin perder el control

Usa la conversación del dot como mesa de control y cada hilo como unidad de ejecución. La mesa de control conserva una lista pequeña: objetivo, tarea, estado, último hallazgo, próxima decisión y enlace al hilo. No copies todos los mensajes; conserva el dato que cambia el plan.

Ejecuta en paralelo sólo tareas independientes. La investigación de competidores, la revisión de accesibilidad y el análisis de eventos pueden avanzar al mismo tiempo. La implementación del experimento debe esperar a que exista una decisión de alcance.

Pide al dot que te informe por excepción. El progreso rutinario puede quedar en la actividad; una fecha en riesgo, un permiso faltante o dos fuentes contradictorias merecen notificación. OpenAI permite revisar las tareas que el dot inició desde Activity y dar instrucciones directas. El dot también puede comprobar resultados y enviar seguimientos.

Cierra el ciclo con una revisión del estado final. Que un hilo diga “completado” no prueba que el resultado se entregó. Abre el artefacto, ejecuta la prueba o inspecciona el sistema externo antes de actualizar el plan principal.

Hilos paralelos intercambian artefactos mediante un centro de contexto con permisos, dependencias, pausas y aprobación humana final.

Memoria no significa acceso ilimitado a todas tus conversaciones

El dot usa la conversación actual, memoria relevante de ChatGPT y notas propias sobre preferencias, decisiones y responsabilidades. Esas notas no son una transcripción completa. Los mensajes visibles en ChatGPT, Slack o Teams permanecen en sus canales; cambiar de canal no crea otro dot, pero tampoco copia todo el historial en cada lugar.

Un nuevo hilo recibe el contexto que el dot le proporciona. Conectar un computador no concede acceso a todas las conversaciones ni hereda las sesiones del navegador personal. El computador cloud del dot tiene archivos y sesiones propios. Un entorno de Codex también debe configurarse con el repositorio y la preparación que necesita.

Para un product manager, esto conduce a una práctica concreta: documentar decisiones críticas en un artefacto compartido y pasar un resumen explícito a cada tarea. No uses “ya lo hablamos” como dependencia invisible. Si una restricción afecta precio, privacidad o alcance, escríbela en la fuente canónica.

Coordinar no equivale a autorizar

Las conexiones están separadas. Un canal de mensajería permite hablar con el dot, pero no conecta automáticamente el correo, un plugin o el computador. Cada aplicación conserva sus permisos. Las acciones que afectan cuentas o comparten información pasan por una revisión que puede permitir, pedir aprobación o devolver el paso a la persona.

Las reglas personalizadas pueden definir comportamientos como actuar sin preguntar, actuar cuando se lo indiques, preguntar antes o entregarte la acción. Sirven para fijar límites recurrentes, pero no conceden acceso a una aplicación ni eliminan requisitos de seguridad.

Diseña por impacto. Leer un tablero puede ser continuo. Preparar un borrador puede no requerir interrupción. Enviar un correo a clientes, borrar archivos compartidos, mover dinero o publicar en WordPress necesita un alcance explícito. Un buen orquestador reduce preguntas rutinarias y aumenta la calidad de las preguntas importantes.

Ejemplo: coordinar un lanzamiento de producto

Objetivo principal: liberar una nueva activación móvil con métricas y plan de reversa.

Hilo 1, investigación: comparar cinco sesiones de usuario y entregar los tres puntos de abandono con evidencia.
Hilo 2, producto: convertir esos hallazgos en un alcance de versión, criterios de aceptación y preguntas abiertas.
Hilo 3, Codex: implementar el flujo aprobado, ejecutar pruebas y preparar un diff revisable.
Hilo 4, calidad: revisar accesibilidad, estados de error y telemetría con un checklist.
Hilo 5, lanzamiento: preparar notas, plan de reversa, responsables y comunicación, sin enviar nada.

El dot puede abrir o continuar esos hilos, seguir sus estados y resumir dependencias. Si la investigación cambia el alcance, detiene la implementación antes de desperdiciar trabajo. Si calidad encuentra un bloqueo, actualiza el riesgo y solicita una decisión. Cuando todos los criterios se cumplen, prepara el paquete de lanzamiento. La acción final sigue su control correspondiente.

El valor no está en tener cinco chats. Está en que cada uno entrega una evidencia al mismo objetivo y existe una instancia que sabe cuándo unirlos.

Configúralo como un sistema operativo de producto

1. Elige una sola responsabilidad que ya revisas cada semana.
2. Conecta únicamente las fuentes necesarias y comprueba sus permisos.
3. Define resultados, excepciones y acciones que requieren aprobación.
4. Decide qué información vivirá en una fuente canónica.
5. Pide un inventario inicial de tareas, riesgos y decisiones pendientes.
6. Delega un resultado por hilo y exige criterio de término.
7. Usa Activity para revisar trabajo y Scheduled para la cadencia fija.
8. Configura notificaciones por cambio importante, no por cada avance.
9. Revisa los primeros resultados y corrige instrucciones antes de ampliar el alcance.
10. Audita periódicamente tareas activas, reglas, conexiones y permisos.

Empieza con coordinación de sólo lectura y borradores. Añade acciones externas cuando el proceso ya demuestra que distingue estado, autorización y evidencia. Un dot puede sostener objetivos grandes, pero su mejor diseño no es “total libertad”. Es una responsabilidad clara, herramientas adecuadas y una ruta corta para pedir tu juicio cuando realmente importa.