Réponse rapide


J’ai parlé ailleurs des pièges de la confusion entre le lancement de produit et le succès, et de l’importance de ne pas perdre le focus après avoir expédié votre produit ou service. Dans cet article, je voulais en dire un peu plus sur ce que vous devriez faire pendant cette phase critique de votre projet.

Dans trop d’organisations, les ressources qui ont été mobilisées pour construire et lancer le produit s’évaporent très rapidement après le lancement afin de sauter sur le prochain projet à venir. C’est particulièrement regrettable car c’est le moment où votre opportunité d’apprentissage et de correction est la plus grande. Je considère cela comme un échec du processus de gestion de projet et de développement de produit qui peut être corrigé simplement en étendant légèrement le projet pour incorporer cette phase critique. Aucune phase du processus ne fournira un meilleur retour sur investissement que celui-ci, donc ce changement n’est pas un argument difficile à gérer.

Je recommande fortement que toutes les équipes de projet planifient une phase qui commence au lancement et dure au moins deux semaines, et peut-être plus. J’appelle cette phase «réponse rapide» pour souligner qu’il s’agit de répondre rapidement à ce que vous apprenez une fois le produit lancé.

Notez que bien que cette approche soit née des services Internet grand public où cela est particulièrement critique et bien adapté, je pense qu’elle est également importante pour la plate-forme, l’infrastructure et les produits d’entreprise.

Même si vous avez fait tous les premiers prototypes et tests de validation avant l’ingénierie que je préconise, et que vous avez une excellente équipe d’assurance qualité, le produit est donc fiable, vous devez toujours vous attendre à ce qu’il y ait des problèmes qui ne pourront être découverts qu’une seule fois tu es en direct. L’approche typique consistant à attendre de voir quelle est la réponse et s’il y a des problèmes, puis à essayer de planifier des versions ponctuelles de suivi suivant le même cycle général prend beaucoup trop de temps et coûte trop cher.

La question n’est pas de savoir s’il y aura des problèmes, mais plutôt à quelle vitesse vous les réglerez?

Les trois clés du succès sont: a) une image claire de la façon dont vous mesurez le succès; b) la rapidité avec laquelle vous pouvez identifier ce qui se passe; et c) la rapidité avec laquelle vous pouvez répondre.

Pour mesurer le succès, vous devez disposer d’un ensemble clair et hiérarchisé de mesures commerciales. Cherchez-vous des pages vues? Utilisateurs enregistrés? Du temps sur place? Taux de conversion du visiteur au membre? Des abonnements? Revenue publicitaire? Le bon ensemble de statistiques dépendra de votre produit et de vos objectifs commerciaux, mais dans tous les cas, vous devez savoir ce qui vous intéresse et ce que vous suivrez. De plus, vous devez savoir quels résultats vous considéreriez comme un succès et ce que vous considéreriez comme un problème.

En ce qui concerne la façon dont les utilisateurs réagissent à votre produit, pour les services aux consommateurs, il n’a jamais été aussi facile de comprendre comment les gens utilisent votre produit ou service. Il est facile d’instrumenter et de suivre l’activité. Il existe de nombreux produits dans cet espace, mais j’ai été particulièrement impressionné par la récente acquisition par Google d’Urchin, désormais appelé “Google Analytics” (www.google.com/analytics). Ces services peuvent vous informer rapidement et facilement sur la façon dont vos utilisateurs utilisent votre service.

Pour les logiciels d’entreprise, j’aime envoyer des membres de l’équipe produit – chef de produit, ingénieurs, concepteurs – sur le site du client pour être là avec eux lorsqu’ils installent le logiciel et travaillent pour le faire vivre et l’utiliser. Il est étonnant de constater à quel point les problèmes sont identifiés et résolus beaucoup plus rapidement lorsqu’un membre de l’équipe comprend qu’il sera sur le site du client jusqu’à ce que le client soit opérationnel et référençable.

Une fois les problèmes identifiés, l’équipe produit doit se réunir (au moins quotidiennement), hiérarchiser les problèmes et discuter de la meilleure façon de répondre. Le résultat peut être un «correctif» qui est précipité sur le site, ou peut-être un contenu supplémentaire expliquant les zones à problème. Si l’équipe est préparée à ces changements et comprend à quel point il est essentiel d’apprendre et de réagir rapidement, alors en très peu de temps, l’équipe peut apporter des améliorations substantielles à l’efficacité du produit ou du service.

L’analyse de site Web n’est certainement pas le seul outil que vous devez utiliser pour comprendre vos utilisateurs et ce qu’ils pensent de votre site. Des sondages, des discussions par courrier électronique, des tableaux, des tests sur le terrain, sont d’autres exemples. Mais les données fournissent des informations tellement en temps réel que j’examine l’analyse du site Web pour tous les sites dans lesquels je suis impliqué presque quotidiennement. Je regarde d’où viennent les gens, quelles sont leurs pages et activités préférées, combien de temps les gens passent sur le site, combien de pages ils consultent et à quelle fréquence ils reviennent.



Source

  • Partager cet article

Laisser un commentaire