WEBVTT

1
00:00:07.652 --> 00:00:08.614
Derrière chaque grande boîte,

2
00:00:08.794 --> 00:00:09.516
il y a un grand produit.

3
00:00:10.236 --> 00:00:11.122
Derrière chaque grand produit,

4
00:00:11.243 --> 00:00:12.209
il y a des gens talentueux,

5
00:00:12.329 --> 00:00:13.356
passionnés et ambitieux.

6
00:00:14.162 --> 00:00:14.546
Musique,

7
00:00:14.606 --> 00:00:15.414
come on here !

8
00:00:15.616 --> 00:00:16.845
On les appelle Product Manager,

9
00:00:17.127 --> 00:00:18.256
CPO ou Product Leader.

10
00:00:19.399 --> 00:00:20.226
Quels que soient leurs titres,

11
00:00:20.347 --> 00:00:21.276
ils ont tous la même mission,

12
00:00:21.556 --> 00:00:24.510
devenir la clé de voûte de leur entreprise à la croisée du design,

13
00:00:24.670 --> 00:00:28.336
du business et de la tech pour créer les futurs produits indispensables de demain.

14
00:00:28.596 --> 00:00:28.718
Well,

15
00:00:28.739 --> 00:00:29.593
that's Clé de voûte !

16
00:00:29.836 --> 00:00:30.219
Clé de voûte,

17
00:00:30.662 --> 00:00:32.556
c'est le podcast des products pour les products.

18
00:00:32.976 --> 00:00:33.418
Chaque semaine,

19
00:00:33.680 --> 00:00:36.896
je te fais passer un moment aux côtés des meilleurs leaders du produit français.

20
00:00:37.316 --> 00:00:37.900
Avec une mission,

21
00:00:38.041 --> 00:00:39.107
te livrer tous leurs secrets,

22
00:00:39.268 --> 00:00:43.376
méthodes et apprentissages pour devenir toi aussi la clé de voûte de ton entreprise.

23
00:00:43.750 --> 00:00:43.871
Oh,

24
00:00:44.195 --> 00:00:45.004
j'aime cette idée.

25
00:00:45.585 --> 00:00:47.630
Ce podcast est rendu possible par Stellar,

26
00:00:48.010 --> 00:00:51.939
un collectif de top CPO qui ont participé au succès de startups comme Zenin,

27
00:00:52.260 --> 00:00:52.640
Sunday,

28
00:00:53.001 --> 00:00:54.264
Spendesk ou BlaBlaCar.

29
00:00:56.124 --> 00:00:57.911
J'ai cofondé ce collectif avec une mission,

30
00:00:58.232 --> 00:01:01.664
aider les dirigeants d'entreprises tech à créer les produits donnés dans l'industrie.

31
00:01:02.905 --> 00:01:03.668
Retard sur la roadmap,

32
00:01:04.129 --> 00:01:04.892
équipe des amis,

33
00:01:05.233 --> 00:01:06.257
produits lents à décoller,

34
00:01:06.458 --> 00:01:06.939
ces problèmes,

35
00:01:07.040 --> 00:01:08.164
nos CPO les connaissent par cœur.

36
00:01:08.324 --> 00:01:11.197
Et ils débarquent à tes côtés pour les résoudre dans des formats rapides,

37
00:01:11.459 --> 00:01:12.624
actionnables et clés en main.

38
00:01:13.970 --> 00:01:16.458
Si tu es dirigeant ou CPO et que tu écoutes ce podcast,

39
00:01:16.699 --> 00:01:18.264
c'est qu'on a très certainement des choses à se dire.

40
00:01:18.604 --> 00:01:22.064
On se retrouve sur wearestellar.io ou via le lien en description de l'épisode.

41
00:01:23.246 --> 00:01:25.784
Je m'appelle Timothée Frein et bienvenue dans Clé de l'Oud.

42
00:01:27.167 --> 00:01:27.329
Hello,

43
00:01:27.512 --> 00:01:28.264
j'espère que tu vas bien.

44
00:01:28.704 --> 00:01:29.026
Aujourd'hui,

45
00:01:29.247 --> 00:01:33.953
j'aimerais te parler d'un sujet qui me tient à cœur puisque je l'adresse tous les jours en échangeant avec mes clients sur Stellar,

