Les erreurs à commettre pour rater le lancement de son application B(2B)2C

Prenons le problème à l’envers. 

D’habitude, on trouve sur internet tout un tas d’articles pour indiquer

“Les 7 erreurs à ne pas commettre pour lancer son application mobile”

ou bien “Les 5 conseils ultimes pour réussir son projet d’application mobile”.

Très bien, ces ressources sont toujours utiles d’un point de vue théorique pour atteindre les fameux 10% de chances de réussir.

Ce que nous proposons à travers cet article, c’est de démontrer ce qu’il faut faire pour avoir 99,9% de chances d’échouer.

Voici du concret inspiré de faits réels pour (au choix) : 

• mettre à mal son projet digital

• répondre à un besoin déjà assouvi

• retarder la mise en ligne et faire exploser les coûts et les délais

Cet article s’adresse aux porteurs de projet, innovants ou pas, dans un marché saturé ou non (quoi qu’on en dise, ces deux points restent des facteurs à impacts mineurs sur le résultat d’un lancement de produit).

Plutôt sur une cible B2C ou B2B2C (le B2B c’est différent).

Vous êtes entrepreneurs sur le digital ou en charge du marketing dans une TPE-PME ?

Si ces quelques retours d’expériences vous font réagir, contactez-moi pour en parler. Le sujet est trop grave pour le garder pour soi !

Commencer par les maquettes graphiques avant toute chose

Indéniablement, un classique consiste par avoir une idée de lancement de produit (digital) et de contacter son graphiste en interne ou son freelance designer pour sortir des maquettes !

Il faut en effet d’urgence que toutes ces idées nichées dans le cortex surgissent et s’animent sur des maquettes graphiques, les plus belles possibles soient-elles.

Effet waouh garanti !

Sauf que sans cahier des charges, le designer fait son possible pour transformer des idées, des vocaux, des “tu vois bien de quoi je parle ?” sur des maquettes qui au final :

• manque de cohérence

• n’ont pas de vision technique

• ne répondent pas à un objectif business

Si une charte graphique est déjà existante, tant mieux, car il existe une base.

Sinon, elle n’existe pas et elle se construit (tant bien que mal) au fil du temps.

Dans un projet d’application mobile, le design system est le prince oublié.

Avoir une v1 prête à la mise en ligne et modifier 20% des fonctionnalités

C’est du garanti. L’application “sur maquettes” est prête.

Elle a été recettée (testée de A à Z dans le jargon).

Après des semaines, des mois d’efforts, l’application est telle que désirée. L’équipe projet est motivée comme jamais, car un lancement, ce n'est pas tous les jours non plus !

Sauf qu’au moment de donner son accord pour la mise en ligne, le chef de produit de l’application a des nouveaux éclairs de lucidité (ou bien fait tester l’application à sa femme) et décide de modifier 20% des fonctionnalités de l’application.

Sur un coup de tête.

En pensant que c’est ce qu’il faut faire (c’est certain !), et sans en parler avec un vrai (futur) utilisateur.

Résultat, le circuit de production se remet en branle :

• des nouvelles maquettes graphiques sont exécutées en urgence (vite !)

• les développeurs sont mis à contribution (vite, vite !)

• les testeurs aussi (un peu plus de bugs qu’en v1 tiens)

La chaine de production est mise sous pression car c’est un premier retard à l’allumage.

Parler du concept au décisionnaire final une fois le projet développé

Enfin (!) l’application et ses ajustements de dernière minute, mais non moins essentiels, sont prêts.

Il est grand temps d’exposer le fruit du dur labeur au grand patron.

Sauf que là, c’est la douche froide !

Impossible, selon le grand chef, que ça fonctionne avec ce qu’il voit sous ses yeux ébahis.

Ni une ni deux, il distille à la volée les grandes lignes directionnelles des nouvelles modifications à effectuer (la v3 donc).

C’est reparti pour un tour : design, développeurs, testeurs… L’équipe de production, qui a l’expérience des virevoltes, sent que le projet commence à tourner au vinaigre.

Les délais s’allongent.

La facture devient salée.

Toute l’équipe projet, unie au départ, commence à se regarder en chiens de faïence.

Un projet digital, une application mobile, c’est un bout d’aventure humaine avec des gens qui ont des rêves et d’autres qui sont là pour les accompagner à les réaliser.

Il ne faut pas l’oublier.

Parler à ses utilisateurs (payants) après avoir passé des mois de travail et dépensé des milliers d’euros

Ne parler surtout pas à vos utilisateurs payants avant de développer le projet et vous perdrez du temps et de l’argent au mieux, ou vous irez dans le mur au pire.

Trop de porteurs de projets pensent à la place de leurs (futurs) clients au lieu de leur parler.

L’empathie a sa limite. Elle s’appelle la trésorerie.

Avoir une vision stratégique basée uniquement sur les détails fonctionnels du produit

Aie ! Ici, on est en plein dans le “Vendez-moi ce stylo” du Loup de Wall Street.

Souvent, la stratégie (globale) est basée sur des détails fonctionnels du produit qui font que le porteur de projet est obnubilé par des priorités mineures (pour ne pas dire des futilités).

