L’espace Notion d’un Product Manager : ce qu’il ouvre chaque matin
L’espace Notion d’un Product Manager : ce qui attend sa validation, les décisions à trancher, les specs et les ADR, et le travail avec le design et la QA.
L’espace Notion d’un Product Manager tient sur une page : ce qui attend sa validation, les stories à affiner, les décisions à trancher et les epics en cours, chacun dans une vue filtrée sur son nom. Autour, trois appuis : des spécifications reliées aux epics, un journal de décisions, et des liens directs vers le travail du design, du développement et de la recette.
Un Product Manager passe ses journées à arbitrer, et chaque arbitrage demande de retrouver une information : la spec d’une fonctionnalité, la raison d’une décision prise il y a trois mois, l’état d’une story en recette.
Quand ces informations vivent dans cinq outils, le travail se transforme en recherche. Ce guide montre l’espace Notion d’un PM ou d’un Product Owner, tel que je l’ai conçu dans ProductOS. Le cadre général de l’équipe est dans Scrum dans Notion.
Que doit contenir l’espace Notion d’un Product Manager ?
L’espace d’un PM n’est pas un tableau de bord rempli de chiffres. C’est une page de travail, qui répond chaque matin à une question : qu’est-ce qui attend une décision de ma part ?
Elle contient en général cinq blocs, chacun une vue liée d’une base de l’équipe, filtrée sur la personne :
- À valider : les stories terminées par l’équipe, en attente de l’acceptation du PO.
- À affiner : les stories des prochains sprints qui manquent encore de critères ou d’estimation.
- Priorisation du backlog : la liste ordonnée, où se fait le tri.
- Epics en cours : les grands chantiers, avec leur avancement calculé.
- Décisions à trancher : les questions ouvertes, avec une date limite.
Chaque bloc est une vue d’une base partagée, pas une copie. Le PM travaille sur les mêmes données que l’équipe, seulement filtrées autrement. Le principe des vues liées est expliqué dans les vues liées de Notion.
La page du matin : ce qui attend une décision
L’ordre des blocs n’est pas anodin. En haut, ce qui bloque les autres : une story en attente de validation retient un développeur, une décision non tranchée retient tout un epic. En bas, ce qui peut attendre la fin de journée : l’affinage et la relecture du backlog.
Trois réglages rendent cette page utile :
- Des filtres sur la personne, pas sur un nom écrit en dur. Le même modèle de page sert alors à chaque PM d’une équipe.
- Des vues courtes, triées par ancienneté : ce qui attend depuis le plus longtemps remonte.
- Une vue vide quand tout va bien. Une liste « À valider » vide en fin de journée est le meilleur indicateur qu’un PO puisse avoir.
Où ranger les spécifications et les décisions ?
Les specs et les décisions sont la mémoire du produit. Mal rangées, elles se perdent dans des pages isolées ; bien rangées, elles répondent à la question « pourquoi est-ce fait comme ça ? » des mois plus tard.
Les spécifications, reliées aux epics
Une base « Documentation » avec un type (Spécification, Décision, Procédure) et une relation vers les epics. La spec d’un chantier s’ouvre depuis la page de l’epic, et l’epic s’ouvre depuis la spec. Personne ne cherche.
Les décisions, en ADR
L’ADR (Architecture Decision Record) est un format court popularisé par Michael Nygard pour consigner une décision technique : le contexte, la décision, ses conséquences. Le format s’applique très bien aux décisions produit. Une page par décision, avec un statut (proposée, acceptée, remplacée) et la date. Quand une décision en remplace une autre, une relation les relie.
Les procédures
Comment on met en production, comment on signale un bug, comment on accueille un nouveau membre. Ces pages changent peu et se lisent souvent. La méthode pour les écrire est dans documenter ses procédures dans Notion.
Comment le PM travaille-t-il avec le design, le développement et la recette ?
Le PM n’est pas seul dans l’espace. En construisant ProductOS, j’ai donné une page à chaque métier, chacune filtrée sur son nom : le PO / PM, le développeur, le designer / UX et le testeur. Tous travaillent sur les mêmes stories ; seul le filtre change.
Le passage de relais se fait par le statut de la story :
- Avec le design : une story prête passe « En design ». La designeuse ou le designer voit apparaître la maquette à livrer, la fait valider, puis la story continue.
- Avec le développement : la story passe « En dev », puis « En revue ». Le développeur découpe en tâches dans sa page.
- Avec la recette : « En recette », le testeur déroule les cas de test reliés aux critères d’acceptation, signale les bugs, et la story revient au PO pour validation.
Ce circuit évite les messages « où en est cette story ? ». Chacun voit dans sa page ce qui l’attend, et le PM voit dans la sienne ce qui revient vers lui. Pour régler qui voit quoi, voyez les permissions Notion en équipe.
Quels rituels le PM anime-t-il dans Notion ?
Le Scrum Guide confie au Product Owner la responsabilité du Product Backlog et de son ordre. Dans la pratique, il prépare ou anime plusieurs moments :
- Le sprint planning : il propose l’objectif du sprint et les stories prêtes les plus prioritaires.
- L’affinage : il complète les stories à venir avec l’équipe, depuis la vue « À affiner ».
- La sprint review : il présente ce qui est terminé aux parties prenantes et recueille les retours, qui deviennent de nouvelles stories.
Une base de comptes rendus reliée aux sprints garde la trace de ce qui a été décidé à chaque rituel. Le détail de chaque événement est dans Scrum dans Notion, et la méthode de tri dans le backlog produit dans Notion.
Template ou espace construit soi-même ?
Construire l’espace d’un PM soi-même est possible, à condition que les bases de l’équipe existent déjà : la page du PM n’est faite que de vues de ces bases. C’est là que le temps part, dans les relations, les statuts et les filtres de chaque vue.
Si l’équipe démarre de zéro, un template fait gagner tout ce travail et arrive avec les pages des autres métiers. Pour un wiki d’équipe autour du produit, voyez aussi le wiki d’équipe Notion.
Partir de ProductOS
ProductOS installe l’espace complet de l’équipe produit : la page du PO / PM avec ce qui est à valider, à affiner, la priorisation du backlog, les epics en cours et les décisions à trancher ; la documentation avec les spécifications, les décisions (ADR) et les procédures ; et une page pour le développeur, le designer et le testeur. Un seul paiement couvre toute l’équipe.
Questions fréquentes
Notion est-il adapté à un Product Manager ?
Oui, surtout quand le PM travaille avec une équipe de plusieurs métiers. Notion réunit le backlog, les spécifications, les décisions et la roadmap dans un même espace relié. Le PM dispose d’une page filtrée sur son nom, avec ce qui attend sa validation ou sa décision.
Que mettre dans un template Notion de Product Manager ?
Une page de travail avec ce qui est à valider, à affiner, les décisions à trancher et les epics en cours, plus une base de documentation pour les spécifications, les décisions et les procédures. Toutes ces vues s’appuient sur les bases partagées par l’équipe, jamais sur des copies.
Qu’est-ce qu’un ADR ?
Un ADR, ou Architecture Decision Record, est une fiche courte qui consigne une décision : le contexte, la décision prise et ses conséquences. Le format, popularisé par Michael Nygard pour les décisions techniques, convient aussi aux décisions produit. Dans Notion, une page par décision, avec un statut et une date.
Quelle différence entre Product Manager et Product Owner ?
Le Product Owner est une responsabilité définie par le Scrum Guide : il ordonne le backlog et maximise la valeur du produit. Product Manager est un intitulé de poste, souvent plus large, qui inclut la stratégie et le marché. Dans beaucoup de petites équipes, la même personne tient les deux rôles.
Existe-t-il un template Notion pour équipe produit ?
ProductOS est un template Notion pour toute l’équipe produit : backlog, sprints, bugs, cas de test, releases, roadmap et documentation reliés, avec une page pour le PO / PM, le développeur, le designer et le testeur. Un seul paiement couvre toute l’équipe.