46
00:01:34.155 --> 00:01:35.804
le collectif de CPO que j'ai cofondé.

47
00:01:36.833 --> 00:01:39.692
Beaucoup d'entreprises tech font face à une difficulté lorsqu'elles grossissent.

48
00:01:40.153 --> 00:01:40.952
Elles perdent de la vitesse.

49
00:01:41.672 --> 00:01:42.632
Et ça pose un problème.

50
00:01:42.972 --> 00:01:43.840
Car une boîte qui ralentit,

51
00:01:43.840 --> 00:01:45.172
c'est une boîte qui prend moins de décisions,

52
00:01:45.672 --> 00:01:48.292
qui innove moins et qui dépense de l'argent anormalement.

53
00:01:48.792 --> 00:01:49.257
Autrement dit,

54
00:01:49.439 --> 00:01:50.852
c'est une boîte qui meurt à petit feu.

55
00:01:51.252 --> 00:01:53.412
Et s'il y a bien quelqu'un qui en connaît un rayon sur ce sujet,

56
00:01:53.692 --> 00:01:54.519
c'est Alex Watrellos,

57
00:01:54.882 --> 00:01:56.172
l'actuel CPO de Furious,

58
00:01:56.632 --> 00:01:59.772
ancien CPO de Sunday et membre de notre collectif Stellar.

59
00:02:00.866 --> 00:02:01.269
Chez Sunday,

60
00:02:01.410 --> 00:02:03.444
Alex s'est imposé un rythme difficile à tenir.

61
00:02:03.844 --> 00:02:04.971
Arrivé premier employé de Sunday,

62
00:02:05.071 --> 00:02:07.144
il recrute 25 products en 18 mois,

63
00:02:07.344 --> 00:02:09.283
tout en maintenant un rythme de delivery très soutenu.

64
00:02:10.064 --> 00:02:10.911
Fort de son expérience,

65
00:02:10.972 --> 00:02:12.444
de ses réussites et de ses challenges,

66
00:02:12.704 --> 00:02:16.104
Alex a repéré 6 erreurs qui détruisent la vélocité d'une boîte tech.

67
00:02:16.724 --> 00:02:20.224
J'avais très envie qu'il m'en dise plus sur ces erreurs et les solutions concrètes pour les éviter,

68
00:02:20.484 --> 00:02:23.324
alors je l'ai invité sur ma newsletter Product Inbox en janvier dernier,

69
00:02:23.744 --> 00:02:26.104
et je te propose ici d'en faire la synthèse sur ce podcast.

70
00:02:27.417 --> 00:02:29.302
Pour commencer à creuser doucement le sujet,

71
00:02:29.663 --> 00:02:32.651
Alex m'a évoqué le premier écueil souvent vécu par les boîtes tech,

72
00:02:33.032 --> 00:02:34.496
les mises en production trop complexes.

73
00:02:35.436 --> 00:02:36.981
Par mise en production ou MEP,

74
00:02:37.322 --> 00:02:41.376
on entend le fait de faire passer des changements dans le produit utilisé en live par les clients.

75
00:02:41.916 --> 00:02:43.356
C'est le baptême du feu pour les derniers développements.

76
00:02:44.456 --> 00:02:45.118
Mais quel est le problème ?

77
00:02:45.761 --> 00:02:46.363
Au début de Sunday,

78
00:02:46.623 --> 00:02:50.216
Alex et les équipes de développeurs subissent de plein fouet les bugs inhérents à toute MEP.

79
00:02:51.215 --> 00:02:53.552
Ces bugs sont d'autant plus présents qu'un produit est jeune.

80
00:02:53.952 --> 00:02:55.457
La réaction initiale d'Alex et des équipes,

81
00:02:55.819 --> 00:02:59.672
c'est de sécuriser les MEP en ajoutant beaucoup de tests et en ralentissant le rythme.

82
00:03:00.252 --> 00:03:02.432
Alex souligne que ce changement entraîne deux problèmes.

83
00:03:03.072 --> 00:03:03.353
D'abord,

84
00:03:03.594 --> 00:03:08.032
le bug est perçu comme une erreur grave et les développeurs n'osent plus produire sans multiplier les vérifications.

85
00:03:08.852 --> 00:03:09.133
Ensuite,

86
00:03:09.333 --> 00:03:10.918
le rythme de MEP étant ralenti,

