Cómo redactar un PRD a partir de una petición de función de una sola línea
6 min de lectura
La mayoría de los PRD empiezan igual: un documento en blanco y una idea de una línea como "dejar que los usuarios exporten sus datos". A partir de ahí es fácil escribir libremente lo primero que viene a la mente, usualmente los requisitos, y darse cuenta tres párrafos después de que no hay un planteamiento del problema ni una métrica de éxito en ninguna parte del documento. Un PM entusiasmado con una idea de función tiende a empezar escribiendo la mecánica de cómo debería funcionar, los campos exactos, la ubicación exacta del botón, mucho antes de detenerse a escribir qué problema resuelve en realidad.
Advertencia
Un documento en blanco no te recuerda qué secciones necesita un PRD. Solo refleja de vuelta el orden en que se te ocurrieron las cosas, que rara vez es el orden en que un revisor espera leerlas.
Una idea de función es una frase. Un PRD es una estructura. Escribir libremente te da la frase, expandida.
Por qué escribir libremente omite secciones sin que lo notes
Escribir desde una página en blanco significa que vas inventando la estructura sobre la marcha, y es fácil escribir las partes que se sienten obvias, usualmente los requisitos, mientras se omiten las partes que exigen más reflexión, como nombrar el problema real o elegir una métrica que demuestre que la función funcionó. La sección de requisitos es concreta y satisfactoria de escribir, porque es una lista de cosas específicas y verificables. El planteamiento del problema exige dar un paso atrás y articular por qué importa cualquiera de esas cosas, que es un tipo de pensamiento distinto y más difícil, y es la parte que se omite primero bajo presión de tiempo.
Toma una idea de una línea como "dejar que los usuarios exporten sus datos como CSV". Un PM entusiasmado con la idea podría pasar veinte minutos detallando exactamente qué campos debería incluir la exportación y qué debería decir el botón, y solo darse cuenta al enviar el documento a revisión de que no hay ninguna frase que explique por qué importa esto, que soporte lleva meses recibiendo solicitudes manuales de exportación. Un revisor que abre ese documento no tiene forma de juzgar si los requisitos propuestos resuelven el problema real, porque el problema real nunca quedó escrito.
Antes: abrir un documento en blanco, empezar a escribir los requisitos de la idea de función, darse cuenta después de que faltan el planteamiento del problema y las métricas de éxito.
Después: darle a Claude la idea de una línea y el problema que resuelve, y recibir un primer borrador estructurado, problema, objetivos, requisitos y métricas, con cada sección ya en su lugar para refinar.
Un proceso para un primer borrador estructurado
- 1
Plantea la idea de función y el problema que resuelve
Una frase para cada una basta para empezar. "Dejar que los usuarios exporten sus datos como CSV, porque soporte sigue recibiendo esa solicitud de forma manual" le da a Claude tanto el qué como el por qué.
- 2
Pide una estructura fija, no un borrador abierto
Pide específicamente un planteamiento del problema, un número reducido de objetivos, requisitos funcionales y métricas de éxito, en ese orden. Una estructura fija es lo que hace que el borrador sea revisable en vez de un ensayo.
- 3
Da un número real para objetivos y métricas
Pide una cantidad específica, tres objetivos, dos métricas, en lugar de "algunos objetivos". Un número obliga a priorizar en vez de una lista abierta que sigue creciendo.
- 4
Trata el borrador como una estructura de partida, no un documento final
Relee cada sección y reescríbela con tu propia voz. El valor del primer borrador es que no falta nada, no que la redacción sea definitiva.
Queremos dejar que los usuarios exporten sus datos como CSV. Redacta un PRD de una página con un planteamiento del problema, tres objetivos, requisitos funcionales y dos métricas de éxito que podamos rastrear en los primeros 30 días.
”Si la idea de función surgió de una fuente específica y conocida, un conjunto de tickets de soporte, una petición de cliente, un vacío competitivo, vale la pena decírselo explícitamente a Claude, ya que un planteamiento del problema basado en una fuente real y nombrada se lee como mucho más creíble para un revisor que uno plausible pero genérico.
Esta idea surgió directamente de 15 tickets de soporte durante el último mes, todos pidiendo una forma de sacar sus datos sin contactar a soporte. Reescribe el planteamiento del problema para referirse a esa fuente real específicamente, no a una descripción genérica de la necesidad.
”
Dentro de Claude Tutorial
Partir de una estructura fija en lugar de una página en blanco es transferible.
Trabajar desde un conjunto conocido de secciones, en lugar de inventar la estructura mientras escribes, aplica mucho más allá de los PRD. La app tiene una lección completa sobre esto, con práctica que se traslada a cualquier documento con una forma que los revisores ya esperan.
Cuando los objetivos no coinciden con las métricas
Un vacío común en un primer borrador es un objetivo sin una métrica asociada, o una métrica que en realidad no demuestra que el objetivo declarado ocurrió. Ese desajuste vale la pena detectarlo antes de que el documento salga, no después de que alguien pregunte cómo sabrás que la función funcionó. Un objetivo como "reducir la carga de soporte" emparejado con una métrica como "número de exportaciones realizadas" suena relacionado pero no demuestra realmente el objetivo, porque los usuarios podrían exportar datos todo el tiempo sin evitar un solo ticket de soporte.
Consejo
Pide a Claude que revise cada objetivo contra su métrica directamente: ¿alcanzar este número realmente demuestra el objetivo, o solo algo correlacionado con él? Una métrica fácil de medir no es automáticamente la correcta.
Aquí están los tres objetivos y las dos métricas de este borrador de PRD. Para cada objetivo, dime con honestidad si las métricas realmente demuestran que ocurrió, o si solo miden algo adyacente a él.
”Si una métrica resulta genuinamente difícil de rastrear con las herramientas actuales, vale la pena señalar esa limitación desde temprano en lugar de lanzar un PRD con una métrica de éxito que nadie puede medir en realidad una vez que la función esté en vivo.
Una de estas métricas requeriría un rastreo que no tenemos actualmente implementado. Sugiere una métrica que demuestre el mismo objetivo pero que sea realista de medir con nuestra configuración de analítica existente.
”Sigue leyendo
- Afina un PRD antes de enviarlo a revisión: poner a prueba el borrador estructurado que produce este artículo antes de que llegue a un revisor.
- Escribe un documento de roadmap que explique las decisiones de prioridad: qué pasa una vez que esta idea de función tiene que competir con otras por un lugar en el roadmap.
- Convierte tickets de soporte en temas priorizados: una fuente de ideas de función reales para redactar PRD desde el inicio.