Business : Gestion des versions axée sur les objectifs: un meilleur schéma pour les versions de produits

Oh, le MVP! Le concept incroyablement populaire qui a conquis le monde du logiciel il y a plus de dix ans lorsque Eric Ries changé la façon dont nous pensons à l’adéquation produit-marché.

L’idée d’un produit minimum viable valait en effet son pesant d’or à une époque où le risque le plus important pour les entreprises était de livrer trop tard, de rater le marché, de tout miser sur des hypothèses non prouvées qui ne menaient nulle part. Je voudrais que nous pensions que notre industrie a finalement dépassé le MVP.

De nos jours, les différentes parties prenantes ont tendance à avoir des interprétations étonnamment différentes de ce que signifie Minimum viable. Les organisations sont devenues bonnes à expédier tôt. Trop bon, parfois. Maintenant que nous avons surmonté cette bosse en tant qu’industrie, nous avons surtout du mal à trouver juste combien de temps un produit ou une fonctionnalité spécifique doit être lancé et communiqué à toutes les parties concernées.

La version pilotée par les objectifs (GDV) est une meilleure approche du MVP, et les gains suivants deviennent immédiatement disponibles avec:

• Un meilleur alignement autour du niveau de maturité d’un produit est et devrait être
• Une progression cohérente des objectifs fixés pour chaque produit que vous expédiez
• Une meilleure compréhension du coût attendu de chaque niveau de maturité
• Un moyen facile d’élaborer des stratégies et de communiquer l’investissement dans chacun de vos produits au fil du temps

Voici le TLDR: vous versionnez vos produits en interne à l’aide de la gestion de versions sémantique (par exemple, v3.1.9), et associez des versions majeures spécifiques à quelques jalons que vous jugez essentiels pour chaque produit que vous atteignez à l’avenir. Pour atteindre ces jalons, vous publiez des versions incrémentielles en cours de route, en communiquant mieux où se trouve votre produit et où vous le souhaitez!

Voici un exemple de recette que j’aime utiliser pour mon GDV:

De façon intéressante, Gitlab a mis au point un cadre similaire qu’ils utilisent pour leurs produits, et j’ai été ravi de voir qu’il y a une tonne d’alignement entre leur recette et la mienne.

1. Souhaitable (v0.1.0)
2. Précieux (v1.0.0)
3. Et enfin, Délégant (v10.0.0)

Ce sont trois objectifs essentiels (le «G» dans «GDV) que la plupart des produits atteignent tout au long de leur processus de développement. Pour ceux qui ont passé quelques années à créer des logiciels, il devrait être évident que chacun de ces termes traduit des niveaux de maturité et d’investissement extrêmement différents. Bien que vous puissiez choisir vos noms, je vous encourage à les considérer car ils sont faciles à approuver par les parties prenantes et leur réalisation a tendance à être facile à mesurer concrètement.

Par exemple:

La fonctionnalité est-elle souhaitable? Eh bien, je viens de donner une démo à un prospect et ils se sont immédiatement inscrits pour un essai. Ok, expédions!

Le produit est-il précieux? Bien que nos clients continuent de se plaindre des aspérités de notre produit, ils ne peuvent pas se permettre de cesser de l’utiliser. Ok, expédions!

Que diriez-vous délicieux? Nous avons littéralement reçu notre troisième tweet positif d’un utilisateur. Ils continuent de passer le mot sur nous. Ok, expédions!

La principale raison d’aligner la version de votre produit sur ces objectifs est d’accomplir le développement de votre produit dans le bon ordre. Vous ne devez pas investir dans l’amélioration de votre produit avant de savoir que vous êtes sur la bonne voie en termes d’adaptation au marché des produits. Ce système fonctionne également bien car vous pouvez parcourir la ligne entre ces trois objectifs en utilisant des versions partielles comme la v0.5.0. La maturité de votre produit est un continuum qui les unit.

Voici l’affaire, construire quelque chose de souhaitable est considérablement moins cher que de construire quelque chose de précieux. Le niveau de profondeur, d’itération et de minutie requis par un produit entièrement fonctionnel est si écrasant que la plupart des entreprises doivent d’abord s’assurer que leur vision du produit peut d’abord attirer l’attention des clients. De même, un produit qui est de délicieux jouets avec la définition de « magique ». Le type de polissage, les connaissances et l’expertise qui peuvent amener une équipe à accomplir un tel exploit ne valent tout simplement pas la peine d’être recherchés tant que votre produit ne peut pas générer de réels revenus.