87
00:03:11.459 --> 00:03:13.204
chaque MEP contient trop de codes,

88
00:03:13.384 --> 00:03:16.272
la rendant trop complexe à auditer et générant encore plus de bugs.

89
00:03:16.853 --> 00:03:17.617
La conclusion d'Alex,

90
00:03:17.879 --> 00:03:20.592
c'est qu'il y a à la fois une perte de rythme et une perte de qualité.

91
00:03:21.697 --> 00:03:22.081
Heureusement,

92
00:03:22.222 --> 00:03:23.616
tout problème vient avec sa solution,

93
00:03:23.876 --> 00:03:24.842
puisque Arnaud Lemaire,

94
00:03:24.943 --> 00:03:26.271
alors VP Engineering de Sunday,

95
00:03:26.573 --> 00:03:27.116
et ses équipes,

96
00:03:27.756 --> 00:03:30.616
décident de suivre une philosophie simple en faisant des releases,

97
00:03:30.756 --> 00:03:32.116
ce qu'Alex qualifie de non-événements.

98
00:03:33.057 --> 00:03:34.169
Mais qu'est-ce que ça veut dire concrètement ?

99
00:03:34.856 --> 00:03:35.399
Pour faire simple,

100
00:03:35.520 --> 00:03:36.968
Alex recommande de faire de la MEP,

101
00:03:37.411 --> 00:03:38.236
une affaire bénigne,

102
00:03:38.757 --> 00:03:39.809
qui peut être faite par tous,

103
00:03:39.991 --> 00:03:40.476
à tout moment.

104
00:03:41.516 --> 00:03:41.838
D'abord,

105
00:03:41.919 --> 00:03:46.505
il faut diminuer le nombre de bugs faisant partie d'une mise en production en diminuant sa complexité,

106
00:03:47.048 --> 00:03:48.496
puis diminuer l'impact de chaque bug.

107
00:03:49.389 --> 00:03:52.148
Alex m'a partagé deux initiatives à pousser pour mettre ce système en place.

108
00:03:52.808 --> 00:03:53.110
Tout d'abord,

109
00:03:53.130 --> 00:03:54.760
il faut mettre en production beaucoup plus fréquemment,

110
00:03:54.921 --> 00:03:55.988
pour avoir des MEP plus petites.

111
00:03:56.608 --> 00:03:58.358
Des petits changements engendrent moins de bugs,

112
00:03:58.579 --> 00:04:00.188
et ça devient plus facile de corriger les petits problèmes.

113
00:04:01.028 --> 00:04:03.661
On peut donc réduire exponentiellement la durée des tests,

114
00:04:03.802 --> 00:04:05.008
laissant plus de place au développement.

115
00:04:05.888 --> 00:04:06.150
Ensuite,

116
00:04:06.210 --> 00:04:07.397
il faut simplifier le rollback,

117
00:04:07.538 --> 00:04:09.128
c'est-à-dire le retour à la release précédente.

118
00:04:09.948 --> 00:04:10.270
Pour Alex,

119
00:04:10.451 --> 00:04:13.688
un simple bouton doit pouvoir régler n'importe quel bug de production en une minute.

120
00:04:14.428 --> 00:04:15.717
Ça minimise l'impact d'un bug,

121
00:04:15.918 --> 00:04:17.328
et ça le banalise au sein des équipes.

122
00:04:18.381 --> 00:04:19.846
Tout comme les mises en production fréquentes,

123
00:04:19.887 --> 00:04:23.600
le rollback simplifié permet de diminuer encore plus la durée des phases de test.

124
00:04:24.600 --> 00:04:24.982
Selon Alex,

125
00:04:25.223 --> 00:04:26.148
tout ce process a payé,

126
00:04:26.751 --> 00:04:28.660
puisqu'il partage les résultats obtenus chez Sunday,

127
00:04:28.960 --> 00:04:32.371
qui est passé de deux situations d'urgence par semaine à moins d'une par mois,

128
00:04:32.853 --> 00:04:35.080
alors même que les MEP devenaient beaucoup plus fréquentes.

129
00:04:35.940 --> 00:04:38.651
Ces deux solutions ont permis à Sunday de décupler sa vélocité,

130
00:04:39.012 --> 00:04:41.060
tout en minimisant le nombre de problèmes en production.

