Esta mañana abriste una página de Notion titulada "PRD: [nombre de la feature]". Tres horas después, sigue diciendo "PRD: [nombre de la feature]".
Conoces el problema. Conoces la solución. Ayer se lo explicaste dos veces a tu tech lead. Pero en cuanto te sientas a redactarlo, te bloqueas.
Esto no es un problema de pensar. Es un problema de teclear.
A los PMs no les pagan por teclear. Te pagan por decidir qué construir y por qué. El PRD es solo el artefacto que recoge esa decisión para que ingeniería, diseño y dirección puedan actuar sobre ella. En algún punto entre saber qué escribir y terminar el documento, se evaporan las horas.
Hay un camino más rápido. El PRD es uno de los documentos más "hablables" que escribe un PM. En el fondo es lo que dirías delante de una pizarra explicando la feature. Cuando dejas de teclear PRDs y empiezas a dictarlos, el tiempo de redacción cae en picado.
El impuesto de escritura del PM del que nadie habla
Cada PRD que escribes compite con una reunión, una revisión de roadmap o un hilo de Slack con stakeholders. La escritura real ocurre en ventanas robadas de media hora o después de cenar.
Las cuentas son demoledoras. Una persona media teclea a unas 40 palabras por minuto. Y habla a unas 150. Eso son aproximadamente 3,5 veces más rápido, antes de contar la fricción que hace que escribir cueste: borrar, reformular, dudar de una frase tres veces antes de seguir.
Un PRD de 1.500 palabras que tardas 90 minutos en teclear te lleva unos 25 minutos hablado. El pensamiento es el mismo. El resultado es el mismo. Solo cambia el mecanismo.
Por qué los PRDs encajan a la perfección con la voz
La mayoría de documentos castigan al dictado porque exigen precisión: código, tablas, modelos financieros. Los PRDs son justo lo contrario. Son documentos narrativos.
Piensa en el último PRD que escribiste. La sección de "Problema" son dos párrafos explicando por qué algo importa. La de "Solución" describe cómo funciona la cosa. Las "User stories" son frases con el formato "Como X, quiero Y, para que Z". La sección de "Casos límite" es una lista de escenarios del tipo "qué pasa cuando...".
Nada de eso requiere precisión de teclado. Todo es del tipo de cosa que dirías en una reunión. El formato ya coincide con la manera en que un PM comunica el trabajo en la vida real.
El flujo para redactar un PRD en 30 minutos
Esta es la estructura que funciona: 1. Abre un documento en blanco con los encabezados de sección ya en su sitio: problema, solución, user stories, criterios de aceptación, casos límite, fuera de alcance y preguntas abiertas. 2. Ve sección a sección. Dicta cada una como si se la estuvieras explicando a un ingeniero que acaba de entrar en el equipo. 3. No edites mientras hablas. El salto mental entre "hablante" y "editor" es lo que más te frena. 4. Cuando hayas dictado todas las secciones, lee el borrador entero una vez, de arriba abajo. Ajusta el lenguaje. Corrige lo que esté realmente mal. 5. Mándalo a revisión.
La disciplina está en el paso tres. Si te paras a arreglar frases cada dos por tres, no aprovechas la ventaja de velocidad. Vuelves a la velocidad de teclado con otro disfraz.
Sección a sección: cómo dictar cada parte de un PRD
Algunas secciones son más fáciles de dictar que otras. Así puedes afrontar cada una.
Planteamiento del problema
Esta es la sección más fácil de dictar. Pura narrativa. Estás explicando qué está roto, a quién le afecta y por qué importa ahora.
Háblalo como si pusieras al día a un compañero nuevo en la daily. Menciona el segmento de usuario, la fricción que sufre y la métrica que toca. No te preocupes por la elegancia de la prosa. Eso es trabajo de la edición.
Visión general de la solución
Recorre la solución propuesta como si la estuvieras dibujando en una pizarra. "El usuario pulsa aquí, ve esto, y entonces...". La voz lo maneja con soltura porque encaja con la manera en que ya lo explicarías de palabra.
User stories
Las user stories suenan mecánicas por el patrón "Como X, quiero Y, para que Z", pero se dictan bien si te comprometes con el formato. Di cada historia como una sola frase y pasa a la siguiente.
Si tienes diez historias, dicta las diez de una pasada. No las numeres sobre la marcha. Deja que el editor del documento o tu pasada de limpieza con IA se encargue del formato.
Criterios de aceptación
Las listas son la parte más delicada del dictado por voz, pero se pueden manejar. Dos opciones:
La primera es dictar los criterios como frases completas y dejar que la IA los convierta en una lista al pulirlos. Di algo como: "El usuario debe poder filtrar los resultados por fecha, por usuario y por estado. El estado del filtro debe persistir entre sesiones. El estado vacío debe mostrar un consejo".
La segunda es marcar explícitamente la estructura de viñetas: "Punto uno, filtrar por fecha. Punto dos, filtrar por usuario. Punto tres, persistir entre sesiones". Quédate con la que te resulte menos forzada en la boca.
Casos límite
Aquí es donde la voz brilla de verdad. Los casos límite son ese tipo de contenido de "pensar en voz alta" que sale limpio cuando hablas y torpe cuando lo tecleas. Preguntas como "qué pasa si el usuario está sin conexión" o "y los casos en los que los datos están desactualizados" fluyen mucho mejor habladas que escritas.
Dicta todos los casos límite que se te ocurran, incluso los que parezcan obvios. Ya podarás en la edición.
Fuera de alcance
Tres frases. Cuatro como mucho. La voz se lo come en menos de un minuto.
Preguntas abiertas
Esta sección está infravalorada. La mayoría de PMs se la saltan porque no quieren parecer inseguros. Error. Es donde ingeniería, diseño y tu skip-level cazan las cosas que aún no has pensado del todo.
La voz es la herramienta adecuada para esto. Las preguntas abiertas son justo esos pensamientos a medio cuajar que salen bien cuando los hablas y se vuelven extrañamente pesados cuando intentas teclearlos. Dicta cada duda en voz alta, incluso las que sospechas que tienen una respuesta obvia. La mitad se resolverán en la próxima daily. La otra mitad te salvarán el lanzamiento.
Adaptar el tono a cada sección
Un PRD no se escribe con una sola voz. El resumen ejecutivo de arriba debe ser conciso y estratégico. Las especificaciones técnicas deben ser precisas. La sección de "preguntas abiertas" puede ser más informal.
Cuando dictas, cambias de registro de forma natural. Tu voz se pone formal al hablar de estrategia y se relaja al recorrer los casos límite. El problema es que la mayoría de herramientas de dictado escupen la misma transcripción plana sin importar el contexto.
Aquí entran en juego las Smart Rules de Voicr. Puedes configurar un estilo de "especificación profesional y limpia" para tu editor de documentos, un estilo de "brainstorming informal" para tus hilos de Slack y otro de "claridad técnica" para la wiki de ingeniería. Voicr detecta la app activa y aplica el estilo correcto de forma automática, así que el mismo pensamiento hablado aterriza de manera distinta según dónde acabe.
Para los PRDs en concreto, configura una regla que pida prosa profesional y limpia, elimine muletillas y estructure listas con viñetas cuando las marcas. Hablas una vez. El documento se lee como si lo hubieras escrito con calma.
Dónde la voz no ayuda
Seamos honestos: no todas las partes de un PRD se benefician de la voz.
Las tablas y matrices siguen siendo más rápidas tecleadas. Si tu PRD incluye una rejilla de comparación de features, una matriz de permisos o una tabla de estimaciones, escríbelas.
Las cadenas técnicas exactas también van más rápido tecleadas. Nombres de endpoints de API, nombres de columnas de base de datos, números de versión: puedes dictarlos a base de rodeos ("el endpoint es, barra, users, barra, ID"), pero queda forzado. Esos, tecléalos.
Los diagramas, evidentemente, no se pueden dictar. Dibújalos en la herramienta que prefieras e insértalos.
Para todo lo demás —narrativa, user stories, casos límite, decisiones, justificación— la voz gana en velocidad y, sobre todo, en que no te quedas atascado a media frase intentando fraseo perfecto.
El cambio de mentalidad: piensa en voz alta, edita después
La mayor ganancia al dictar PRDs no son las cuentas de palabras por minuto. Es que dejas de pulir mientras escribes.
Cuando tecleas, borras. Reescribes una frase dos veces. Te quedas mirando un párrafo "casi bien" durante diez minutos. Ahí es donde mueren los PRDs: en el limbo entre redactar y editar, donde no ocurre ninguna de las dos cosas del todo.
Cuando dictas, te comprometes. Dices una frase, aterriza en la página y sigues. La primera pasada es más sucia que lo que tecleas. Pero terminas el borrador. Y un borrador sucio pero terminado es muchísimo más útil que uno pulido a medias.
Una vez existe el borrador, editar es una actividad muy distinta y bastante más rápida. A menudo dedicarás más tiempo a refinar que a dictar, y está bien. Pulir un documento completo es un trabajo conocido. Quedarse mirando uno en blanco, no.
Pruébalo en tu próximo PRD
Elige un PRD que llevas posponiendo. Abre el documento, coloca los encabezados de sección y dicta de arriba abajo sin editar. Pon un temporizador de 25 minutos. A ver qué sale.
La primera vez te resultará raro. Te preocupará que el resultado no sea lo bastante bueno. Resiste el impulso de arreglar cosas a mitad. Solo termina.
Si quieres que el dictado salga tan limpio que apenas tengas que editar, Voicr se encarga del pulido por ti. Mantén pulsado FN desde cualquier parte de tu Mac, habla durante una sección, suelta y pega el texto ya limpio en tu documento. Quita muletillas, arregla la gramática y estructura tus ideas antes de que lleguen al portapapeles. El borrador de PRD que antes te ocupaba una tarde ahora cabe en una sentada.
Tus PRDs no se van a escribir solos. Pero tampoco tienen por qué teclearse.