La mayoría del contenido sobre IA en producto se queda en una de dos esquinas. En una, artículos conceptuales sobre "el futuro del product management con IA" que no bajan a tierra. En la otra, herramientas que resuelven una fase específica: Figma AI para prototipar, GitHub Copilot para codear, Miro AI para sintetizar research. Hay poca o nula conversación sobre cómo se conecta todo el ciclo. Y nadie habla sobre qué pasa cuando tu framework de producto empieza a funcionar bien y genera un problema que no anticipaste.
Este artículo cuenta cómo construí un framework que cubre el ciclo completo de desarrollo de producto — desde la estrategia de negocio hasta el código en producción — con agentes de IA como co-builders. Y cómo usarlo en productos reales me obligó a construir algo que no estaba en el plan: un sistema operativo para gestionar el framework mismo.
El punto de partida: qué le faltaba al SDD
Trabajo en producto hace años. He operado como PM, como consultor de producto, como founder técnico. Hoy trabajo en Thoughtworks — una organización que respeto profundamente por su liderazgo cultural y su capacidad de transformación tecnológica — y en paralelo construyo productos propios. Y cuando los agentes de IA empezaron a ser útiles de verdad — no demos impresionantes, sino herramientas que podían sostener trabajo real — vi una oportunidad que la industria no había articulado.
El Spec-Driven Development se estaba convirtiendo en mainstream. Thoughtworks lo reconoció como una de las prácticas emergentes más importantes de 2025. GitHub lanzó Spec Kit. Amazon sacó Kiro con Spec Mode integrado. EY lanzó EY.ai PDLC en marzo de 2026 — un approach AI-native al desarrollo de software que promete ir de "idea a producción en días en vez de meses."
Pero todo ese movimiento tenía un mismo sesgo: se enfocaba en la fase de build. Tienes una feature decidida, la especificas, la implementas con agentes. El pipeline es: specify → plan → tasks → implement.
Lo que faltaba — lo que le faltaba a toda esa conversación — era el ciclo completo. ¿Cómo llegas a decidir qué feature construir? ¿Dónde están las entrevistas de usuario, el experience mapping, el assumption testing? Todo eso ocurre antes de que escribas una sola spec. Y después del build, ¿dónde está la validación experimental? ¿Cómo determines que lo que construiste realmente genera el cambio de conducta esperado en el usuario antes de hacer el rollout?
La spec-driven mindset no es solo para codear. Es para todo el ciclo de producto.
Qué construí: E2E-SDPB
E2E-SDPB — End-to-End Spec-Driven Product Building — es un framework que cubre el ciclo completo de desarrollo de producto — desde la estrategia de negocio hasta la validación experimental, con un aprendizaje que cierra el loop:
Estrategia de negocio
│
▼
Business Outcome ◄──────────────────────────────────────────┐
│ │
▼ │
Evidencia → Oportunidades → Sizing & Priorización │
│ ↑ │ Aprendizaje
│ [Discovery continuo] │
▼ │
Soluciones → Supuestos críticos → Plan de validación │
│ │
▼ │
Spec funcional + Spec del experimento │
│ │
▼ │
Build (SDD: constitution → specify → plan → tasks → impl.) │
│ │
▼ │
Validación experimental → Resultados → Decisión ────────────┘En su forma más abstracta, la premisa del ciclo es:
Evidencia → Especificación → Implementación → Validación
↑ │
└──────────────── Aprendizaje ─────────────────┘Nada se construye sin spec. Ninguna spec se escribe sin evidencia. Todo lo construido se valida. Los aprendizajes alimentan el siguiente ciclo.
El framework opera en cinco fases. Las tres primeras están implementadas y en producción. Las dos últimas están diseñadas y documentadas, listas para entrar en operación.
Fase 1: Shape — La piedra filosofal del product management
Shape es donde empieza todo, y es donde el framework se diferencia más radicalmente de lo que existe.
El punto de entrada es un business outcome — un resultado de negocio concreto que quieres conseguir. No una feature, no un requerimiento, no "el cliente pidió X". Un outcome: incrementar retención en un 15%, reducir churn de trial a paid, aumentar activación en la primera semana.
A partir de ese outcome, el framework construye un Opportunity Solution Tree (OST) — un árbol que conecta el resultado de negocio con los problemas reales de los usuarios y las posibles soluciones. Esto no es nuevo: el OST viene de Teresa Torres y Continuous Discovery. Lo que es nuevo es cómo el framework lo opera con agentes de IA.
El agente puede tomar transcripciones de entrevistas de usuario y construir interview snapshots estructurados — resúmenes que capturan los hallazgos clave como fuentes de evidencia formales. Esos snapshots alimentan el OST, que se genera de forma semi-automática con dos dimensiones que lo hacen accionable: un nivel de confianza basado en la cantidad y calidad de la evidencia que respalda cada nodo, y un nivel de relevancia basado en qué tan directamente contribuye a conseguir el business outcome.
Esto es lo que yo considero la piedra filosofal del product management: la capacidad de vincular sistemáticamente el problema que le resuelves al usuario con el resultado de negocio que necesitas conseguir. Si resuelves el problema correcto, generas un cambio de conducta en el usuario que mueve la métrica de negocio. Esa cadena causal — problema → cambio de conducta → resultado de negocio — queda explícita y trazable en el OST.
El framework incluye un proceso de sizing y priorización que te lleva a tomar decisiones sobre qué oportunidad elegir, con criterio explícito y documentado. Y genera un shaping-discovery plan — un plan de actividades que te permite seguir construyendo certidumbre y detalle en las ramas del OST que lo necesiten, mientras ya puedes avanzar con la siguiente fase para las oportunidades que tienen suficiente evidencia. El discovery no se detiene porque empezaste a idear — corre en paralelo, alimentando el árbol continuamente.
Fase 2: Ideate & Validate — De la oportunidad a la solución con evidencia
Con una oportunidad elegida y respaldada por evidencia, la fase de Ideate & Validate genera múltiples ideas de solución desde distintos puntos de vista — producto, diseño, ingeniería, negocio — cada una con sus consideraciones y tradeoffs explícitos.
Pero generar ideas no es el valor. El valor está en lo que viene después: identificar los supuestos críticos que deben ser verdad para que la solución, de construirse, genere el impacto esperado. ¿Realmente el usuario va a cambiar su conducta si le ofreces esto? ¿El cambio técnico es viable sin comprometer performance? ¿El modelo de negocio soporta esta feature?
A partir de los supuestos, el framework construye un plan de validación — actividades concretas de analítica de datos, investigación cualitativa, prototipos rápidos, o lo que se necesite para reducir la incertidumbre antes de comprometerse a construir. La salida de esta fase no es "una idea que nos gusta" — es una solución elegida con evidencia de validación y un plan de discovery complementario para los supuestos que todavía tienen riesgo.
Fase 3: Handoff to Delivery — Convergencia a la spec
Aquí la solución validada toma forma concreta. El framework guía un proceso de chunking y priorización: la solución se descompone en épicas, features o PBIs, se organiza en un mini backlog, y cada pieza converge hacia una spec que contiene dos dimensiones.
La primera es la spec funcional: qué se construye, para quién, con qué criterios de aceptación, en qué contexto técnico. Esta es la parte que la industria ya conoce como SDD.
La segunda es la spec del experimento: el diseño estadístico que te permite determinar, con una confianza estadística definida, que lo que construiste realmente genera el cambio de conducta esperado en el usuario — y que no produce efectos adversos en otras métricas. No es un A/B test improvisado; es una especificación formal del experimento que incluye hipótesis, métricas primarias y guardrail, tamaño de muestra, duración, y criterios de decisión.
Las specs que salen de esta fase son lo suficientemente detalladas para que un agente o un equipo de desarrollo pueda implementar con mínima ambigüedad. Y lo suficientemente rigurosas para que la validación posterior sea científicamente sólida.
Fase 4: Build — El SDD en acción (diseñada)
Esta es la fase donde el framework conecta con lo que la industria está haciendo mainstream. El pipeline speckit orquesta la construcción: constitution → specify → plan → tasks → implement. Cada spec funcional se materializa en código, se testea, se deploya.
Pero a diferencia de usar SDD como punto de entrada, aquí llegas al build con algo que el SDD estándar no tiene: el contexto completo de por qué estás construyendo lo que estás construyendo. El OST, la evidencia, los supuestos validados, el experimento diseñado — todo eso viaja como contexto para los agentes que implementan. No es "aquí tienes una spec, constrúyela". Es "aquí tienes una spec que existe porque descubrimos este problema en estas entrevistas, validamos estos supuestos con estos datos, y necesitamos medir este cambio de conducta con este experimento."
Fase 5: Experimentation & Insights — Cerrar el ciclo (diseñada)
La fase que cierra el loop. Una vez que la feature está construida y deployada, el framework guía la ejecución del experimento diseñado en la fase 3: el A/B test corre, las métricas se monitorean, y los resultados se evalúan contra los criterios de decisión especificados.
Si los resultados no son los esperados, la spec se ajusta — no se descarta todo y se empieza de cero. El framework permite iterar sobre la especificación funcional con los insights del experimento, recorrer un ciclo corto de ajuste y re-experimentación, y llegar a los resultados necesarios antes del rollout completo. Los aprendizajes del experimento alimentan el OST — cerrando formalmente el ciclo evidencia → spec → build → validación → aprendizaje.
Cómo funciona por debajo: contexto y gobernanza
El framework no es solo fases y artefactos. Lo que lo hace funcionar en la práctica son dos decisiones de ingeniería que no son visibles desde la descripción de las fases.
Context engineering: Cada producto vive en un repositorio autocontenido con toda su información — estrategia, contexto de squad, design system, tech stack, bitácora, specs, artefactos de discovery. El framework gestiona qué contexto cargar según la tarea en curso. No se carga todo siempre. Los agentes reciben exactamente el contexto que necesitan para la tarea que están ejecutando, ni más ni menos. Esto es lo que permite que los agentes produzcan trabajo de calidad en vez de alucinar por exceso o falta de contexto.
Branching y colaboración: El framework gestiona las ramas del repositorio con una convención que refleja el trabajo real. Cada rama se nombra con la fase, la fecha del ciclo y opcionalmente la actividad específica: shape/2026-03-c1, ideate-validate/2026-03-c1/assumption-testing, handoff/2026-04-c1/spec-checkout-flow. Esto permite que los miembros de una tríada trabajen en sus computadores locales, en un repositorio compartido, con claridad total sobre en qué fase y ciclo está cada pieza de trabajo. No es un detalle menor — es lo que hace operativo el framework cuando hay más de una persona involucrada.
Gobernanza local: Cada producto tiene su propio CLAUDE.md que le dice al agente cómo navegar el repositorio, qué leer según la tarea, qué reglas seguir. El framework define el flujo y los artefactos, pero quién ejecuta cada paso es configurable — una persona sola con agentes, una tríada humana con dev team, o un híbrido. Cada producto declara su modo de operación.
El problema que no anticipé
El framework funcionaba. Los productos se construían con más estructura, mejor documentación, menos ambigüedad. Pero después de usarlo en múltiples productos — Gravity (una app que ayuda a implementar un highlight diario que le da foco a tu día) fue el primero y la piedra angular donde empezó todo, seguido de guilles-blog y Voltics, además de informar trabajo de consultoría con equipos de producto en organizaciones más grandes — apareció un problema que no había considerado.
Los aprendizajes quedaban atrapados en silos.
En guilles-blog descubrí que el sub-proceso de Build no estaba documentado en el framework — lo agregué ahí. Descubrí que necesitaba una política de bypass para sub-procesos cuando las decisiones ya estaban tomadas — la creé ahí. Descubrí que el principio de repositorio autocontenido era fundamental — lo documenté ahí. Seis aprendizajes concretos sobre el framework, todos registrados en guilles-blog.
Pero cuando creé Voltics, el siguiente producto, esos aprendizajes no existían. Voltics nació del template original — la versión congelada del framework antes de todo lo que aprendí.
Cuanto más valioso es tu template, más costoso es que se quede atrás. Y este template — con cinco fases diseñadas, agentes especializados, skills operativos, context engineering, y todo el andamiaje metodológico — es demasiado valioso para que se congele.
La solución: un Operating System para el portafolio
Lo que construí para resolver esto fue un Product Building Operating System — una capa de gobernanza que envuelve al framework y gestiona cómo los productos nacen, cómo los aprendizajes fluyen, y cómo el template evoluciona.
La distinción es importante: el framework le dice a cada producto cómo construirse. El OS gestiona cómo el framework mismo mejora.
El OS opera a través de cuatro protocolos:
Seed — Crear un producto nuevo. Copia el template actual completo. El producto recibe un snapshot autónomo con todo lo necesario para operar desde el momento cero, más los artefactos que lo conectan al learning loop.
Onboard — Integrar un producto pre-existente de forma no-invasiva. Solo agrega los artefactos de gobernanza para participar en el learning loop.
Harvest — Extraer aprendizajes al template. Durante el trabajo normal, el agente detecta aprendizajes sobre el framework y los registra clasificados como product-level (específico) o framework-candidate (generalizable). Cuando yo lo solicito, el OS consolida los candidates de todos los productos, propone cambios al template con justificación basada en evidencia, y yo apruebo o rechazo. Los cambios se versionan con semver.
Sync — Propagar mejoras a productos existentes. Informativo al abrir sesión. Adopción selectiva a demanda. Nunca automático — cada producto es autónomo.
El primer harvest ya ocurrió: seis framework-candidates de guilles-blog aplicados al template, de v0.1.0 a v0.2.0. Cuando creé Voltics vía seed, ese producto nació con todas las mejoras incorporadas. No porque yo recordara qué había aprendido — sino porque el sistema lo canalizó.
Lo que aprendí
Sobre el alcance del SDD: La industria lo está aplicando a la fase de build. El potencial real está en aplicar la misma mentalidad — evidencia antes de acción, especificación antes de implementación — a todo el ciclo de producto. Si tu framework empieza cuando ya decidiste qué construir, te estás perdiendo el problema más difícil y el más valioso: decidir qué construir y por qué.
Sobre frameworks y sistemas: Un framework que no evoluciona con su uso es un documento estático que diverge de la realidad con cada proyecto. La diferencia entre un framework y un sistema es que el sistema tiene mecanismos de retroalimentación. El learning loop bidireccional es lo que convierte una metodología en algo vivo.
Sobre el modelo humano-agéntico: La división que funciona no es "la IA hace lo fácil y el humano hace lo difícil". El humano conserva el juicio estratégico — qué construir, qué priorizar, qué aprendizajes aplicar. El agente absorbe la carga operativa — construir interview snapshots desde transcripciones, generar OSTs con niveles de confianza, ejecutar protocolos, mantener artefactos, comparar versiones. Los dos son necesarios, pero no son intercambiables.
Gracias
Este framework no se construye en soledad. Hay personas cuya influencia, generosidad o modo de pensar están incorporados en lo que se describe arriba — y quiero nombrarlas.
Ivana Ciric — Product Principal en Thoughtworks — tiene una claridad sobre el Product Development Lifecycle que es difícil de encontrar. Su manera de estructurar el ciclo de producto fue la referencia mental cuando empecé a diseñar este framework. Trabajar junto a ella en una product clinic y poder conversar con ella regularmente ha sido una de las experiencias de aprendizaje más valiosas de los últimos años.
Ariel Contreras — CPO de Leadsales y colega de los primeros años en producto — fue quien me introdujo a Scrum y al diseño de productos. Años después, me pasó un ingrediente que no esperaba: la idea de trabajar producto directamente en un repositorio con Claude. Su versión son carpetas bien estructuradas; yo le sumé el PDLC completo, los agentes, los skills y el sistema operativo. La semilla, sin embargo, es suya.
Alejandra Godoy — Product Manager de Latam Pass — es la primera early adopter y contribuidora directa del framework. En seis meses de trabajo diario, sus preguntas y sus ángulos han hecho que el sistema sea considerablemente más robusto de lo que habría sido solo. Hay una diferencia real entre un sistema que se prueba en silencio y uno que se prueba con alguien que lo cuestiona en serio.
Joao Pereira — Engineering Chapter Lead de Latam Pass — actuó como ángel inversor de este experimento. Cuando le contamos lo que estábamos intentando construir, despejó espacio en su agenda sin pensarlo dos veces. Nos presentó Spec-kit y el paradigma SDD, nos guió en los conceptos técnicos, ayudó a habilitar los ambientes necesarios, y ha estado disponible cada vez que lo hemos necesitado.
E2E-SDPB está en producción con tres productos propios (Gravity, guilles-blog, Voltics), un template en versión 0.2.0, y un Operating System funcional. Las fases 4 y 5 están diseñadas y entran en operación con el próximo producto. Es un sistema que se usa todos los días para construir productos reales — no un concepto en una presentación.
A nivel personal, este trabajo me tiene genuinamente emocionado. No por lo que hace hoy, sino por lo que representa: despejar el camino para que otros profesionales de producto puedan aprovechar las ventajas de la tecnología sin tener que recorrer todo el trayecto desde cero. Es hacer camino al andar — y compartirlo es parte del propósito.