Le développement d’un nouveau produit présente plusieurs défis pour le Product Manager et particulièrement dans les entreprises déjà bien établies. Ces entreprises ont un portefeuille de produits matures et pour certains en phase de croissance sur leurs marchés.
Dans la grande majorité, le développement des produits existants est mené suivant le principe de la cascade (waterfall), la projection est sur une durée de 3 ans minimum et tout est particulièrement bien détaillé jusque dans les moindres détails grâce à un GANTT. Il y a très peu de marge de manœuvre en raison du cadre interne (le grand nombre de personnes actives sur le produit, les investissements faits, l’organisation, les process), l’orientation profitabilité des produits existants et la tendance à réagir à la concurrence.
Le Product Manager a qui l’on confie le développement d’un nouveau produit est alors naturellement amené à adopter une approche projet et il devient très facile de confondre la roadmap produit avec la gestion de projet.
Ne pas faire cet amalgame est alors un véritable défi, particulièrement lorsque le nouveau produit est en développement et a déjà un client et que ce dernier est un client clé.
Le Product Manager est pris dans un dilemme entre construire le produit avec les fonctionnalités spécifiques demandées par ce premier client en sachant qu’elles ne vont peut-être pas faciliter une meilleure approche du marché global.
L’Armageddon du Product Manager se produit quand ce client demande une fonctionnalité longue et coûteuse à développer et que « c’était pour hier … ».
C’est dans ces situations difficiles qu’avoir une roadmap produit claire et construite avec les meilleures informations disponibles est une aide essentielle pour le Product Manager. Il lui faut faire cohabiter une roadmap produit avec des contraintes projet.
Voici quelques approches qui m’ont permis de gérer ce type de situation.
Une roadmap c’est quoi ?
Définir ce qu’est une roadmap n’est pas simple, chaque entreprise a ses propres besoins et chaque Product Manager a ses préférences. Quelques soient les méthodes et les outils, d’après mon expérience, une roadmap obéit à quelques grands principes. A chacun d’adapter, construire, développer sa roadmap.
- La roadmap aligne le développement produit avec la stratégie de l’entreprise (cout/moyen/long terme)
- La roadmap lie le «Présent» avec le « Futur »
- La roadmap apporte le «Pourquoi» et le « Comment» aux équipes de développement
- La roadmap aide à la priorisation des actions en restant alignée sur la stratégie de l’entreprise
Pour ceux qui sont familiers de Simon Sinek, la roadmap définit le « Why » et le « How »du développement produit. Le reste (Gantt, backlog …) c’est le « What ».
La façon de construire la roadmap est tout aussi importante que la roadmap elle-même. Le Product Manager est au carrefour de trois axes : Stratégie/Ressources/Produit. La roadmap doit être le lien qui les réunit.
L'alignement stratégique
Le point clé est de comprendre les objectifs de l’entreprise et ses priorités
- Rencontrer les décisionnaires (CEO, Directeurs, DAF, …) – Privilégier les entretiens en 1-1
- Demander leurs objectifs prioritaires sur 1 à 3 ans
- Traduire les objectifs en utilisant les OKR (ou SMART) pour concrétiser la stratégie
- Poser la base temporelle et l’adapter selon le contexte
La base temporelle est un point clé d’une roadmap performante. Voici plusieurs façons de faire :
Version cascade
Une forme courante de découpage du temps est d’appliquer le 1/3/3. On applique une unité de base et on adapte pour les suivants.
Start-Up : timing accéléré, base = 1 semaine
1 semaine / 3 semaines / 3 mois
Entreprise en croissance, base = 1 mois
1 mois / 3 mois / 3 ans
Version souple
Une autre est de découper en court terme / moyen terme / long terme.
En général, le trimestre est une bonne base pour démarrer.
Quelque soit la méthode, le plus important est de rester dans une logique stratégique. La tentation est grande de dérouler dans le comment et le quoi.
L’article suivant traitera de la bascule vers la conduite du développement produit : vision, priorisation et gestion des aléas.
Vos commentaires sont les bienvenus.
