Wesabe vs Mint : les vraies raisons de l’échec

C’est toujours intéressant de connaître l’histoire des vainqueurs, d’essayer de lire dans cette histoire pour comprendre quels ont été les critères de succès. Mais très souvent ça ne sert à rien, à cause de la fâcheuse tendance de l’être humain à voir des causes là ou n’y en a pas.

Ce qui est bien plus intéressant c’est de connaître l’histoire des perdants. Surtout quand ils arrivent à prendre suffisamment de recul pour comprendre d’où est venu l’échec. Et le dernier en date à se livrer à cet exercice publiquement est Marc Hedlund, co-fondateur de Wesabe (aujourd’hui l’appli a disparu, il ne reste « que » la communauté). A la base, Wesabe était la première application en ligne de gestion de compte, un type d’application désormais défini comme Mint-like. Le principe: on upload ses extraits de compte et l’application génère automatiquement du reporting financier mignon qui permet de comprendre pourquoi on est toujours à découvert dès le 15 du mois.

L’article en question est vraiment à lire, il se trouve par là.

Dans la première partie de son analyse, Mister Hedlund explique les raisons, souvent évoquées par la presse, qui selon lui ne sont pas à la base de leur échec:

  • Que Mint soit sorti en premier. C’est faux: c’est Wesabe qui est sorti en premier, et ils ont même réussi à prendre une bonne longueur d’avance en terme de nombre d’utilisateurs. Mais Mint a profité des débuts de Wasabe pour observer dans l’ombre et comprendre ce qu’il fallait faire, et ne pas faire. Le premier n’est donc pas toujours le gagnant.
  • Wesabe n’a jamais fait d’argent. C’est faux mais pas vraiment pertinent par rapport à cet article 🙂
  • Mint a un meilleur nom et un meilleur design. C’est vrai, mais Marc Hedlund ne pense pas que ça ait été un point déterminant dans la victoire de Mint. J’ai tendance à penser que si, tout du moins pour le design. Pour viser le grand public, il vaut mieux une appli belle mais un peu foireuse sur les bords que l’inverse, contrairement aux professionnels, qui sacrifieront la beauté pour les fonctionnalités. Pour moi, il faut d’abord que (1) l’appli fonctionne et fonctionne rapidement, ensuite (2) qu’elle soit belle, enfin (3) qu’elle couvre l’intégralité du périmètre fonctionnel. Mint a les deux premiers, Wesabe a tenté le premier et le dernier.
  • Wesabe n’a pas été viral alors que Mint oui. Faux: les deux l’ont été plus ou moins.

Mais alors, si ce ne sont pas ces raisons qui ont provoqué la chute de Wasabe, quelles sont les vraies raisons? Pour Marc Hardlund c’est:

Une erreur d’exécution : Ils ont eu un choix difficile à faire pour une fonctionnalité clef de l’application: le moteur de conversion automatique des fichiers uploadés provenant de la myriade de banques des utilisateurs dans leur modèle de stockage unique. Honnêtement, j’aurai fait le même choix qu’eux: re-développer en interne plutôt que d’utiliser celui de l’unique fournisseur à la réputation plus que sulfureuse. Mint a eu moins de scrupule, ça a payé: ils ont eu accès à la fonctionnalité d’upload automatique (sans retravail des utilisateurs donc) avant Wasabe qui avait été lancé 6 mois plus tôt.

Une erreur de design :  Mint part du principe que l’utilisateur ne doit rien faire, le moteur va donc essayer de ranger automatiquement les dépenses qui apparaissent sur les relevés de compte de l’utilisateur dans des catégories type loisir, restaurants, loyer… Évidemment ça donne des résultats bien foireux, mais ça donne des résultats. L’utilisateur de Mint a donc accès à un graphique de ses comptes dès les premières minutes de l’utilisation de l’application. A côté de ça, l’utilisateur Wasabe devait saisir et saisir et corriger et saisir et trier et saisir avant d’avoir le même résultat. Ok Mint n’est précis qu’à 80%, mais il donne un résultat quand Wasabe ne donne rien.

Ce qu’il faut retenir de cette aventure c’est que l’équipe de Wasabe a fait tous les bons choix par rapport à l’inscription du business dans le long terme: un moteur développé en interne, des résultats d’une grande qualité. Mais ils étaient placés face à des concurrents prêts à choisir des solutions court termes pour gagner absolument et tuer la concurrence. C’est ce qu’il s’est passé. C’est triste, mais certainement pas incontournable.

