¿Empezar por un PRD o por un prototipo? Una guía para definir productos con IA

El artículo de Ravi Mehta parte de un cambio práctico: con las herramientas de IA, crear un prototipo funcional puede llevar menos tiempo que redactar un PRD (documento de requisitos de producto) bien pensado. Eso reabre una pregunta clásica: ¿qué va primero? Su respuesta es que no se empieza por ninguno de los dos, sino por la decisión de producto que hay que tomar. Después se elige el artefacto que dé más claridad sobre esa decisión.

Según el autor, si todavía estás eligiendo una dirección, conviene construir un prototipo de concepto, que da algo concreto desde donde empezar el PRD. A medida que la dirección se aclara, el PRD sirve para explicar por qué se construye, cómo se medirá el éxito y qué está dentro, fuera o aún sin decidir. El prototipo de diseño, por su parte, muestra exactamente qué está construyendo el equipo. Ambos no compiten: el PRD preserva el porqué y el prototipo hace tangible el qué. Los mejores equipos se mueven entre los dos a medida que aprenden.

El texto contrasta esto con el modelo antiguo y lineal: escribir el PRD, pasarlo a diseño, hacer una revisión de producto, pasarlo a ingeniería y lanzar. Cada etapa era cara, así que el trabajo avanzaba como una cadena de montaje. Esa restricción ha cambiado. Ahora PRD y prototipos pueden evolucionar juntos en un bucle de aprendizaje: la retroalimentación puede cambiar el motivo de construir, los objetivos o las métricas, y llevar a un nuevo prototipo que explore otro concepto o profundice en el actual. Cada artefacto afina al otro hasta que el feedback justifique el lanzamiento.

Sobre qué pertenece a cada uno, el autor propone una división sencilla. El PRD recoge el problema del cliente, por qué importa, el resultado deseado, cómo se medirá el éxito, cómo se llevará a cabo, el alcance, lo que queda por decidir, dónde encontrarán el producto los clientes y cómo se impulsará su adopción. El prototipo aclara la experiencia y el flujo, el comportamiento del producto, lo que ven y hacen los usuarios, cómo se sienten las interacciones, cómo encajan las piezas y si la experiencia resulta creíble. Un prototipo, por pulido que esté, responde solo a una parte de la pregunta de producto; un PRD, en cambio, deja margen a la interpretación, porque dos personas pueden leer el mismo párrafo e imaginar productos distintos. El prototipo crea un objeto compartido sobre el que pueden reaccionar clientes, interesados, diseñadores e ingenieros.

¿Puede un prototipo reemplazar a un PRD? Normalmente no. Puede sustituir las partes del PRD que describen con esfuerzo la interfaz o la interacción, pero no el porqué debe existir el producto, cómo se medirá el éxito ni lo que está dentro, fuera o pendiente. Esto importa más cuando una IA construye a partir de los artefactos: un prototipo convincente puede esconder cientos de pequeñas decisiones que el modelo tomó por su cuenta, algunas sensatas y otras contrarias a lo aprendido con los clientes. El objetivo, dice el autor, no es producir más documentación, sino hacer visibles las decisiones intencionadas y fáciles de identificar las decisiones incidentales de la IA.

Como ejemplo, el autor cuenta que en su etapa en TripAdvisor vio uno de los mejores PRDs, que definía un producto complejo de planificación de viajes. Un equipo multifuncional dedicó unas seis semanas a la misión, la investigación y los wireframes. Una suposición inicial trataba la planificación como una actividad individual, pero la investigación mostró que debía soportar a varios viajeros desde el principio. Años después, introdujo ese material, con algo de contexto adicional, en Magic Patterns y le pidió inferir un sistema de diseño a partir del sitio de TripAdvisor. En unos 20 minutos obtuvo un prototipo funcional, en el que podía abrir lugares, ver conversaciones, quitar un elemento de un viaje, revisar guardados sin programar y recorrer cada día en un mapa. El prototipo comunicaba la experiencia mejor que el documento solo, pero también tomó decisiones no aprobadas: quitar un elemento no pedía confirmación, no estaba claro qué ocurría con la conversación asociada a un lugar eliminado y algunos datos y detalles de diseño eran incorrectos. La velocidad, concluye, no convierte las decisiones generadas en intención de producto.

