20 prompts para product manager que muestran los trade-offs

01. Escribe un PRD a partir de un brief desordenado y lista las preguntas abiertas

Tienes un hilo de Slack, una nota de llamada y una fecha límite, pero ninguna especificación.

Convierte este brief desordenado en un documento de requisitos de producto.

[pega el brief, el hilo, las notas de la llamada o lo que tengas]

Secciones, en este orden: el problema y quién lo tiene, la evidencia que tenemos, el objetivo con un resultado medible, qué entra en el alcance, qué queda fuera, el flujo del usuario en pasos numerados, requisitos marcados como MUST o SHOULD, y dependencias de otros equipos.

Usa solo lo que dice el brief. Donde no diga nada, escribe [ABIERTO: la pregunta] en lugar de rellenarlo.

Luego lista al final todas las preguntas abiertas, agrupadas por quién puede responderlas (yo, diseño, ingeniería, legal, un cliente), con las tres que bloquean el desarrollo primero.

02. Divide una funcionalidad en historias de usuario con criterios de aceptación

La refinación es mañana y la funcionalidad sigue siendo un único ticket enorme.

Divide esta funcionalidad en historias de usuario que un equipo pueda construir y entregar una por una.

Funcionalidad: [qué hace]
Usuarios: [quién la usa y qué intenta conseguir]
Restricciones: [plataformas, plazos, cosas ya construidas]

Para cada historia:
1. Como [usuario], quiero [acción], para [resultado].
2. Criterios de aceptación en formato Dado / Cuando / Entonces, de tres a seis por historia, cada uno verificable por alguien que no la escribió.
3. Una estimación de tamaño S, M o L y lo único que la hace incierta.

Ordena las historias de modo que la primera entregue algo que un usuario real pueda usar, aunque sea pequeño. Señala cualquier historia que en realidad sean dos, y cualquiera que solo tenga sentido cuando se entregue otra.

03. Encuentra los casos límite que tu PRD pasó por alto

La especificación parece terminada e ingeniería empieza la semana que viene.

Lee este PRD como el ingeniero que recibirá los reportes de errores después del lanzamiento.

[pega el PRD o la especificación]

Lista los casos límite que no cubre, agrupados en: estados vacíos y de primera vez, errores y tiempos de espera, permisos y roles, límites (muy largo, muy numeroso, cero, duplicado), concurrencia (dos personas editando, doble clic, reintentos), datos anteriores a que existiera esta funcionalidad y accesibilidad.

Para cada uno: el escenario en una línea, lo que la especificación implica hoy que ocurriría y la pregunta que tengo que responder. Ordena los cinco primeros según la probabilidad de que un usuario real los encuentre en el primer mes. No inventes requisitos: pregunta.

Desbloquea gratis los otros 17 prompts

Suscríbete al boletín de Whizi para leer el resto de este pack.

4. Puntúa un backlog con RICE y muestra los cálculos
5. Convierte notas de entrevistas en trabajos, dolores y citas
6. Escribe una guía de entrevista de descubrimiento sobre lo que la gente hizo, no lo que quiere
7. Agrupa tickets de soporte en problemas de producto que merecen arreglo
8. Escribe una especificación de una página con la que los ingenieros puedan construir
9. Elige una métrica de éxito y la contrametrica que la mantiene honesta
10. Diseña un experimento y responde primero a las preguntas de tamaño de muestra
11. Crea una checklist de lanzamiento con un responsable por cada equipo
12. Escribe notas de versión que los usuarios sí lean
13. Escribe una actualización para stakeholders que empiece por lo que cambió
14. Escribe una narrativa de roadmap que diga lo que no vas a hacer
15. Rechaza una petición de funcionalidad con el motivo y un siguiente paso
16. Haz un pre-mortem antes de que salga el lanzamiento
17. Desmonta la página de producto de un competidor afirmación por afirmación
18. Escribe un único objetivo de sprint a partir de una larga lista de tickets
19. Convierte una solución pedida en el problema que hay detrás
20. Pide a un segundo modelo que revise el PRD del primero