Les startups sont essentiellement des machines qui construisent des MVP (produits minimum viables) qui aident à répondre aux questions et à réduire progressivement les risques de la proposition de valeur de l'entreprise.
La clé est que chaque MVP créé par une entreprise doit se concentrer sur la réponse à une question très particulière. Si vous faites autre chose que cela, c'est une perte de temps et d'efforts. D'après mon expérience, de nombreuses startups s'inquiètent de la mise à l'échelle trop tôt, gaspillant des ressources sur quelque chose qui ne sera peut-être jamais nécessaire.
Cette tendance est particulièrement évidente dans les start-ups fondées par des personnes issues de disciplines d'ingénierie dans de grandes entreprises à grande échelle. Mais les choses que vous devez faire pour soumettre du code sur Facebook, Netflix, Amazon ou Google ne s'appliquent pas de la même manière aux startups en démarrage.
Les startups en démarrage peuvent avoir quelques centaines ou milliers de clients, et chaque liste de clients a son propre ensemble de défis.
Ne vous méprenez pas; Il est toujours préférable de s'assurer que votre code est relativement sécurisé et écrit de manière à ne pas dégrader l'expérience client. Mais les fondateurs techniques se trompent souvent et passent beaucoup de temps à durcir le code (c'est-à-dire à le rendre sécurisé) ainsi qu'à l'écrire et à l'implémenter de manière à ce qu'il soit évolutif.
Mais cela ne fonctionne pas tout à fait lorsque vous êtes en mode preuve de concept.
Les fondateurs inexpérimentés sont souvent sur la défensive à propos de ce genre de choses, s'inquiétant trop de savoir si le produit ou la fonctionnalité qu'ils viennent de créer offriront une expérience utilisateur transparente ou s'inquiétant de savoir s'il peut gérer un million d'utilisateurs simultanés. Oui, ces choses sont importantes, mais elles peuvent ne pas être justes à ce moment précis.
L'état d'esprit des startups en phase de démarrage devrait être que vous créez des MVP pour répondre aux questions. Gardez à l'esprit que MVP est toujours un terme terrible ; ce n'est ni un produit ni viable. Ce n'est pas non plus si "minimal" dans de nombreux cas. Un MVP est le moins de travail que vous puissiez faire pour confirmer ou rejeter une hypothèse pour votre startup.
Si l'hypothèse est : "Est-ce qu'un million de clients peuvent utiliser cette application en même temps ?" Bien sûr, c'est le bon moment pour l'optimiser à un pouce de sa durée de vie. Mais, lorsque vous créez une entreprise au début, c'est rarement la question, et à moins que vous ne soyez dans des catégories particulières d'applications qui doivent être résistantes à des volumes de trafic notables, les investisseurs ne s'en soucieront probablement pas.
Dans l'une des start-ups que j'ai aidées, l'entreprise avait un produit dans lequel elle mettait des dizaines de milliers de personnes dans une salle d'attente, et lorsqu'un compte à rebours expirait, tout le monde pouvait entrer dans le produit. Cela s'est avéré être un défi intéressant : que se passe-t-il lorsque 10,000 XNUMX personnes accèdent exactement à la même partie d'une application Web à une seconde d'intervalle ?
Comme vous pouvez l'imaginer, même de petites inefficacités dans la plate-forme ont provoqué des goulots d'étranglement majeurs et une dégradation potentielle du service. À court terme, il a "résolu" le problème en allumant un tas de serveurs supplémentaires, puis en laissant entrer les gens en quelques minutes ; avoir 500 personnes frappant le code légèrement inefficace à la fois était beaucoup moins un problème que d'avoir 10,000 XNUMX personnes se connectant toutes en même temps.
Élégant? Non. Cela a-t-il fonctionné ? Oui, et cela avait du sens car, à l'époque, l'entreprise ne se souciait pas explicitement de savoir si le service pouvait desservir 100.000 XNUMX clients en même temps. Alerte : ce n'était pas possible, et au moment nécessaire, cette partie du code avait été refactorisée de manière à ce qu'elle le soit.
Au début, les questions tendent à être : « Est-ce que ce que nous essayons de faire est possible ? ou "Est-ce que les gens vont payer pour ça?" ou "Pouvons-nous convaincre une entreprise partenaire d'intégrer cela ?" ou "Pouvons-nous acquérir des clients à un coût raisonnable ?" ou "Pouvons-nous faire cela à un prix qui a du sens?" ou "Comment fonctionne l'économie unitaire de ce produit à mesure que nous évoluons?"
Pour une entreprise de pré-amorçage, vous n'avez pas besoin d'une conception et d'une évolutivité parfaites ; vous devez créer suffisamment de produit et de traction pour obtenir les commentaires des utilisateurs. À partir de là, vous pouvez itérer et créer de la valeur pour les clients. Une fois que vous commencez à offrir suffisamment de valeur pour laquelle les clients sont prêts à payer, vous pouvez commencer à envisager d'investir davantage dans l'évolutivité.
La sur-ingénierie d'un produit trop tôt n'est ni importante ni intelligente. C'est un contre-indicateur : cela indique aux investisseurs que vous ne savez pas ce qui est important au stade actuel de votre startup.
Lorsque l'attention est concentrée, le test décisif s'exécute : votre activité actuelle contribue-t-elle à la garantie pour vous aider lors de votre prochaine ronde de collecte de fonds ? Sinon, vous travaillez probablement sur quelque chose qui semble super important, mais qui n'est pas approprié pour le scénario.
C'est un problème - vous pourriez toujours passer plus de temps à construire quelque chose de plus sophistiqué, plus rapide, plus joli ou plus évolutif - mais le mantra au démarrage devrait être "assez bon, c'est assez bon". C'est incroyable la rapidité avec laquelle vous pouvez aller une fois que l'entreprise l'a internalisé.
