Comparar
PRD vs. Intent Contract: una comparación práctica
Dos formas de alinear a un equipo antes de construir: una especificación de funcionalidades, o una declaración breve del resultado y de cómo se verificará.
Comience con nuestro agente de IA. Encuentre su siguiente paso.
Guía de decisión
PRD o Intent Contract
- Funcionalidades y especificaciones frente a resultados
- Extensión, responsables y momento en que se redacta cada uno
- Cómo se miden el alcance y el éxito
Cuando está listo para construir algo, necesita alineación. Pero la pregunta no es solo "¿qué debemos construir?". Es "¿qué problema estamos resolviendo y cómo sabremos que funcionó?". Dos documentos compiten por esa tarea de alineación: el tradicional documento de requisitos del producto (PRD, por sus siglas en inglés) y el Intent Contract, el documento de alineación centrado en resultados que InTech usa al inicio de cada proyecto.
Ambos funcionan. La elección depende de su contexto, de la estructura de su equipo y de lo que busca optimizar.
¿Qué es un PRD?
Un documento de requisitos del producto es una especificación detallada de funcionalidades, historias de usuario y criterios de aceptación. Responde a una pregunta: ¿qué debe hacer el producto?
Un PRD suele incluir:
- Listas de funcionalidades y especificaciones funcionales
- Historias de usuario y casos de uso
- Criterios de aceptación y métricas de éxito
- Referencias a wireframes u orientaciones de diseño
- Restricciones técnicas y dependencias
- Orden de prioridades y fases
Los PRD van desde versiones ligeras (unas cuantas épicas bien enfocadas) hasta documentos exhaustivos (más de 50 páginas). Los redactan los gerentes o líderes de producto, los revisa el equipo de ingeniería y se usan como referencia durante todo el desarrollo.
La fortaleza de un PRD es la claridad sobre el alcance y las funcionalidades. Todos saben qué construir. La debilidad es que los PRD se centran en las funcionalidades, no en los resultados. Se puede tener un PRD perfecto para el problema equivocado.
¿Qué es un Intent Contract?
Un Intent Contract es una declaración breve y aprobada del resultado, el alcance, las métricas de éxito, las restricciones, los límites de la autoridad humana y los criterios de aceptación. No es un acuerdo legal; las condiciones comerciales se establecen en el contrato del proyecto. Es mucho más breve que un PRD (normalmente de 2 a 4 páginas) y parte del objetivo de negocio, no de listas de funcionalidades.
Un Intent Contract responde:
- ¿Cuál es el objetivo de negocio o el problema del usuario?
- ¿Qué resultado medible define el éxito?
- ¿Qué está explícitamente dentro del alcance y qué queda fuera?
- ¿Qué restricciones y dependencias existen?
- ¿Cómo mediremos los resultados después del lanzamiento?
- ¿En qué condiciones reduciríamos el alcance o nos detendríamos?
Un Intent Contract incluye criterios de aceptación, pero se basan en resultados, no solo en completar funcionalidades. Lo redactan en conjunto el líder de producto, el equipo de ingeniería y el cliente o las partes interesadas, y requiere aprobación antes de que comience el desarrollo.
La fortaleza de un Intent Contract es la claridad sobre el resultado y los límites explícitos del alcance. La debilidad es que no sustituye el diseño técnico detallado ni las especificaciones de UX en trabajos complejos.
Diferencias estructurales clave
| Aspecto | PRD | Intent Contract |
|---|---|---|
| Enfoque principal | Funcionalidades y especificaciones | Resultados de negocio y métricas de éxito |
| Extensión | 10-50+ páginas | 2-4 páginas |
| Responsable | Gerente de producto | Líder de producto + ingeniería + partes interesadas |
| Cuándo se redacta | Antes del desarrollo | Antes del desarrollo, con aportes de ingeniería |
| Pregunta principal | ¿Qué debemos construir? | ¿Por qué lo construimos y cómo sabremos que funcionó? |
| Modelo de alcance | Acumulativo (las funcionalidades, una vez incluidas, se quedan) | Flexible (el alcance se ajusta para lograr el resultado) |
| Criterios de cancelación | A menudo no existen | Explícitos desde el inicio |
| Se actualiza durante el proyecto | Rara vez | Con regularidad (cada semana o después de un aprendizaje importante) |
| El éxito se mide por | ¿Entregamos todo? | ¿Se movió la métrica de resultado? |
Lo que cada uno hace bien
Fortalezas del PRD
- Especificación exhaustiva que escala a trabajos complejos con varios equipos
- Traspaso claro de los requisitos detallados a diseño e ingeniería
- Deja un registro documental para contextos regulatorios o de cumplimiento
- Funciona bien cuando hay confianza en la solución y lo que se necesita es optimizar la ejecución
- Útil para coordinar equipos distribuidos que no pueden iterar en tiempo real
Fortalezas del Intent Contract
- Obliga a conversar sobre por qué algo importa antes de construirlo
- Delimita explícitamente el alcance y declara lo que queda fuera
- Incluye métricas de éxito y criterios de cancelación desde el inicio, no como una idea de último momento
- Sigue siendo relevante durante todo el desarrollo porque evoluciona con lo aprendido
- Cambia la pregunta de responsabilidad de "¿entregamos?" a "¿funcionó?"
- Es más rápido de redactar, más fácil de comunicar y menos propenso a convertirse en un documento obsoleto
Cuándo usar cada uno
Use un PRD cuando:
- Trabaja en una industria regulada (finanzas, salud, gobierno) donde se exige una documentación a fondo
- Tiene equipos grandes y distribuidos que necesitan una coordinación detallada entre áreas
- Su producto tiene integraciones complejas o dependencias entre varios equipos
- Las partes interesadas necesitan una referencia detallada de funcionalidades antes del desarrollo
- Está construyendo un producto maduro en un mercado conocido, donde la solución está prácticamente definida
Use un Intent Contract cuando:
- Está construyendo algo nuevo y el comportamiento de los usuarios es incierto
- La velocidad importa más que una especificación exhaustiva
- Trabaja con un socio especializado en ingeniería de producto que asume la responsabilidad por los resultados
- El crecimiento descontrolado del alcance es su mayor riesgo
- Su equipo avanza rápido y aprende construyendo e iterando
- Necesita saber no solo qué construir, sino por qué y cómo medirlo
¿Pueden coexistir?
Sí. Un Intent Contract y un PRD no se excluyen mutuamente.
De hecho, un Intent Contract sólido suele preceder a un PRD detallado. Redacte primero el Intent Contract para establecer la claridad sobre el resultado, los límites del alcance y las métricas de éxito. Si necesita una especificación detallada por razones regulatorias, de coordinación o de complejidad, el PRD que siga partirá de las restricciones del Intent Contract. El PRD se convierte en un documento sobre el cómo, no en un sustituto de pensar en resultados.
Muchos equipos descubren que un Intent Contract sólido vuelve innecesario el PRD. Una vez respondidas las preguntas difíciles sobre el resultado y el alcance, los ingenieros y los diseñadores pueden trabajar con especificaciones menos formales. Pero en entornos complejos, con varios equipos, tener ambas herramientas puede funcionar bien.
Preguntas frecuentes
¿Qué tan detallado debe ser un Intent Contract en cuanto a requisitos técnicos?
Un Intent Contract recoge las restricciones técnicas y las dependencias, como "necesitamos integrarnos con Stripe", "debemos ejecutarnos en Cloudflare Workers" o "no podemos escalar más allá de 100k usuarios mensuales". Pero no especifica qué base de datos, framework o patrón de arquitectura usar. Esas son decisiones de ingeniería. El Intent Contract fija los límites; el equipo completa los detalles.
¿Y si todavía no sabemos qué significa el éxito?
Entonces no está listo para empezar el desarrollo. Justamente para eso sirve un Intent Contract. El proceso de redactarlo obliga a tener esa conversación. Quizá descubra que el éxito significa un aumento de 30% en la interacción de los usuarios, una reducción de 50% en los tickets de soporte o alcanzar la rentabilidad en 18 meses. Hasta que lo defina, el Intent Contract queda incompleto. Eso es valioso: evita que construya lo que no es.
¿Quién es responsable del Intent Contract y quién del PRD?
En el Intent Contract, la responsabilidad es compartida. El líder de producto lo impulsa, pero el equipo de ingeniería y las partes interesadas deben ponerse de acuerdo sobre él antes de empezar el trabajo. En el PRD, normalmente el responsable es un gerente de producto, con aportes de ingeniería. La diferencia es que un Intent Contract es un documento de colaboración; un PRD suele ser un documento de especificación que se entrega a otros.
¿Con qué frecuencia debe actualizarse un Intent Contract?
Cada semana o después de un aprendizaje importante. Si el comportamiento de los usuarios difiere de lo esperado o cambia un supuesto técnico, se actualiza. Los cambios sustanciales se acuerdan y se aprueban de nuevo. Un Intent Contract es un documento vivo. Un PRD normalmente se redacta una vez, se aprueba y se trata como algo fijo, aunque el mundo cambie a su alrededor.
¿Puede un Intent Contract reemplazar todos los PRD?
No del todo. Para integraciones muy complejas, industrias reguladas o equipos de grandes empresas, algunas organizaciones agregan un PRD técnico que complementa el Intent Contract. Pero en el trabajo de producto donde se busca maximizar la velocidad y la claridad sobre el resultado, un Intent Contract suele ser suficiente.
¿Qué relación hay entre un Intent Contract y un Decision Record?
Son documentos distintos. Un Intent Contract fija el resultado y los límites del alcance. Un Decision Record documenta cómo resolvió el equipo de ingeniería problemas técnicos específicos dentro de esos límites. Ambos importan, pero cumplen propósitos distintos. El Intent Contract responde "¿qué buscamos resolver?". Un Decision Record responde "¿cómo decidimos construir esta pieza específica?".
En resumen
Un PRD es una herramienta de especificación. Un Intent Contract es una herramienta de alineación. Los PRD funcionan cuando se necesita una especificación detallada y coordinación entre varios equipos. Los Intent Contracts funcionan cuando se necesita claridad sobre el resultado y disciplina en el alcance.
En el desarrollo de productos que avanza rápido, el equipo que responde "¿por qué importa esto?" antes de "¿qué debemos construir?" suele ganar. Que use un PRD, un Intent Contract o ambos depende de su contexto. Pero no se salte la conversación. Demasiados equipos pasan directo a las funcionalidades sin articular el resultado que buscan, y ahí es donde las cosas salen mal.
Cuéntenos qué es lo que se interpone.
Dígale a nuestro agente de IA qué quiere mejorar. Le ayudaremos a encontrar un primer paso útil.