131
00:04:41.801 --> 00:04:44.472
Ça a aussi permis d'instaurer plus de sérénité au sein des équipes,

132
00:04:44.512 --> 00:04:46.680
où chacun a confiance dans la solidité du produit.

133
00:04:47.470 --> 00:04:49.988
On poursuit cet épisode avec un deuxième écueil dont nous parle Alex,

134
00:04:50.208 --> 00:04:55.168
qui concerne le cycle de vie des développements et qui peut massivement impacter la valeur livrée par une équipe produit.

135
00:04:56.197 --> 00:04:58.094
Pour permettre aux développeurs de coder sans dérangement,

136
00:04:58.354 --> 00:05:01.314
beaucoup d'entreprises adoptent des cycles de développement longs sur leurs gros chantiers.

137
00:05:02.094 --> 00:05:06.333
Ces cycles de développement en mode sous-marin ne prévoient pas de mise en production intermédiaire.

138
00:05:07.174 --> 00:05:07.537
Selon Alex,

139
00:05:07.739 --> 00:05:09.354
cette situation amène deux problèmes majeurs.

140
00:05:10.014 --> 00:05:10.417
Le premier,

141
00:05:10.820 --> 00:05:12.754
c'est que peu de temps après ces développements massifs,

142
00:05:13.194 --> 00:05:18.074
on peut se retrouver à adapter la nouvelle fonctionnalité au produit actuel qui a continué à évoluer pendant cette période.

143
00:05:18.984 --> 00:05:22.462
Ça entraîne beaucoup de travail supplémentaire et les nouvelles dépendances sont difficiles à repérer,

144
00:05:22.962 --> 00:05:24.822
ce qui rend les mises en production sujettes aux bugs.

145
00:05:25.342 --> 00:05:26.206
Mais le plus gros problème,

146
00:05:26.488 --> 00:05:29.422
c'est qu'on se prive de tout retour utilisateur pendant ce laps de temps.

147
00:05:30.262 --> 00:05:31.469
En adoptant le mode sous-marin,

148
00:05:31.711 --> 00:05:36.062
on passe à côté de tous les retours utilisateurs qui auraient pu être obtenus en mettant en production plus tôt.

149
00:05:36.662 --> 00:05:37.425
Pour éviter cet écueil,

150
00:05:37.988 --> 00:05:41.162
la solution est de mettre tout développement en production régulièrement,

151
00:05:41.642 --> 00:05:43.242
à savoir au maximum toutes les deux semaines.

152
00:05:44.122 --> 00:05:47.182
Peu importe la taille du chantier et même si la fonctionnalité est incomplète.

153
00:05:48.316 --> 00:05:49.059
Dans le cas de Sunday,

154
00:05:49.321 --> 00:05:52.434
Alex explique que les équipes avaient pour mission de construire un ledger,

155
00:05:52.634 --> 00:05:55.733
c'est-à-dire une base de données comprenant toutes les transactions qui y passent.

156
00:05:56.154 --> 00:05:56.576
Concrètement,

157
00:05:56.817 --> 00:05:57.279
chez Sunday,

158
00:05:57.420 --> 00:05:58.525
si le ledger fait défaut,

159
00:05:58.666 --> 00:06:00.534
les restaurateurs ne reçoivent pas l'argent de leurs clients,

160
00:06:01.134 --> 00:06:03.814
ce qui concerne quand même des centaines de milliers de transactions par semaine.

161
00:06:04.434 --> 00:06:07.174
C'était un développement très complexe à faire sur plusieurs mois.

162
00:06:07.874 --> 00:06:08.297
Toutes les semaines,

163
00:06:08.297 --> 00:06:11.214
les équipes de Sunday mettaient une nouvelle partie de ce ledger en production,

164
00:06:11.714 --> 00:06:14.634
ce qui leur permettait de gagner en confiance sur le système qui tournait à vide au début,

165
00:06:15.055 --> 00:06:17.714
jusqu'à progressivement le brancher sur des parties de plus en plus larges du code.

166
00:06:18.348 --> 00:06:19.152
En adoptant cette approche,

167
00:06:19.212 --> 00:06:21.726
Sunday a réussi à éviter les écueils de développement massif,

168
00:06:22.006 --> 00:06:23.806
permettant une progression constante du projet,

169
00:06:23.986 --> 00:06:26.486
tout en bénéficiant des retours utilisateurs dès que possible.

