Stratégie Startup 101 : 10 erreurs technologiques et produit à éviter
Lorsque vous lancez une startup, vous avez une page blanche : les possibilit\u00e9s sont infinies et s’il est vrai qu’il n’existe pas de manuel 100 % efficace pour d\u00e9marrer, il y a des recommandations sur ce qui fonctionne g\u00e9n\u00e9ralement et ce qui ne fonctionne pas. Dans cet article, je souhaite partager mon exp\u00e9rience de travail dans plusieurs startups, et parler des erreurs courantes que j’ai observ\u00e9es lors de la d\u00e9finition de la strat\u00e9gie technologique et produit. Bien entendu, ce n’est pas une liste exhaustive, et vous trouverez certainement des exceptions pour la plupart des points, mais je pense que ce sont des d\u00e9cisions qui, dans de nombreux cas, peuvent \u00eatre consid\u00e9r\u00e9es comme erron\u00e9es ou du moins non optimales. Dans le monde des startups, les erreurs sont souvent qualifi\u00e9es d’apprentissages, mais tr\u00e9bucher deux fois sur la m\u00eame pierre, ce n’est plus de l’apprentissage…
Sans plus tarder, je vais \u00e9num\u00e9rer ce que je consid\u00e8re \u00eatre les erreurs les plus courantes en mati\u00e8re de strat\u00e9gie technologique et produit.
Commencer \u00e0 construire une solution \u00e0 un probl\u00e8me sans l’avoir valid\u00e9.
Concevoir une architecture scalable et hautement disponible d\u00e8s le d\u00e9part (avec des exceptions bien justifi\u00e9es).
Choisir des frameworks ou des technologies tr\u00e8s r\u00e9cents et avec peu de communaut\u00e9 de d\u00e9veloppeurs, alors qu’il existe des alternatives plus r\u00e9pandues.
Ne pas avoir une bonne strat\u00e9gie d’externalisation (les parties centrales sont externalis\u00e9es, ou l’externalisation n’est pas du tout envisag\u00e9e).
Concevoir un MVP avec trop de fonctionnalit\u00e9s.
D\u00e9finir une feuille de route produit comme une liste de fonctionnalit\u00e9s et de t\u00e2ches sans contexte de probl\u00e8me.
Ne pas parler aux early adopters ou aux clients. Ou \u00e9couter tout ce qu’ils disent et le mettre directement dans la feuille de route.
Prendre des d\u00e9cisions techniques co\u00fbteuses sans impact (ou avec peu d’impact) sur le business.
Consid\u00e9rer l’\u00e9quipe d’ing\u00e9nierie comme une \u00e9quipe de services internes (comme une \u00e9quipe IT), plut\u00f4t que comme une \u00e9quipe de d\u00e9veloppement produit.
Comme je l’ai dit au d\u00e9but, cette liste ne se veut pas exhaustive, mais elle pr\u00e9sente certaines de ce que je consid\u00e8re \u00eatre les erreurs les plus courantes. Qu’en pensez-vous ? Ajouteriez-vous ou retireriez-vous des points ?