El sábado organizamos Product Night Bogotá en la Universidad de los Andes. para hablar sobre “Agentic Product Builing”, la forma actual en la que profesionales de producto trabajan con herramientas de AI como Claude Code y otros tools.
Trajimos a tres operadores alrededor de una tesis directa: las dificultades históricamente percibidas de hacer producto en LATAM — menos capital, equipos más chicos, distancia con los hubs — tienen ahora una vía de nivelación concreta: AI y agentes. Tienen la capacidad de hacer cada fase del ciclo de vida de producto más rápida, y sentimos que si alguien tiene el contexto para proponer cómo hacerlo, es LatAm.
Andrea Giraldo (Sr Product Engineering Manager @ Simetrik) abrió la noche. Su charla nos hizo entender que: el cuello de botella en hacer producto con AI no es el modelo, es el contexto que cada equipo pierde en cada handoff interno.
Los equipos de producto de Simetrik ya trabajan AI Native, y han reducido el tiempo promedio de desarrollo de producto de 6 meses a sólo 2 incorporando un end to end AI accelerated.
— Luis
Retos de adoptar AI: “No éramos lentos. Estábamos fragmentados.”
Ese fue el slide 3. Andrea mostró el pipeline de Simetrik antes del cambio:
Etapa | Tiempo entre handoffs |
|---|---|
Insights / Métricas | — |
→ PRD | 3-5 días |
→ RFC / Matrices de prueba | 4-5 días |
→ Tickets | 7-10 días |
→ Código | 4-5 horas |
End-to-end, seis meses. Pero el número no es el punto. El punto es la línea debajo del pipeline: cada handoff destruía contexto. El equipo no estaba construyendo producto. Estaba traduciendo contexto entre humanos, y la calidad final quedaba limitada no por las herramientas, sino por cómo pensaban el problema en la primera milla.
Mi lectura: Andrea formalizó algo que los buenos PMs LATAM ya hacen informalmente. En equipos chicos el PM compensa los handoffs rotos con explicación manual — vuelve a contar el PRD en planning, lo repite en Slack, lo dibuja en una llamada con el dev. Es el trabajo invisible que sostiene producto en la región. Lo que ella propone es que se vuelva infraestructura, no una habilidad personal del PM que se quema.
El orden importa: proceso, contexto, tooling — en ese orden
La parte operativa de la charla no fue una herramienta. Fue un orden:
Definición de proceso — antes de tocar IA
Documentación de contexto — la base de todo lo demás
Stack técnico — Claude Team, Claude CLI, LLMs, plataformas no-code
Estructura de equipo + mindset
La mayoría de los PMs que conozco arrancan por el (3) y no llegan al (1) ni al (2). Sin proceso definido y sin contexto documentado, el tooling no comprime nada. Esa es la fricción real.
Lo que destrabó Simetrik fue construir lo que Andrea llamó un “brain”: Usan Obsidian como knowledge base central que conecta seis fuentes de información del equipo — tickets, entrevistas, Slack, Figma, GitHub, PRDs — y se las sirve a Claude estructuradas. No es un repositorio de documentos. Es un grafo de información que el modelo puede recorrer.
Detalle operativo importante: no arrancaron con todo a la vez. Empezaron documentando cómo trabaja el equipo. Después agregaron proceso. Después outputs. La tentación de montar el stack técnico primero era exactamente la trampa.
La IA es el 10% del trabajo
El slide al que más volví: un diagrama lineal — MCP + Skills + Tools → Brains → Inputs/Context → LLMs y Agents → Output → Testing → loop.
Debajo, la idea que cierra el reframe: la IA es apenas el 10% del trabajo. El 90% es el sistema que la hace confiable.
Esa es exactamente la confusión que veo a menudo, el modelo es cada vez más un commodity. La infraestructura de contexto y tooling que lo rodea — MCP servers, skills, tools, knowledge base, pipeline de testing — es el diferencial.
La arquitectura concreta que Andrea presentó como “From Signals to Software” convierte señales del producto (uso real, tickets, métricas) en código de producción a través de tres agentes especializados, no uno solo:
Fase | Input | Agente | Output |
|---|---|---|---|
Inputs | Información de producto + contexto | Discovery Agent | Reportes |
Build | Contexto de ingeniería | Developer Agent | Production code |
Validación | Escenarios de prueba | QA Agent | Verified releases |
Encima, una orchestration layer: un agente coordinador que pasa contexto entre Discovery, Developer, QA y Ops. No son agentes independientes haciendo cada uno su tarea — eso sería volver al pipeline fragmentado, solo que con bots. Es un sistema multi-agente con coordinador central, y la información fluye entre los nodos en vez de fragmentarse.
El detalle que Andrea remarcó sobre el coordinador: cuando Discovery Agent termina su reporte, el coordinador lo inyecta como parte del prompt activo, junto con los PRDs relacionados, los tickets recientes y las métricas de uso. El Developer no “lee el reporte” — opera con el reporte ya cargado en su ventana de razonamiento. Eso es el handoff que Simetrik dejó de hacer manualmente.
El equipo cambia: AI Builders sobre orquestadores
El slide más incómodo de la charla, y por lo mismo el que más vale la pena mirar.
Antes: PM con PO, Diseñador, Desarrolladores y QA debajo. Después: AI PM con cuatro AI Builders, agentes orquestadores y sub-agentes.
La frase de cierre del slide: el equipo ya no ejecuta instrucciones — itera sobre contexto.
Eso redefine qué significa “PM” como rol. Si el equipo itera sobre contexto, el PM no escribe el PRD para que alguien lo ejecute. Diseña la infraestructura editorial sobre la que humanos y agentes operan. Es producto sobre infraestructura contextual, no producto sobre instrucciones.
Cómo se ve un día de un AI Builder
Andrea nos dió una idea de cómo se ve el día a día de un AI Builder, no escribe código todo el día. Escribe prompts, valida outputs, ajusta knowledge bases y diseña los handoffs que antes ejecutaban humanos. Su trabajo de la mañana es revisar lo que los agentes produjeron — el batch de PRDs que Discovery generó, el código que Developer mergeó, los tests que QA flageó como sospechosos. La tarde es ingeniería de contexto: encontrar la pieza de información que los agentes necesitaban y no tenían, y decidir si la nueva pieza vive en el “brain” central o en un sub-agente especializado. Cero standups de status. Cero refinamiento manual de tickets. El leverage no está en cuántas líneas de código escribe — está en cuántos loops del sistema deja andando bien sin él.
El resultado
Antes | Después |
|---|---|
De idea a prototipo: semanas | horas |
Desarrollo de PRDs: semanas | días |
RFCs y arquitectura: semanas | días |
End-to-end: 6 meses | 2 meses |
Cada fila es un handoff que dejó de existir o se comprimió. No porque el modelo se haya vuelto mejor — el mismo Claude que tiene Simetrik lo tiene cualquier equipo con acceso. Sino porque el contexto que ese modelo necesita para ejecutar bien dejó de pasar de cabeza en cabeza.
Si trasladas esa compresión a tu propia tabla — cuántos sprints toma una feature en tu equipo, cuántos días un PRD bien escrito, cuántas reuniones para alinear un RFC — el ejercicio que vale la pena no es comparar contra Simetrik. Es preguntarte qué handoff específico de los tuyos se podría comprimir si la información dejara de fragmentarse en el camino. La respuesta casi siempre es uno solo. Empezar por ése y medir el delta antes de tocar el siguiente. Andrea no llegó a la compresión 6→2 por reescribir todo el pipeline; llegó por documentar primero la primera milla y dejar que el resto se ordenara desde ahí.
Lo que Andrea dejó instalado en la sala
Audita handoffs antes de auditar tu stack. Dónde se rompe el contexto entre tu PRD, tu RFC, tu ticket y tu código — ahí está el 6→2. El modelo no se mueve hasta que esos handoffs se cierren. Esta semana: dibuja en una hoja los 5 últimos handoffs entre humanos en tu pipeline, y mide cuánto tiempo perdieron por re-explicación.
Documentar contexto va antes que escribir prompts. El orden importa. Tooling sin proceso definido y sin contexto documentado no comprime nada. Empezar por uno solo — documentar — y después agregar. Esta semana: identifica una decisión recurrente que tu equipo toma con información incompleta, y empieza a capturar esa información en un solo lugar antes de tocar Claude.
El PM diseña la infraestructura de contexto, no escribe instrucciones. Cuando el equipo itera sobre contexto, el rol cambia: el PM construye la infraestructura sobre la que humanos y agentes operan. Es producto sobre infraestructura, no sobre handoffs. Esta semana: tu próximo PRD escríbelo como si Discovery Agent lo fuera a leer, no un humano. Vas a notar dónde tu contexto interno tenía hoyos.
El moat no va a estar en quién accede al modelo más nuevo. Va a estar en quién tiene la infraestructura editorial mejor diseñada debajo. Andrea mostró cómo se ve cuando alguien lo construye en serio.
— Luis
Sobre Andrea Giraldo: Sr Product Engineering Manager en Simetrik, donde lidera la transición del equipo a un pipeline AI-native. Abrió Product Night Bogotá el 2 de mayo de 2026 con “Del Prompt al Producto”, la primera de las tres charlas curadas alrededor de la tesis “The LatAm Way”.
Si esto te suma, suscríbete al newsletter de Prisma. Cada jueves: cómo los AI-Native PMs de LatAm están construyendo producto. → getprisma.lat/newsletter