170
00:06:27.447 --> 00:06:27.749
Ensuite,

171
00:06:27.789 --> 00:06:30.326
on a continué de creuser le sujet avec Alex sur les écueils à éviter,

172
00:06:30.586 --> 00:06:32.266
et il a choisi de me parler des équipes instables.

173
00:06:33.306 --> 00:06:33.770
En startup,

174
00:06:33.830 --> 00:06:35.766
on a envie de faire tourner régulièrement les membres d'une squad,

175
00:06:35.966 --> 00:06:37.315
composée de product managers,

176
00:06:37.315 --> 00:06:39.006
de product designers et de développeurs,

177
00:06:39.527 --> 00:06:40.766
pour éviter les silos de connaissances.

178
00:06:41.286 --> 00:06:46.486
On aimerait que chaque personne ait un niveau de connaissance suffisant pour agir sur chaque bout de notre code et produit.

179
00:06:47.223 --> 00:06:52.482
On a tous et toutes entendu parler d'une personne clé au sein de l'entreprise dont on redoute absolument qu'elle s'absente,

180
00:06:52.942 --> 00:06:54.802
car elle connaît les choses que personne d'autre ne sait.

181
00:06:55.702 --> 00:06:56.023
Pour Alex,

182
00:06:56.244 --> 00:06:57.648
le problème de ce genre d'organisation,

183
00:06:57.749 --> 00:07:01.942
c'est qu'il faut beaucoup de temps pour s'assurer que chaque membre d'une équipe est un bon niveau de connaissance global.

184
00:07:02.342 --> 00:07:04.189
A chaque fois qu'une personne change de périmètre,

185
00:07:04.650 --> 00:07:07.942
elle doit se remettre à niveau sur ce sujet et réapprendre à travailler avec sa nouvelle équipe.

186
00:07:08.755 --> 00:07:09.139
Évidemment,

187
00:07:09.260 --> 00:07:13.694
Alex m'a proposé une solution à ce problème et recommande de garder une équipe telle qu'elle pendant au moins 6 mois,

188
00:07:14.054 --> 00:07:14.821
dans le cas d'une startup,

189
00:07:15.366 --> 00:07:16.234
sur un périmètre précis.

190
00:07:16.874 --> 00:07:17.176
Selon lui,

191
00:07:17.357 --> 00:07:18.384
pour une entreprise plus mature,

192
00:07:18.444 --> 00:07:20.014
on peut même allonger cette période de stabilité.

193
00:07:20.954 --> 00:07:21.236
Bien sûr,

194
00:07:21.256 --> 00:07:24.954
les aléas de l'entreprise imposent parfois des changements d'organisation sur une ou deux personnes.

195
00:07:25.515 --> 00:07:30.334
Mais il faut éviter de généraliser ses mouvements au sein des équipes pour préserver sa vélocité et son efficacité.

196
00:07:30.834 --> 00:07:31.336
En conclusion,

197
00:07:31.558 --> 00:07:35.034
maintenir les équipes en place pendant une durée minimale donnée a deux conséquences positives.

198
00:07:35.973 --> 00:07:36.376
Tout d'abord,

199
00:07:36.417 --> 00:07:37.770
on obtient des équipes plus efficaces,

200
00:07:37.910 --> 00:07:42.410
puisque collaborer avec les mêmes personnes dans le temps aide à mieux connaître leur façon de réfléchir et de travailler.

201
00:07:43.130 --> 00:07:43.452
In fine,

202
00:07:43.613 --> 00:07:46.450
cette collaboration stable augmente l'efficacité de toute l'équipe.

203
00:07:47.507 --> 00:07:47.810
Ensuite,

204
00:07:48.011 --> 00:07:50.126
on construit une meilleure connaissance de son périmètre.

205
00:07:50.566 --> 00:07:58.306
Chaque membre d'une équipe devient expert de son périmètre en évitant la dispersion sur d'autres sujets et partage seulement la connaissance sur ce périmètre avec les autres membres de son équipe.

206
00:07:58.926 --> 00:07:59.308
Selon Alex,

207
00:07:59.549 --> 00:08:06.366
cette réorganisation modifie totalement la productivité des équipes en seulement 6 mois puisqu'elles se font confiance et vont deux fois plus vite dans leur mission.

