Une équipe de développement agile bien structurée, avec un excellent Product Owner ou Product Manager: voilà la première étape vers une organisation produit efficace.
Cependant, de nombreuses entreprises s’arrêtent ici dans leur raisonnement et conservent une vision produit portée par un département dédié, construite selon des processus lents, peu visibles et assez peu orientés vers les utilisateurs.
Comment casser ces silos et faire un lien sans couture entre le backlog et la roadmap stratégique ? Comment faire en sorte de tester / prototyper les idées très en amont plutôt qu’une fois qu’il est trop tard ? Comment construire un processus continu (parfois appelé dual-track scrum) pour dé-risquer les évolutions clés du produit et alimenter les équipes de développement ?
Nous vous proposons un retour d’expérience sur la mise en place de cette approche « Continuous Product Discovery ».
Similar to XebiCon'17 : Continuous Product Discovery, comment dé-risquer systématiquement les évolutions clés de votre produit - Simon Joliveau-Breney (20)
4. Pourquoi c’est important ?
Continuous Product Discovery
Une intuition n’est pas
toujours fiable
1
Nos besoins personnels
ne sont pas forcément
universels
2
La première solution qui
vient en tête n’est pas
toujours la meilleure
3
L’aspect économique est
trop souvent ignoré
4
5. En pratique…
Continuous Product Discovery
Un point de départ
« J’adore les jeux de société ! »
Une idée
« Un réseau social pour amateur de
jeux de société ! »
Un rapide benchmark
« J’ai trouvé un site qui fait déjà ça
mais il est moche »
On y va
« Investissons 5 millions pour faire le
Facebook du jeu de société »
6. Pourquoi, trop souvent, cela ne fonctionne pas
Continuous Product Discovery
Parce que personne ne se saisit du sujet
« Discovery » au sein de l’organisation
1
Parce qu’on confie le « Discovery » au PO
ou à l’UX d’une équipe SCRUM
2
• Rôle du directeur / fondateur maître de la
vision produit
• Résistance culturelle
• Peur de l’échec
• Tendance à être « le nez dans le guidon »
• Focus sur le « Build »
• Orientation solution plutôt que problème à
résoudre
• Propension à tester après coup
7. Notre proposition : une équipe dédiée composée de Product Managers et d’UX
Continuous Product Discovery
Product Discovery
Product
Development
Squad :
PO
Dev
UX / UI
…
Squad :
PO
Dev
UX / UI
…
Squad :
PO
Dev
UX / UI
…
Squad :
PO
Dev
UX / UI
…
Product Manager + UX Product Manager + UX
Mobilisation du PO, de l’UX, voire du Lead Dev
des équipes concernées au cours du processus
Discover
Domaine fonctionnel 1 Domaine fonctionnel 2
8. Exemple de processus Product Discovery
Continuous Product Discovery
Idée
Un réseau social pour
amateur de jeux de
société !
Entretiens « besoin » Personas
Business Case Brainstorming
Décision
de dev
Formalisation
use-case et
hypothèses Prototype
9. Combien de temps dure ce processus ?
Continuous Product Discovery
1. Assigner un niveau de risque à chaque hypothèse
2. Prioriser la vérification des hypothèses les plus risquées
3. Doser le niveau d’effort en fonction du niveau de risque
Cela dépend du sujet abordé
10. Quelles sont les compétences du Product Manager ?
Continuous Product Discovery
Veille Recherche utilisateur Vision produit Business Model
• Suivi des tendances
marché
• Suivi des tendances
techno
• Capacité à comprendre
l’utilisateur, à identifier
des problèmes et des
opportunités
• Création de personas
• Tests
• Bonne connaissance du
produit / portefeuille de
produit
• Garant de la roadmap
long-terme
• Collabore avec les autres
départements (Marketing,
IT…)
• Capacité à évaluer le
potentiel d’un marché ou
les opportunités de
monétisation d’une
fonctionnalité ou d’un
produit
11. L’équipe Product Discovery n’a pas le monopole de ces outils ni de la relation avec les clients
Continuous Product Discovery
Product Discovery
Team
Dev Team
Boîte à outils
commune
• Sujets de prospective / de R&D / de long-termes
• Sujets risqués
• Sujets stratégiques
• Sujets d’optimisation / d’amélioration
• Sujets urgents
• Sujets de courts-termes
12. Les étapes pour construire ce processus de manière continue et systématique
Continuous Product Discovery
S’appuyer sur le PO et les UX
1
• Capitaliser sur la capacité de
l’équipe à générer des idées
• S’appuyer sur des compétences UX
existantes
Structurer la recherche
utilisateur
2
• Rationnaliser les phases de
recherche utilisateur
• Mieux partager l’information
Créer un rôle dédié (PM / Epic
Owner…)
3
• Eviter de sur-solliciter les équipes
de développement
• Adopter une vision de long terme
• Dégager du temps
• Matérialiser le processus (EPIC,
features, board dédié)
• Sélectionner les EPIC risquées
• Créer des communautés de pratique
• Documenter et partager la
recherche utilisateur entre équipes
• Découper le produit en
périmètres fonctionnels
• Recruter des PM et UX dédiés
• Toujours impliquer les équipes
de dev
PourquoiComment