Attirés par le défi de lancer une startup et ayant une idée simple mais prometteuse, nous avons décidé, avec mon ami Alessandro, de créer notre propre entreprise : Abyssale.
En un mot, Abyssale est une plateforme de génération de publicité bannière , un service qui vous aide à prendre le contrôle créatif de votre stratégie marketing. Voici notre manifeste en la matière.
Nous avons récemment lancé le produit minimum viable(MVP), dont la mise sur le marché nous a pris 5 mois. De cette aventure, j'ai décidé de partager mon expérience d'un point de vue technique et produit.
Sachant cela, des sujets importants tels que la " levée de fonds ", la " stratégie marketing " ou le " business plan " ne seront pas abordés. Évidemment, gardez à l'esprit qu'expliquer chaque choix que j'ai fait n'était pas faisable car cela transformerait cet article en une lecture lourde.
Ne vous surchargez pas ! Attention aux frais de bagages
Avant tout développement ou feuille de route de produit, il est fondamental de créer une vision forte du produit et d'être totalement aligné sur celle-ci.
Pour replacer les choses dans leur contexte, cette phase initiale a duré un semestre, car notre stratégie consistait à conserver nos emplois en travaillant en dehors des heures de travail sur le projet jusqu'à ce que nous soyons confiants dans son potentiel... ou du moins que nous ayons réduit nos chances d'échouer lamentablement.
Au début, tout le concept était très flou pour nous. Faire des études de marché, itérer sur des idées de produits, clarifier notre proposition de valeur et imaginer la situation dans son ensemble nous a techniquement aidés à définir les objectifs.
Nous avons fait confiance à notre intuition, mais nous savions aussi que nous devions affronter le monde extérieur et rechercher des avis extérieurs :
- Nous avons rédigé le manifeste de Abyssale et créé une page d'accueil. Après les avoir partagés avec notre réseau(amis, collègues... ), nous avons commencé à constituer une première base d'utilisateurs et avons reçu des commentaires qui nous ont confortés sur son potentiel(et rassurés par la même occasion).
Réduire les facteurs de risque associés à une idée de produit avant de s'impliquer pleinement dans le projet nous a permis de partir du bon pied.
Le sous-marin est prêt. Embarquons dans l'aventure
De nos jours, tout le monde sait que les idées théoriques peuvent valoir leur pesant d'or, mais que sans stratégie pour parvenir à une adéquation produit/marché, elles ne valent rien. D'où l'expression" Il nous faut un plan !"
Structurer notre façon de travailler
La livraison itérative et efficace était cruciale car nous devions obtenir un retour d'information le plus rapidement possible, afin de pouvoir adapter ou pivoter le plus tôt possible.
Nous avons décidé d'adopter la " méthodologie Lean Startup " et sa fameuse boucle de rétroaction construire-mesurer-apprendre pour structurer notre façon de travailler, tout au long du cycle de développement de nos produits.
Identifier notre marché cible pour fournir un produit sur mesure
Connaître et comprendre notre marché est un autre sujet important car notre produit est suffisamment large pour pouvoir atteindre différentes cibles, B2C, B2B, e-commerce, petites startups...
Par conséquent, notre stratégie de définition d'un MVP à l'époque consistait à cibler " tout le monde ", c'est-à-dire à ne contenir que des fonctionnalités très simples telles que la génération, la mise en signet, le téléchargement ou le marquage de bannières que tout le monde pouvait utiliser.
La définition de " produit minimum viable (MVP) " est très diverse. À des fins de clarification, pour nous, cela signifie livrer un produit avec juste assez de fonctionnalités pour tester la faisabilité de notre idée et obtenir autant de feedback que possible pour définir plus précisément un marché ainsi qu'une adéquation problème/solution.
Bien entendu, avant de commencer à construire un MVP complet, nous devions nous assurer que l'idée théorique était techniquement réalisable.
Oow, est-ce faisable ? De la conceptualisation au prototype
Un prototype(ou preuve de concept) est un produit minimal fonctionnel très précoce qui garantit la faisabilité du cœur de votre idée et vous aide à transmettre votre message plus efficacement. Pour le définir, il faut comprendre la valeur ajoutée essentielle de votre produit. Pour nous, c'était assez simple :
Générer des variations simples des annonces bannière pour un produit spécifique.
En tant que CTO, votre rôle est crucial dans sa réalisation. Sans aucune expérience préalable de la construction d'un prototype, vous vous sentirez évidemment dépassé, craignant soit l'échec, soit de ne pas savoir comment y parvenir. C'est un sentiment normal, vous devez l'accepter, affronter vos peurs et commencer à agir:
- Bien sûr, il n'y a pas de solution miracle.
- Essayez d'utiliser une technique qui a déjà fonctionné pour vous, en parcourant le web à la recherche de réponses, en divisant les problèmes en petites étapes, en commençant à développer sans aucun plan...
- Ce qui fonctionne pour moi, c'est d'écrire des phrases qui décrivent les problèmes critiques, d'y associer des solutions potentielles(avec la technologie), d'esquisser des graphiques qui représentent les éléments interconnectés, et enfin de commencer à développer.
Notre prototype de construction nous a pris un peu plus d'un mois et ressemblait à ceci :
Cette image animée a été communiquée dans un marketing email à notre base d'utilisateurs. Pour être honnête, nous n'avons pas eu beaucoup de retours. Cependant, le bâtiment nous a rassuré sur la faisabilité et a clarifié les problèmes auxquels nous devrions faire face dans un avenir proche.
Se concentrer sur le côté technique (sombre)
Il est essentiel d'évaluer l'adéquation d'un langage de développement logiciel(et de son écosystème) avec le problème que vous résolvez. Sauf si vous connaissez déjà la solution, tester rapidement plusieurs bibliothèques/langages est une compétence que vous devez maîtriser.
Un autre élément clé pour s'attaquer avec succès à un problème est de trouver un système similaire dans un autre domaine.
Par exemple, de nombreuses idées peuvent être tirées des navigateurs web et appliquées à notre système. En gros, il s'agit d'analyser une page web et de la restituer. Même si cela ne correspond pas exactement à nos besoins, cela m'a permis d'imaginer de nouvelles façons de résoudre les problèmes et de définir/réutiliser des mots génériques qui permettent d'identifier précisément un business case (ce dernier point représente le fameux " Ubiquitous Language ").
Afin de choisir une langue de développement, j'ai essayé de suivre ces directives de base :
- Ne gardez que des langues stables avec une communauté importante et active. Cela garantira l'accès à un grand nombre de ressources et de développeurs en ligne pour les recrutements futurs.
- Ne pas accorder trop d'importance à mes compétences. Il est évident qu'elles m'aideront à livrer plus rapidement, mais elles peuvent être inappropriées pendant cette phase, car la rapidité et l'adéquation problème/solution sont plus importantes. Néanmoins, si une langue n'offre pas une courbe d'apprentissage raisonnable, oubliez-la.
- Trouver des bibliothèques qui couvrent déjà mes problèmes.
- Il est clair que les performances ne sont pas une préoccupation
Comme je ne voulais pas tout reconstruire après la phase de prototype, j'ai anticipé plusieurs sujets :
- Utiliser des outils fondamentaux sur lesquels nous pouvons facilement construire par-dessus.
- Réduction des coûts d'infrastructure : Faible empreinte mémoire et faible utilisation du CPU.
- Bonnes capacités de manipulation et de traitement des images
- Support de l'apprentissage automatique. L'apprentissage automatique peut être un moyen d'aborder le problème, mais comme je n'étais pas encore sûr, je préfère utiliser un langage qui permet les calculs scientifiques (soit à partir de bibliothèques, soit à partir du langage lui-même).
Comme le produit va sûrement évoluer et changer radicalement, prendre du temps sur le style du code, les tests unitaires (ou fonctionnels/smoke...) et la documentation ne sont pas une priorité. La qualité du code est également un bonus.
Où j'ai atterri
Pour être tout à fait honnête, au début, je n'ai pas suivi toutes les règles précédentes et j'ai fini par perdre presque une semaine. J'ai été attiré par le battage médiatique autour de Golang ainsi que par ses très bonnes performances. Cependant, après plusieurs jours de développement, j'ai réalisé que le langage lui-même n'était pas adapté à mes besoins :
- le typage statique m'empêche d'itérer à un rythme acceptable
- le langage est très verbeux, surtout en ce qui concerne la gestion des retours nil.
- les bibliothèques d'images que j'ai trouvées n'étaient pas assez adaptées à mes besoins (il aurait fallu écrire du code par-dessus pour les couvrir)
J'ai ensuite décidé d'essayer Python et j'ai été ravi de ma découverte :
- Syntaxe simple et claire
- Le typage dynamique m'a permis d'itérer rapidement sans aucun obstacle.
- Les bibliothèques de manipulation d'images sont complètes et simples à utiliser
- L'indication de type facultative permet la vérification statique des types
La validation technique du concept a diminué notre risque d'échec et nous a permis de passer sereinement à l'étape suivante.
Parallèlement au développement du prototype, Alessandro a travaillé sur une vision haute-fidélité design de notre produit : le produit final idéal. Pour être tout à fait honnête, cet exercice était trop précoce et compliqué, mais il nous a confrontés à une question fondamentale :
Nous avions besoin de mieux connaître nos utilisateurs et notre marché, et les clarifications viendront du MVP.
Une affaire sérieuse. Vers le MVP
Une solution est purement abstraite tant que vous n'avez pas mis la main à la pâte et commencé à la produire. Le prototypage m'a aidé à clarifier les problèmes de génération de bannières :
Qu'est-ce qu'une bonne publicité sur bannière et comment la générer ?
Néanmoins et comme vous pouvez l'imaginer, comparé à un prototype, un MVP est un nouveau monde merveilleux puisqu'il consiste à lancer un produit utilisable et aimable.
Utilisation appropriée, ciblant une plateforme spécifique
Avant de définir précisément la portée du MVP, il faut déterminer le type de produit qui sera développé(application de bureau, SaaS, application mobile).
Par un processus d'élimination :
- La génération de bannières dépend des actifs numériques marketing qu'un utilisateur doit télécharger. Par conséquent, nous doutons fortement que ces actifs soient accessibles sur une application mobile.
- Au départ, une application de bureau semblait très attrayante car la puissance de calcul pouvait être entièrement déplacée vers l'hôte. Cependant, elles nécessitent une installation initiale et pourraient empêcher les utilisateurs de tester notre produit(la confiance est difficile à gagner).
Le SaaS est parfaitement adapté. Nous pouvons livrer de manière itérative et très efficace. Chaque utilisateur bénéficiera d'une expérience unifiée. Cela facilitera notre entrée sur le marché.
Il est temps de devenir plus fort ! Définition du champ d'application
En partant du principe qu'aucune fonctionnalité ciblant un marché spécifique ne sera développée, la portée du MVP a été définie. Nous avons réalisé un premier exercice de feuille de route et établi des priorités en gardant à l'esprit le " principe de Pareto ".
Notre produit devrait prendre forme dans environ 4 mois et inclure :
- Un entonnoir pour les débutants(un formulaire pour générer des bannières qui fournit des explications claires à chaque étape).
- Une interface/expérience utilisateur accessible
- Authentification et autorisation simplifiée
- Une architecture classique à trois niveaux(couches de présentation, d'application et de données, ainsi que leurs ponts de communication).
Un back-office interne serait également ajouté pour soutenir et faciliter notre travail quotidien.
En ce qui concerne les fonctionnalités du produit, nous avons choisi de nous attaquer en premier lieu à l'entonnoir de génération de nouveaux utilisateurs, car c'est celui qui apporte le plus de valeur à notre produit. Il a été défini comme un formulaire assistant(un modèle d'interface utilisateur design signifiant une série d'étapes pour atteindre un objectif spécifique).
Complexité technologique
J'imagine une infrastructure idéale et compliquée, des services entièrement orchestrés, évoluant automatiquement en fonction du trafic, utilisant un langage unique pour la communication, communiquant entre eux de manière synchrone ou asynchrone, envoyant des événements via des événements de bus (Kafka), des travailleurs asynchrones consommant des brokers (RabbitMQ), des bases de données dédiées(non SQL, relationnelles) en fonction de l'utilisation(le fameux Théorème CAP aide à choisir une technologie de base de données), réplication de bases de données, journalisation (Fluentd, Logstash), monitoring (Kibana) et pile d'alerte (Prometheus), et à côté d'eux un lac de données(pour analyser et prendre des mesures en fonction des données collectées lors de l'utilisation de la plateforme).
Pour être tout à fait honnête, cette vision idyllique n'existe que pour les entreprises bien établies. Une chose est sûre : cela ne peut pas être notre cible MVP. J'ai plutôt essayé de suivre le principe KISS en gardant notre plateforme la plus simple possible :
- REST(sur HTTPS) comme contraintes de communication pour nos services web. Le SOAP de la vieille école ou les technologies émergentes telles que GraphQL et Protocol buffers nécessitent trop de structure.
- Une seule base de données relationnelle(MySQL, la base de données relationnelle open-source la plus utilisée) avec un seul schéma(pour faciliter la jonction) pour stocker les données persistantes. Pas de réplication.
- Un magasin clé-valeur (Redis) pour mettre en cache nos bannières et les servir plus rapidement(facultatif mais améliore vraiment l'expérience utilisateur)
- Pas de tâches asynchrones(donc pas de travailleurs, pas d'événements de bus, pas de lac de données)
- Pas de communication directe entre services dorsaux.
- Seulement 2 environnements(local & production uniquement / pas de staging, pré-production)
Localement, Docker(en tant que conteneur logiciel uniquement) est utilisé pour chaque service backend afin d'anticiper la cohérence de l'environnement(entre les développeurs et le local/prod).
L'environnement de production est trop tôt pour être défini.
Les choses ne se passent jamais exactement comme prévu
Côté Backend : Le moteur central
Je pensais initialement que l'ensemble de la logique commerciale resterait dans un seul service, construit sur le code du prototype. Cependant, les choses ne sont pas aussi simples.
À la fin de la phase de prototype, nous n'étions pas du tout satisfaits de la qualité des bannières générées. Elles étaient légèrement floues en raison du format d'image matricielle que nous utilisions (JPEG). Nous avons donc décidé de passer à une génération de format vectorisé (SVG).
La contrainte de pouvoir générer sur la partie backend un fichier SVG autosuffisant(sans appel HTTP externe) nous a poussé à convertir des textes(avec une police spécifique) en SVG Paths. Sauf à utiliser des bibliothèques de polices de bas niveau et à coder de toutes pièces la transformation, je n'ai trouvé qu'une seule bibliothèque qui le couvre.
Comme je ne voulais pas perdre de temps, j'ai été obligé d'utiliser Javascript du côté backend (Node.JS) pour couvrir la partie rendu.
À partir de cette malheureuse réalité, j'ai décidé de séparer clairement les préoccupations :
Génération de bannières (service Python/ Falcon - framework API / Gunicorn - serveur WSGI):
- Comme il s'agit du cœur de notre produit et qu'il contient la majeure partie de la complexité de notre activité, il doit être conçu de manière adéquate. En m'en tenant à l'approche Domain Design Driven (DDD), j'ai pu définir précisément la responsabilité de chaque composant et représenter les problèmes et solutions de l'entreprise dans le code. Évidemment, le DDD peut augmenter le délai de livraison et doit être limité dans une certaine mesure pour maintenir une vitesse élevée.
- Il doit être dimensionné uniquement en fonction du nombre de bannières générées.
Rendu des bannières et des actions des utilisateurs
(service Javascript / Node.js - serveur web / Express - cadre API) :
- Je l'ai considéré comme éphémère, car les actions de l'utilisateur vont sûrement changer/évoluer de façon spectaculaire entre le MVP et la prochaine version.
- Comme toujours, dans le processus de hiérarchisation de mes efforts, il est de moindre qualité que son homologue Python.
- Il doit être mis à l'échelle en fonction du nombre d'utilisateurs, de bannières enregistrées et générées.
Présentation layer: La représentation de notre marque
Depuis la montée en puissance des frameworks Javascript pour construire des applications d'interface utilisateur, la présentation layer offre également une grande variété de choix. Dans cet écosystème, le langage lui-même évolue à un rythme très rapide. L'introduction d'ECMAScript 6 a constitué une évolution majeure du langage et le rend facilement utilisable.
Nous avons choisi de construire une application à page unique(SPA), afin d'offrir l'expérience utilisateur la plus fluide.
Je n'avais aucune expérience préalable dans la construction de SPA, juste une expérience dans la construction à partir de zéro d'un script JS pour afficher de multiples formats publicitaires bannière sur des sites web. Pour réduire les risques, et après de nombreuses lectures, j'ai choisi le plus gros vaisseau existant(processus de publication très actif, énorme communauté et très tendance), React.
Le fameux projet " Create-React-Application "(CRA) de Facebook m'a permis de créer une nouvelle application sans les inconvénients de la configuration des environnements, du bundler d'actifs (Webpack!), le transpilateur ECMA/JSX (Babel) et en plus de cela plusieurs optimisations de production sont déjà réglées. En ce qui concerne la partie visuelle, le framework React " Material-UI " était parfait pour commencer.
De la même manière que pour la partie backend, j'ai essayé de rendre la partie frontend aussi simple que possible, TypeScript et les bibliothèques de gestion d'état(Redux, MobX) semblent être des technologies/bibliothèques très attrayantes à utiliser mais je ne les ai pas utilisées car elles nécessitent des compétences que je n'avais pas à ce moment-là et peuvent apporter de nouveaux problèmes et augmenter la complexité du code.
Authentification et autorisation simplifiée
Il n'apporte presque aucune valeur à notre produit mais ne doit pas être sous-estimé car des données sensibles(confidentialité des utilisateurs) sont en jeu ainsi que notre image de marque. Je sais aussi que ce choix initial risque de nous suivre pendant longtemps car migrer d'une solution à une autre facilement est toujours compliqué.
Comme je ne voulais pas passer du temps sur ce sujet, j'ai choisi le service Auth0. Il fournit un plan gratuit, des widgets de connexion et d'inscription, des connexions aux fournisseurs d'identité sociale(Google, Facebook... ) et des jetons JWT qui peuvent être utilisés pour authentifier un utilisateur spécifique et lui autoriser des actions limitées.
Pour être honnête, si c'était à refaire, je n'utiliserais probablement pas cet outil car le chemin était très compliqué pour le rendre pleinement opérationnel (et c'est un service très coûteux une fois que le plan gratuit n'est plus adéquat, comme l'utilisation d'un domaine personnalisé pour intégrer le login de notre côté et ne pas faire face au problème de partage des ressources d'origine croisée(CORS)).
Notre back-office interne
De ce côté, la seule chose qui comptait était l'évolutivité fonctionnelle de la solution.
Nous avions 3 options :
- Construire à partir de zéro
- Utiliser un cadre d'administration et l'héberger manuellement
- En utilisant un SaaS tel que Forest.
Ne connaissant pas bien les services SaaS, nous avons choisi la deuxième option(en utilisant react-admin) afin de réduire tout risque lié à une fonctionnalité non disponible ou payante par exemple et d'en accélérer la livraison.
Pour l'instant, ce choix répondait pleinement à nos exigences.
Un nouveau membre a rejoint notre équipe fondatrice
Rémy nous a rejoint après 2 mois et demi en tant que fondateur. Ses compétences DevOps ont été cruciales pour la mise en place de notre infrastructure de production.
Mais d'abord, plusieurs choses ont été faites avant la mise en place de la production :
Le code de chaque projet a été copié sur un dépôt git distant(cela aurait pu être fait plus tôt, honte à moi !). Gitlab a été choisi car il fournit un nombre illimité d'utilisateurs ainsi qu'un CI/CD limité mais gratuit.
Sa courbe d'apprentissage devait être la plus rapide possible. Comme je devais expliquer le projet, les problèmes et les solutions auxquels nous avons fait, faisons et ferons face, j'ai dû prendre une courte pause.
Cette "pause" dans le développement m'a permis de me remettre sur pied, d'analyser ce qui a été livré, de mettre des mots sur des concepts théoriques que je n'avais que dans ma tête. Cela nous a également permis de discuter et de définir des orientations globales qui façonneraient notre produit pour l'avenir.
Prêt pour la production
L'architecture
Au début, j'ai imaginé utiliser un PaaS(Platform as a Service) en nuage (par opposition à IaaS en nuage ou sur site), comme Google App Engine ou Amazon Elastic Beanstalk, pour réduire le coût de maintenance, accélérer notre livraison et être capable d'évoluer facilement en fonction du trafic que vous obtenez sans aucune connaissance/compétences requises sur les détails opérationnels(réseau, CPU, mémoire, stockage... ). Les inconvénients de leur utilisation sont les suivants :
- le coût final qui peut être élevé et est difficile à connaître à l'avance puisqu'il s'agit d'un modèle de paiement à l'utilisation pricing
- l'énorme dépendance que vous obtenez vis-à-vis d'un seul fournisseur de nuages(connu sous le nom de verrouillage des fournisseurs).
Rémy a eu l'idée d'utiliser un Kubernetes (lesystème d'orchestration de conteneurs) géré par le Cloud. J'étais assez réticent à l'idée, car je n'avais aucune expérience en la matière et nous devions maintenir nos serveurs et nos bases de données.
Après quelques discussions, les capacités :
- la possibilité de passer d'un fournisseur à un autre sans trop de difficultés à l'avenir était très attrayante.
- Nos images Docker pourraient être poussées vers un registre distant et utilisées telles quelles facilement.
Le fait de savoir qu'il avait déjà adopté cette technologie en production(avec les microservices) m'a convaincu d'aller dans cette direction.
Nous avons obtenu 5k $ de crédits AWS grâce à notre abonnement à ProductHunt Ship, donc notre choix de fournisseur de cloud était assez simple :)
Néanmoins, je ne recommande pas du tout cette option pendant la phase MVP si vous n'avez pas d'expérience de la technologie. Même si ce n'est pas le moyen le plus rapide d'atteindre un environnement prêt pour la production, il apporte un système évolutif incroyable.
S'attaquer aux derniers 20%
Environ un mois avant la date de livraison prévue, 80 % ont été livrés et nous savions que cette phase serait compliquée car elle nécessite de tout mettre au point :
- Ajout de connecteurs Slack aux soumissions de feedback et de contact. Cela assure une meilleure réactivité du support utilisateur, presque en temps réel.
- Configuration de Hotjar et Google Analytics
- Révision de la base de données MySQL, pour s'assurer que la nomenclature et les index ont été correctement définis. Comme vous le savez, une fois en production, la migration des schémas/tables/colonnes est un peu plus délicate.
- Configurer les niveaux de journalisation dans toutes nos applications pour réduire le bruit.
- Assurer la sécurité de nos services backend (en utilisant des jetons JWT et en configurant des CORS).
- Polir les interfaces et ajouter Sentry pour suivre les erreurs du front-end
- Examiner un maximum de possibilités pendant la génération et s'attaquer aux bogues lorsqu'ils sont découverts.
- Nous avons modifié notre processus d'invitation car il est extrêmement important d'offrir une très bonne expérience lors de la première interaction avec votre marque.
Ouf, enfin ! Prêt à lancer \o/ Une semaine de retard par rapport à la date de livraison que nous avions prévue 4 mois plus tôt.
Wow, quel paysage magnifique :) Le lancement du MVP par la suite
Bien entendu, même après une phase d'assurance qualité(AQ) très poussée, des bogues surviennent toujours et doivent être corrigés.
Simultanément, le produit a été commercialisé sur plusieurs sites web, ce qui nous a permis d'obtenir du trafic et des retours.
Nous savions que plusieurs fonctionnalités devaient être améliorées et nous avons volontairement supprimé certaines d'entre elles dans cette version(mieux vaut moins de fonctionnalités que trop). Le retour d'information que nous avons reçu correspondait presque exactement à ce que nous avions prévu et nous a permis de définir plus précisément notre marché cible, ainsi que l'évolution future du produit.
À ce moment-là, nous avons pris le temps d'analyser et de classer chaque commentaire, puis nous avons lancé une session de discussion/remue-méninges de 3 jours à temps plein afin de définir la direction que nous devions suivre pour le produit bêta.
Le rôle du directeur technique dans une startup en phase de démarrage
Le rôle du CTO est évolutif : les responsabilités et les tâches ne sont pas les mêmes selon la phase dans laquelle se trouve l'entreprise.
De mon point de vue, dans une startup très précoce, ce rôle consiste à être capable de choisir des technologies, de livrer rapidement et efficacement... Les compétences nécessaires sont différentes de celles d'une autre étape de la startup où l'on attend du leadership et de la gestion :
- Capacité à comprendre les exigences de la recherche d'un langage de programmation approprié
- Responsable d'un très large spectre (front-end, back-end, dev ops, produit) et en même temps être pleinement conscient, comprendre et participer à chaque autre partie (marketing, affaires, communication).
- Restez concentré et motivé quoi qu'il arrive, personne ne vous dirige.
- N'ayez pas peur d'utiliser un langage/un cadre que vous ne maîtrisez pas, l'apprentissage rapide doit devenir votre meilleur atout/compétences.
- Évidemment, la communication avec vos collègues étant essentielle, le changement de contexte est un autre atout important à posséder.
- Make vos choix judicieux et soyez aussi neutre que possible
- Prendre des responsabilités
- Refactoriser souvent... très souvent...
À mon avis, le rôle du directeur technique à ce stade est proche d'un mélange de développeur full stack et de chef de produit.
Into the Abyss, tant de choses à découvrir !
Construire un concept minimum viable sur le plan technique est une question de choix en fonction du projet, de l'ambition, de l'expérience et des compétences techniques de l'équipe de la startup. Ces décisions, comme vous pouvez l'imaginer dans cet article, doivent être prises avec précaution car elles peuvent entraîner des retards importants dans la livraison du produit.
Par conséquent, il n'y a pas de solution miracle qui convienne à tous. Le seul conseil que je puisse donner est de façonner votre produit en fonction des forces de votre équipe fondatrice.
Je pense que nous avons atteint notre première étape avec succès, mais la partie la plus difficile reste à faire. Il faut d'abord réussir à monétiser notre produit en choisissant le bon modèle d'entreprise (et pricing), puis le faire évoluer tout en maintenant une rétention saine.
👏👏 vous avez survécu avec succès à cet article ! ! !:)
Si vous avez des questions concernant cette histoire, n'hésitez pas à nous contacter à l'adresse suivante :Abyssale.com.