208
00:08:07.341 --> 00:08:08.230
Et on ne va pas s'arrêter là,

209
00:08:08.392 --> 00:08:08.978
sur les écueils,

210
00:08:09.138 --> 00:08:13.358
car il y a encore des points d'attention à garder à l'esprit pour ne pas détruire la vélocité d'une boîte tech.

211
00:08:14.019 --> 00:08:15.578
Alex m'a donc présenté le suivant,

212
00:08:15.938 --> 00:08:17.838
qui concerne la collaboration trop séquentielle.

213
00:08:18.678 --> 00:08:19.063
En effet,

214
00:08:19.164 --> 00:08:20.198
dans de nombreuses boîtes tech,

215
00:08:20.398 --> 00:08:24.238
la collaboration au sein de l'équipe produit suit un schéma qui ressemble à la logique fordienne.

216
00:08:25.018 --> 00:08:25.642
Ce qu'on entend par là,

217
00:08:25.944 --> 00:08:27.998
c'est la division du travail sur les chaînes de production.

218
00:08:28.298 --> 00:08:33.838
On a d'abord la product manager qui réalise des spécifications de solutions sans avoir de retour des techs et des designers.

219
00:08:34.995 --> 00:08:38.674
On a aussi la designer qui sort des maquettes abouties mais difficiles à coder,

220
00:08:38.874 --> 00:08:44.374
et enfin les développeurs qui codent une solution qui ne respecte pas 100% de la maquette et des specs par manque de temps.

221
00:08:45.354 --> 00:08:47.694
Alex m'a parlé de son expérience et m'a partagé qu'au début de Sunday,

222
00:08:47.914 --> 00:08:52.274
les PM avaient de gros périmètres produits et passaient trop de temps à encadrer les développements en cours.

223
00:08:52.557 --> 00:08:54.194
Ils n'avaient plus le temps de penser à l'après.

224
00:08:54.514 --> 00:08:55.018
En plus de ça,

225
00:08:55.219 --> 00:08:57.214
les développeurs et designers étaient frustrés.

226
00:08:57.654 --> 00:09:00.174
Les premiers car ils recevaient des designs trop complexes à coder,

227
00:09:00.394 --> 00:09:02.274
les seconds car leur design n'était pas respecté.

228
00:09:03.085 --> 00:09:03.549
Dans ce schéma,

229
00:09:03.791 --> 00:09:05.142
Alex identifie un gros problème.

230
00:09:05.902 --> 00:09:08.262
Chaque membre de l'équipe accomplit son rôle de manière linéaire,

231
00:09:08.562 --> 00:09:10.882
ce qui apporte un sentiment de sécurité et de clarté.

232
00:09:11.882 --> 00:09:12.204
Cependant,

233
00:09:12.405 --> 00:09:19.582
cette approche ne garantit pas la livraison d'un produit de haute qualité qui prend en compte toutes les contraintes et utilise pleinement les connaissances de chaque membre de l'équipe.

234
00:09:20.462 --> 00:09:20.926
Par exemple,

235
00:09:21.026 --> 00:09:23.242
les spécifications du produit ne sont pas toujours respectées,

236
00:09:23.402 --> 00:09:25.142
ce qui entraîne de la frustration pour la PM.

237
00:09:26.007 --> 00:09:26.370
De même,

238
00:09:26.672 --> 00:09:28.346
lorsque la maquette n'est pas suivie à la lettre,

239
00:09:28.606 --> 00:09:30.806
cela peut conduire à l'insatisfaction du product designer.

240
00:09:31.446 --> 00:09:31.849
De plus,

241
00:09:32.151 --> 00:09:39.066
un processus de développement fastidieux et stressant peut générer de la frustration chez les développeurs qui peuvent se sentir dépassés par les exigences du projet.

242
00:09:40.346 --> 00:09:41.091
Pour résoudre ce problème,

243
00:09:41.272 --> 00:09:47.606
Alex m'a recommandé de passer d'une logique séquentielle à une logique en boucle dans laquelle l'APM amène la designer et le tech en discovery.

244
00:09:48.556 --> 00:09:51.074
La designer s'assoit avec le tech pour faire une ébauche.

245
00:09:51.414 --> 00:09:56.194
Le tech code une fonctionnalité minimale et la montre à la designer qui y terre et ajuste ensemble.

