5 raisons pour lesquelles votre projet parallèle n'est jamais devenu un produit

Photo de Photocreo on Depositphotos

Avez-vous des projets secondaires inactifs dans des dossiers ou des référentiels Git, intacts pendant des mois ou des années? Combien sont complets à 80%? Fonctionnel et occasionnellement utilisé par vous mais pas en état de vendre ou de donner? Combien semblaient être de bonnes idées à l'époque?

Le triste état du projet parallèle est le fléau de la vie de chaque pirate. Nous avons une idée. Nous restons coincés après le travail ou le week-end, tous impatients et remplis de passion. Des semaines voire des mois passent, des progrès sont réalisés puis nous nous arrêtons ou nous passons. Semble familier?

J'ai travaillé sur une douzaine de projets parallèles que j'ai peaufinés et publiés. Certains étaient des produits de bureau commerciaux, des applications en ligne gratuites, mais tous ont atteint un état d'exhaustivité qui m'a permis de les diffuser à de vrais utilisateurs.

À chaque fois, j'ai dû me battre pour franchir la ligne d'arrivée, mettre le projet dans un état où ce n'est plus un projet mais un produit. Le temps de crise atteint généralement 80% lorsqu'il est utilisable par moi avec une petite configuration manuelle. L'interface utilisateur peut être un peu gênante, des choses importantes peuvent être manquantes, il peut être loin d'être prêt pour la sortie.

C'est à ce stade que mes démons intérieurs (et les vôtres) font de leur mieux pour dérailler le projet et l'empêcher de devenir un produit.

Voici cinq raisons pour lesquelles votre projet parallèle est resté un projet et n'est jamais devenu un produit.

1. Les bits ennuyeux à la fin

Les premières étapes d'un projet parallèle sont amusantes. Vous et vous seul pouvez choisir la pile technologique - plus de bibliothèques vieilles de six ans, plus d'IDE désuets et de clients de bases de données. C'est nouveau et frais tout le long.

Mais à mesure que le projet se développe et se rapproche de plus en plus de devenir un produit réel, le plaisir cède la place au banal. Tout commence à ressembler au travail de jour.

Le libellé est-il correct dans les menus et les boutons? Tout est-il activé ou désactivé alors qu'il devrait l'être? Avez-vous construit le programme d'installation, le code a-t-il signé les fichiers EXE? Comment obtenez-vous même un certificat de signature de code?

C'est une liste qui ne semble jamais se terminer, remplie de petits travaux ennuyeux qui prennent tout le plaisir de créer votre propre application. Mais ils doivent être faits, sinon votre projet reste un projet, ramasse la poussière et vous rappelle chaque jour votre échec.

Comment réparez-vous ceci?

Vous le corrigez une tâche à la fois. Mais vous devez d'abord définir ces tâches, pour construire une liste. Tout se passe sur la liste: les bugs, les changements cosmétiques, les fonctionnalités manquantes, l'installateur, le site web, le forum des utilisateurs, même le certificat de signature de code.

Photo de Glenn Carstens-Peters sur Unsplash

Je sais à quoi tu penses: "Je n'ai pas besoin de Jira pour mon petit projet parallèle." Vous avez raison, vous n'en avez pas besoin pour votre projet parallèle. Mais vous en avez besoin - ou quelque chose de similaire - pour votre produit.

Alors que je construisais la première version d'Atomic Scribbler en 2017, c'est à l'étape 80% que j'ai présenté Jira. Atomic a fonctionné - pour moi. Mais il était loin d'être prêt pour le reste du monde.

À 7 heures du matin un matin de semaine, assis à Starbucks sur les quais de Dublin, j'ai construit ma première liste Atomic Scribbler Jira. Tout était sur cette liste - plus de 100 tâches, bogues et histoires d'utilisateurs. Certains s'avéreraient être un travail de dix minutes, d'autres me prendraient des jours pour terminer. Je les ai tous listés puis j'ai mis en place mon premier sprint: sept jours, vingt tâches.

Cet après-midi-là, je travaillais dans un autre café et j'ai fait glisser deux tâches sur la liste Terminé. Chaque jour, je répétais le processus. Une ou deux tâches le matin, glisser-déposer, une ou deux l'après-midi, rincer et répéter. À la fin de cette semaine, les 20 tâches étaient terminées et j'ai mis en place le sprint de la semaine suivante.

Lorsque vous ressentez l'élan, lorsque vous observez que les tâches sont supprimées chaque jour, la fin devient réelle. Vous commencez à voir le jour de sortie juste au coin de la rue. Un produit, pas un projet.

2. Vous avez perdu votre concentration et votre conduite

Nous y avons tous été. Quand la passion ne suffit pas, quand Netflix ou Facebook ou de nouvelles choses brillantes nous attirent, nous arrachent à notre projet. La procrastination peut nous faire perdre des jours, des semaines, voire des mois. Pour beaucoup d'entre nous, c'est la fin - nous ne retrouvons jamais notre chemin vers notre projet et notre produit meurt avant même sa naissance.

