L’Outil Surpuissant pour Exploser ton Chiffre d'Affaires en 2024 !
La voie vers un produit minimal attrayant
Au cours de la dernière année, mon équipe et moi avons mis au point une toute nouvelle solution d'analyse sociale au sein de Buffer appelée Buffer Analyze. Nous avons fait de notre mieux pour résumer les recherches, les données et l'intuition en une solution allégée et adorable, et nous avons eu la chance de trouver les premiers signes de compatibilité produit / marché.
(Actuellement, la version bêta de Analyze est ouverte à Clients de Buffer for Business . Vous pouvez en savoir plus sur les fonctions d'analyse sociale d'Analyze ici .)
Nous souhaitons tellement faire avec Analyze parce que nous sommes tellement convaincu apportera de la valeur. En même temps, nous sommes très limités par nos ressources en tant que très petite équipe au sein de Buffer.
Pour être honnête, je ne l’aurais pas fait autrement. Des contraintes strictes imposent une approche créative, disciplinée et critique de la conception et du développement de produits.
Le produit résulte de la gestion d'un équilibre délicat des compromis. .
Je suis ravi de partager plus d'informations sur ces compromis: comment nous travaillons dans le respect des contraintes, comment définissons-nous les nouvelles fonctionnalités du produit et comment nous créons et fournissons de la valeur aux clients. Continuez à lire pour en savoir plus et n'hésitez pas à poser des questions dans les commentaires ou laissez-moi une note sur Twitter .
Avant de nous rejoindre: rêvez en grand, puis allez petit [19659009] En ce qui concerne la mise en œuvre des fonctionnalités du produit, je rêve généralement de grand, puis de petit.
Une fois que je pense avoir identifié nos plus grandes opportunités (un processus digne de son propre poste!), Je me réunis avec notre concepteur d’analyse, James pour examiner plusieurs solutions potentielles. Nous finirons par tomber sur un design qui, nous le pensons, va dans tous les sens, nous préciserons de nombreux détails et créerons un prototype de flux de travail pertinents. Nous incluons toujours les ingénieurs dans ce processus pour obtenir un retour rapide sur la conception et les idées.
C'est par exemple une solution que nous avons explorée pour notre nouvel outil d'analyse de hashtag. Nous avons fini par construire quelque chose de très différent!
Le résultat de cette exploration est généralement un prototype cliquable, accompagné d'une spécification détaillée – nous les appelons «spécifications» – en bref, des choix que nous avons faits en cours de route. (Nos spécifications ne sont pas traditionnelles: au lieu d'un document long, hautement technique et structuré, nous écrivons le nôtre en langage naturel avec une ventilation bien motivée de la solution proposée.)
Le design et les spécifications représentent souvent le Version idéale de la fonctionnalité si nous pouvions tout faire.
Mais, bien sûr, nous ne pouvons pas tout faire… et nous ne devrions pas le faire!
Dans une petite équipe aux ressources limitées et aux coûts d'opportunité élevés, il est dans l'intérêt de nos utilisateurs d'optimiser la valeur au lieu de complétude .
Plusieurs fois, exhaustivité des fonctionnalités. ne dessert pas directement le travail de base à effectuer mais offre plutôt une certaine commodité. La commodité n’est pas sans valeur en soi, mais lorsqu'un produit en est à un stade très précoce, il est primordial de trouver le produit / marché qui convient en fournissant une valeur fondamentale.
Alors, avec notre prototype complet et polyvalent, il est temps de prendre du recul et de faire le point sur le projet.
Devons-nous maintenant? construire tout de cela?
Presque tout le temps, la réponse est non; nous n'avons pas besoin de tout cela pour livrer la valeur fondamentale.
Avant de créer une fonctionnalité, nous passons par trois étapes de cadrage:
- Portée du produit
- Portée technique
- Portée du cycle
Durée
Première étape: définition de la portée du produit et histoires d'utilisateurs
Pendant la phase de définition du produit, chefs de produit et concepteurs collaborent pour concevoir la ou les fonctionnalités que nous souhaitons traiter dans un prochain cycle de développement. Nous nous retrouvons avec une version spécifique, dotée de nombreuses fonctionnalités, si nous pouvons le faire. La portée est presque toujours plus grande que celle que nous allons construire initialement.
Une fois que notre fonction est conçue, nous allons explicitement prendre du temps pour définir et réduire la version minimale attrayante . qui est la plus petite version du produit qui apporte toujours une valeur matérielle à l'utilisateur.
Toute version plus petite que la version minimale aimable ne fait tout simplement pas le travail et ne vaut donc pas la peine d'être construite.
Vous pouvez presque toujours expédier une version plus petite que celle que vous pensez d’abord! Pousser pour aller vite dans l'esprit de la navigation et pour apprendre plus tôt.
Exemple: lorsque j'ai analysé la version minimale d'Analyze, mes recherches et mon intuition m'ont toutes deux dit qu'il nous fallait une simple comparaison. outil comme base, caractéristique minimale. J'étais convaincu que personne ne paierait notre produit sans cela, mais je me suis trompé. La fonction de comparaison a pris un peu plus de temps que prévu, et nous avons décidé d’envoyer Analyze sans le logiciel et de voir ce qui se passait. Et voilà, nous avons gagné notre premier client heureux et payant même sans l'outil de comparaison!
Ce fut une excellente occasion de tester mon hypothèse selon laquelle les gens avaient besoin de l'outil de comparaison pour obtenir suffisamment de valeur, et cette hypothèse. a été heureusement invalidé. Cette expérience m'a incité à remettre en question tous les aspects essentiels d'un nouveau produit ou d'une nouvelle fonctionnalité.
Par exemple, nous avons découvert que les utilisateurs pouvaient obtenir beaucoup de valeur en comprenant mieux l'impact de leurs hashtags sur la portée et l'engagement. . Après plusieurs explorations de conception, nous sommes arrivés à cette version complète de notre module d’analyse Hashtag, si-nous-pouvions-tout-le-faire:
est présentée ci-dessous.
Une fois que notre solution complète est spécifiée, je vais la diviser en histoires d'utilisateurs.
Une histoire d'utilisateurs est un bloc discret d'utilisateurs. valeur. Nous utilisons le format suivant:
"En tant queje veux ainsi je peux "
puis joindre des dessins, des détails et des critères d'acceptation.
une histoire suffit pour représenter une fonctionnalité complète, mais le plus souvent, une fonctionnalité se transforme en plusieurs histoires d'utilisateurs: chacune étant un bloc de valeur discret et pouvant être expédié.
Nous réduisons ensuite notre liste complète d'histoires d'utilisateurs en un plus petit sous-ensemble, ce qui représentera notre version minimale attrayante. Par exemple, un prototype peut générer cinq user stories, mais notre version minimale ne sera que deux de ces cinq.
Deuxième étape: cadrage technique et estimations
Avec les conceptions à portée de main, les spécifications du produit en main, et notre Les histoires d'utilisateurs réduites et prêtes à l'emploi, nous nous réunissons en équipe et parcourons ensemble les histoires d'utilisateurs. Les ingénieurs posent souvent des questions de clarification, et nous ajusterons les détails de nos histoires ensemble, si nécessaire.
Une fois que les ingénieurs sont satisfaits de bien comprendre le problème et la solution proposée, ils décomposent les histoires d'utilisateurs. tâches d'ingénierie.
Les tâches d'ingénierie sont des tâches discrètes qui sont estimées avec un ensemble intentionnellement grossier d'estimations possibles: un jour, trois jours ou une semaine. Les travaux estimés sont calculés conjointement par les ingénieurs et servent à deux objectifs principaux:
- Assurez-vous que tous les ingénieurs sont sur la même page dans conditions d'effort requises pour chaque tâche
- Fournissez au responsable produit une vérification générale de l'intestin pour la planification du cycle.
Les estimations ne sont pas utilisées à des fins de responsabilisation des ingénieurs. Nous voulons seulement savoir que nous estimons à mi-chemin l’estimation des tâches d’ingénierie (ce qui est notoirement difficile à bien faire!) Et que nous sommes tous d’accord sur ce que les tâches impliquent.
Étape 3: Cycle de cadrage et de planification [19659030] Maintenant que nous avons une liste des user stories et des tâches d'ingénierie qui représentent leur réalité, j'utilise ces informations pour planifier notre cycle de développement. Nous travaillons actuellement sur des cycles de développement de six semaines mais je n’aurai pour objectif que de planifier les quatre premières semaines au départ. Au cours de la troisième semaine du cycle, je ferai le point sur notre situation, réaffecter les priorités et planifier la seconde moitié du cycle.
Une fois les tâches d'ingénierie en place, je suis en mesure de hiérarchiser nos user stories. dans le contexte du temps disponible. Nous travaillons souvent sur deux, voire trois fonctionnalités à la fois, et le budget des dépenses me permettra de décider laquelle doit venir en premier.
Par exemple, si nous avons trois histoires d’utilisateurs, je pourrais quand même choisir de créer les «moins utiles». ”Une première si cela prend beaucoup moins de temps que les autres. Cela a plus de valeur pour nos utilisateurs plus tôt.
Et – s'il vous plaît, gardez-moi -, je vais aussi «retracer» certaines histoires au-delà de notre version minimale aimable.
Je sais, je sais! J’ai prêché les vertus de ramasser et d’abaisser encore.
Mais imaginez une jarre pouvant contenir cinq cailloux. Même si vous ne pouvez pas installer un sixième rocher, il y a encore un espace entre les cinq rochers et peut-être que nous pouvons insérer dix cailloux dans cet espace.
Dans cette analogie, le pot correspond à notre cycle de six semaines, les rochers étant le les user stories requises pour satisfaire nos exigences minimales en matière de fonctionnalités attrayantes, et les galets sont de plus petites histoires d'utilisateurs ou tâches d'ingénierie qui vont au-delà de nos exigences minimales. C'est un excellent moyen d'intégrer quelques aspects du facteur «wow» à une caractéristique ou à un produit qui ne sont pas strictement tenus de fournir de la valeur.
En fin de compte, le cycle consiste essentiellement à équilibrer l'obtention de valeur plus rapidement pour l'utilisateur et à lui fournir le plus de valeur (Parfois, vous avez de la chance et ces choses sont les mêmes!). Cet équilibre informe à la fois sur ce que nous construisons et sur le moment où nous le construisons.
Récapitulons
Portée du produit (le responsable produit est responsable)
- Concevez votre solution au problème à résoudre
- Créez une analyse détaillée des spécifications de la solution.
- Transformez cette spécification en user stories
- Taille réduite: définissez votre version minimale de cette fonctionnalité génératrice de valeur.
Portée technique (le responsable de l'ingénierie est responsable)
- Obtenez un alignement complet de l'équipe sur la spécification et sur l'utilisateur stories
- Découpez les user stories en tâches techniques
- Estimez les tâches techniques
Détermination du cycle (le responsable produit est responsable)
- Sur la base des estimations, sélectionnez les histoires et les tâches à exécuter dans le cycle de développement actuel
- Laissez le reste de côté pour un autre jour
Si vous voulez savoir qui est responsable de quoi dans ce processus de cadrage, voici ce qu'il se passe:
À vous de répondre
Ce processus résulte de nombreuses itérations et continue d'évoluer avec le temps. C’est loin d’être la meilleure approche pour le développement de produits, mais nous l’avons trouvée efficace dans notre cycle de développement de produits spécifique. Cela dit, nous cherchons toujours activement à améliorer notre processus et à le rendre plus confortable et efficace pour l'équipe.
Si cela déclenche des questions ou des réflexions, n'hésitez pas à laisser un commentaire ci-dessous ou tweet à moi . Je serais ravi d’entendre parler de vous!
Source link