Commencez pour 0,99 $

20 prompts de product manager qui montrent les compromis

L'IA rédige un PRD sûr de lui en quelques secondes en inventant l'utilisateur, les données et le périmètre. Ces prompts la font travailler à partir de ton brief, de tes notes et de tes chiffres, montrer ses calculs et lister les questions ouvertes avant que l'ingénierie ne démarre.

Remplace tout ce qui est entre [crochets] par ton brief, tes notes, tes tickets ou tes chiffres.

01. Rédiger un PRD à partir d'un brief brouillon et lister les questions ouvertes

Tu as un fil Slack, une note d'appel et une échéance, mais aucune spec.

Transforme ce brief brouillon en document d'exigences produit (PRD).

[colle le brief, le fil, les notes d'appel ou ce que tu as]

Sections, dans cet ordre : le problème et qui le rencontre, les preuves que nous en avons, l'objectif avec un résultat mesurable, ce qui est dans le périmètre, ce qui est hors périmètre, le parcours utilisateur en étapes numérotées, les exigences marquées MUST ou SHOULD, et les dépendances avec d'autres équipes.

Utilise uniquement ce que dit le brief. Là où il est muet, écris [OPEN : la question] au lieu de combler le vide.

Termine par la liste de toutes les questions ouvertes, regroupées selon qui peut y répondre (moi, le design, l'ingénierie, le juridique, un client), avec en premier les trois qui bloquent le développement.

02. Découper une fonctionnalité en user stories avec critères d'acceptation

L'affinage du backlog est demain et la fonctionnalité tient encore dans un seul gros ticket.

Découpe cette fonctionnalité en user stories qu'une équipe peut construire et livrer une par une.

Fonctionnalité : [ce qu'elle fait]
Utilisateurs : [qui l'utilise et ce qu'il cherche à accomplir]
Contraintes : [plateformes, échéances, éléments déjà construits]

Pour chaque story :
1. En tant que [utilisateur], je veux [action], afin de [résultat].
2. Des critères d'acceptation au format Given / When / Then, trois à six par story, chacun testable par quelqu'un qui ne l'a pas écrit.
3. Une estimation de taille S, M ou L et l'élément qui la rend incertaine.

Ordonne les stories pour que la première livre quelque chose qu'un vrai utilisateur peut utiliser, même si c'est petit. Signale toute story qui est en réalité deux stories, et toute story qui n'a de sens qu'une fois une autre livrée.

03. Trouver les cas limites que ton PRD a oubliés

La spec semble terminée et l'ingénierie démarre la semaine prochaine.

Lis ce PRD comme l'ingénieur qui recevra les rapports de bugs après le lancement.

[colle le PRD ou la spec]

Liste les cas limites qu'il ne couvre pas, regroupés ainsi : états vides et première utilisation, erreurs et délais dépassés, permissions et rôles, limites (très long, très nombreux, zéro, doublon), concurrence (deux personnes qui éditent, doubles clics, nouvelles tentatives), données antérieures à cette fonctionnalité, et accessibilité.

Pour chacun : le scénario en une ligne, ce que la spec laisse actuellement entendre qu'il se passerait, et la question à laquelle je dois répondre. Classe les cinq premiers selon la probabilité qu'un vrai utilisateur les rencontre dans le premier mois. N'invente pas d'exigences : pose des questions.

Débloque gratuitement les 17 autres prompts

Inscris-toi à la newsletter de Whizi pour lire la suite de ce pack.

  1. Noter un backlog avec RICE et montrer le calcul
  2. Transformer des notes d'entretien en jobs, irritants et verbatims
  3. Rédiger un guide d'entretien de discovery sur ce que les gens ont fait, pas sur ce qu'ils veulent
  4. Regrouper les tickets support en problèmes produit qui méritent d'être corrigés
  5. Rédiger une spec d'une page à partir de laquelle les ingénieurs peuvent construire
  6. Choisir une métrique de succès et la contre-métrique qui la garde honnête
  7. Concevoir une expérience en répondant d'abord aux questions de taille d'échantillon
  8. Construire une checklist de lancement avec un responsable pour chaque équipe
  9. Rédiger des notes de version que les utilisateurs lisent vraiment
  10. Rédiger un point d'avancement pour les parties prenantes qui commence par ce qui a changé
  11. Rédiger un récit de roadmap qui dit ce que tu ne fais pas
  12. Refuser une demande de fonctionnalité avec la raison et une suite
  13. Faire un pre-mortem avant que le lancement ne parte
  14. Décortiquer la page produit d'un concurrent, affirmation par affirmation
  15. Écrire un seul objectif de sprint à partir d'une longue liste de tickets
  16. Remonter d'une solution demandée au problème qui se cache derrière
  17. Faire relire le PRD du premier modèle par un second modèle