Comment réparez-vous ceci?

Il y a toute une industrie qui vend des réponses à cette question. Des guides d'entraide dont le seul but est de nous aider à tuer la procrastination, des conférenciers motivateurs qui volent dans les stades en hélicoptère pour nous sauver de nous-mêmes, des livres pas tout à fait académiques qui parlent de Grit and Mindset et de Deep Work. Tous répondent à la même question de différentes manières: comment mieux travailler.

Photo de Pedro da Silva sur Unsplash

Je trouve que l'approche la plus utile consiste à travailler mon projet parallèle comme je le fais dans la journée. Donnez-moi un patron et faites ce qu'il me dit de faire, comme au travail.

Que faites-vous lorsque votre patron vous attribue une liste de petites tâches sans intérêt? Vous grommelez, vous tapez agressivement sur le clavier, puis vous commencez à travailler. Vous continuez à travailler, jour après jour, jusqu'à ce que la liste soit complète. Que faites-vous quand il vous demande d'écrire 1 000 mots décrivant de nouvelles fonctionnalités? Vous détestez peut-être écrire, ce n'est peut-être pas votre truc, mais vous vous asseyez à 10 heures du matin et vous êtes coincé malgré tout.

Ce n'est pas l'argent qui vous fait faire le travail, c'est l'instruction d'un gars que vous voyez comme étant en droit de vous instruire.

Ces 20% finaux - ces tâches qui empêchent votre projet de devenir un produit - ce sont juste le genre de tâches que vous n'aimez pas faire dans la journée mais que vous faites néanmoins.

Traitez votre projet parallèle comme un travail - quelques heures OT chaque jour. Soyez le patron. Écrivez ces Jiras et attribuez-les à vous-même. Commencez un sprint hebdomadaire et tenez-vous aussi responsable que votre patron au travail vous tient. Il ne faudra pas longtemps avant que ce produit ne commence à prendre forme.

3. Il doit être parfait

À quelle fréquence dans la journée vous demande-t-on de construire quelque chose rapidement, de couper les coins ronds, de rester simple. «Il n'est pas nécessaire que ce soit parfait, il doit simplement fonctionner. Il y a une démo mardi. "

Vous avez déjà entendu ça?

Un projet parallèle est différent. Personne ne peut nous dire de précipiter de nouvelles fonctionnalités, de laisser de côté, de parquer les tests unitaires et d'y revenir plus tard. Nous sommes déterminés à tout faire correctement. Pas de raccourcis.

Le problème avec la recherche de la perfection est que vous n'y arrivez jamais. Comme l'écrivain qui ne cesse de réviser chaque paragraphe et qui ne tape jamais «The End», vous continuez à trouver des améliorations qui n'ont qu'à être apportées.

Photo de Bill Williams sur Unsplash

Si votre application est mentionnée dans le New York Times, vous devez pouvoir évoluer rapidement - mieux vaut mettre cela en place maintenant, au cas où. Et qu'en est-il de ces utilisateurs français? Ils ne sont peut-être pas là pour la version 1, mais ils arriveront assez tôt - mieux implémenter cette prise en charge multilingue dès le début, cela vous fera gagner du temps plus tard. Windows 12 devrait sortir l'année prochaine - j'installerai la première version candidate et je veillerai à ce que mon application soit compatible, étouffez tous les problèmes dans l'œuf pendant que le code est frais dans mon esprit.

Cela ressemble à une blague, mais ce n'est pas le cas. Ce type de perfectionnisme tue votre projet avant qu'il ne devienne un produit.

Comment réparez-vous ceci?

Vous devez couper les fonctionnalités, pas les ajouter. Votre version 1 devrait être le produit qui convient à une infime proportion de vos utilisateurs potentiels, pas à tous.

Dressez une liste des fonctionnalités et des scénarios que vous pensez devoir gérer dans la version 1. Pour le moment, garez Jira, faites-le sur papier. Notez tout cela - options d'exportation, sauvegardes, support multi-utilisateurs, tags (les tags apparaissent toujours sur ces listes), impression, connexion Google et Facebook, peu importe.

Retirez ensuite le stylo rouge et parcourez la liste. La question que vous devez poser pour chaque élément de cette liste est: "Si je laisse cela de côté, un utilisateur peut-il toujours utiliser mon produit?"

C'est ça. Pas "Sera-ce parfait?" Si un utilisateur peut utiliser votre produit sans cette fonctionnalité, biffez-le. Garez-le jusqu'à la version 2.

Cette approche a un avantage au-delà de vous aider à sortir la version 1 de la porte. La moitié des éléments que vous avez barrés ne seront jamais mentionnés par vos premiers utilisateurs. Ce ne sera pas qu'ils puissent vivre sans eux pour l'instant, ce sera qu'ils ne les intéressent pas du tout.

