Claude pour les Product Managers : Roadmap, Specs et User Research

Rédaction de PRDs (Product Requirements Documents)

Du Brief au PRD Complet

Rédige un PRD pour la feature suivante.

Brief :
- Problème : [2-3 phrases décrivant le problème utilisateur]
- Audience : [persona principale + volume estimé]
- Contraintes : [budget, timeline, dépendances techniques]
- Métrique de succès : [KPI principal à impacter]

Structure du PRD :
1. Contexte et problème
2. Objectifs et métriques de succès (SMART)
3. Audience cible et personas
4. User stories (format "En tant que... je veux... pour...")
5. Spécifications fonctionnelles (comportement attendu, détaillé)
6. Spécifications non-fonctionnelles (performance, sécurité, accessibilité)
7. Edge cases et scénarios d'erreur
8. Design mockup requirements (description textuelle)
9. Dépendances techniques
10. Plan de rollout (phases, feature flags)
11. Out of scope (ce qui n'est PAS dans cette version)
12. Questions ouvertes

Sois exhaustif sur les edge cases — c'est souvent la partie manquante des PRDs.

Exemple : PRD pour une Feature de Notifications

Brief : Les utilisateurs se plaignent de manquer des mises à jour importantes sur leurs projets.
Audience : 15 000 utilisateurs actifs quotidiens, principalement des chefs de projet.
Contrainte : Livraison en 6 semaines, équipe de 3 développeurs.
Métrique : Augmenter le taux de rétention J7 de 45% à 55%.

Claude génère un PRD de 3-4 pages couvrant :

• →8 user stories avec critères d'acceptation
• →Matrice de notification (type × canal × fréquence)
• →Edge cases : fuseau horaire, mode ne pas déranger, double notification
• →Plan de rollout en 3 phases avec feature flags

Itérations avec les Stakeholders

Un avantage clé : vous pouvez itérer avec Claude dans la conversation.

Le CTO a des questions sur la section technique :
1. Comment gérer les notifications pour les utilisateurs avec 50+ projets ?
2. Quel impact sur la base de données ?
3. Peut-on utiliser des WebSockets au lieu de polling ?

Mets à jour la section "Spécifications non-fonctionnelles" et "Dépendances techniques" 
du PRD pour adresser ces questions.

User Stories

Génération Structurée

Génère les user stories pour la feature [nom].

Contexte : [résumé du PRD ou de la feature en 3-4 lignes]

Pour chaque story :
- Format : "En tant que [persona], je veux [action] pour [bénéfice]"
- Critères d'acceptation (3-5 par story, format Given/When/Then)
- Taille estimée (S/M/L/XL)
- Priorité (Must/Should/Could)
- Dépendances (si applicable)

Organise par epic, puis par priorité décroissante.

Refinement et Splitting

Cette user story est trop grosse (estimée XL par l'équipe) :
"En tant qu'admin, je veux gérer les permissions des utilisateurs"

Découpe-la en stories de taille S ou M maximum.
Chaque sous-story doit être :
- Indépendante (livrable seule)
- Testable (critères d'acceptation vérifiables)
- Valuable (apporte de la valeur utilisateur même sans les autres)

Propose un ordre de livraison logique.

Priorisation de Features

Framework RICE avec Claude

Voici ma liste de features candidates pour le prochain trimestre.

Pour chaque feature, j'ai estimé :
- Reach : nombre d'utilisateurs impactés
- Impact : faible (1), moyen (2), élevé (3)
- Confidence : % de certitude sur les estimations
- Effort : en semaines-dev

Features :
1. [Feature A] - Reach: 5000, Impact: 3, Confidence: 80%, Effort: 4 semaines
2. [Feature B] - Reach: 12000, Impact: 1, Confidence: 90%, Effort: 2 semaines
3. [Feature C] - Reach: 3000, Impact: 3, Confidence: 50%, Effort: 8 semaines
...

Calcule le score RICE pour chaque feature.
Produis un tableau classé + recommandation argumentée.
Identifie les dépendances entre features.
Propose un séquençage optimal sur 12 semaines.

Comparaison de Frameworks

J'ai 12 features. Applique le framework RICE ET MoSCoW en parallèle.
Compare les résultats et identifie les divergences.
Les divergences sont souvent les features qui méritent le plus de discussion.

[lister les features avec données]

Analyse Concurrentielle Produit

Feature Comparison Matrix

Je suis PM pour [mon produit].
Voici les pages features de 3 concurrents :
- Concurrent A : [coller ou résumer]
- Concurrent B : [coller ou résumer]
- Concurrent C : [coller ou résumer]

Produis :
1. Matrice de features (mon produit vs. A vs. B vs. C)
   ✅ = disponible, ⚠️ = partiel, ❌ = absent
2. Gaps critiques : features que TOUS les concurrents ont et que nous n'avons pas
3. Différenciateurs : features que NOUS seuls avons
4. Opportunités : features que personne n'a encore
5. Recommandations stratégiques (3 actions)

Analyse de Positionnement

Analyse le positionnement produit de ces 4 concurrents basé sur leur page d'accueil et pricing.

Pour chaque concurrent :
- Proposition de valeur principale (1 phrase)
- Audience cible
- Positionnement prix (low-cost, mid-market, premium)
- Forces perçues
- Faiblesses potentielles

Produis une carte de positionnement (2 axes) recommandée pour visualiser le paysage.
Suggère un positionnement différenciateur pour notre produit.

Synthèse de Recherche Utilisateur

Analyse d'Interviews

Voici les transcriptions de 15 interviews utilisateurs (30 min chacune).
Contexte : nous explorons les besoins autour de [thème].

Analyse :
1. Thèmes récurrents (classés par fréquence d'apparition)
2. Pain points majeurs (avec citations directes)
3. Besoins exprimés vs. besoins latents
4. Segments utilisateurs identifiés (si des patterns émergent)
5. Insights surprenants (ce qui contredit nos hypothèses)
6. Recommandations produit (5 actions concrètes)

Pour chaque thème, indique :
- Fréquence (X utilisateurs sur 15 l'ont mentionné)
- Intensité (frustration faible/moyenne/forte)
- Citation la plus représentative

[coller les transcriptions]

Analyse de Feedback Produit

Voici 200 feedbacks utilisateurs collectés via notre outil in-app ce mois.
Mix de NPS comments, feature requests et bug reports.

Produis :
1. Catégorisation (bug, feature request, UX issue, praise, autre)
2. Top 10 thèmes par volume
3. Sentiment par catégorie
4. Feature requests les plus demandées (avec fréquence)
5. Corrélation : les utilisateurs qui donnent un NPS < 7 mentionnent quels thèmes ?
6. Quick wins : améliorations à fort impact et faible effort

[coller les feedbacks]

Roadmap Planning

Roadmap Trimestrielle

Voici les inputs pour la roadmap Q[trimestre] [année] :
- Objectifs stratégiques : [O1, O2, O3]
- Features candidates (avec scores RICE du backlog)
- Capacité de l'équipe : [X] semaines-dev disponibles
- Dettes techniques à traiter : [liste]
- Engagements clients : [si applicable]

Produis :
1. Proposition de roadmap — répartition par mois
2. Allocation capacité : features (70%) / dette technique (20%) / exploration (10%)
3. Dépendances et risques identifiés
4. Features repoussées et justification
5. Version "narrative" pour la présentation aux stakeholders

Communication Roadmap par Audience

Adapte cette roadmap pour une présentation au board en 3 slides :
Slide 1 : Résumé exécutif (vision + 3 big bets)
Slide 2 : Timeline avec milestones et métriques attendues
Slide 3 : Ressources nécessaires et risques

[coller la roadmap détaillée]

Spec Reviews et Quality

Review de Specs Techniques

Voici les specs techniques rédigées par l'équipe engineering pour la feature [nom].
En tant que PM, je veux m'assurer que :

1. Toutes les user stories sont couvertes par les specs
2. Les edge cases identifiés dans le PRD sont adressés
3. Le plan de rollout est compatible avec la stratégie produit
4. Les métriques de succès sont mesurables avec l'implémentation proposée
5. Aucun compromis technique n'impacte l'expérience utilisateur de manière inacceptable

PRD original : [coller]
Specs techniques : [coller]

Produis un rapport de gap analysis avec les écarts identifiés.

Definition of Done

Crée une Definition of Done (DoD) pour l'équipe produit de [nom du produit].

Contexte : équipe de [X] devs, produit SaaS B2B, release hebdomadaire.

La DoD doit couvrir :
- Code (review, tests, lint)
- Produit (specs respectées, edge cases, accessibilité)
- Design (pixel-perfect, responsive, states)
- QA (tests manuels, smoke tests, regression)
- Documentation (changelog, help center, release notes)
- Monitoring (alertes, logs, métriques)

Format : checklist actionnable directement intégrable dans Jira/Linear.