Pourtant, toute la littérature du lean start up est claire là-dessus : dans le cadre d’un lancement de produit, un porteur de projet ne doit être obnubilé que par trois points :

• lancer le plus rapidement possible sur le marché

• se focaliser sur l’acquisition, l’acquisition, et … ah oui, l’acquisition !

• itérer par sprints avec les retours des utilisateurs

Si vous n’êtes pas avertis à cela (ce qui n’est plus le cas maintenant), alors le chemin risque d’être semé d’embûches.

Miser sur le ressenti pour savoir si le projet va dans le bon sens

En début de projet, ne poser surtout pas d’objectifs chiffrés pour avoir un but à atteindre en tant que décideur.

Cela évitera de mener l’équipe projet dans une direction commune.

Le fumeux ressenti fait son apparition à coup sûr car les indicateurs clés de performances n’existent pas vu que personne ne sait vraiment ce qu’il faut mesurer.

Mesurer quoi pour répondre à quoi ?

Ne reste alors plus que le ressenti qui est un biais comportemental et qui a autant de réponses différentes que de personnes qui y répondent.

Lancer un projet qui est un copycat sans valeur ajoutée

Ce concept que vous avez en tête est très peu concurrentiel et il est dominé par un acteur en situation de monople.

Là où il y a un numéro 1, il y a toujours un numéro 2 ! pensez-vous ?

Internet est passé par là et là où il y a un numéro 1, il n’y a pas nécessairement de numéro 2 (exemples des places de marché ultra-dominatrices et tant d’autres…).

Les utilisateurs (oui, encore eux) :

• sont lassés qu’on les prenne pour des tiroirs caisse (un abonnement par-ci, un abonnement par là…)

• sont paresseux et ne recherchent pas la nouveauté à tout prix

• veulent des services qui leur facile la vie (confort)

• ou leur fasse faire des économies (argent)

• ou leur fasse gagner de l'fficacité (temps)

• améliore leur santé ou leur environnement (bien que…)

• ou améliore leur statut social (rencontres…)

Changer sa stratégie de lancement de produit au dernier moment

Revenons au développement du projet pendant sa phase initiale version numéro 1.

À ce moment-là, la stratégie est de faire un coup de buzz ! Miser gros dès le début : ça prendra fort au début ou jamais à la fin !

Des lignes de budget sont prévues pour faire de la publicité en ligne ou pour louer les services d’une agence en création de buzz !

Sauf que rappelez-vous, le porteur de projet a cassé 20% des fonctionnalités pour la v2 et que le grand chef a brisé l’élan avec la v3.

Résultat des courses, elle est passée où la ligne pour la pub ?

Et ça, c’est au dernier moment que le porteur s’en aperçoit.

Faire intervenir un nouvel intervenant en cours de projet

Vous rencontrez fortuitement une nouvelle personne qui vous fait une forte impression, qui parle bien, mais qui n’y connait en fait pas grand-chose (manque d'expérience par exemple).

Vous êtes cette personne et vous intégrez le train du projet en marche. Que faites-vous pour vous faire respecter ?

Vous démontez les en-cours, auréolé par votre aplomb, vous êtes écoutés par le décideur. 

Car si vous dites que ce qui est en place est correct, à quoi servez-vous ?

Résultat : une petite v4 des familles (avec son délai supplémentaire et ses frais associés, sans parler aux utilisateurs et en dégradant la cohésion d’équipe).

Penser que du jour au lendemain des milliers d’utilisateurs seront au rendez-vous

C’est le biais du survivant. Penser que parce que les géants du numérique l’ont fait, alors le prochain Zuc’ est en face du miroir.

Un lancement from scratch, sans bâtir de communauté en parallèle du lancement, c’est comme partir avec son bâton de pèlerin pour traverser le pays en marchant sur les chemins noirs à côté d’une autoroute.

Pensez qu’une application dure toute seule dans le temps

Un lancement de projet est souvent considéré comme un accouchement.

Ne dit-on pas que son projet est “son bébé” ?

Sauf que bébé ne grandit pas tout seul, il faut le nourrir, l’éduquer, le surveiller comme le lait sur le feu (et je sais de quoi je parle) !

Penser que son application fonctionnera sans faille pendant longtemps dans un écosystème digital en évolution continue n'est pas sérieux.

En espérant que ces quelques préceptes vous seront fort utiles, vous aurez saisi que certains propos étaient tournés en dérision pour mettre en évidence certains points qui peuvent prêter à sourire ici, mais qui arrivent malheureusement.

Vous l’aurez sans nul doute compris, être accompagné par des spécialistes expérimentés comme notre service copilote technique est un atout dans votre manche et comme dirait un décideur un peu (trop) confiant : on a un full aux as avec ce projet !

Rédigé par Guillaume Dupuis

Sources

Environ 90% des starts-up échouent complètement : https://startupgenome.com/fr/article/the-state-of-the-global-startup-economy

Lean start-up : adoptez l'innovation continue : https://www.youtube.com/watch?v=RDTiI8E4rW0

Vendez-moi ce stylo, Le Loup de Wall Street, vidéo Julien Raffin : https://www.youtube.com/watch?v=w2mNrkvxJ0c

Les 3 niveaux de développement de produit, par Timothée Frin :