Le fait d’inscrire son business dans une stratégie long terme n’implique pas de renoncer à employer des tactiques court termes. C’est même strictement nécessaire pour lutter contre des business qui eux ne vivent qu’autour de leur stratégie court terme.

Comment cela s’applique pour Wasabe? Si la fonctionnalité d’import automatique était tant critique ils auraient dû lancer les 2 efforts en parallèle: développer leur propre moteur en interne, au calme, pour le long terme, et utiliser celui du fournisseur foireux à court terme pour gagner le sprint initial. Si les utilisateurs voulaient avoir un premier rapport rapidement après s’être inscrit, alors il fallait le leur offrir, même s’il était incomplet voir faux. Ensuite, rien n’empêchait d’éduquer progressivement ses utilisateurs (tout du moins la partie réceptive), en utilisant un bon design, pour les encourager à aller plus loin et faire mieux, et à ce moment leur offrir les outils pour le faire.

Et comme d’habitude, je conclue en faisant le lien par rapport au métier de consultant, où là aussi il faut savoir utiliser des tactiques à court terme pour faire progresser ses clients sur le long terme. Parce qu’il ne faut pas oublier que lorsqu’on se fait sortir d’un compte par des concurrents qui utilisent des techniques court terme, ça rend la tâche difficile pour faire progresser ses clients… qu’on a plus…

4 liens rapides pour la semaine (2010-42)

Et hop:

  1. Au cas où vous manquiez de volonté en ce moment : un petit remontant.
  2. Comment empêcher les Capitaines de tuer leurs passagers, au 18ème siècle bien sur! C’est une parfaite démonstration de comment de mauvais incentives peuvent tuer des gens, littéralement!
  3. Deux mythes mis à mal par Mike Masnick de Techdirt : non, les grandes entreprises n’arrivent pas toujours à imiter les petits nouveaux, et l’illusion du modèle économique des lames de rasoirs.
  4. Enfin, je m’étonne de ne pas encore avoir posté le guide des startups par Marc Anderseen (cofondateur de Netscape). Dernièrement j’ai apprécié la partie 4, mais toutes les autres sont très biens: 123456789. Oui, c’est le roman de la semaine!

Ps: j’ai créé une nouvelle catégorie d’articles : « 4 liens« , pour regrouper tous ces articles sur une seule page. Depuis le menu elle est accessible en dessous de Divers.

<< Semaine PrécédenteSemaine Suivante >>

4 liens rapides pour la semaine (2010-40)

Et hop :

<< Semaine PrécédenteSemaine Suivante >>

Les deux mondes de la BI

Vu chez Flowing Data, ce slide issu d’une présentation de Tableau Software:

Le slide est commenté par son auteur ici, je trouve sa réflexion extrêmement pertinente. La citation « big software, little analysis » pour décrire le datawarehousing est tellement vraie!

L’idée présentée dans ce slide est très bien résumée par cette phrase de Nathan Yau : « You have to get over the wall to really get something out of your data. Otherwise, you’re just a drone doing a computer’s work when it should be the other way around » (« Tu dois aller à droite du mur si tu veux tirer quelque chose de tes données. Sinon tu n’es qu’un drone qui fait le boulot d’un ordinateur alors que cela devrait être l’inverse.« )

Le message nous est en partie adressé, à nous les consultants qui fabriquons les applications décisionnelles, bien à l’abri à gauche du mur:

  1. nos applications doivent être conçues pour permettre aux utilisateurs de franchir le mur,
  2. nous devons accompagner les utilisateurs pour qu’ils puissent le faire.

En terme d’outils, à gauche du mur on retrouve SQL Server, SSIS et SSRS. Pour moi la brique qui fait le pont entre les deux mondes c’est SSAS. De l’autre côté, on a Excel (tableaux croisés dynamiques ou avec les fonctions cube), maintenant PowerPivot (gratuit sur Excel 2010) et les modules de données de SharePoint (ex PPS Monitoring). Cela plus tous les outils de l’écosystème Microsoft (Tableau pour l’analyse, Clarity Systems pour le BPM,…), ça ne fait pas de nous les plus mal équipés pour traiter le problème!

Alors va falloir s’y mettre! 🙂

Ps: J’ai testé Tableau, enfin leur soft, et je l’ai trouvé vraiment sexy. Par contre je ne l’ai encore jamais déployé ni vu déployé. A venir peut être!

Ps: Je cite Clarity ici parce que j’ai eu droit à une démo de leur produit, et leur module de saisie (objectifs, budgets…) est juste bluffant.