246
00:09:57.094 --> 00:09:59.174
Cette solution a fonctionné en moins de deux mois chez Sunday.

247
00:09:59.700 --> 00:10:00.725
Pour continuer sur notre lancée,

248
00:10:00.866 --> 00:10:03.358
Alex m'a ensuite parlé d'un cinquième écueil à éviter,

249
00:10:03.798 --> 00:10:05.738
les process excessifs dans la collaboration.

250
00:10:06.598 --> 00:10:07.000
En effet,

251
00:10:07.282 --> 00:10:12.378
certaines entreprises mettent en place des process rigides pour construire leurs produits afin de contrôler et éviter tout risque.

252
00:10:13.158 --> 00:10:17.098
Alex a par exemple mentionné un document justifiant la valeur business d'un développement,

253
00:10:17.838 --> 00:10:20.538
la demande de validation par le product manager pendant un sprint,

254
00:10:21.239 --> 00:10:22.738
la création d'une maquette par un designer,

255
00:10:23.278 --> 00:10:26.538
la création d'un ticket sur Jira ou encore le scoping par l'équipe tech.

256
00:10:27.645 --> 00:10:29.412
Le problème avec ce genre de process pour Alex,

257
00:10:29.834 --> 00:10:31.982
c'est qu'ils sont inadaptés aux petits chantiers par nature,

258
00:10:32.562 --> 00:10:36.155
comme par exemple changer la position d'un bouton ou corriger un bug mineur,

259
00:10:36.737 --> 00:10:37.982
car ils font perdre beaucoup de temps.

260
00:10:38.542 --> 00:10:43.718
Il ajoute que cette lourdeur dans les process empêche les entreprises qui y ont recours de régler un bug dans la journée,

261
00:10:44.059 --> 00:10:45.162
les faisant perdre en agilité.

262
00:10:46.403 --> 00:10:46.864
En plus de ça,

263
00:10:46.904 --> 00:10:53.022
les équipes business deviennent frustrées puisque la friction pour des changements minimes les laisse dans l'incompréhension et diminue leur visibilité sur l'avenir du produit.

264
00:10:53.422 --> 00:10:56.782
Ils ont l'impression que leurs problèmes sont incompris et que leur urgence n'est pas partagée.

265
00:10:57.563 --> 00:11:04.142
Alex souligne également la dégradation de la vélocité comme les équipes produits sur ton startup gèrent des dizaines de petits développements par semaine.

266
00:11:05.042 --> 00:11:10.562
Rajouter un process de 5 minutes sur chaque développement entraîne une charge supplémentaire très forte aux dépens de la production.

267
00:11:11.342 --> 00:11:16.792
La solution se trouve dans l'équilibre entre la simplicité sur les petits chantiers qui passent par de la communication directe,

268
00:11:17.173 --> 00:11:18.495
communication orale de préférence,

269
00:11:19.036 --> 00:11:20.519
et la structure sur les gros paris,

270
00:11:21.020 --> 00:11:22.002
dits bets en anglais.

271
00:11:22.524 --> 00:11:25.255
Les équipes s'alignent sur l'objectif et la solution envisagée,

272
00:11:25.596 --> 00:11:26.982
puis elles mesurent le résultat du pari.

273
00:11:28.168 --> 00:11:34.378
Alex conclut en disant que résoudre simplement et rapidement les petits problèmes permet d'aller vite là où l'investissement en développeurs,

274
00:11:34.699 --> 00:11:35.542
et donc le risque,

275
00:11:36.044 --> 00:11:36.406
est faible.

276
00:11:37.106 --> 00:11:41.166
Les équipes business se sont écoutées et ont entre les mains un produit stable et bien fini.

277
00:11:42.019 --> 00:11:42.729
Pour les gros chantiers,

278
00:11:42.729 --> 00:11:43.134
en revanche,

279
00:11:43.434 --> 00:11:46.274
des bons process aident à produire les bonnes solutions aux bons problèmes.

280
00:11:46.914 --> 00:11:49.254
On termine cet épisode en beauté par notre dernier écueil,

281
00:11:49.414 --> 00:11:51.494
ce qu'Alex appelle la roadmap produit non objectivé.

282
00:11:51.974 --> 00:11:52.416
Concrètement,

283
00:11:52.416 --> 00:11:55.634
la roadmap est probablement l'outil le plus populaire des équipes produites tech.

