problem-statement

Vue d’ensemble du skill problem-statement

Le skill problem-statement vous aide à transformer une demande produit floue en une formulation de problème centrée sur l’utilisateur, qui explique qui est bloqué, ce qu’il essaie de faire, pourquoi c’est important et ce que cela provoque chez lui. Il est particulièrement utile quand il faut s’aligner avant de passer à la solution : discovery, priorisation, PRD et revues avec les parties prenantes.

À quoi sert problem-statement

Ce skill problem-statement est conçu pour cadrer le problème, pas pour concevoir une fonctionnalité. Il aide à décrire le problème du point de vue de l’utilisateur afin que les équipes puissent décider si le travail vaut la peine d’être mené avant de débattre de l’implémentation.

Pour qui il est le plus adapté

Utilisez-le si vous rédigez des briefs produit, des spécifications techniques, des synthèses de recherche ou des notes de roadmap et que vous avez besoin d’un récit de problème plus clair. C’est aussi un très bon choix dans les workflows de Technical Writing lorsqu’il faut transformer des informations brouillonnes en une formulation concise et empathique.

Ce qui le différencie

Le skill s’appuie sur le cadre de formulation du problème : I am, Trying to, But, Because et Which makes me feel, auxquels s’ajoutent le contexte et les contraintes. Cette structure est plus utile pour la prise de décision qu’un prompt générique, parce qu’elle vous oblige à capturer à la fois le blocage fonctionnel et l’impact humain.

Comment utiliser le skill problem-statement

Installer et inspecter le skill

Installez-le avec :

npx skills add deanpeters/Product-Manager-Skills --skill problem-statement

Puis lisez d’abord skills/problem-statement/SKILL.md, ensuite template.md et examples/sample.md. C’est le moyen le plus rapide de comprendre la forme attendue, le rendu final et ce à quoi ressemble une formulation de problème aboutie.

Ce qu’il faut fournir dans votre prompt

Pour bien utiliser problem-statement, donnez au skill une entrée imparfaite mais précise : le type d’utilisateur, la tâche qu’il veut accomplir, le blocage rencontré et les contraintes éventuelles. Si vous ne fournissez qu’une demande de fonctionnalité, le résultat aura tendance à dériver vers le langage de solution plutôt que vers un vrai problème.

Un input plus solide ressemble à ceci :

• Persona : « nouveaux agents du support sur mobile »
• Objectif : « résoudre les tickets sans changer d’outil »
• Blocage : « ils perdent le contexte entre le CRM et le chat »
• Contraintes : « fort volume, faible temps de formation, équipe en remote-first »

Workflow recommandé

Commencez par une courte ébauche, puis resserrez-la jusqu’au récit en cinq parties. Utilisez le template comme une checklist : si Because commence à ressembler à une solution, revenez en arrière et demandez-vous quelle est la vraie cause de la douleur. Si Which makes me feel paraît trop générique, remplacez-le par une émotion réelle de l’utilisateur, directement liée au workflow.

Fichiers à lire en premier

Priorisez SKILL.md, template.md et examples/sample.md. Le fichier d’exemples est particulièrement utile, car il montre à la fois un bon schéma de cadrage et un anti-pattern, ce qui aide à éviter d’écrire une solution déguisée au lieu d’une formulation de problème.

FAQ du skill problem-statement

problem-statement n’est-il qu’un modèle de prompt ?

Non. Le skill problem-statement est une méthode de cadrage réutilisable, pas seulement un prompt à trous. Sa valeur tient au fait qu’il impose de clarifier l’utilisateur, le blocage et la cause racine avant de rédiger un PRD ou de proposer une correction.

Quand ne faut-il pas l’utiliser ?

N’utilisez pas problem-statement si vous avez déjà un document de besoins bien cadré ou si vous documentez un détail d’implémentation. C’est aussi un mauvais choix quand l’objectif est de faire émerger des solutions ; ce skill sert d’abord à définir le problème.

problem-statement est-il accessible aux débutants ?

Oui, si vous savez décrire un utilisateur et un point de douleur en langage simple. Le template est facile à prendre en main, mais la qualité dépend de votre capacité à séparer le problème de l’utilisateur de la solution que vous préférez.

Comment s’intègre-t-il au travail de Technical Writing ?

En Technical Writing, ce skill est utile quand il faut clarifier la douleur du public, appuyer une demande de documentation ou cadrer un manque de contenu avant d’écrire. Il aide à garder le document orienté vers le résultat, au lieu de dériver vers un récit de fonctionnalités.

Comment améliorer le skill problem-statement

Donnez au skill des preuves, pas des slogans

Les meilleurs résultats avec problem-statement viennent d’observations concrètes : ce que l’utilisateur a essayé, où il a bloqué, ce qu’il a utilisé à la place et ce qui a cassé. « Les utilisateurs sont perdus » est faible ; « les administrateurs débutants ne peuvent pas terminer la configuration parce que l’interface masque le champ de clé API obligatoire » est bien plus solide.

Séparez le problème de la solution

Un écueil fréquent consiste à glisser une solution dans la formulation. Si votre brouillon dit « les utilisateurs ont besoin d’un tableau de bord », reformulez en « les utilisateurs ne peuvent pas comparer l’état des comptes entre services parce que les signaux de statut sont dispersés ». Cela garde problem-statement centré sur l’obstacle réel.

Ajoutez les contraintes qui changent la réponse

Incluez tout ce qui modifie la forme du problème : appareil, taille de l’équipe, pression temporelle, conformité, niveau d’expérience ou limites de la plateforme. Ces détails rendent la formulation plus crédible et aident le résultat final à mieux soutenir la priorisation.

Itérez du brouillon vers une formulation prête à décider

Après la première version, vérifiez si la formulation est assez précise pour tenir face à une revue avec des parties prenantes. Sinon, resserrez la persona, rendez le Because plus causal et assurez-vous que la phrase finale peut être lue sans explication supplémentaire.