feedback-synthesis

Par mkurman · zorai

npx skills add https://github.com/mkurman/zorai --skill feedback-synthesis

name: feedback-synthesis description: Quand l'utilisateur doit analyser, catégoriser ou extraire des insights actionnables à partir de retours clients provenant de plusieurs sources, notamment les demandes de fonctionnalités. related: [user-research-synthesis, churn-analysis, prd-writing] reads: [startup-context]

tags: [nontechnical, startup-founder-skills, feedback-synthesis] ----|-----------|-------------------|-------------------|---------------------|----------| | [Thème] | [Nombre] | [Segments] | [Score] | [Élevé/Moyen/Bas] | [H/M/L] |

Top 3 Opportunities (Deep Dives)

Opportunity 1: [Nom du Thème]

  • Rationale: Besoins clients et alignement stratégique
  • Citations représentatives: Langage utilisateur direct
  • Solutions alternatives: Autres moyens d'adresser ce besoin
  • Hypothèses à haut risque: Ce qui doit être vrai
  • Test le moins cher: Comment valider avec effort minimal

Quick Wins

Actions qui adressent les retours fréquents avec faible effort d'implémentation.

Not Prioritized (and Why)

Thèmes explicitement déprioritisés avec justification.

Appendix: Raw Data Summary

Ventilation par source, segment et période.



## Frameworks & Best Practices

### Opportunities Over Features
Ne laisse jamais les clients concevoir les solutions. Priorise les opportunités (problèmes), pas les fonctionnalités. Quand un utilisateur dit "Je veux un diagramme de Gantt", l'opportunité sous-jacente pourrait être "Je dois visualiser les timelines de projets et communiquer le statut aux stakeholders." Approfondis toujours le job-to-be-done derrière la demande.

### Opportunity Score (Dan Olsen)
Score chaque thème : Opportunity Score = Importance x (1 - Satisfaction), normalisé à 0-1. Cela met en évidence les problèmes à la fois importants et mal desservis. Une zone haute-importance, haute-satisfaction est déjà bien servie et ne doit pas être priorisée face à un gap haute-importance, basse-satisfaction.

### Signal vs. Noise Rules
- **Un client qui le dit n'est pas un pattern.** Exige 3+ mentions indépendantes d'un thème avant de le traiter comme un signal. Exception : si ce client unique est un whale account le citant comme un risque de churn.
- **Recency bias check.** Un flot de retours récents sur un sujet peut éclipser un problème persistant. Compare toujours avec la période antérieure.
- **Le plus bruyant ne signifie pas le plus important.** Les power users et clients vocaux génèrent des retours disproportionnés. Pèse par taille de segment et contribution revenue, pas par volume seul.
- **Le compliment est une donnée aussi.** Suit ce que les utilisateurs adorent. Connaître tes forces t'empêche de les casser accidentellement lors d'une refonte.

### Assumption Testing
Pour chaque opportunité de top priorité, identifie l'hypothèse à plus haut risque et conçois le test le moins cher possible. Ne construis pas la solution complète pour valider une hypothèse qui pourrait être testée avec un prototype, une survey ou une expérience Wizard of Oz.

### Source-Specific Guidance
| Source | Strengths | Watch Out For |
|--------|-----------|---------------|
| Support tickets | Signal fort, problèmes spécifiques | Penche vers les bugs, omet les utilisateurs satisfaits |
| NPS/surveys | Couverture large, quantifiable | Faibles taux de réponse peuvent biaiser les résultats |
| Feature request boards | Organisé, votes disponibles | Power users dominent le vote |
| Sales call notes | Proche du revenue, perspective prospect | Les prospects demandent des fonctionnalités qu'ils n'utiliseront peut-être jamais |
| App store reviews | Public, inclut comparaisons concurrents | Penche négatif, plaintes vagues |
| Social media | Unfiltré, temps réel | Bruyant, difficile à segmenter |

### Avoiding Common Mistakes
- **Cherry-picking quotes** qui soutiennent une hypothèse préexistante. Présente la distribution complète, incluant les retours contradictoires.
- **Confondre fréquence avec importance.** Un problème basse-fréquence qui cause du churn importe plus qu'une gêne haute-fréquence que les utilisateurs tolèrent.
- **Livrer des données sans recommandations.** Une carte thématique sans items d'action est un rapport, pas une synthèse. Termine toujours par ce qu'il faut faire ensuite.
- **Ignorer la majorité silencieuse.** Les utilisateurs qui ne se plaignent jamais peuvent être satisfaits ou désengagés. L'analyse par segment aide à distinguer les deux.

## Related Skills
- `user-research-synthesis` -- Chaîne quand l'analyse de retours révèle des gaps nécessitant de la user research dédiée (interviews, tests d'usabilité).
- `churn-analysis` -- Chaîne quand les thèmes de retour corrèlent avec des patterns de churn et nécessitent une analyse de rétention plus approfondie.
- `prd-writing` -- Chaîne quand une opportunité claire émerge de la synthèse et doit être spécifiée dans une PRD.

## Examples

### Example 1: Feature request prioritization
**User:** "Notre feature request board a 150 items. Aide-moi à figurer ce qu'on doit construire le trimestre prochain."

**Good output excerpt:**
> **Executive Summary:** 150 demandes se regroupent en 9 thèmes. L'opportunité top n'est pas la fonctionnalité la plus demandée (SSO, 34 votes) mais le besoin le plus mal desservi : "collaboration temps réel sur documents partagés" (Opportunity Score : 0,82). SSO score moins haut (0,45) car les contournements existants satisfont adéquatement la plupart des utilisateurs.
>
> **Opportunity 1: Real-time collaboration**
> - **Rationale:** 22 demandes sur 4 segments. Citée comme expansion blocker dans 3 deals enterprise valant $85K ARR. Satisfaction actuelle : 2/10.
> - **Alternative solutions:** (a) Édition temps réel complète, (b) Légères annotations et indicateurs de présence, (c) Workflow d'examen asynchrone avec notifications
> - **High-risk assumption:** Les utilisateurs veulent l'édition simultanée, pas juste la conscience de ce que font les autres
> - **Cheapest test:** Ajouter les indicateurs de présence uniquement (montrer qui visualise un document) et mesurer si les tickets collaboration-related diminuent

### Example 2: Multi-source synthesis
**User:** "Nous avons 200 support tickets, 50 réponses NPS et notes de 10 interviews client du mois dernier. Que nous disent les clients ?"

**Good output excerpt:**
> **Theme 1: CSV export broken for large datasets** (Opportunity Score : 0,91)
> - 47 support tickets, 8 NPS detractors, 3 interviews. Les utilisateurs atteignant la limite de 10K lignes la contournent en divisant les exports manuellement.
> - **Strategic alignment:** Élevé -- l'export de données est core à notre positionnement "open platform".
> - **Cheapest test:** Pas nécessaire; c'est un bug/limitation clair. Corrige directement.
> - **Quick win:** Augmente la limite d'export CSV à 100K lignes (estimation engineering : 2 jours).

Skills similaires