Un démarrage, par définition, est une entité avec des ressources limitées. Ces ressources pourraient être le budget, le temps, le talent ou tout autre élément lié, mais ce qui est certain, c’est qu’il existe effectivement une forme de limitation des ressources - sinon, ce ne serait pas une start-up.
C'est pour cette raison que de nombreux styles de gestion ont été testés et testés pour relever le défi que représente le lancement et l'exécution de ces bêtes de temps et d'énergie. Et au fil des ans, il semble y avoir deux écoles de pensée indépendantes sur le marché: le lancement allégé et le grand développement.
Le lancement allégé implique des processus tels que les processus de développement agile, les tests utilisateur, la validation des idées, la programmation ciblée, le développement axé sur les comportements et bien d’autres encore. Par ailleurs, vous avez la grande version avant le lancement: dans ce modèle, les développeurs consacreraient beaucoup de temps et veilleraient à ce que les fonctionnalités soient complètes avant qu'un seul client ne les voit une seule fois.
Ces deux écoles de pensée ont chacune leurs avantages et leurs inconvénients, comme on pourrait l’imaginer, et elles ont chacune des gestionnaires qui y croient presque complètement. Dans cet article, nous pouvons découvrir lesquels ne sont pas durs et ceux qui le sont. Ou nous pouvons trouver quelque chose de surprenant. Plongeons dedans.
Let's face it, le design est extrêmement important. En fait, le design est si important qu'il a presque entièrement dépassé certains processus de démarrage. Ils consacrent tout leur temps et leur énergie à l'expérience de l'utilisateur et, pour atteindre un état de fonctionnalité complet, ils ont peu de temps pour autre chose - et peut-être à juste titre. Maintenant, l’autre partie ne dirait pas que c’est la bonne façon, mais nous laisserons cet argument pour plus tard. Pour l'instant, nous parlons du monde d'un UX poli et d'un ensemble de fonctionnalités avant le lancement.
Tirer parti de la marque complète
Le branding est un sujet de grande envergure, et c'est pour cette raison que les gens semblent ressentir le besoin de travailler de cette manière. Ils ont le sentiment que s’ils vont lancer, ils devraient lancer avec tout ce que leur marque représente, en cours de construction sur le site dès le premier jour. Le classique, "v1 devrait être complet" est quelque chose que j'ai entendu des gestionnaires fréquemment. Et il y a un bon raisonnement derrière cela. Ils ne veulent pas que leur site Web reflète ce qu’ils ne sont pas et c’est là que réside la parodie. Nous y reviendrons plus en détail dans la section contre, mais cela peut conduire à de sérieux écarts de fonctionnalités. Ma devise est, si vous entrez dans un espace où il y a des concurrents qui sont peut-être plus marqués que n'importe quel autre espace en ligne (pensez à Dropbox ou Apple), alors vous voudrez peut-être sérieusement envisager cela. très important. Cependant, on peut épouser un lancement allégé avec une technologie fabuleuse et une belle marque, tout en un - dont nous discuterons également plus tard.
Recevoir un intérêt immédiat
Un autre point positif en ce qui concerne le déploiement raffiné et soigné est qu’il peut attirer plus d’utilisateurs à l’avance grâce à la conception fantastique et au service complet apporté à l’ensemble du produit. C'est du moins ce que nous aimons assumer. De façon réaliste, cependant, cela peut également constituer un obstacle à l’entrée. J'ai vu des utilisateurs qui ont le sentiment qu'un produit est trop gros ou a trop de fonctionnalités pour qu'ils puissent ressentir le besoin de l'utiliser, et ils rebondiront sur le site en moins d'une minute. Se produit tout le temps, et c'est trop triste. Je déteste voir les idées des entrepreneurs ou même des gestionnaires être aspirées à cause de la fluidité trop fréquente des fonctionnalités. Bien que cela se produise, les entrepreneurs n’ont toujours pas le sentiment que l’intérêt sera multiplié par dix s’ils remplissent entièrement leur produit avant leur lancement. C'est un gros
Être complet
Si vous parvenez à ce stade et que vous vivez dans ce camp, alors vous êtes plus que probable que la fonction soit complète à ce stade. Nous en avons parlé un peu jusqu'ici dans les sections ci-dessus, mais voici où cela devient intéressant. Beaucoup, et je veux dire qu’un grand nombre de start-ups estiment qu’elles doivent être complètes avant de pouvoir facturer ou avoir un impact. Je ne dis pas qu'il n'y a pas de mérite à cet argument, mais je pense qu'il a été exagéré au fil des ans. De mon point de vue et de ce que j'ai vu au fil des ans, vous pouvez simplement demander si les utilisateurs paieraient pour un produit avant de compléter le tout. Maintenant, disons que vous étiez sur le point d'être complet, et que vous vouliez vraiment tout. Eh bien, vous pourriez lancer une version très minimale de chaque fonctionnalité. Quelque chose qui représente les fonctionnalités en question, ou peut-être même les vidéos manquantes. Gardez à l'esprit qu'il y a des façons de compléter les fonctionnalités sans être réellement présentes.
Caractéristique de fluage
Il s’agit d’un échec commun en ce qui concerne l’UX et son approche complète du lancement d’une start-up. Et c'est ce que nous appelons une situation appelée la spirale de la mort des caractéristiques. Les responsables ou les propriétaires ressentiront le besoin d’ajouter de plus en plus de fonctionnalités au produit au fur et à mesure que vous en compléterez d’autres, jusqu’à ce qu’il n’y ait plus rien à faire mais à ajouter de nouvelles fonctionnalités. Il s'agit d'un cycle sans fin dans certains cas, en particulier dans les cas où vous ne disposez pas d'un ensemble rigide de lignes directrices ou de spécifications .
Développement de cascade
Le développement des cascades est un problème à part entière et non sans controverse. Un flux de travail typique en cascade ressemble à ceci: idée, conception, développement, test, maintenance. Il y a des gens qui prospèrent dans un tel environnement, mais au moins un nombre égal le trouve absolument préjudiciable. Ou bien c'est un processus assez standard qui semble très normal pour la plupart d'entre nous, et pourtant, pour des idées qui deviendront bientôt évidentes, cela peut souvent nuire à l'expédition d'un produit.
La raison n'est pas nécessairement dans le modèle du système lui-même, mais dans le fait que vous avez des équipes distinctes qui effectuent des tâches qui sont chacune gérées par des gestionnaires individuels. Par exemple, un flux typique peut ressembler à ceci: une idée est formée par le fondateur / entrepreneur; il embauche une équipe de conception et de développement et peut-être des directeurs ou des directeurs créatifs pour chaque équipe; l'idée est passée à la conception, pour créer des maquettes, ces maquettes se transforment en documents Photoshop qui vont et viennent avec le propriétaire et le directeur de la création jusqu'à ce qu'ils soient parfaits; alors, sans aucun consensus quant à ce qui est même possible, il est transmis au développement pour être créé; puis, après avoir fait des allers-retours avec le responsable de l’équipe de développement, le propriétaire et peut-être même le directeur de la création, ils trouvent un terrain d’entente et finissent le produit.
Ce que je n’ai pas mentionné, c’est que chacune de ces étapes impliquait probablement 50 à 100 e-mails individuellement, et c’est une estimation prudente (très conservatrice). Comme vous pouvez le constater, ce n’est pas vraiment efficace, car à tout moment, le propriétaire et le fondateur peuvent ajouter plus de travail qui ne figurait pas dans le plan ou en changer. La microgestion n'est souvent pas la meilleure option en matière de développement logiciel, et pourtant, le système en cascade semble prospérer dans un tel style de gestion.
Gardez toujours cela à l'esprit, et si vous ne travaillez pas bien, faites-le savoir à votre patron. Rappelez-vous qu'il vaut toujours mieux être franc et honnête à propos d'un futur improductif que de se retrouver dans une situation improductive. Gardez également à l’esprit qu’il ya des problèmes de microgestion plus courants dans ce système; D'après mon expérience personnelle, ce n'est pas idéal.
Alors, quel est l'idéal? Eh bien, c'est subjectif, mais je peux vous dire que ma capacité à lancer rapidement et à parcourir les temps de cycle a permis à mes équipes et moi-même d'expédier une plus grande quantité de produits qu'avec Waterfall. Alors, quel est ce mystérieux système magique de produit d'expédition?
À mon avis, la start-up Lean a révolutionné notre communauté. Et c'est principalement parce qu'il est basé sur ce qu'on appelle la boucle de rétroaction apprendre-construire-mesurer.
L'art du déploiement rapide - souvent une simple page qui demande aux utilisateurs de payer pour cela, ou peut-être un produit simple - est quelque chose que les gens ont perfectionné au cours des années et que je suis de plus en plus attaché à notre monde de la technologie Je pense que c'est de plus en plus important.
L'important est l'acceptation et la validation du marché. Une question clé: qui dit que le code que vous écrivez est significatif? Nous vivons dans une époque où les gens ne peuvent vraiment pas gaspiller une once de leur précieux temps. C’est le moment de le faire ou de le briser, et d’aller à l’envers des mentalités. C'est un moment où la réalité nous frappe tous les jours quand nous ne pouvons pas acheter de la nourriture ou payer un loyer, et c'est pourquoi il est d'autant plus important de ne pas gaspiller du code que personne n'utilisera.
Vous n'avez pas besoin d'être un génie du marketing, mais vous devez comprendre un état d'esprit expérimental. L'état constant de la bêta est une brillante métaphore. Nous ne devrions jamais être tellement emballés par notre fierté que nous ne pouvons même pas changer un élément d’un projet. Nous devons nous rappeler que la vie est expérimentale et que le plus tôt vous vous en rendrez compte, et qu’il n’ya pas de meilleur moyen que le démarrage simplifié.
Commentaires des utilisateurs
Utiliser une méthode comme celle-ci revient à parler d'un stock avant qu'il ne soit à son maximum. C'est un excellent moyen d'obtenir des informations sur votre cible démographique de base et d'obtenir une validation avant de perdre votre temps.
Voici comment vous le faites. Obtenez une page de destination et montrez ce que votre produit ou service fait de manière très belle et explicative. Dépensez de l'argent sur cette partie si vous le souhaitez, car c'est le plus important. Ensuite, inscrivez-vous avec votre adresse e-mail si cela vous intéresse. Terminé. Maintenant, cela peut ne pas sembler faire beaucoup, mais vous faites beaucoup dans la réalité. Vous validez un marché de produits ou un marché de services complet avec une page. Vous ne dépensez pas des mois et des milliers de dollars pour créer quelque chose d’inutile que personne n’utilisera, vous ne faites que créer une chose pour savoir si cela en vaut la peine.
Il y a des gens qui lancent 5 pages de service similaires à ce que je viens de dire, et ceux avec lesquels ils ont le plus de commentaires sont ceux avec lesquels ils avancent. C'est un acte brillant et on peut le voir investir de nombreuses façons. Vous obtenez des rendements sur votre investissement et, sinon, vous quittez le marché avant de perdre beaucoup de gains potentiels. Je pense que Warren Buffet aimerait ça.
Cycles d'itération plus rapides
L'une des meilleures choses à faire en matière de développement de produits est que vous constaterez souvent que vos cycles d'itération sont beaucoup plus rapides et que, dans certaines entreprises, ils livrent du code plus de 20 fois par jour. Il y a beaucoup de philosophie derrière cela, par exemple comment sur Facebook quand un nouvel ingénieur est mis à bord, ils reçoivent 5 corrections de bogues dans leur e-mail de bienvenue le premier jour. Une grande partie du raisonnement derrière de telles choses est que si votre système est configuré de manière à ce qu’il se casse chaque fois qu’un nouvel employé arrive à bord, ce n’est pas lui que votre système est cassé.
Développement agile
Le développement agile va par essence d’une petite chose à l’autre le plus rapidement possible. Vous passez ensuite de chaque sprint au sprint suivant, qui est souvent défini par une user story et qui est simplement un utilisateur de votre site qui souhaite un peu de fonctionnalité. Il est très similaire au test dans Rails ou autre, car vous ne faites que ce dont vous avez besoin et rien de plus. On peut gagner énormément de temps en faisant du développement de cette façon.
Un petit point négatif qui peut se produire lorsque vous utilisez le système de développement agile et de démarrage allégé est que le site peut changer au fil du temps. Maintenant, idéalement, cela se produirait à la demande d'un utilisateur, mais cela pourrait toujours choquer certains utilisateurs.
Donc, le faire avec classe et élégance est important. Surtout si c'est un produit qui les intéresse. Ne déracinez pas la base utilisateur principale de votre produit, contrairement à Digg v4, mais fournissez plutôt des détails sur ce que vous faites et pourquoi, et si tout le reste échoue.
Veillez à toujours utiliser quelque chose comme git ou subversion pour enregistrer les versions de votre produit. En fait, je le fais en tant que succursales, de sorte que nous pouvons toujours revenir en arrière si nécessaire.
Si votre démarrage est si technique que cela n'a pas d'importance, continuez avec le déploiement rapide. Les gens se soucieront du changement technologique qu'ils voient. Cependant, si vous êtes en compétition dans un espace où la concurrence est forte, une combinaison des deux est peut-être la meilleure. En bref, faites toujours de votre mieux avec des UX raffinés, mais faites-les en rafales agiles.