Table des matières
Dans le quotidien d’un Product Manager, savoir dire non est une compétence indispensable. Bien souvent, on préfère dire oui ou éviter de dire non de façon tranchée, pensant que cela évitera le conflit. En réalité, c'est tout le contraire : ne pas dire non clairement peut créer de la frustration, affaiblir le produit, et brouiller la vision stratégique. Accumuler les demandes non prioritaires dans le backlog ou faire croire que certaines seront peut-être traitées plus tard ne sert personne. Savoir dire non, c’est aussi clarifier ses priorités et donner de la visibilité aux équipes sur ce qui compte vraiment.
Dire non ne se fait pas de la même manière selon l’interlocuteur. Que ce soit le CEO, les stakeholders ou les designers et développeurs, la méthode varie, mais l’objectif reste le même : être transparent, responsable, et fidèle à la stratégie.
Les CEOs ont souvent une multitude d’idées et des priorités qui évoluent rapidement. Ce n’est pas qu’ils ne comprennent pas le product management ; au contraire, ils ont souvent une vision globale du produit, nourrie par les retours clients et une bonne connaissance de la concurrence. Mais ils ne sont pas dans le même niveau de détail que les PMs et peuvent parfois perdre de vue les priorités opérationnelles.
Quand le CEO propose une idée, il est important de ne pas la rejeter directement. Montre-lui plutôt comment cela impacterait la roadmap existante et les objectifs stratégiques actuels. Présente les scénarios possibles pour que l’idée soit réalisable (ou pas) et fais preuve de transparence sur ta recommandation. En agissant ainsi, tu prends la responsabilité de la décision et montres que tu as envisagé toutes les options avant de conclure. Dire non, ici, n’est pas une fin de non-recevoir, mais un acte de cohérence avec la stratégie de l’entreprise.
Les stakeholders abordent souvent le produit sous l’angle de leurs propres objectifs et contraintes. Ils cherchent naturellement à influencer le produit pour répondre à leurs besoins, pensant que cela est nécessaire pour atteindre leurs buts. Dans ce cas, éviter un non clair peut mener à des attentes irréalistes et compromettre leur performance.
Pour dire non aux stakeholders, rappelle les priorités actuelles du produit et la stratégie qui guide les choix. Explique les ressources et l’effort nécessaires pour leur demande, et pourquoi cela ne s'aligne pas avec les objectifs prioritaires. Plutôt que de les laisser dans l’attente, clarifie les décisions, et si le besoin persiste, envisage d’escalader la demande au product leadership pour validation. Cela te permet de rester transparent sans te décharger de ta responsabilité.
Les designers et développeurs cherchent souvent à aller plus loin que le strict minimum pour enrichir le produit. Parfois, cette envie de perfectionnement est un atout, mais elle peut aussi dévier les priorités si elle n’est pas contrôlée. Par exemple, il est courant qu'ils veuillent ajouter des fonctionnalités ou optimiser certains aspects alors que cela n’est pas essentiel.
Le plus démotivant pour les équipes est de croire qu’une demande sera “dernière itération” alors qu’elle n’a pas de place dans le scope. Soyons clairs dès le départ : soit une idée fait partie du scope, soit elle n’y est pas. Cela ne veut pas dire ignorer leurs suggestions ; au contraire, écouter leurs arguments est souvent bénéfique, car leurs perspectives peuvent enrichir la vision produit. Mais n’hésite pas à dire non lorsque les priorités exigent un focus plus strict.
Dire non est un art, mais s'y prendre maladroitement peut provoquer des malentendus ou des tensions inutiles. La première erreur fréquente est d’éviter de répondre clairement en utilisant des formules vagues comme “je vais mettre ça dans le backlog” ou “je reviendrai vers toi plus tard.” Ces phrases laissent entendre que la demande reste en course alors qu’elle ne l’est pas. Autant annoncer franchement que ce n’est pas au programme, même si la réponse est décevante.
Ensuite, un autre piège est de s’appuyer trop lourdement sur des détails techniques comme les méthodes de priorisation (RICE, ICE, etc.). Si ces scores sont utiles en interne, ils ne sont pas ce que les stakeholders attendent de toi. Ils veulent savoir si leur demande sera traitée et dans quel délai, pas comment tu la priorises. Préfère des réponses simples et transparentes sur les priorités actuelles et la stratégie.
Enfin, évite de perdre du temps en analyses trop poussées sur des demandes qui ne sont pas alignées avec la stratégie. Tout analyser minutieusement, c'est risquer de diluer ton attention sur des détails accessoires. En tant que PM, ton rôle est de garder le cap sur la stratégie et de consacrer ton énergie aux priorités qui comptent vraiment pour faire avancer le produit.
Dire non, ce n’est pas refuser de manière arbitraire, c’est affirmer une vision et une direction pour le produit. C’est donner aux équipes, du CEO aux opérationnels, une compréhension claire de ce qui compte pour le produit et pour l’entreprise. Dans le fond, dire non, c’est être responsable de l’avenir du produit.