El artículo presenta después cuatro tipos de prototipo, cada uno ligado a una decisión. El prototipo de concepto responde a qué dirección seguir: se usa cuando se entiende el problema pero no se ha elegido solución, y su meta no es el pulido sino decidir hacia dónde ir. El prototipo de diseño responde a qué se construye exactamente: define la experiencia prevista con mayor fidelidad, trabaja junto al PRD y debe servir de plano para el equipo de entrega. El prototipo de investigación responde a si los clientes lo querrán y usarán: debe ser lo bastante creíble para que la gente reaccione como si fuera real, por lo que importan el texto, las imágenes y los datos; si esos detalles rompen la ilusión, se acaba probando la calidad del prototipo y no el valor de la idea. El prototipo técnico responde a si es posible: pone a prueba la viabilidad, algo especialmente importante en funciones de IA (¿se pueden afinar los prompts?, ¿puede el modelo hacer lo necesario?), y puede que nunca se muestre a un cliente. Antes de crear cualquier prototipo, plantea una pregunta: ¿qué decisión nos ayudará a tomar? Si no hay respuesta clara, no hay que construirlo todavía, porque los prototipos baratos sin decisión detrás generan ruido, no claridad.

Para usar PRD y prototipo como bucle de aprendizaje propone estos pasos: identificar la pregunta clave sin respuesta, elegir el artefacto que pueda responderla, ponerlo ante las personas adecuadas, registrar lo aprendido, lo que cambió y lo que sigue sin decidir, actualizar el PRD, el prototipo o ambos, y repetir hasta tener suficiente convicción para construir. La secuencia no es universal; la disciplina sí: en cada etapa el equipo debe saber qué pregunta responde, qué decisiones están cerradas y qué supuestos aún necesitan evidencia.

El autor advierte también de una "Feature Factory 2.0". La antigua fábrica de funcionalidades estaba limitada por el coste de construir, y la inversión de meses generaba presión por lanzar lo construido (coste hundido). La IA elimina gran parte de ese límite y un equipo puede generar más conceptos y prototipos funcionales de los que los clientes pueden absorber. Su propuesta es añadir un paso explícito de curación: tras crear y probar algo, preguntarse si es digno de la atención del cliente, y convertirlo en una decisión formal antes de producción o lanzamiento. Lo compara con un fotógrafo que no publica todos sus fotogramas o un director que no estrena todas sus escenas: crear de forma amplia, aprender rápido, descartar sin miedo y lanzar solo lo mejor.

Finalmente, aborda cómo evitar un PRD de 30 páginas escrito por IA. Un documento así puede aparecer en un minuto, pero la cuestión es si quien lo generó lo leyó entero, entendió cada decisión y estuvo de acuerdo con cada supuesto. Su proceso es deliberadamente más acotado: escribir él mismo el prompt inicial (a veces dedica de 30 minutos a una hora, porque cada palabra representa una decisión y no un supuesto introducido en silencio por la IA); pedir divergencia antes de convergencia, es decir, cuatro o cinco enfoques realmente distintos para comparar y elegir; dar feedback minucioso, ya que una palabra de copy o un dato puede revelar un malentendido mayor; hacer una pasada humana sobre los textos, porque el copy generado por IA suena completo pero suele ser genérico o ligeramente erróneo; minimizar capas de supuestos (herramientas, plantillas y habilidades añaden los suyos); y leer el resultado completo, sin generar un PRD largo, resumirlo con otra IA y dar por hecho que la intención sobrevivió. Cuenta que lo aprendió al construir un producto de autoevaluación: pidió a la IA convertir poco contexto en un PRD de unas 20 páginas, aparentemente impresionante, pero al leerlo con detalle encontró supuestos que nunca hizo y funciones que nunca eligió. Volvió a empezar y dedicó una hora a escribir el prompt él mismo.

Como guía práctica final: si no sabes qué solución seguir, un prototipo de concepto; si necesitas aclarar el porqué, la medición del éxito o lo que está dentro, fuera o sin decidir, el PRD; si el equipo no logra imaginar la experiencia, un prototipo de diseño; si necesitas evidencia de que los clientes lo valorarán, uno de investigación; si dudas de que la tecnología lo permita, uno técnico; si tienes demasiados artefactos, sintetizarlos en una definición concisa, coherente y ejecutable; y si ya tienes algo funcionando, curar antes de lanzar. La conclusión del autor es que la velocidad de construir ha cambiado, pero lo difícil no: decidir qué quiere el cliente, qué merece existir y qué nivel de calidad debe alcanzar el producto.

Nota sobre el material: el artículo escrito es gratuito y completo. La grabación del taller (con secciones sobre contexto, métricas cuando los story points dejan de servir, o el turno de preguntas) y las diapositivas en PDF quedan reservadas a miembros de pago del Top 1% Builder Club, por lo que este resumen se basa solo en la guía escrita.