284
00:11:56.134 --> 00:11:57.059
Dans la plupart des startups,

285
00:11:57.159 --> 00:12:00.294
le format utilisé est appelé feature-based roadmap,

286
00:12:00.614 --> 00:12:02.314
soit une roadmap basée sur les fonctionnalités.

287
00:12:02.854 --> 00:12:05.914
Bien que l'utilisation des feature-based roadmaps soit généralisée,

288
00:12:06.214 --> 00:12:07.427
son efficacité est discutable,

289
00:12:07.548 --> 00:12:08.134
surtout en startup.

290
00:12:09.060 --> 00:12:09.443
Selon Alex,

291
00:12:09.504 --> 00:12:09.866
en effet,

292
00:12:09.967 --> 00:12:13.958
les roadmaps basés sur les fonctionnalités donnent de la visibilité sur le futur du produit pour les mois à venir.

293
00:12:14.538 --> 00:12:17.418
Mais elles ne garantissent pas l'impact des fonctionnalités prévues.

294
00:12:17.958 --> 00:12:18.441
Plus simplement,

295
00:12:18.562 --> 00:12:21.338
les feature-based roadmaps favorisent le développement du produit,

296
00:12:21.778 --> 00:12:22.938
mais pas le développement d'entreprises.

297
00:12:23.298 --> 00:12:24.978
Alex considère que pour impacter ce dernier,

298
00:12:25.438 --> 00:12:27.858
la roadmap devrait non pas promettre des fonctionnalités,

299
00:12:28.298 --> 00:12:30.838
mais engager des résultats business chiffrés et mesurables.

300
00:12:31.855 --> 00:12:32.759
Pour illustrer ce sujet,

301
00:12:33.100 --> 00:12:36.334
on a ensuite fait une petite étude de cas avec Alex sur Netflix,

302
00:12:36.874 --> 00:12:37.579
un exemple fictif,

303
00:12:38.103 --> 00:12:44.434
en étudiant différents types de roadmaps que vous pourrez retrouver dans l'édition de la newsletter que je vous mets directement en description d'épisode.

304
00:12:45.457 --> 00:12:46.894
Avec le modèle des fonctionnalités fictives,

305
00:12:47.014 --> 00:12:49.274
on a une idée claire des fonctionnalités sur le point d'être développées.

306
00:12:49.474 --> 00:12:49.877
En revanche,

307
00:12:50.340 --> 00:12:54.014
c'est impossible de s'assurer d'une responsabilisation de l'équipe technique sur leur impact business.

308
00:12:55.094 --> 00:12:56.394
Alex m'a alors fait part de sa solution,

309
00:12:56.714 --> 00:13:00.254
qui consiste à transformer la roadmap pour ne plus réfléchir en fonctionnalités,

310
00:13:00.336 --> 00:13:00.973
mais en résultats.

311
00:13:01.844 --> 00:13:02.146
Pour ça,

312
00:13:02.468 --> 00:13:04.942
on introduit ce qu'on appelle une outcome-based roadmap.

313
00:13:05.482 --> 00:13:07.062
Ce format ne fait plus apparaître de fonctionnalités,

314
00:13:07.582 --> 00:13:11.322
on y inscrit directement des résultats chiffrés et mesurables qui sont définis au préalable.

315
00:13:12.938 --> 00:13:13.159
Voilà,

316
00:13:13.481 --> 00:13:14.730
j'espère que cet épisode t'a plu.

317
00:13:16.733 --> 00:13:17.217
Si c'est le cas,

318
00:13:17.499 --> 00:13:18.770
tu peux me soutenir de deux façons.

319
00:13:19.130 --> 00:13:25.090
Laisser 5 étoiles sur Apple Podcasts ou Spotify et un petit commentaire ou partager cet épisode à une personne de ton entourage.

320
00:13:26.491 --> 00:13:27.990
Je te remercie vraiment pour tes retours.

321
00:13:28.270 --> 00:13:31.650
C'est grâce à toi que j'améliore Clint Wood pour le rendre utile à ton quotidien.

322
00:13:34.093 --> 00:13:38.050
Je te donne rendez-vous la semaine prochaine pour un tout nouvel épisode riche en contenu actionnable.

323
00:13:38.530 --> 00:13:38.920
À très vite !