Pourquoi choisir des cycles d'engagement et de développement courts

Je discutais il y a deux jours avec un spécialiste de l’e-commerce qui me rappelait à quel point fidéliser ses clients était fondamental pour atteindre la rentabilité. Le problème est encore plus critique en e-commerce, où le coût d’acquisition d’un nouveau client est souvent supérieur à ce que son premier panier rapporte.

Au delà de cette évidence – les choses simples le sont toujours, n’est-ce pas ? – il nous expliquait l’intérêt de mettre en place des cycles d’engagements courts.

Parce qu’ils leur assurent des revenus sur une longue période, les cycles d’engagement longs, de un à trois ans, ont toujours eu les faveurs des entreprises. Ils posent pourtant deux problèmes :

• Côté client, on s’engage plus facilement sur une courte durée à moins d’être certain que le produit ou le service correspond réellement à nos besoins et que le retour sur investissement sera positif.
• Côté marchand, on doit attendre un an pour vérifier que son modèle est bon et que les clients reviennent. Or, un an, dans la vie d’une jeune entreprise, c’est très long.

Quel rapport avec les cycles de développement d’un produit ?

Je voyais la semaine dernière un ami qui m’exposait la roadmap de son produit. Il tablait sur des cycles de release très courts – 45 jours au plus – avec chaque fois des apports fonctionnels non pas minimes, mais suffisamment marginaux pour

1. Ne pas perdre les clients existants en leur apportant chaque fois un produit révolutionné
2. Pouvoir revenir facilement en arrière s’il s’aperçoit qu’il s’est trompé de route

Ces cycles de développement courts ne doivent pas faire oublier les chantiers de fond, nécessaires pour garder une base saine à mesure que le produit s’enrichit. Mais là encore, ils permettent de tester son modèle sur des durées assez courtes pour prendre le bon virage quand le besoin s’en fait sentir.

Quand j’ai commencé à développer, une des premières choses que l’on m’ait apprise était release early, release often. Mes dernières observations, discussions et enseignements me font également de plus en plus pencher pour un sell early, sell often.

Si cet article vous a plu, suivez-moi sur Twitter

2 commentaires sur Pourquoi choisir des cycles d'engagement et de développement courts »

1. 

   Par Thomas Tourlourat le 24 juin 2010 à 14h33 :

   
   

   “45 jours au plus – avec chaque fois des apports fonctionnels non pas minimes, mais suffisamment marginaux pour”

   Whaou. On parle de mise à jour qui révolution l’outil ? Ou simplement une fonctionnalité supplémentaire ?

   Mais, les clients ne préfèrent-ils pas une version fonctionnelle qui n’évolue pas tout les 4 matins ? Car s’il faut reformer le personnel, ca doit être un sacrée bordel..

2. 

   Par maxime le 24 juin 2010 à 17h31 :

   
   

   Non je pense qu’il s’agit d’évolution, pas de révolution. De toute façon, bosser 6mois sur un gros dev c’est la meilleure façon de se lancer dans une idée super 6Mois avant et dépassé 6mois apres, ou alors avec un mauvais timing, ou alors ne pas donner l’impression que le service n’évolue pas, ou alors de faire en sorte de ne pas choquer les utilisateurs existants avec une grosse mise à jour.

   Coté économique, c’est pareil, ça permet de coller avec une réalité, de pouvoir communiquer plus aisément sur les mises à jours concretes, à courts termes qui intéressent et démontrent une volonté d’action.

   Pour tout le reste, c’est bien expliqué dans l’article

Trackbacks sur Pourquoi choisir des cycles d'engagement et de développement courts

Les trackbacks sont fermés pour cause de spam.