Pourquoi les produits technologiques échouaient-ils toujours en 2016?

Initialement écrit en janvier 2017.

«Cette application devait être créée en 2 mois. Maintenant vous me dites, 10 mois plus tard, qu’il faudra 2 mois pour le terminer. Comment diable est-ce arrivé? »

J’ai fait beaucoup de conseil en produits logiciels en 2016, et j’ai été surpris qu’un bon nombre de concerts visaient à corriger des projets qui avaient complètement déraillé. Dans le même temps, j’ai eu le privilège d’être une mouche sur le mur de quelques échecs de projets logiciels, tout en conseillant des amis au milieu de la désillusion.

Si ce n’est pas l’inexpérience ou le manque de connaissances qui sont à l’origine de ces échecs, quelle en est la cause?

Tous les projets que j’ai examinés présentaient un large éventail de symptômes et se trouvaient dans des situations très différentes, mais je peux toujours les relier à un seul point d’échec, ce qui a conduit à des effets en cascade dans différentes directions.

/ p>

Ce point de défaillance unique entraîne une méconnaissance de quelques principes clés et une incompréhension de ce qu’est un produit logiciel. Certains des points que je vais essayer de faire valoir sont subtils, et donc facilement négligés, mais ils font toute la différence.

Tout d’abord, examinons les symptômes de 3 projets différents que j’ai observés en 2016.

Symptômes d’échec

La start-up Scrappy

En mai 2016, j’ai été amené à sauver un projet d’application pour une nouvelle startup de marketplace. Ils avaient déjà leur backend en place et avaient besoin de l’application pour que leurs fournisseurs de services puissent participer au marché.

Ils avaient commencé le projet en juillet 2015 avec un échéancier de 2 à 3 mois, mais le projet avait environ 10 mois de retard et seulement 50% terminé!

Pour une raison quelconque, plus le travail effectué sur l’application est important, plus le délai d’achèvement semble s’allonger! Le PDG était tout naturellement contrarié par le fait que cela prenait 6 fois plus de temps que prévu .

Ces retards ont eu un impact négatif sur leurs efforts pour lever des fonds auprès des investisseurs et ébranlé la confiance de leurs partenaires fournisseurs de services.

L’entreprise d’entreprise

Tout au long de l’année 2015, j’ai été un observateur secondaire d’un nouveau produit en cours de construction par une entreprise riche en capital. Ils avaient déjà validé et obtenu la traction des utilisateurs avec un MVP et un bon marketing, et étaient prêts à créer la version de production du produit.

Ils ont fait appel à une équipe de développement expérimentée, avec un budget à six chiffres et un délai de 3 mois pour lancer la prochaine version.

12 mois plus tard, le budget avait été multiplié par 5 et ils n’avaient toujours pas de produit fonctionnel.

Après tout ce temps, ils ont fini par rater la fenêtre d’opportunité et l’idée qu’ils élaboraient n’était plus pertinente pour leur clientèle.

La start-up financée

En septembre 2016, Rand Fishkin a publié un article de blog sur les tentatives de Moz de créer plusieurs logiciels, dont beaucoup ont fini par fermer.

Moz a levé 28 millions de dollars entre 2012 et 2016 pour développer et commercialiser ces logiciels. Le lancement du logiciel a pris environ 2 ans de plus que prévu, et une fois lancés, les produits n’ont pas répondu aux attentes, provoquant des licenciements et l’arrêt de quelques produits.

N’oubliez pas que toutes les personnes impliquées dans tous ces projets étaient des personnes intelligentes, et certaines personnes de chacune de ces équipes ont même travaillé dans des startups technologiques prospères pendant un certain temps! Si les techniciens ne parviennent toujours pas à créer des logiciels, comment un non-technique peut-il avoir une chance de réussir?

Pourquoi ont-ils échoué?

À première vue, on pourrait rejeter carrément la faute sur les équipes d’ingénieurs sur ces projets. Peut-être que si cela leur prenait 2 à 6 fois plus de temps pour construire le logiciel, ils n’étaient tout simplement pas bons en développement logiciel?

Mais c’est comme blâmer un os cassé d’être trop faible pour résister à sauter d’un immeuble de 5 étages. Bien sûr, vous pouvez essayer de renforcer vos os, mais c’est probablement une meilleure stratégie pour prendre les escaliers.

De même, chacune de ces entreprises a perdu de vue la réalité en se repliant dans une salle de «développement logiciel» en bac à sable, puis en essayant de sauter du toit de l’adéquation produit-marché.

Le point de défaillance unique qui les lie tous ensemble? Ils ont tous échoué dans la réorientation continue de leurs produits, de leurs employés et de leurs processus avec la réalité.

Ils ont tous pris un bon départ, ont obtenu un peu de force en explorant la réalité, en parlant aux utilisateurs, en testant le marché.

Mais à un moment donné, ils ont tous dit: “ok, nous en savons maintenant assez, laissons se retirer dans une pièce pendant un moment et construisons cette grande vision que nous avons formée.”

