Les startups grandissent et évoluent. Le modèle RASCI est parfait pour accompagner cette évolution. En effet, les rôles à l’intérieur changent et souvent cela conduit à des problèmes de focus, où plusieurs personnes empiètent sur les responsabilités leurs responsabilités respectives. C’est un problème particulièrement sérieux en ce qui concerne le Product Management : tout le monde a une opinion sur le produit.
Que ce soit les investisseurs, les développeurs, les clients, les sales, je ne peux pas citer le nombre de fois où une personne est allé voir directement un développeur pour implémenter une fonctionnalité dont il avait besoin.
1. Le challenge du Product Mananger
La mission du Product Manager est de trouver le market fit. Il lui incombe donc de faire en sorte que tout le monde se concentre sur ce qui est important. Pour cela, ses outils principaux sont la roadmap des hypothèses et la roadmap produit. Elles mettent vos équipes sur la même longueur d’ondes au niveau stratégique, et au niveau tactice.
Mais il n’est pas rare qu’un jour, une discussion commence entre par exemple un sales et un développeur sur une fonctionnalité à développer. La communication est saine, on veut éviter de créer des silos. Mais sans définition claire des rôles et responsabilités, cette discussion saine peut devenir une feature request officielle, que le développeur va soudainement prioriser au détriment de la roadmap produit. Le Product Manager se retrouve en position de devoir expliquer pourquoi cette feature n’est pas la priorité à l’heure actuelle, et cela va créer des frustrations au sein de l’équipe : le sales ne va pas se sentir écouté, le développeur a l’impression d’être un exécutant de la roadmap. C’est la raison pour laquelle vous devez impliquer tout le monde dans la conception de vos roadmaps. Une source de vérité établie évite ces remises en questions permanentes lorsque quelqu’un a une idée ou une opinion.
De façon générale, le Product Manager est le gardien de cette dynamique, et ne vous méprenez pas : dans certaines startups, son rôle sera principalement de dire « non » et d’essuyer les critiques. Mais au fur et à mesure que la roadmap avance et que les résultats sont là, son rôle sera consolidé, et la confiance s’établira au sein des équipes.
2. Accélérer le processus avec RASCI
Ce processus d’avancer dans la roadmap et obtenir des résultats prend du temps. Avant d’obtenir des résultats, ce qui peut prendre plusieurs mois, il est possible que le Product Manager essuie des revers : le CEO ou le CTO pourrait imposer ses features requests à l’équipe de développement. Cela retarde le travail sur la roadmap et ralentit le progrès de votre équipe. Il est donc important de disposer des bons outils pour désamorcer ces situations et aider vos équipes à ce concentrer. C’est là qu’intervient le modèle RASCI.
RASCI est l’abréviation de Responsible, Accountable, Supportive, Consulted, Informed. Il s’agit d’un outil qui peut être utilisé pour définir les rôles et les responsabilités au sein d’une équipe. Revenir dessus régulièrement permet d’éviter les malentendus, évite les arguements d’autorité et garde tout le monde sur la même longueur d’onde.
3. Qu’est-ce que le modèle RASCI ?
Le modèle RASCI est un système bien défini qui attribue des rôles et des responsabilités aux individus au sein d’une organisation. Il est souvent utilisé dans les grandes organisations, mais peut également être adapté aux petites entreprises en démarrage. La clé du modèle RASCI est la clarté. Le rôle et la responsabilité de chaque personne doivent être clairement définis et compris par tous les membres de l’organisation.
Voici comment cela fonctionne :
- R = Responsable de la tâche
- A = Responsable des résultats de la tâche (toujours une seule personne)
- S = Soutien à la personne responsable de la tâche (facultatif selon les cas)
- C = Consulté sur la tâche (facultatif selon les cas)
- I = Informé de la tâche
La clé du succès de RASCI est une communication claire entre tous les membres de l’organisation. Le rôle et la responsabilité de chaque personne doivent être clairement définis et compris par tous pour être efficaces. Lorsque les rôles sont ambigus ou prêtent à confusion, cela peut amener à des tensions au sein de l’équipe.
4. Comment l’appliquer au sein d’une startup ?
J’ai découvert le modèle RASCI chez TIAO, quand la mauvaise définition de mon rôle de Product Manager a conduit à des tensions avec d’autres membres de l’équipe. Les tensions ne sont pas anormales dans un environnement de travail, ce qui compte est de pouvoir les adresser rapidement. Dans ce cas-ci, RASCI a bien aidé à leur résolution. Nous l’avons utilisée pour définir les rôles du CEO, du CTO, du PM et des développeurs.
Au sein d’une startup, surtout une early stage startup, il n’est pas rare que chaque employé porte plusieurs chapeaux. C’est normal. Peut-être que le product manager sera aussi en charge du site internet, le CEO fera la comptabilité, ou le développeur postera sur les réseaux sociaux. Cette diversification des rôles conduit forcément à une confusion dans les missions principales. De nos jours, l’absence de définition claire de certains rôles (comme le Product Manager ou le Product Owner, qui sont généralement définis par leurs outputs) ne facilite pas les choses.
5. Exemple high level
Par conséquent, chacun savait ce qu’il devait faire et, surtout, ce dont il n’était pas responsable. Voici un exemple et les explications high level :
| Item | Responsible | Accountable | Support | Consulted | Informed |
|---|---|---|---|---|---|
| Product Roadmap | Product Manager | Product Manager | Developpeurs | Developpeurs | Tout le monde |
| Développement de features | Développeurs | Product Manager | Product Manager | Sales, Product Manager ou CEO (selon les cas) | Tout le monde |
| Relations clients | CEO | CEO | Product Manager | Personne | Ca dépend |
| Relations investisseurs | CEO | CEO | CFO | C-suite | C-suite / All |
a. La roadmap
De façon générale, le Product Manager est responsable et accountable pour la gestion et mise en oeuvre de la product roadmap. Par ailleurs, il doit absolument consulter les développeurs pour la concevoir, et peut même demander le support des développeurs pour décrire la partie technique de chaque élément de la roadmap. Par nature, la roadmap est publique au sein de l’organisation, donc tout le monde est informé de son évolution.
b. Le développement
Le développement des features mêmes est sous la responsabilité des développeurs. Le Product Manager est accountable pour le résultat. C’est aussi lui qui a la responsabilité de faire la demande (en créant la description de l’item sur la roadmap) et sa priorisation. Les développeurs peuvent demander le PM en support (pour réaliser des mockups par exemple), et il sera consulté en cas de doute sur l’implémentation. Le développement des features est public, sur la roadmap, donc tout le monde est informé.
c. Les relations clients et investisseurs
Les relations clients se font sous la responsabilité du CEO (par exemple, ça dépend du produit). Il peut demander le support du Product Manager, et selon les cas peut informer d’autres parties prenantes.
Les relations avec les investisseurs sont sous la responsabilité du CEO, avec le support du CFO, dans certains cas, la C-Suite sera peut-être consultée, sûrement informée.
6. A l’échelle de la roadmap
| Item | Responsible | Accountable | Support | Consulted | Informed |
|---|---|---|---|---|---|
| Création d’un item de la roadmap | Product Manager | Product Manager | Développeurs | Développeurs | Tout le monde |
| Développement d’un item de la roadmap | Développeurs | Product Manager | Product Manager | Product Manager | Tout le monde |
| Mise à jour sécurité | Développeurs | CTO | Développeurs | Product Manager | L’équipe technique |
| Maintenance du tech stack | Développeurs | CTO | Développeurs | Product Manager | L’équipe technique |
a. Création d’un item de la roadmap
Un item sur la roadmap est créé par le Product Manager. Il le fait grâce à sa compréhension du marché, et de son tech stack. Il est aussi accountable pour cela. Il doit consulter les devs, et peut leur demander leur support pour préciser la demande si nécessaire. Tout le monde est informé de la roadmap parce qu’elle est publique.
Les mises à jour de sécurité ou la maintenance du tech stack sont sous la responsabillité des développeurs. Le CTO est accountable pour cela. Le Product Manager peut être consulté si le produit ou l’expérience utilisateurs risquent d’être affectés. L’équipe technique dans son ensemble doit être informée de l’évolution (il n’y a pas toujours besoin de support).
7. En conclusion
En tant que Product Manager, je ne vais jamais aller expliquer comment les développeurs doivent gérer leur tech stack, et les développeurs étant rarement en contact avec les clients, vont rarement pouvoir prioriser la roadmap de façon efficace. Une startup qui fonctionne, c’est avant tout une startup où chacun a une zone de responsabilité et d' »accountability » claires, où la communication est fluide, et où chacun peut venir en support des autres lorsque les compétences peuvent être utilisées de façon optimales.
Ca, ce sont des choses que votre équipe doit comprendre. La méthode RASCI ne va pas s’implanter par magie. Votre mission en tant que Product Manager est de convaincre vos collègues que c’est le meilleur moyen pour tous de minimiser la partie « bullshit » de leur job, et de maximiser leur impact. Au final, c’est demander à chacun de se concentrer sur les fondements de leur mission au sein de votre startup.