Ma liste de plumes rouges pour Atomic Scribbler était énorme. Je suis sur la version 6 maintenant et je n'ai toujours pas implémenté certains des éléments de cette première liste - pas même les balises. Pourquoi? Parce qu'un an et demi plus tard avec plusieurs milliers d'utilisateurs, personne ne les a demandés.

Un produit imparfait est toujours un produit, mais un projet n'est toujours qu'un projet.

4. Vous vous êtes enlisé et ne saviez pas où aller

Comme un écrivain de 30 000 mots dont l'intrigue est tombée d'une falaise, vous vous êtes codé dans un mur. Tout allait bien, le projet se mettait en place, puis vous vous êtes retrouvé coincé sans aucune idée où aller ensuite.

Vous avez perdu votre vision de ce qu'était le projet, ou vous n'avez jamais eu de vision au départ. Vous n'avez jamais vu le produit.

Photo d'Alistair MacRobert sur Unsplash

Comment pouvez-vous résoudre ce problème?

Il est facile de confondre cette incapacité à avancer pour la procrastination, mais ce n'est pas, c'est pire. Quelque chose ne va pas avec votre projet. Vous ne savez pas où aller ensuite parce que vous n'avez pas défini votre futur produit ou votre utilisateur cible. Vous créez quelque chose pour un utilisateur générique alors que vous devriez créer un produit pour le plus petit créneau possible.

Avec Atomic Scribbler, ce créneau était les écrivains créatifs qui écrivaient des romans. Ni les écrivains en général, ni les blogueurs, ni les journalistes, ni les poètes ni les universitaires. Bien sûr, ils pouvaient tous utiliser l'application, mais ce n'était pas pour eux. Un développeur unique ne peut pas créer une application générique remplie de fonctionnalités pour une multitude d'utilisateurs différents.

Une fois que vous avez cet utilisateur, regardez votre produit de son point de vue. Qu'y a-t-il dont il n'a pas besoin et qu'est-ce qu'il n'y a pas ou qu'il ne touche pas à la version 1? Élaborez un plan pour ranger votre projet, pour couper les fonctionnalités dont il n'a pas besoin et pour ajouter les fonctionnalités les plus légères possibles. Oubliez la mise à l'échelle future ou la livraison de la version 6 dès le départ. Il s'agit de la version 1 pour un utilisateur spécifique.

Construisez une vision pour votre produit autour de cet utilisateur de niche et conservez cette vision.

5. Vous n'êtes pas sorti de votre zone de confort

Mes deux premiers travaux, j'ai écrit des applications de bureau en C ++. Mon premier projet qui s'est transformé en un produit - PageFour - était une application de bureau écrite en C ++. J'étais un gars C ++ qui a construit des produits de bureau.

Ce n'est que plus tard, en passant d'entreprise à entreprise en tant qu'entrepreneur, que j'ai réalisé à quelle vitesse je pouvais acquérir de nouvelles technologies et à quel point cette compétence était précieuse. Différentes entreprises, différentes piles technologiques, partout des idées et des façons de faire différentes. Soudain, tout était possible.

La plupart d'entre nous vivent dans une bulle définie par notre histoire et notre expérience. Nous codons en Java ou Python, nous sommes back-end ou front-end. Nous sommes des techniciens ou des clients. Cette incapacité à mettre des chapeaux différents peut tuer nos projets secondaires avant qu'ils ne deviennent des produits.

Photo de Michal Bar Haim sur Unsplash

Comment peux-tu réparer cela?

Vous devez sortir de la bulle, travailler dans des domaines que vous ne connaissez pas ou dans lesquels vous pensez ne pas être bon. Cela signifie apprendre de nouvelles technologies lorsque votre projet l'exige et assumer des rôles de vente et de marketing ainsi que rédiger du code. Pas un gars de la base de données? Commencer à apprendre. Vous n'avez jamais construit de service Web? Si votre application en a besoin, vous devez l'apprendre. Jamais parlé aux clients? Commencez maintenant.

Vous devez rencontrer des gens qui peuplent ces autres domaines, qui travaillent et vivent dans les zones où vous êtes le plus faible. N'allez pas au groupe de rencontre des pirates, essayez le groupe de marketing. Au lieu de vous connecter sur LinkedIn avec d'autres développeurs dans votre ville natale, connectez-vous avec des fondateurs de start-up non technologiques, avec des vendeurs et des personnes centrées sur le client, avec des écrivains et des blogueurs.

Prenez des réunions, déjeunez. Tout le monde veut se retrouver. Tous ceux qui valent le temps au moins. Parlez-leur, partagez des idées et surtout écoutez et apprenez.

Pour que votre projet devienne un produit, il lui faut plus que du code. Vous devez entrer dans d'autres mondes et apprendre de nouvelles choses. Vous devez vous rendre compte qu'aucune de ces autres compétences requises pour créer un produit n'est plus difficile à apprendre que les langages et les frameworks que vous choisissez facilement.

Cette histoire est publiée dans The Startup, la plus grande publication sur l'entrepreneuriat de Medium, suivie par +434 678 personnes.

Abonnez-vous pour recevoir nos meilleures histoires ici.