Comme exercice, supposons que nous sommes Slack. À quoi ressemblerait la version v0.1.0? Ce devrait être la plus petite version du produit qui puisse prouver visuellement que la vision actuelle est quelque chose que les clients veulent. Je pense que cela ressemblerait à un simple client de chat qui illustre le concept de canaux. Les canaux (l’idée de salons de discussion sur des sujets de longue date que les gens peuvent décider de rejoindre ou de quitter eux-mêmes) sont le principal facteur de différenciation de Slack. Les canaux doivent être en v0.1.0 afin qu’ils puissent prouver que notre vision est souhaitable une fois que les utilisateurs auront vu la démo.

Hourra! Nous montrons le produit et les gens aimé le concept de canaux, inscrivez-vous immédiatement, puis réalisez rapidement qu’il y a des lacunes. Nous n’avons pas construit la fonction de «recherche», et c’est fondamental. Nous pouvons même perdre certains de ces premiers croyants. Certains d’entre eux pourraient tweeter que vous êtes une personne terrible. N’ayez pas peur; tout cela fait partie du plan! Nous avons prouvé que les chaînes fonctionnent!

À mesure que notre feuille de route progresse vers la v1.0.0, les objectifs sur lesquels nous nous concentrons passeront à toutes les autres fonctionnalités dont les utilisateurs ont besoin au quotidien. Des choses comme une fonctionnalité de recherche de base, le partage d’images et de documents et les intégrations seront dans la version 1.0.0. À ce stade, les utilisateurs tireront de la valeur du produit. Ils peuvent ne pas l’aimer, mais cela répondra à leurs besoins, alors ils ne cesseront pas de l’utiliser. Ils vont se plaindre et demander des fonctionnalités manquantes essentielles, mais ils ne partiront pas. C’est ce que vous voulez à la v1.0.0.

La v10.0.0 est le millier de nouveautés qui font de Slack le produit que nous aimons tous. Une recherche très étendue, des chaînes privées, des chaînes partagées, des discussions, des thèmes et des réactions emoji tellement impressionnantes. Une fois que vous avez capturé un public et qu’il paie pour votre produit, vous pouvez et devriez entreprendre avec plaisir de découvrir la myriade de demandes de fonctionnalités et d’améliorations de l’utilisabilité qui le transformeront en v10.0.0. Accéder à la version 10.0.0 est l’objectif si vous voulez rester indéfiniment. Rester en v1.0.0 est ce qui est arrivé à Feu de camp.

Nous ne faisons qu’effleurer la surface sur GDV. J’ai trouvé le cadre extrêmement précieux pour communiquer et visualiser les étapes du développement de produits.

Différentes fonctionnalités d’un produit peuvent être versionnées indépendamment. Vous souhaitez accomplir ces étapes à des moments différents pour chaque fonction de votre produit? Versionnez-les indépendamment et agrégez-les approximativement pour déterminer à quel stade se situe votre produit global.

v0.5 est une chose. Croyons-nous que nous devrions investir au T2 pour arriver à mi-chemin de l’objectif de notre vision de «précieux»? Bien sûr, alors appelez-le «Nous avons livré la version 0.5.0», et tout le monde comprendra à peu près le genre de progrès qu’un tel jalon représente.

La stratégie produit peut être facilement représentée et discutée via le contrôle de version. Voici un exemple de plan de produit qui peut facilement atterrir dans une plate-forme de réunion du conseil d’administration. Chacune de ces boîtes peut être des produits sur une plateforme plus grande ou des fonctionnalités de votre produit unique:

Permettez-moi de répéter nos gains clés. En adoptant le GDV (Goal Driven Versioning), les éléments suivants deviennent immédiatement disponibles:

• Un meilleur alignement autour du niveau de maturité d’un produit est et devrait être
• Une progression cohérente des objectifs fixés pour chaque produit que vous expédiez
• Une meilleure compréhension du coût attendu de chaque niveau de maturité
• Un moyen facile d’élaborer des stratégies et de communiquer les investissements dans chacun de vos produits au fil du temps

Qu’est-ce que tu penses? Cela semble-t-il une approche raisonnable? Essayez-la la prochaine fois que vous construisez quelque chose!