Et ce qui arrive souvent lorsque vous faites cela, lorsque vous arrêtez de vous familiariser avec la réalité, ce sont ces aspects imprévus de l’expérience produit qui apparaissent, et l’équipe fait juste de son mieux pour y remédier. Et puis plus de choses surgissent en plus de cela, et d’autres meilleures suppositions sont construites en plus, et vous vous retrouvez avec un produit plein de risques et de complexité.

Voici comment cela s’est passé pour chacun des projets:

The Scrappy Startup n’avait pas une bonne compréhension des besoins de leurs fournisseurs de services et de leurs processus. Ils ont commencé le projet avec une spécification qui n’était pas beaucoup plus que «créer une application où ils peuvent gérer les prospects et les clients sur le terrain». En fait, ils ont découvert au cours de l’année qu’il fallait construire un flux de processus métier très complexe. Souvent, ces découvertes se produisent pendant que le développeur créait une fonctionnalité et demandait: “Attendez, que se passe-t-il quand il fait X?”

The Corporate Venture avait un problème similaire, ils voulaient reconstruire leur MVP pour qu’il soit moins bogué et plus convivial, mais en train d’essayer de réfléchir au codage de chaque partie, l’ingénierie L’équipe a découvert qu’il y avait des failles conceptuelles dans le MVP qui devaient être complètement repensées, ce qui a entraîné une dérive continue des fonctionnalités au lieu d’un apprentissage continu.

La start-up financée manquait apparemment également de boucle de rétroaction entre ses idées de produits et ce qu’elle avait construit. Je suis sûr qu’il y a eu des complications techniques imprévues en raison de l’ambition des projets, mais le fait que l’utilisation des produits ait dans certains cas complètement manqué la cible suggère qu’ils ne réorientaient pas régulièrement leurs produits avec les besoins de leurs utilisateurs. .

Le fil conducteur de tous ces échecs est un manque d’orientation avec la réalité.

C’est ce manque de réorientation régulière avec la réalité qui sème la confusion chez les équipes de développement, ce qui entraîne des retards massifs dans l’achèvement du logiciel. En fait, généralement personne dans l’équipe ne sait vraiment ce que signifie «complet»!

Lorsqu’il y a un manque de clarté autour d’un produit, les équipes sont confuses et passent beaucoup de temps à déterminer comment quelque chose «devrait» fonctionner. Mais en fait, la seule façon dont cela «devrait» fonctionner est la façon dont vos utilisateurs veulent l’utiliser. En ne découvrant pas réellement comment les utilisateurs l’utilisent, vous avez des caprices & amp; confusion, pas de clarté & amp; exécution.

Principes clés pour éviter la défaillance d’un nouveau produit

Le but d’une startup est d’explorer la réalité et de découvrir de nouvelles possibilités. L’ensemble du système de démarrage doit être organisé pour consommer la réalité et en tirer des leçons.

Réorientez-vous régulièrement avec la réalité. Faites-le au minimum chaque semaine. Cela signifie vérifier que vos idées et vos produits fonctionnent dans l’environnement dans lequel ils sont censés travailler. Cela impliquera souvent une sorte de test utilisateur, pour voir comment les utilisateurs réagissent réellement à votre produit (pas l’idée de celui-ci). Configurez des systèmes qui permettent aux membres de l’équipe, aux décisions relatives aux produits et au processus de s’adapter régulièrement aux leçons tirées de la réalité.

Itérations courtes. Traitez et finalisez moins de choses à la fois. Cela s’applique à la fois au processus d’innovation / découverte et au processus d’exécution. Testez rapidement de nouvelles idées une fois que vous les avez afin de ne pas perdre de temps à planifier des idées qui ne fonctionnent pas. Créez et finalisez une fonctionnalité afin de pouvoir la tester en production avant de passer à la suivante.

Soyez précis. Les concepts généraux ne donnent pas de résultats. Creuser dans les détails précis de ce qui va se passer et comment est le seul moyen de créer une expérience qui fonctionne. Le logiciel, en particulier, est un ensemble de milliers de définitions précises et ne peut fonctionner qu’avec des détails. «Les amateurs parlent de tactiques, mais les professionnels étudient la logistique.» – Gén. Robert H. Barrow, USMC

Le produit est l’expérience utilisateur. Le produit n’est PAS la technologie qui le fabrique. La façon dont votre produit est fabriqué n’a pas d’importance pour l’utilisateur, il se soucie seulement de bénéficier de l’expérience qu’il souhaite. Que mon Uber soit un chauffeur de taxi chevronné, un étudiant ou un robot ne m’importe pas tant que je vais de A à B, rapidement et en toute sécurité. La correspondance en temps réel extrêmement compliquée & amp; le logiciel de routage qu’ils ont construit pour le faire fonctionner n’a aucune importance pour le pilote.

Que pouvez-vous faire dès maintenant pour augmenter votre succès?

L’application de ces principes à l’ensemble de l’organisation demandera du temps et de la réflexion, mais vous pouvez prendre des mesures dès maintenant pour ralentir l’accumulation de risques liés aux produits.

Telle est la réalité de votre produit. Ne vous éloignez jamais.

Histoires associées de DDI: