Le produit minimum viable (MVP) est l'une des étapes du cycle complet de développement d'un produit. Le MVP (Minimum Viable Product) est une stratégie permettant de valider rapidement votre idée de lean startup en construisant et en diffusant un produit minimalement viable sur votre marché cible. Cela vous permet d'obtenir un retour d'information de la part de clients réels au début du processus, ce qui peut vous aider à prendre des décisions essentielles sur la façon de faire progresser votre entreprise.

Cependant, cet article de blog abordera le fonctionnement du MVP (Minimum Viable Product) et la manière dont vous pouvez l'utiliser pour valider votre idée de lean startup. MVP en agile méthodologie. Nous aborderons également les avantages d'un produit minimum viable (MVP) et la manière dont il peut vous aider à réussir dans votre entreprise.

Qu'est-ce qui n'est pas un MVP ?

Un MVP (Minimum Viable Product) n'est pas un produit avec seulement quelques fonctionnalités manquantes. A produit minimum viable (MVP) n'est pas un moyen de faire des corners pour obtenir une version anticipée de votre produit (bien que cela puisse être le cas) ; c'est simplement un programme à moitié terminé.

Bien que vous puissiez d'abord développer un prototype pour tester votre idée de produit à moindre coût, un produit minimum viable (MVP) n'est pas la même chose qu'un prototype. Les MVP ne sont pas réservés aux startups. Quels que soient les détails du produit ou la maturité de l'organisation qui a l'intention de le produire, ils constituent une étape viable et souvent pratique du développement.

En d'autres termes, un produit minimum viable (MVP) consiste à obtenir le meilleur rapport qualité-prix avec le moins d'argent possible. Plus important encore, un MVP est une étape dans le processus de création d'une entreprise. processus de développement. Un produit complet avec des caractéristiques appropriées pour (et attrayantes pour) les clients cibles.

Développement logiciel agile

Vous pouvez vous rapprocher des MVPs en appliquant les idées agiles à développement de produits numériques. L'utilisation d'un cadre d'approche agile pour le développement de logiciels devient de plus en plus courante, en particulier lorsque l'on travaille dans des situations incertaines ou potentiellement changeantes. Les besoins des clients du produit final et les objectifs commerciaux des propriétaires du produit sont prioritaires dans une approche agile.

Une méthodologie agile s'appuie sur les tests et la recherche pour s'assurer que le bon produit est généré. Le concept initial du produit et les caractéristiques essentielles sont au minimum mis à l'épreuve - souvent avec des personnes réelles - et les résultats sont analysés. Les informations obtenues sont ensuite utilisées pour affiner le processus de développement. Lors des tests, les "produits partiels" comportant peu de fonctionnalités, tels que les prototypes et les MVPs, sont courants.

Une méthodologie agile s'appuie sur les tests et la recherche pour garantir que le bon produit est généré.

Travailler de manière agile

Le travail agile consiste à donner aux personnes et à l'équipe produit la liberté de faire leur meilleur travail, de prendre les meilleurs jugements et d'obtenir les meilleurs résultats possibles. Le développement agile implique de fonctionner avec une capacité d'adaptation, une volonté de changement et une absence de contraintes excessives.

Développement agile consiste à laisser tomber les structures organisationnelles et les tâches strictes (plus de chefs de projet) pour libérer la capacité de créativité et de collaboration de toute l'équipe. Cependant, les approches suivantes sont de bonnes approches de développement logiciel agile :

• Développement itératif - Le produit est considéré comme une collection de composants distincts qui doivent être construits et testés séparément au cours de brefs sprints. Chaque sprint a son propre processus de planification et de révision, ce qui permet à l'équipe de développement logiciel d'évaluer le processus et de pivoter pour se concentrer sur de nouveaux objectifs plus pertinents, si nécessaire.

• Une collaboration étroite - Les itérations du produit sont testées avec les utilisateurs et les clients, et les commentaires des utilisateurs sont recueillis et analysés avant d'être utilisés pour modifier le développement prévu.
• Des équipes auto-organisées - L'équipe produit s'accorde sur sa vision du produit et sa feuille de route de développement avec le représentant du propriétaire du produit du client, sans fonction formelle de chef de projet (initialement, en utilisant un atelier de découverte du produit). L'équipe de développement du logiciel continue à gérer ses progrès, en passant en revue le travail et les objectifs et en fixant les priorités de chaque sprint avec l'aide d'un maître de mêlée.
• Travail d'équipe et communication au quotidien - Une excellente communication entre les membres de l'équipe (et les parties prenantes importantes) est essentielle au succès, comme vous pouvez le penser, étant donné la caractéristique d'auto-organisation.

Le développement d'un (ou plusieurs) produit(s) minimum viable(s) est une méthode de travail intelligente et agile. Créer une version du produit avec seulement une ou deux caractéristiques fonctionnelles, puis les tester pour identifier la prochaine priorité de développement est idéal pour une méthodologie agile.

L'importance de travailler de manière agile

De nombreuses études ont démontré que le fait de donner aux employés la liberté de travailler quand, où et comme ils le souhaitent augmente la productivité. Les employés comme les entreprises bénéficient d'un environnement de travail flexible.

En effet, plutôt que de se concentrer sur le temps et la présence, les employés se concentrent sur les résultats et les performances, ce qui améliore considérablement les biens, les idées et la culture de l'entreprise. Cependant, voici l'importance de travailler selon la méthodologie agile :

Économies de coûts

Le travail agile présente de nombreux avantages commerciaux. La réduction des coûts est l'un des principaux avantages des espaces de travail agiles pour les entreprises. Les employés qui bénéficient d'un espace de travail flexible, comme la possibilité de travailler de chez eux ou de n'importe où, économisent beaucoup d'argent car ils n'ont pas à payer pour un espace de bureau et tous les équipements et autres dépenses qui l'accompagnent.

Ces économies sont répercutées sur vos candidats sous la forme de salaires plus élevés. Avec le travail agile, votre organisation peut embaucher des personnes tout aussi compétentes dans d'autres parties du pays, voire du monde, où elles peuvent payer moins cher tout en obtenant les compétences dont elles ont besoin.

Amélioration de l'équilibre entre vie professionnelle et vie privée

Il est plus crucial que jamais pour les salariés d'aujourd'hui de trouver un équilibre entre leur vie professionnelle et leur vie personnelle. À l'heure actuelle, les employés apprécient tellement de passer la majeure partie de leur temps avec leurs amis, leur famille et leurs proches qu'ils sont prêts à accepter un salaire inférieur en échange de la liberté de choisir comment ils veulent passer leur temps.

Vos employés seront très heureux si vous utilisez des concepts de travail agile dans votre organisation. Proposer le travail agile est aujourd'hui plus facile que jamais, grâce à la technologie qui permet aux employés d'accéder à leur travail n'importe où, ce qui leur permet de travailler en fonction de leur emploi du temps social.

Une plus grande autodétermination

Dans un cadre de travail typique, les cadres et les rôles supérieurs disent aux employés comment, quand et où ils doivent travailler. Cependant, lorsque les employés se voient proposer un travail agile, cette hiérarchie est brisée, ce qui permet un environnement plus respectueux qui reconnaît mieux la voix des individus. Les employés qui ont plus d'autodétermination font un meilleur travail car ils ont plus de contrôle sur leur travail.

Augmentation de la rétention de talents de haute qualité

Avec la demande croissante de travail flexible, il devient de plus en plus important pour les entreprises d'offrir des choix de travail flexible à leurs employés. L'offre de travail agile est très demandée et a augmenté de plus de 40% au cours des dernières années.

Toute entreprise qui ne permet pas le travail agile est susceptible de perdre les meilleurs talents. Tout employé qui prend des congés pour voyager ne doit pas abandonner son travail, de sorte que le travail agile améliore les taux de rétention. Ils peuvent travailler depuis leur domicile, et les activités habituelles se poursuivent.

Avantages du produit minimum viable (MVP)

L'objectif principal du MVP (Minimum Viable Product) est de fournir la fonctionnalité minimale qui répondra aux demandes de base des utilisateurs réels et résoudra un problème. La rentabilité, la réduction des risques, la clarté du produit et d'autres avantages ne sont que quelques-uns des avantages de cette méthode.

Se concentrer sur les fonctionnalités de base

La technique MVP (Minimum Viable Product) permet de clarifier et de se concentrer sur les fonctions essentielles de votre produit. Elle vous permet de tester votre idée commerciale à peu de frais et en peu de temps.

La plupart des propriétaires de produits ont tendance à introduire des fonctionnalités redondantes avant que le produit ne touche le marché. Lorsque vous ajoutez beaucoup de fonctionnalités, il est facile de perdre de vue le problème que vous essayez de résoudre.

Clarté de la vision

Vous devez noter les caractéristiques essentielles de votre logiciel et sa valeur pour le client au début de son développement. Partagez cette liste avec le reste de l'équipe une fois le projet terminé. À long terme, cette vision centrale vous aidera sans aucun doute à rester sur la bonne voie et à faire de meilleurs choix.

Développement de relations précoces avec les clients

Le timing est essentiel dans les affaires. Pendant le les premières phases du développementil aide à recruter de nouveaux utilisateurs et de nouvelles parties prenantes. Les premiers utilisateurs vous aideront à faire connaître votre produit tout en fournissant une précieuse boucle de rétroaction. Quoi de plus crucial que de s'assurer que votre produit est centré sur le client ?

Une meilleure compréhension des besoins du client

On ne saurait trop insister sur l'importance de la collecte de données et de l'examen approfondi de la clientèle cible. Le retour d'information des premiers utilisateurs est bien plus précieux que les analyses des entreprises et les meilleures hypothèses des consultants expérimentés.

Plus tôt les clients ont l'occasion de faire l'expérience des produits, mieux c'est. Vos utilisateurs actifs vous diront quelles sont les fonctionnalités qu'ils préfèrent, celles qu'ils n'aiment pas et celles que vous devriez intégrer dans la prochaine édition.

L'objectif principal du MVP (Minimum Viable Product) est de fournir la fonctionnalité minimale qui répondra aux demandes de base des utilisateurs réels et résoudra un problème.

Interface utilisateur claire

La méthode MVP (Minimal Viable Product) permet d'éviter que votre premier produit ne soit encombré de fonctionnalités inutiles. En conséquence, le produit est simple et facile à mettre en œuvre. C'est également une excellente occasion d'expérimenter d'autres fonctionnalités. Vous n'avez pas besoin de tout suivre, car vous pouvez examiner chaque fonctionnalité séparément.

Libération plus rapide

La décision de créer la fonctionnalité de base a permis de réduire considérablement le temps nécessaire à la publication du produit. Après avoir publié la première version de votre produit, vous pouvez rapidement tester des hypothèses et recevoir les commentaires des clients sur les fonctionnalités essentielles et souhaitées.

Repousser la date de sortie peut entraîner le développement de fonctionnalités inefficaces et la perte de temps pour des corrections de bugs coûteuses. Il y aura toujours quelqu'un qui pourra sortir une meilleure application avant vous. Faites tout votre possible pour que votre première version soit la plus courte possible, suivie de versions progressives. Cela améliorera considérablement votre réactivité sur le marché.

Flexibilité et mises à jour constantes

L'avantage suivant de la création d'un MVP (Minimum Viable Product) est sa capacité à être particulièrement sensible aux besoins du secteur actuel, qui évolue rapidement. Les mises à jour et les nouvelles fonctionnalités demandées par les clients peuvent être prises en compte grâce à la technique du MVP (Minimum Viable Product).

Votre produit peut également profiter de l'arrivée de nouvelles technologies et de nouveaux outils. Cela vous aidera à garder votre produit pertinent sur un marché encombré.

Un développement avec un minimum de risques

Il est important de se rappeler que les applications à grande échelle bien conçues prennent des années à développer et sont coûteuses en argent et en temps. Les applications logicielles les plus utilisées et les plus populaires ont commencé modestement et ont gagné en complexité au fil du temps. Les MVPs comprennent Facebook, Instagram, Snapchat, Spotify, Airbnb, Uber, Zappos, Dropbox et d'autres plateformes de médias sociaux.

Comment créer un MVP en Agile

Les individus consacrent généralement beaucoup d'efforts aux premières phases de sélection et d'approbation des idées lorsqu'ils créent une entreprise ou lancent un nouveau produit. Une fois le concept approuvé, le processus de développement de MVP est le meilleur moyen de le transformer rapidement en un produit fonctionnel qui peut être lancé et évalué.

Étape 1 : Commencez par une étude de marché

Les idées ne répondent pas toujours aux besoins du marché. Avant de lancer le processus de développement du MVP (Minimum Viable Product), une entreprise doit s'assurer que l'idée principale répond aux besoins des utilisateurs réels prévus.

Cela peut se faire par le biais d'enquêtes. Plus une entreprise dispose de données, plus elle a de chances de réussir. Gardez également un œil sur ce que vos concurrents proposent et sur la manière dont vous pouvez faire ressortir votre concept de produit.

Étape 2 : réfléchir à la valeur ajoutée

Quelle est la valeur ajoutée du nouveau produit pour ses utilisateurs ? Quels sont les avantages pour eux ? Pourquoi quelqu'un achèterait-il cet article ? Ces questions peuvent vous aider à déterminer la valeur de votre application. Les estimations importantes pour le produit doivent également être évidentes.

Le produit doit apporter de la valeur aux utilisateurs dans sa forme la plus élémentaire, comme l'indique l'expression "produit minimum viable". Vous pouvez commencer par esquisser les exigences des utilisateurs, puis concevoir le MVP en fonction de celles-ci.

Étape 3 : Définir le flux d'utilisateurs

La phase de conception du MVP est cruciale. Rendez l'application aussi conviviale que possible. Vous devez examiner l'application du point de vue de l'utilisateur, de la première fois qu'il l'utilise jusqu'à ce qu'il effectue une transaction, comme un achat ou une livraison.

En outre, le flux d'utilisateurs est vital car il garantit que rien n'est négligé tout en gardant à l'esprit le futur produit et ses utilisateurs. Les étapes du processus doivent être définies avant de pouvoir créer le flux d'utilisateurs.

À cet égard, il est essentiel de préciser les méthodes requises pour atteindre l'objectif principal. Plutôt que de se concentrer sur les caractéristiques, il convient de privilégier les fonctions essentielles telles que la découverte et l'achat d'un produit ou le traitement et la réception des commandes.

Ce sont les objectifs que les utilisateurs du produit vont poursuivre en l'utilisant. Il est temps de préciser les caractéristiques de chaque étape après que chacune de ces étapes de la procédure ait été correctement exposée.

Étape 4 : Prioriser les fonctionnalités du MVP

Donnez la priorité à toutes les fonctionnalités que le MVP prendra en charge à ce stade. "Que veulent les utilisateurs ?" Vous pourriez vous demander. Pour vous aider à décider des fonctionnalités MVP à prioriser. Est-ce quelque chose qui va les aider ? Etc.

Ensuite, attribuez une priorité à chaque fonctionnalité MVP restante : priorité élevée, priorité moyenne ou priorité faible. Une autre étape essentielle consiste à organiser ces fonctionnalités dans le backlog du produit (par ordre de priorité). Il est maintenant temps de commencer à travailler sur votre MVP. Un prototype MVP peut être construit si une entreprise souhaite voir à quoi ressemblera son futur produit.

Étape 5 : Lancement du MVP

Le MVP peut être développé une fois que l'entreprise s'est mise d'accord sur les caractéristiques principales et a pris connaissance des besoins du marché. N'oubliez pas qu'un MVP n'est pas une version de moindre qualité du produit final ; il doit toujours répondre aux besoins du client. Par conséquent, il doit être simple à utiliser, attrayant et pertinent pour la population cible.

Étape 6 : Exercice "BML" - Construire, mesurer et apprendre

Tout se fait dans un ordre précis : il faut d'abord définir l'étendue du travail, puis transférer le produit à la phase de développement. Le produit doit être testé lorsque la phase de développement est terminée. Ingénieurs en assurance qualité effectuer le premier niveau de test pour améliorer la qualité du produit (même s'il n'est pas encore lancé).

Une fois que vous avez lancé le MVP, revoyez tout une fois de plus. Les clients doivent donner leur avis sur le lancement pour que l'entreprise puisse aller de l'avant. En fonction de leurs précieux commentaires, ils peuvent déterminer l'acceptation et la compétitivité de leurs produits sur le marché.

Erreurs courantes à éviter lors de l'élaboration d'un MVP

L'idée de Darwin de "la survie du plus fort" s'applique bien au secteur hautement compétitif des affaires numériques d'aujourd'hui. Le processus de développement de MVP permet aux chefs d'entreprise de tester la valeur de leur produit sans avoir à dépenser beaucoup de fonds ou de temps.

Cependant, pour créer un excellent MVP, vous devez éviter quelques erreurs de développement qui pourraient conduire à un désastre commercial massif.

Une stratégie produit inadaptée

Considérez votre stratégie produit comme le cœur battant de votre entreprise. C'est le mécanisme destiné à transformer l'argent que vous avez investi en quelque chose que vous pouvez voir. Si votre moteur ne fonctionne pas bien, vous ne pourrez pas aller très loin.

Vous serez en mesure de solliciter de nouveaux investissements si vous pouvez démontrer que votre produit fonctionne, même s'il ne bat pas de records mondiaux. Toutefois, les choses se compliquent lorsque votre stratégie prend du retard. Voici quelques-uns des risques potentiels liés à la poursuite d'une stratégie produit inefficace :

• Garder votre équipe occupée au lieu d'être productive
• Incapacité à maintenir l'engagement des clients et à les fidéliser
• Dépenser trop d'argent en marketing, augmenter les ventes trop rapidement et ne pas obtenir les résultats souhaités.
• Manque de fonds

Surcharge de fonctions

C'est comme escalader une montagne pour atteindre le succès commercial de vos produits. Vous pouvez utiliser de nombreuses technologies et cibler divers publics pour atteindre vos objectifs commerciaux, tout comme plusieurs sentiers mènent au sommet.

Les deux procédures sont toutefois dirigées par le même principe : apporter trop de choses avec soi rendra la progression et l'atteinte du sommet plus difficiles. En ce qui concerne la création d'un MVP, la surcharge de fonctionnalités se traduit directement par :

• Retarder la distribution de la première version de votre produit
• Remaniement des modules de produits qui n'ont pas apporté de valeur ajoutée à vos clients.
• Vous serez à court d'argent plus rapidement et ne pourrez pas atteindre vos objectifs.

Une équipe de développement surdimensionnée

Il est tentant de croire que plus vous avez de développeurs à bord, plus vite votre MVP sera publié. Cela ne pourrait pas être plus éloigné de la vérité.

Si le fait d'avoir plus d'expérience peut être bénéfique à court terme, le fait d'avoir une équipe trop importante trop rapidement peut compromettre le succès à long terme de votre projet. Voici quelques-uns des inconvénients d'une équipe nombreuse :

• Parce qu'il n'y a pas assez de travail pour tout le monde, la vitesse de développement ralentit, les performances diminuent et le moral de l'équipe s'en ressent.
• Utiliser votre argent et occuper vos planificateurs avec des choses qui ne contribuent pas à la génération de revenus.
• Développer une mauvaise stratégie de produit

Confusion entre le feedback qualitatif et quantitatif

Il existe deux méthodes pour recueillir des données auprès des utilisateurs cibles : le retour d'information qualitatif et quantitatif. Cependant, en dépendant de l'un et en ignorant l'autre, il peut être difficile pour l'entreprise d'établir une décision appropriée.

Les deux types de retour d'information ont des objectifs différents. Il est donc essentiel de trouver le bon équilibre entre eux si vous voulez parvenir à une conclusion bien équilibrée qui vous aidera à apporter des améliorations en connaissance de cause.

Les constatations liées à la qualité et à la convivialité des caractéristiques du produit/service constituent le feedback qualitatif. Il évalue directement la convivialité du système en aidant les développeurs à identifier les éléments défectueux de l'interface utilisateur.

Si le fait d'avoir plus d'expérience peut être bénéfique à court terme, le fait d'avoir une équipe trop importante trop rapidement peut compromettre la réussite à long terme de votre projet.

Le retour quantitatif se présente sous la forme de mesures qui indiquent la facilité ou la difficulté des activités à réaliser. Il évalue la facilité d'utilisation de la conception d'une manière détournée. Ce type de retour d'information peut être basé sur les performances de l'utilisateur pour une tâche donnée (taux de réussite, nombre d'erreurs, etc.).

Conclusion : Comment le MVP en Agile peut valider vos idées de startup

En général, le MVP est une idée avec laquelle toutes les startups devraient commencer. Bien sûr, les produits entièrement nouveaux qui viennent de démarrer sur le marché en tireront le plus grand profit. Lors de l'introduction d'un tout nouveau produit, il est préférable d'ajouter des fonctionnalités progressivement plutôt qu'en une seule fois.

C'est ce qui rend le MVP si précieux : la possibilité de surveiller comment votre produit est reçu par les gens et de l'adapter à leurs besoins. Après avoir reçu des commentaires, vous pouvez déterminer si l'API supplémentaire doit être ajoutée et s'il est plus vital d'améliorer l'interface utilisateur ou votre approche des revenus.

Cependant, quelle que soit l'activité ou la taille du produit, il est impossible que le MVP puisse compromettre le lancement. En utilisant le processus de développement MVP, vous travaillez intelligemment et vous lancez rapidement. Vous n'attendez pas que le produit soit parfait avant de le lancer.

Une fois que vous avez identifié un besoin du marché, vous pouvez rapidement créer la forme la plus élémentaire du produit et attirer les utilisateurs avec la solution que vous proposez. Cela vous permet d'établir rapidement votre autorité et votre clientèle. Par conséquent, le MVP vaut bien chaque centime qu'il rapporte.

The post MVP In Agile: How To Build And Validate Your Startup Idea appeared first on Startup Oasis.

La cartographie des histoires d'utilisateurs est une activité visible qui aide les chefs de produit et les équipes de développement à définir les tâches spécifiques qui aboutiront à la meilleure expérience utilisateur possible. Elle aide les équipes à mieux comprendre leurs clients et à hiérarchiser leurs efforts.

Les équipes développent une esquisse dynamique des interactions d'un utilisateur représentatif avec le produit numérique, évaluent les étapes qui offrent le plus d'avantages pour les activités de l'utilisateur, et classent par ordre de priorité ce qui doit être construit ensuite en utilisant l'utilisateur. cartographie narrative.

Les cartes de récits d'utilisateurs offrent aux équipes agiles des alternatives à la création d'une liste plate d'éléments du backlog ou au travail à partir de documents d'exigences volumineux. Le concept d'histoires d'utilisateurs, qui transmet les besoins du point de vue de l'utilisateur, est utilisé dans la cartographie des histoires d'utilisateurs pour valider et construire une compréhension partagée des processus de création d'un produit numérique que les consommateurs aiment.

La cartographie des histoires d'utilisateurs est une activité visible qui aide les gestionnaires de produits et les équipes de développement à définir les tâches spécifiques qui aboutiront à la meilleure expérience utilisateur possible.

Ils sont rédigés de manière à capturer la valeur commerciale et peuvent être achevés en une seule itération de développement par les équipes agiles (généralement appelée un sprint). Cependant, dans ce guide étape par étape, cet article de blog vous apprendra à créer une story map efficace qui vous aidera à planifier et à organiser votre produit numérique.

Anatomie d'une carte d'histoire d'utilisateur

Le backlog de produit d'une équipe agile est guidé par un user story map, une activité collaborative. La story map décrit l'interaction du client avec le produit, y compris les activités et les tâches qu'il accomplit. La création de la story map en groupe garantit que les membres de l'équipe sont sur la même longueur d'onde depuis le début du développement jusqu'à la livraison continue de nouvelles versions.

1. Backbone

Une colonne vertébrale fournit la structure. L'épine dorsale de la carte narrative de l'utilisateur capture les activités de haut niveau qu'un utilisateur réalisera en utilisant le produit. Acheter et regarder un film sur une Apple TV, par exemple, peut impliquer les activités suivantes :

• Sélectionner le film
• Acheter un film
• Regarder le film
• Critique / recommandation d'un film

2. Ordre chronologique

Une fois que vous aurez défini les activités de l'épine dorsale, vous les disposerez dans l'ordre où un utilisateur s'engagera avec le produit. Au fur et à mesure que le débat avance, il est courant de remanier les activités existantes ou d'en ajouter de nouvelles.

Il s'agit là d'un avantage majeur de l'utilisation d'une approche collaborative pour créer le backlog de produit, puisque vous pouvez vous appuyer sur l'expertise de toute l'équipe.

3. Histoires

Vous construisez des user stories sous chaque activité de l'épine dorsale pour étoffer l'expérience du client. Par exemple, sous l'action "sélectionner un film", vous pouvez trouver du contenu pour.. :

• recherche en texte libre
• parcourir par genre
• parcourir par un ajout récent
• parcourir par les plus populaires
• parcourir par genre le plus populaire
• parcourir par ajout récent par genre

La valeur perçue par l'utilisateur classe ces histoires. Les conversations avec les utilisateurs, les analyses des tendances d'utilisation ou tout autre type d'information adaptée à votre produit peuvent être utilisés pour déterminer la valeur.

4. Séquence

Il est temps de séquencer le travail une fois que l'équipe dispose de l'ossature et des histoires. Quels sont vos objectifs à long terme pour le MVP, 1.0, 2.0, et ainsi de suite ? Le chef de produit commence souvent un planification du sprint La réunion se termine par un examen de la carte descriptif pour s'assurer que tous les membres de l'équipe sont sur la même longueur d'onde.

Quand utiliser le Story Mapping

L'avantage du story mapping est qu'il peut être utilisé à n'importe quel stade du cycle de vie du produit.

• Vous travaillez sur un produit viable minimum (MVP) ? Un story map est un excellent moyen de déterminer les capacités minimales absolues pour tester votre concept. La cartographie des histoires d'utilisateurs vous évitera d'"oublier" des éléments essentiels de l'expérience utilisateur que vous auriez pu négliger autrement.
• Vous essayez de réfléchir aux moyens d'améliorer la version 1.0 ? En illustrant clairement les nombreuses mises à niveau que vous pourriez appliquer, une story map peut aider votre équipe à avoir des discussions fantastiques sur ce qui aura le plus d'impact sur vos utilisateurs.

• Est-il de plus en plus difficile de suivre votre backlog ? La cartographie des histoires peut vous aider à gérer le carnet de commandes en fournissant un contexte pour chaque élément, en déterminant les priorités et en regroupant les éléments dans une vue d'ensemble. La cartographie des récits d'utilisateurs peut également révéler des lacunes que vous n'auriez pas remarquées autrement.
• Vous élargissez votre gamme de produits avec une nouvelle extension de produit ? Un story map vous montrera ce que vous avez déjà et ce dont vous aurez besoin pour finaliser les nouvelles fonctionnalités avec le même niveau de qualité que le reste de votre produit.

Le story mapping commence par les personas, que votre produit soit encore en développement ou qu'il s'agisse d'un produit existant. Vous devez savoir qui utilisera votre produit et ce qu'il espère réaliser. Cela a un impact sur l'avenir puisque vous imaginez comment ils utiliseront le produit fini avant de le construire.

Au fur et à mesure de l'avancement de votre réflexion, vous découvrirez que vous devrez appliquer différents personas à la même story map, puisque différents types d'utilisateurs tentent d'atteindre différents objectifs avec votre produit. Cette stratégie fera immédiatement apparaître les faiblesses de votre offre dans ces nouveaux scénarios si votre parcours ne peut pas les prendre tous en charge.

Qui devrait participer au User Story Mapping

La cartographie des histoires d'utilisateurs est une approche conjointe qui rassemble des équipes interfonctionnelles pour créer un produit qui sera meilleur demain qu'il ne l'est aujourd'hui. Par conséquent, toute équipe dont les activités contribueront à créer efficacement de la valeur pour le client devrait être représentée.

Parce qu'une carte narrative de l'utilisateur donne une perspective holistique du produit, les membres de toute équipe responsable de l'architecture de l'ensemble de l'expérience du produit devraient être inclus. Dans un exercice de cartographie des récits d'utilisateurs, ces groupes sont souvent représentés :

• Ingénierie
• UX / design
• Gestion des produits
• Ventes
• Marketing
• Support client
• Ops / IT
• Finances
• Juridique

Cartographie des histoires d'utilisateurs et cartographie du parcours du client

Bien qu'une feuille de route et une carte narrative de l'utilisateur contiennent certains des mêmes éléments, elles sont utilisées à des étapes différentes du projet. Une story map est utilisée pour la planification et la mise en œuvre, mais une journey map est utilisée pour évaluer les fonctionnalités du point de vue de l'utilisateur, ainsi que pour découvrir et comprendre les besoins de l'utilisateur.

La cartographie des histoires d'utilisateurs et la cartographie des parcours sont d'excellents partenaires. L'approche de la cartographie des parcours vous pousse à considérer les comportements globaux de vos utilisateurs. Il est simple de développer une compréhension partagée de leurs personas et de leurs besoins.

Le story mapping vous aidera à mettre en œuvre des parcours d'utilisateurs dans votre programme et à hiérarchiser les fonctionnalités à privilégier en donnant aux développeurs et aux chefs de projet une meilleure image des choses exploitables.

Qu'est-ce qu'une épopée ou une histoire ?

Les grandes histoires d'utilisateur sont appelées des épopées. Cela indique que la création d'une épopée est plus coûteuse que la création d'une cartographie des user stories. Les équipes passent souvent par un processus plus approfondi de définition, de validation et de déploiement que pour les user stories individuelles, car l'investissement est plus important.

Alors que les user stories sont normalement ajoutées directement au backlog de produit, les epics sont généralement ajoutés au backlog après être passés par une feuille de route de produit ou un discovery board. L'équipe s'efforce de décomposer l'épopée en petits morceaux, tels que les user stories, pendant qu'ils s'y trouvent (et les tâches et sous-tâches).

Parce que les épopées sont si vastes et complexes, elles prennent souvent la forme d'un petit projet.

Par conséquent, la plupart des épopées nécessitent davantage de planification et de préparation ; des réunions doivent être organisées, les tâches doivent être réparties et les résultats doivent être évalués pour déterminer ce qui a fonctionné et ce qui n'a pas fonctionné.

Les différences entre les épopées et les User Stories

Vous travaillez pour une startup fintech en tant que chef de produit ou propriétaire de projet (idéalement, le PM et le PO sont les mêmes personnes). Vous êtes en permanence en conversation avec les consommateurs pour découvrir de nouvelles opportunités et découvrir constamment de nouvelles opportunités.

Au cours de votre découverte d'opportunités, vous remarquez un problème intriguant auquel de nombreux acheteurs de biens immobiliers sont confrontés : les personnes pensent qu'il est difficile et stressant d'obtenir un aperçu des fournisseurs de prêts hypothécaires et de leurs services.

Déterminer quelle banque offre les meilleurs taux et conditions hypothécaires est une tâche longue et difficile pour ceux qui achètent une maison. De nombreuses personnes trouvent cela stressant, ne sachant pas si elles ont fait le bon choix après avoir choisi une banque.

Exemple : En tant qu'acheteur d'un logement, vous souhaitez acquérir une bonne vue d'ensemble de tous les taux et conditions des prêts hypothécaires afin de pouvoir décider en toute connaissance de cause de la banque à laquelle emprunter en moins de temps et avec moins de doutes.

Tout d'abord, faisons une pause pour apprécier cette fantastique cartographie des histoires d'utilisateurs.

• Elle est établie sur la base de ce que les utilisateurs réels vous ont dit (c'est-à-dire qu'il s'agit véritablement d'une histoire d'utilisateur), et
• Il précise le type de personne dont nous avons entendu l'histoire, son objectif et pourquoi cela lui serait bénéfique.

S'agit-il néanmoins d'un user story mapping ? Est-il possible de l'inclure dans le prochain sprint et de prévoir de le terminer ? Presque certainement pas.

Bien qu'avec un objectif plus restreint, pour mieux comprendre l'espace du problème, générer des idées de solutions potentielles, créer des maquettes et des structures filaires, solliciter les réactions des utilisateurs finaux, décomposer le problème en petits morceaux et aller de l'avant une fois que vous êtes sûr de résoudre un vrai problème avec une solution valable.

Bien sûr, ces éléments peuvent s'appliquer à la cartographie d'une histoire d'utilisateur. D'un autre côté, la plupart des équipes passent beaucoup moins de temps à valider et à tester les histoires individuelles que les épopées. La solution technologique qui répond à une histoire d'utilisateur est, dans la plupart des situations, beaucoup plus facile à étoffer que celle d'une épopée.

Vous avez votre histoire d'utilisateur de haut niveau, que vous avez décidé de classer comme une épopée parce que vous vous attendez à ce qu'elle soit énorme. Il est maintenant temps de la définir, de l'améliorer et éventuellement de la développer. C'est là que l'utilisation d'un modèle épique et l'élaboration d'un PRD s'avèrent utiles. Un bon modèle épique vous guidera à travers ces étapes et enregistrera vos dialogues.

Il vous aidera à gérer le projet (coordination avec les parties prenantes, les concepteurs et les développeurs) et vous orientera vers la solution la plus axée sur les résultats. L'une des compétences cruciales en matière de gestion de produit est d'y parvenir.

Le Backlog plat et le User Story Mapping

Le backlog de produit plat est l'une des approches les plus fréquentes du développement logiciel agile. Vous en avez tous vu, vous y avez tous participé et vous avez tous fini par vous y noyer.

Dans sa forme la plus élémentaire, un backlog de produit plat est une liste de "choses à faire" qui finiront par apporter de la valeur au client. Ces tâches réalisables sont classées par ordre de priorité (de haut en bas) pour apporter de la valeur. Si une équipe utilise Scrum, le backlog est divisé en sprints futurs pour estimer ce qui sera livré et quand.

La liste des choses à faire pourrait être de 10, 100 ou 1 000 éléments exploitables, selon la taille et les besoins de l'entreprise. Il est facile de comprendre comment la mise à jour, l'affectation, le toilettage et la programmation de ces éléments seraient difficiles à gérer.

La chose à faire est toujours affichée sur la carte du récit ; la différence réside dans la manière dont cette information est représentée. Comme vous pouvez le voir, plutôt que de lister ces objets séparément, chacun est placé dans le contexte d'un travail plus vaste. La principale différence entre un backlog de produit plat et une carte d'histoire d'utilisateur, outre la façon dont les informations sont visualisées, est l'accent mis sur le parcours du client.

Ce qu'une carte d'histoire d'utilisateur accomplit qu'un backlog de produit plat ne peut pas faire

Concentrez-vous sur les résultats souhaités par les clients : En visualisant le parcours de l'utilisateur, les équipes peuvent découvrir et mettre en œuvre différentes fonctionnalités en fonction des commentaires des utilisateurs et suivre d'un coup d'œil la progression par rapport à une story map.

• Activez le parcours du client : Les équipes ont désormais une meilleure idée du parcours des utilisateurs et de ce que leurs clients veulent et apprécient, grâce à la transformation du backlog de produit plat en une story map centrée sur le client.
• Prioriser les actions en fonction de la valeur du client : Le parcours du client peut être visualisé pour aider les équipes à hiérarchiser le travail en fonction de la "valeur pour le client", ce qui se traduit par de meilleurs résultats et moins de gaspillage.

Le problème d'un carnet de commandes plat

Quiconque a travaillé avec des logiciels comprend à quel point ces systèmes vitaux peuvent devenir compliqués. Même avec une application simple, il est difficile de suivre toutes les modifications et de s'assurer que les interdépendances restent intactes après une mise à jour.

Dans ce que l'on appelle une "user story", vous présentez le travail à effectuer. Ce format facilite la réalisation d'une tâche et clarifie le contexte de l'activité. Commencer par les premières histoires d'utilisateur est généralement simple, et toute l'équipe connaît les fonctionnalités prévues du système.

Cela devient de plus en plus difficile à mesure que le nombre d'histoires d'utilisateurs augmente, et tous les participants perdent progressivement de vue l'ensemble du système. C'est ce qu'on appelle le problème du backlog "plat". Il est difficile de décrire où tout va dans le système, même si le propriétaire du produit a toujours cette vision du résultat final.

Comment construire un story map en 6 étapes

1. Commencez par les gros rochers

Déterminez les principales intrigues ou les actions générales des utilisateurs que votre logiciel doit prendre en charge. Ce sont de grandes histoires avec beaucoup d'étapes. Il n'est pas nécessaire que ces procédures soient dans un ordre ou un flux de travail particulier. De nombreuses actions utilisateur comportent des étapes qu'un utilisateur effectuera à différents moments et à différents horaires.

Créez une carte pour chaque activité. Organisez-les de manière à ce que l'utilisateur puisse les comprendre. Si quelqu'un dit qu'il va faire une chose, puis une autre, mettez-les dans cet ordre. Si les actions ne sont pas effectuées dans un ordre séquentiel, utilisez l'ordre dans lequel l'utilisateur les décrit. Cela facilitera la transmission de l'histoire de l'application aux autres.

2. Ouvrez vos blocs rocheux

Décomposez l'histoire de chaque activité utilisateur en de plus petits récits de tâches utilisateur. Placez les tâches de l'utilisateur sous l'activité à laquelle elles se rapportent et disposez-les dans le même ordre que les activités, de manière à ce que l'utilisateur y trouve son compte.

3. Trouvez les cailloux qui se sont échappés

Avec une autre personne à vos côtés, parcourez la carte du début à la fin. Il peut s'agir d'un utilisateur, d'un développeur, d'un testeur ou de toute autre personne intéressée par l'application. Parlez des différents types d'utilisateurs qui utilisent votre application et de la façon dont ils l'utilisent.

C'est comme utiliser un canard en caoutchouc pour déboguer votre histoire. Et ça va sans aucun doute mettre en lumière des choses que vous avez négligées. Soit parce que vous trouvez des choses vous-même, soit parce que votre ami le fait. Profitez de l'occasion pour annoter la carte de l'histoire avec des informations supplémentaires que vous apprenez en la parcourant avec quelqu'un.

Opportunités qu'un utilisateur attend et zones de douleur dans le système actuel. Il vous sera utile d'envisager tous les scénarios et toutes les limites possibles. Inscrivez-les sur une note autocollante et collez-les sur la carte appropriée.

4. Mettez vos cailloux en ligne

Hiérarchiser les activités de l'utilisateur n'a aucun sens. En dehors des activités qui ne seront pas employées régulièrement, il est fort probable qu'un aspect de chaque activité soit nécessaire pour former un ensemble fonctionnel. Ainsi, au sein de chaque activité, hiérarchisez les tâches et sous-tâches de l'utilisateur. De plus, vous n'aurez peut-être pas à tenir compte de la priorité relative des tâches associées à des passe-temps distincts.

5. Sculptez un premier bloc de valeur à partir de vos tas de cailloux.

Choisissez les tâches les plus importantes de chaque activité pour produire une première version qui fonctionne du début à la fin, même si c'est sous une forme très rudimentaire. C'est ce que sera votre MVP (Minimum Viable Product).

6. Continuer à sculpter

Classez les activités restantes par ordre de priorité pour planifier vos prochaines versions. C'est à vous de décider comment vous voulez procéder. Vous pouvez choisir de mettre en évidence les enseignements les plus précieux des différents comportements des utilisateurs, voire de tous.

Vous pouvez également vous concentrer sur une activité spécifique et classer toutes les histoires, sauf celles qui ont le moins de valeur. Et les dirigeants de votre entreprise peuvent souhaiter évaluer d'autres facteurs. Ils sont les mieux placés pour dire quelles caractéristiques et quelles histoires créent un bon film.

Vous pouvez modifier la carte pour afficher les versions sous forme d'étendues horizontales d'histoires au lieu de placer des lignes entre elles pour indiquer celles qui passent dans les versions suivantes.

Les 3 C dans les User Stories

Bien que les user stories et les cas d'utilisation puissent sembler identiques, il existe des différences importantes entre les deux. Une cartographie de l'histoire de l'utilisateur porte davantage sur le besoin ou la demande de l'utilisateur, alors qu'un cas d'utilisation décrit la fonctionnalité construite pour répondre aux besoins du client.

Elles sont un peu plus techniques et décrivent comment la fonctionnalité construite interagit avec le reste du système, du logiciel ou du processus. D'autre part, les user stories sont plus simples à lire et à comprendre.

Ron Jeffris a présenté le Carte, Conversation, Paradigme de confirmation pour les histoires d'utilisateurs en 2001 pour la programmation extrême, affirmant que les histoires d'utilisateurs sont des aspects clés de la XP "Le cercle de la vie." Voici les trois différents types de récits d'utilisateurs.

1. Carte

Quel est le meilleur endroit pour écrire des user stories ? Sur des fiches, bien sûr. Elles sont écrites à la main sur des fiches, et cette pratique contribue à la concision des user stories. La carte ne contiendra pas toutes les informations relatives à l'exigence, ni une quantité excessive d'informations.

Au lieu de cela, la carte contiendra suffisamment d'informations pour identifier l'exigence et aider tout le monde à comprendre l'histoire. La carte est un rappel de l'exigence et un excellent outil de planification.

Elle peut également être utilisée pour noter des informations supplémentaires, telles que la priorité de l'histoire ou les coûts associés. Le propriétaire du produit remettra la carte des user stories aux développeurs après avoir finalisé la cartographie des user stories à choisir pour le sprint.

Voici le format habituel pour écrire l'histoire de l'utilisateur sur la carte :

En tant que [type d'utilisateur], je désire / exige [objectif] pour atteindre [justification/valeur commerciale].

2. Conversation

La carte est la première étape de la création de l'histoire utilisateur, mais la demande doit être traitée, affinée et présentée aux développeurs. La conversation est utilisée à cette fin. La conversation entre les développeurs, les propriétaires de produit, les maîtres de mêlée et les parties prenantes facilite la collaboration entre toutes les parties, ce qui aboutit à une connaissance partagée du besoin et du développement du produit.

Cet échange conversationnel d'idées et d'opinions se fait par étapes, en commençant par l'estimation de l'histoire pendant la planification de la version et en poursuivant par la réunion de planification du sprint lorsque l'histoire est sélectionnée pour être mise en œuvre. Bien que la plupart des discussions soient verbales, la documentation peut être utilisée comme support.

3. Confirmation

Même après la discussion la plus approfondie, il y a toujours un certain scepticisme quant à la demande qui doit être développée. Comment faire avancer la user story et s'assurer qu'elle correspond à la demande ?

Ceci est accompli par le troisième C de l'histoire d'utilisateur, "confirmation". Les tests d'acceptation sont utilisés pour confirmer les résultats. La confirmation est un critère d'acceptation qui capture les besoins les plus importants et nous permet d'évaluer le produit fini pour s'assurer qu'il correspond aux exigences.

Le propriétaire du produit crée généralement des critères d'acceptation, modifiés et étendus tout au long de l'affinement du backlog. Le site développeurs mettre en œuvre les critères d'acceptation ou les tests d'acceptation. L'incrément basé sur l'histoire de l'utilisateur doit passer les tests d'acceptation, indiquant que la fonctionnalité a été construite de manière appropriée.

Après l'itération, les développeurs démontrent l'achèvement de l'histoire en passant les critères d'acceptation. C'est la confirmation finale. La fonctionnalité construite est complète et peut être publiée si les trois C des histoires d'utilisateurs sont complétés et remplis.

Les avantages du User Story Mapping

Si vous cherchez le terme "user story mapping", vous pourriez penser qu'il s'agit d'une théorie et d'une technique que seule votre équipe de développement utilise. Pourtant, elle peut profiter à tous les aspects de votre entreprise.

Des unités commerciales allant des ventes et du marketing au support client peuvent bénéficier d'une réflexion stratégique sur le story mapping. Vous constaterez des avantages dans toute votre organisation si votre équipe prend le temps d'apprendre le processus et de créer une feuille de route.

Voici cinq avantages de la cartographie des histoires d'utilisateurs :

Organisation

Il y a beaucoup d'éléments mobiles à gérer à tous les niveaux d'une organisation pour diriger une société prospère. Les cartes de récits d'utilisateurs vous permettent de garder la trace de toutes vos idées en un seul endroit.

En procédant ainsi, vous pouvez éviter les situations où vous oubliez ce qui doit être fait. Chaque pensée est enregistrée et considérée comme correcte sur une carte d'histoire d'utilisateur. Vous pouvez rectifier le tir si vous vous rendez compte par la suite que vous vous êtes trompé. Cela garantit qu'aucune idée n'est perdue et que chaque voix est entendue.

Établissement des priorités

Le fait d'établir des priorités est un effet direct de l'organisation. Vous devez vous concentrer sur les choses qui semblent difficiles et les décomposer. En utilisant des cartes de récits d'utilisateurs, vous pouvez concentrer vos efforts et votre énergie sur des domaines spécifiques à différentes périodes.

Plusieurs tâches peuvent prendre plus de temps que d'autres, ou vous pouvez avoir besoin d'en terminer certaines avant de passer à autre chose. Lorsque vous créez une carte des histoires d'utilisateurs, vous pouvez discuter des composants les plus importants et restructurer votre carte en conséquence.

Notez quelles activités doivent être réalisées en premier, quelles nouvelles fonctionnalités doivent être incluses dans la première version du produit, quelles fonctionnalités doivent être reportées au prochain projet et quelles fonctionnalités peuvent être éliminées.

Vous pouvez décomposer les tâches les plus importantes en morceaux gérables en fixant des dates de diffusion et en assignant des tâches aux membres de l'équipe.

Responsabilité

Gérer une entreprise, c'est gérer des personnes autant que des projets. Les deux aspects de la gestion bénéficient des user story maps. Vous pouvez déléguer certains éléments du projet à des équipes ou des personnes spécifiques, tout comme vous le faites pour les priorités.

Cela ajoute un autre niveau de responsabilité. Le membre de l'équipe comprend ce qui doit être fait et peut s'y consacrer tout en fournissant des mises à jour tout au long du projet. Une culture de travail forte nécessite un haut niveau de responsabilité. La cartographie des histoires d'utilisateurs renforce votre équipe et favorise un sentiment de partage des connaissances et de confiance.

Visualisation

Si vous ne voyez pas l'objectif final, il est difficile de l'atteindre ou de passer à autre chose. C'est pourquoi la visualisation est si importante. Une carte de l'histoire de l'utilisateur décrit vos objectifs du début à la fin. Une perspective globale clarifie et rend l'objectif final plus accessible. Elle fournit un guide pour accomplir la tâche à accomplir.

Considérez votre projet comme une montagne. Vous êtes au pied de la montagne et vous contemplez l'ensemble de la montagne avant de vous lancer dans l'ascension.

Puis vous élaborez une stratégie pour atteindre le sommet, un pas après l'autre. Bien sûr, des difficultés surgiront et perdureront pendant l'ascension. Cependant, vous pouvez vous préparer à affronter ces obstacles si vous planifiez.

La cartographie de l'histoire de l'utilisateur vous permet de développer votre vision d'un concept à un produit fini à partir de la base.

Focus

L'avantage le plus important de tous est la possibilité de se concentrer. La cartographie des histoires d'utilisateurs vous permet de vous concentrer sur les aspects les plus importants de votre projet. L'objectif final de votre client est ce qui importe lors de la création d'un produit.

Vous pouvez savoir comment votre consommateur atteint son objectif final en créant une carte de l'histoire de l'utilisateur. Cela vous permet d'établir vos objectifs et de savoir sur quoi vous concentrer. Avant de perdre du temps sur autre chose, concentrez-vous sur les caractéristiques essentielles.

La cartographie des histoires d'utilisateurs peut vous aider, quelle que soit la fonction que vous occupez dans votre entreprise. Pensez à explorer cette nouvelle technique avant de construire votre prochain produit ou de lancer votre prochain projet.

La cartographie des histoires d'utilisateurs vous permet de vous concentrer sur les aspects les plus importants de votre projet.

Alors que de plus en plus d'entreprises travaillent à distance, il est de plus en plus important de trouver un moyen de se connecter électroniquement. Trouvez des stratégies pour rallier l'ensemble de votre équipe à l'idée du lieu et du but de votre projet. C'est un bon concept que de commencer par une carte de l'histoire de l'utilisateur.

Conclusion : Comment le Story Mapping améliore vos idées de startup

La cartographie des histoires d'utilisateurs est un concept simple. Il s'agit de construire un modèle simple qui décrit l'histoire de votre utilisateur au fur et à mesure que vous parcourez votre produit pour discuter de son expérience. Il s'avère que ce concept simple simplifie le travail avec les user stories en développement agile.

Elle placera vos utilisateurs et ce qu'ils font avec votre produit au premier plan de votre conception. C'est préférable que de s'enliser dans des débats sur les fonctionnalités, comme c'est souvent le cas dans le développement de logiciels.

The post Story Mapping For Beginners: A Step-By-Step Guide appeared first on Startup Oasis.

Le gestionnaire de produit et l'équipe de développement sont généralement les publics cibles de l'initiative histoire d'utilisateur cartes. L'objectif est de créer et d'organiser les histoires d'utilisateurs dans un flux qui a du sens à la fois pour l'utilisateur et pour les objectifs commerciaux du produit, ce qui est utile pour les clients et les autres parties prenantes.

Les équipes développent une esquisse dynamique des interactions d'un utilisateur représentatif avec le produit, évaluent les étapes qui offrent le plus d'avantages pour l'utilisateur et classent par ordre de priorité ce qui doit être construit ensuite en utilisant la cartographie des histoires d'utilisateurs. La cartographie des histoires d'utilisateurs offre une alternative à la création d'une liste plate d'éléments du backlog ou au travail à partir de documents d'exigences volumineux pour les organisations agiles.

Le concept des histoires d'utilisateurs, qui transmet les besoins du point de vue de la valeur pour l'utilisateur, est utilisé dans la cartographie des histoires d'utilisateurs pour valider et construire une compréhension partagée des processus de création d'un produit numérique que les consommateurs aiment. Les user stories sont rédigées de manière à capturer la valeur pour l'entreprise et peuvent être réalisées en une seule itération de développement par les équipes (généralement appelée sprint).

La structure des récits d'utilisateurs - en tant que (type d'utilisateur), je veux (activité) pour (bénéfice) - peut être utile lorsque l'on considère les interactions du produit du point de vue de l'utilisateur.

Cartographie des histoires d'utilisateurs et cartographie du parcours du client

A carte de voyage est une description visuelle d'une histoire d'utilisateur du point de vue du client. Une carte du parcours client est un ensemble d'actions ou de processus par lesquels un client passe pour améliorer son expérience globale. Généralement, une carte de parcours décrit de nombreuses histoires d'utilisateur.

Dans une carte de voyage, l'état mental et les émotions sont alignés avec le processus, mais ils ne sont généralement pas inclus dans les histoires d'utilisateur individuelles. La carte de parcours décrit le processus et identifie les étapes qui ne fonctionnent pas. Elle est utilisée pour améliorer la satisfaction des clients et rationaliser les processus.

Les récits d'utilisateurs sont rédigés de manière à saisir la valeur commerciale et peuvent être achevés en une seule itération de développement par les équipes (généralement appelée sprint).

Le besoin d'une partie prenante est une histoire d'utilisateur. Il comprend des informations sur le rôle, les objectifs et le motif d'un produit ou d'un service. Exemple : En tant que, j'ai besoin de, pour que. Les composants du parcours complet du client sont examinés dans les user stories.

Story Mapping physique ou numérique

Plan du récit physique

Les story maps physiques permettent de visualiser les histoires des utilisateurs afin d'avoir une vue claire et complète de l'expérience utilisateur.

Avantages

• C'est simple à mettre en place : tout ce dont vous avez besoin, c'est de quelques notes autocollantes de différentes couleurs.
• Tout le monde est invité à contribuer - il n'y a aucune restriction sur les licences ou les privilèges d'édition.
• Simple à mettre à jour - S'adapter rapidement à mesure que de nouvelles idées émergent. Pour indiquer un changement de priorité, retirez une carte, ajoutez-en une ou déplacez-la vers le haut ou vers le bas de la liste.
• Excellente visualisation - Vous pouvez voir l'intégralité de la carte de l'histoire en une seule fois, sans avoir à la faire défiler.
• Le radiateur d'informations - Si vous la laissez en place, la carte servira de point de référence à l'équipe lorsqu'elle commencera le développement et à toute personne de l'entreprise qui souhaite voir le parcours client et le produit minimum viable (MVP).

Inconvénients

• Elle nécessite beaucoup d'espace mural, ce qui est difficile à trouver dans de nombreux bureaux.
• Pas bien adapté à la participation à distance - il est difficile de suivre et de contribuer si tous les membres de l'équipe ne sont pas dans la même pièce.
• Pour une utilisation plus simple pendant les sprints, la plupart des équipes placent les informations recueillies sur la carte narrative dans une plateforme de gestion du backlog, telle que JIRA.

Cartes d'histoires numériques

Les cartes d'histoires numériques combinent une technologie cartographique de pointe avec du texte, des photographies et du contenu multimédia pour générer des histoires captivantes basées sur l'emplacement, accessibles depuis n'importe quel appareil connecté à Internet et doté d'un navigateur Web, y compris les tablettes et les smartphones.

Avantages

• Permet la participation à distance - C'est une option fantastique pour les équipes dispersées. Elle permet aux participants à distance de participer et de suivre le processus.
• Un espace physique n'est pas nécessaire - Sans une zone d'équipe désignée, vous pouvez vous lancer.
• Il faut capturer d'autres objets de l'histoire - Attachez des artefacts supplémentaires aux cartes individuelles de la carte de l'histoire, comme des liens, des documents et des images.
• Intégration avec des outils de gestion de projet et Agile - La plupart des comptes payants incluent des intégrations qui vous permettent de transférer plus rapidement les épopées, les histoires et les estimations de votre story map dans votre backlog.
• Il y a plusieurs options parmi lesquelles choisir, et elles sont toutes gratuites à essayer. De nombreuses technologies sont disponibles pour des essais gratuits (StoriesOnBoard, Cardboard, Agile User Story Map JIRA plugin, Feature Map, Realtime Board).

Inconvénients

• Frais de licence mensuels - Pour accéder aux fonctionnalités les plus avantageuses, vous devrez très probablement acquérir une licence mensuelle pour un ou plusieurs membres de votre équipe.
• Il est recommandé d'avoir un seul éditeur à la fois - il peut être difficile d'avoir plusieurs personnes qui modifient une carte simultanément.
• Les entreprises dont les exigences en matière de sécurité sont strictes risquent de ne pas pouvoir utiliser la technologie souhaitée, car les données sont stockées à l'extérieur.
• Il sera plus difficile de rester concentré si vous vous joignez à l'ordinateur, car il y aura plus de distractions. De plus, comme la cartographie narrative peut prendre de quelques heures à plusieurs jours, il n'est pas facile de suivre à distance pendant tout ce temps.

Quand la cartographie des histoires d'utilisateurs est-elle faite ?

Le story mapping présente l'avantage de pouvoir être utilisé à n'importe quel stade du cycle de vie du produit.

• Vous travaillez sur un MVP? Une story map est un excellent outil pour déterminer les capacités minimales requises pour tester votre concept. Elle vous évitera d'"oublier" des aspects importants de l'expérience utilisateur que vous auriez pu ignorer par ailleurs.
• Vous cherchez des moyens d'améliorer la version 1.0 ? Une story map peut aider votre équipe à avoir d'excellentes discussions sur ce qui aura le plus grand impact sur vos utilisateurs en affichant clairement toutes les différentes améliorations que vous pourriez mettre en œuvre.
• Est-il de plus en plus difficile de gérer votre backlog ? En fournissant à chaque élément un certain contexte et en permettant de hiérarchiser et de regrouper les éléments à l'aide d'une vue d'ensemble, la cartographie des histoires d'utilisateurs peut vous aider à contrôler le carnet de commandes ; en outre, elle peut identifier des lacunes que vous n'auriez pas repérées autrement.
• Vous ajoutez une nouvelle extension de produit à votre portefeuille ? Une carte de l'histoire de l'utilisateur vous montrera ce que vous avez déjà et ce dont vous aurez besoin pour compléter la fonctionnalité supplémentaire au même niveau que votre offre actuelle.

La cartographie des histoires d'utilisateurs commence par des personas, que votre produit soit encore en développement ou qu'il soit utilisé depuis des décennies. Vous devez savoir qui utilisera votre produit et ce qu'il tente d'accomplir. Cela influence tout à l'avenir puisque vous imaginez comment ils utiliseront le produit final avant que vous ne l'ayez construit.

Au fur et à mesure de l'avancement de votre réflexion, vous constaterez que vous devrez appliquer plusieurs personas à la même carte de l'histoire de l'utilisateur, car différents types d'utilisateurs tentent d'atteindre différents objectifs avec votre produit. Si votre parcours ne peut pas tous les accueillir, cette approche révélera immédiatement les failles de votre offre dans ces nouveaux scénarios.

Qui devrait participer

La cartographie des histoires d'utilisateurs est une approche combinée qui rassemble des équipes interfonctionnelles dans le but de créer un produit qui sera meilleur demain qu'il ne l'est aujourd'hui. Par conséquent, toute équipe dont les activités contribueront à la création effective de la valeur client devrait être représentée.

Parce qu'une cartographie de l'histoire de l'utilisateur donne une perspective holistique du produit, les membres de toute équipe responsable de l'architecture de l'ensemble de l'expérience du produit devraient être inclus. Dans un exercice de cartographie des histoires d'utilisateurs, ces groupes sont souvent représentés :

• Ingénierie
• UX / design
• Gestion des produits
• Ventes
• Marketing
• Support client
• Ops / IT
• Finances
• Juridique

Comment créer une carte des histoires d'utilisateurs

Le choix du support à utiliser pour créer la story map est la première étape du story mapping utilisateur. Elle peut être réalisée avec des ressources physiques simples comme un mur ou un tableau blanc et des notes autocollantes, ou elle peut être réalisée avec plusieurs outils logiciels pour construire une carte virtuelle. Pour les équipes distribuées, la planification virtuelle peut être bénéfique. Les équipes doivent suivre les instructions ci-dessous, quel que soit le support utilisé :

1er : Définir le problème

Quels problèmes votre produit résout-il pour les utilisateurs, ou quelle tâche les aide-t-il à accomplir ? Dans la cartographie de l'histoire de l'utilisateur et le travail qui suit, il est crucial d'adopter une approche axée sur l'objectif, et les équipes doivent s'assurer qu'elles cartographient l'objectif du client.

C'est vrai même si les équipes travaillent à l'amélioration d'un produit existant. Le format de l'histoire de l'utilisateur (En tant que [type d'utilisateur], je veux [activité] pour que [bénéfice]) peut être utile pour envisager les interactions du produit du point de vue de l'utilisateur.

2 : Comprendre les utilisateurs du produit

Quel est le public visé par votre produit ? Il y a de fortes chances qu'il y en ait plus d'un. Des publics différents auront des objectifs différents et interagiront différemment avec votre produit.

Commencer par un ensemble de personas d'utilisateurs garantit que tous les membres de l'équipe ont une connaissance commune du public cible et peuvent construire des histoires à partir de cette perspective. Cela permet également de réduire le temps consacré aux cas limites qui ne sont pas pertinents pour le public visé.

3ème : Activités des utilisateurs de cartes

Chaque utilisateur qui interagit avec un produit effectuera très probablement des actions typiques. L'épine dorsale de la cartographie de l'histoire de l'utilisateur comprend ces activités, également appelées thèmes ou fonctions. Les utilisateurs d'un produit de commerce électronique, par exemple, peuvent vouloir rechercher des articles à vendre, parcourir des articles par catégorie, ajouter des articles à un panier et terminer une transaction.

Les contes en haut de la carte seront constitués de ces activités, que l'équipe décomposera ensuite en histoires d'utilisateur plus petites.

4ème : Cartographier les User Stories sous les activités

L'équipe peut maintenant étoffer le squelette de la carte en décomposant chaque activité ou thème en de plus petites histoires d'utilisateur, avec l'ossature en place et les thèmes principaux spécifiés.

Par exemple, des histoires telles que "En tant qu'acheteur, je souhaite mettre à jour et supprimer des produits dans mon panier afin de pouvoir changer d'avis avant d'acheter" pourraient être trouvées sous l'activité "Panier d'achat".

5ème : Flux et priorités

Après avoir créé des thèmes de haut niveau et des histoires d'utilisateurs spécifiques, l'étape suivante consiste à les hiérarchiser en les classant verticalement du plus important au moins important. Ensuite, les équipes planifient la manière dont les consommateurs se déplacent dans le produit, généralement de gauche à droite.

Les équipes peuvent vouloir cartographier des scénarios distincts pour différentes catégories d'utilisateurs si un produit a plusieurs types d'utilisateurs. Ces étapes aident les équipes à déterminer quelles histoires sont essentielles et lesquelles ne le sont pas pour offrir une excellente expérience du produit au(x) public(s) cible(s).

6ème : Identifier les lacunes, les dépendances, les exigences techniques et les alternatives.

La story map permet aux équipes d'anticiper les défis possibles tels que les goulots d'étranglement, les dépendances, l'architecture technologique et les connaissances et capacités manquantes qui pourraient les ralentir par la suite.

Identifier ces risques avant de commencer le travail de conception ou de développement peut aider les équipes à les minimiser et à les atténuer, à améliorer la convivialité et à développer des solutions alternatives.

7ème : Planifier les sprints et les versions

C'est là que les groupes transforment un exercice visuel en travail réalisable. Les équipes peuvent voir le travail qui offrira le plus de valeur dans le temps le plus court en priorisant les histoires du haut vers le bas et en regroupant ces histoires en sprints de développement et en versions de produits.

Les équipes diviseront la carte en "tranches" horizontales, en classant les contes selon leur priorité au sein de chaque activité essentielle de l'utilisateur. Il est essentiel de se rappeler qu'il ne s'agit pas de déterminer ce qui est nécessaire pour un produit minimal viable, mais plutôt de déterminer les tâches les plus importantes pour offrir une expérience agréable au client.

Le processus de la cartographie des histoires d'utilisateurs

Quelle est la meilleure façon d'aborder la cartographie des histoires d'utilisateurs ? En fonction de la taille de votre équipe, de la portée et de la durée d'un projet, ainsi que du stade de maturité du produit, vous pouvez le mettre en œuvre de plusieurs manières.

La cartographie narrative est le meilleur point de départ lorsque vous avez rassemblé toutes les exigences du produit et constitué l'équipe de projet. La carte peut être créée à partir du ou des backlogs existants ou comme un document autonome.

1. Classer les histoires par ordre de priorité et définir le MVP

Il existe trois couches qui détaillent un produit. Le mieux est de hiérarchiser les fonctionnalités les plus importantes et les dates de sortie prévues. Les différentes approches doivent être décrites avant de pouvoir être utilisées pour hiérarchiser les user stories en fonction de leur importance.

La planification des sorties se fait avec du ruban adhésif dans le cas des notes autocollantes. Il suffit de diviser les blocs narratifs de manière à ce que chacun d'entre eux représente visuellement un communiqué. Les produits numériques offrent de nombreuses fonctions permettant de regrouper, d'esquisser, de coder par couleur et de répartir les notes.

2. Collecte des documents et sélection d'un outil de cartographie dans la phase préliminaire

Emportez avec vous toute documentation technique utilisable que vous possédez pour un projet. Le document sur les exigences du produit (PRD), les normes et les évaluations seront tous importants à prendre en compte. Vous devriez également examiner les personas d'utilisateurs créés par un chercheur en expérience utilisateur.

Ensuite, répondez à cette question fondamentale : Quel genre de story map voulez-vous créer ? Si vous choisissez d'écrire à la main, rassemblez un tableau noir, de nombreuses notes autocollantes, des feutres, des marqueurs, du ruban adhésif et du café. Si vous voulez que la carte soit bonne, assurez-vous que le produit numérique offre une capacité de partage dans le cadre de sa fonctionnalité gratuite ou payante.

3. Rédiger les User Stories

Entrons maintenant dans le vif du sujet. Les user stories dans un backlog plat sont écrites comme ceci : "En tant que rôle d'utilisateur, je veux agir de manière à obtenir une motivation." Le format des user stories donne suffisamment de détails lorsqu'on aborde les différentes fonctionnalités. Par conséquent, vous pouvez utiliser ce format dans votre carte ou le simplifier en un format de tâche technique, comme l'ajout de la fonction glisser-déposer pour soumettre un fichier.

Le cadre traditionnel d'un récit d'utilisateur n'est pas nécessaire car vous organisez déjà les histoires à travers des épopées avec des personas d'utilisateur désignés. Le nombre d'histoires et leurs détails varieront en fonction de l'endroit où vous vous trouvez dans le projet. processus de planification du projet. Maintenez l'attention sur le MVP (ou Minimum Viable Product), au minimum.

4. Organiser les histoires d'utilisateur qui sont laissées de côté

Vous trouverez certainement de nouvelles idées au cours du débat. En général, les techniques de priorisation comprennent une catégorie distincte pour les histoires agréables à lire. Par conséquent, ne les négligez pas.

Une section "thrash" est un autre élément clé que vous devez inclure. Cette section peut sembler cruelle, mais c'est un endroit où vous pouvez stocker des histoires inutiles. Il est possible que l'importance de cette section ne soit pas immédiatement apparente. Cependant, à mesure que le produit mûrit, vous devez vous attendre à un changement de priorité ou à l'ajout d'exigences supplémentaires.

Ainsi, pour retrouver ces informations en cas de besoin, il faut que tout soit structuré et transparent. Après la mise en place des versions, vous devrez mettre à jour les informations de la carte afin de la maintenir à jour avec l'état actuel du projet.

5. Pour la cartographie narrative, organisez la réunion et intégrez les participants.

Lorsque vous avez comptabilisé tous les participants et effectué tous les préparatifs pratiques, il est temps de dire aux membres ce que vous allez faire. Commencez par un échauffement en conversant simplement avec les individus pendant quelques minutes.

Il est essentiel que tous les participants à une réunion se sentent à l'aise afin qu'ils puissent participer à la discussion et exprimer leurs idées. Expliquez le fonctionnement d'une story map et ce que vous attendez des participants par la suite.

L'objectif principal est d'expliquer les objectifs et de s'assurer que tous les membres de l'équipe sont sur la même longueur d'onde. Ensuite, vous devez expliquer la structure de la carte :

• Expliquez ce que chaque couleur implique si vous utilisez un code de couleurs. Précise-t-elle le type ou la priorité de l'élément ?
• Expliquez aux membres comment les choses doivent être disposées sur la carte.
• Il convient d'expliquer les autres possibilités, comme les pensées ou les zones à privilégier.

Une section "thrash" est un autre élément clé que vous devez inclure. Cette section peut sembler cruelle, mais c'est un endroit où vous pouvez stocker des histoires inutiles.

Bien que l'animateur de la réunion puisse être celui qui écrit les informations sur les notes autocollantes, n'importe quel membre peut le faire indépendamment. Par conséquent, chaque participant doit être au courant des règles.

6. Conduire l'atelier

Après avoir donné tous les détails nécessaires, vous commencerez à travailler sur la carte proprement dite. La création de la carte commence par la création des activités des utilisateurs en fonction des personas des utilisateurs. Les épopées sont utilisées pour organiser les activités des utilisateurs. Ce sera donc la base de votre future offre, les étapes qu'un utilisateur peut suivre pour identifier vos biens.

Tenez compte de la description d'un persona d'utilisateur lorsque vous composez des épopées, car elle fournira des informations cruciales sur la façon de construire l'épopée avec précision. Ensuite, dans le cadre des actions de l'épopée, divisez-les en tâches qu'un utilisateur peut effectuer. Les activités des utilisateurs ne doivent pas être confondues avec les user stories ; elles doivent définir une étape du processus plutôt qu'une fonctionnalité.

7. Sélectionner les membres d'une équipe de Story Mapping

Avant de commencer, dressez une liste des personnes avec lesquelles vous allez travailler pour créer votre carte. Le story mapping prend la forme d'un atelier auquel participe le personnel essentiel de tous les départements. Le résultat de cette phase doit être une liste claire des personnes qui y participeront.

Seuls ceux qui sont capables de porter un jugement et de participer activement à la conversation devraient être pris en considération. Voici un indice : Un maximum de dix personnes peut participer à l'atelier. Vous ne pourrez pas accorder suffisamment de temps à chaque membre si l'équipe s'agrandit. Moins vous sélectionnez de personnes, plus il sera facile d'entamer une conversation entre elles.

8. Mettre en place des personas utilisateurs

Les personas d'utilisateurs fournis par les départements UX ou marketing serviront de base à votre carte. Vous ne serez pas en mesure de comprendre les épopées du produit si vous ne savez pas qui sont vos utilisateurs, et vous passerez à côté de l'idée même du story mapping. Vous pouvez définir qui effectuera des tâches particulières dans le système en utilisant des personas utilisateurs ou en discutant avec le personnel UX.

Que se passe-t-il après l'achèvement de la cartographie des histoires d'utilisateurs ?

Si les équipes ne l'ont pas encore fait, elles devront, à la fin d'un processus de cartographie des histoires d'utilisateurs, organiser leur schéma d'histoires priorisées en sprints et en versions. Pour s'assurer que la feuille de route du produit est acceptée, l'équipe produit peut vouloir partager ou évaluer la carte des histoires d'utilisateurs avec les équipes qui n'ont pas participé, y compris la direction. Toutes les équipes qui contribuent au travail des futurs sprints ou releases non représentés dans l'exercice de cartographie doivent le faire.

Les artefacts de cartographie des récits d'utilisateurs seront très probablement transférés dans une plate-forme d'ingénierie logicielle partagée par les équipes de produits et de développement. Les équipes d'ingénierie devront peut-être ajouter des exigences techniques et des critères d'acceptation pour garantir que tout travail apporte la valeur pour l'utilisateur établie dans l'exercice de cartographie narrative.

La carte des histoires d'utilisateurs ne doit pas être statique. Elle peut être mise à jour en fonction des résultats des pointes de recherche, des estimations modifiées et des commentaires des utilisateurs au cours des sprints et des versions. La story map peut également servir de feuille de route visuelle pour communiquer les activités prévues et inachevées.

Enfin, les équipes chargées de la cartographie des histoires d'utilisateurs devraient profiter de chaque exercice pour se rapprocher des clients et renforcer leur empathie pour ce qu'ils essaient d'accomplir.

Avantages de la cartographie des histoires d'utilisateurs

Voici quelques façons dont la cartographie narrative aide les équipes à améliorer leurs processus pour développer des produits que les utilisateurs apprécieront.

1. Se concentrer sur la valeur pour l'utilisateur

Lorsqu'une équipe produit élabore une story map utilisateur, elle visualise le produit du point de vue de l'utilisateur. La carte narrative qu'elle a créée l'aidera à déterminer comment les consommateurs interagissent avec le produit et quels efforts donneront les meilleurs résultats. Par conséquent, la planification de la feuille de route du produit doit se faire de l'extérieur vers l'intérieur.

2. Donner la priorité au bon travail

La création d'une représentation complète de tout le travail nécessaire pour offrir une expérience produit complète peut aider les équipes à déterminer ce qui est le plus important, à organiser le travail en versions (la livraison d'une nouvelle expérience client) et à dé-prioriser le travail qui a une valeur moindre pour l'utilisateur.

3. Conduit des exigences claires et bien dimensionnées

De nombreuses équipes ont du mal à élaborer des récits d'utilisateurs et des exigences attrayants. La cartographie des récits d'utilisateurs peut aider en illustrant la manière dont les grandes parties du travail sont décomposées en plus petites et en montrant comment les éléments du travail sont liés.

4. Apporter une nouvelle valeur ajoutée tôt et souvent

Les équipes peuvent utiliser la cartographie des histoires d'utilisateurs pour organiser leur travail en itérations et en versions en fonction de leur importance pour les utilisateurs.

Le fait de travailler d'abord sur les éléments les plus essentiels permet aux équipes d'apporter plus rapidement la plus grande valeur ajoutée aux clients, de recevoir un retour d'information précoce de leur part et de déterminer rapidement quelles améliorations du produit seront les plus utiles.

5. Expose les risques et les dépendances

La création d'une carte narrative de la façon dont les clients interagissent avec un produit peut fournir aux équipes une image holistique du produit, leur permettant de voir tous les blocages, risques et dépendances qui doivent être traités pour livrer le produit efficacement.

6. Établir un consensus au sein de l'équipe

La création d'une carte narrative de l'utilisateur permet aux équipes de partager une compréhension commune de l'expérience client et du travail nécessaire pour l'améliorer. Le projet favorise les discussions qui aboutissent à une compréhension commune de ce qu'il faut créer, quand le faire et pourquoi.

Quelles sont les difficultés de la cartographie des histoires d'utilisateurs ?

La cartographie des histoires d'utilisateurs peut aider les équipes à avancer rapidement et à produire des produits que les consommateurs apprécient, mais elle peut aussi conduire à des résultats insatisfaisants si les équipes ne sont pas préparées. Voici quelques-unes des difficultés dont il faut être conscient :

Pas de client clair

Il est difficile de savoir ce qu'un client pense d'un produit si vous ne savez pas qui il est. Vous devez identifier pour qui vous faites des cartographies.

Pas de problème évident

L'ensemble des efforts de histoire d'utilisateur Le mapping peut se retourner contre vous si vous ne savez pas quel problème votre solution résout pour les clients. Construire des histoires vers le mauvais objectif client peut être une perte de temps et d'argent dans l'exercice lui-même et dans les sprints et releases basés sur celui-ci.

Utilité limitée

Il est difficile de maintenir à jour des story maps physiques construites à partir de notes autocollantes sur un tableau blanc. Les itérations et les versions sont expédiées sans mise à jour parce que les notes autocollantes s'enlèvent, les tableaux blancs sont nettoyés et le travail est perdu, ou les itérations et les versions sont expédiées sans mise à jour du tableau. En outre, les story maps créées dans un seul lieu physique ne profitent pas aux équipes travaillant dans d'autres lieux qui ne peuvent pas les voir.

Re-travail et redondance

Pour que les équipes de développement commencent à travailler sur les histoires issues d'une carte des histoires de l'utilisateur, il faut souvent les reproduire dans un backlog plat, tel qu'un outil de génie logiciel. Par conséquent, cette activité peut donner l'impression que les équipes se répètent.

Conclusion : Comment la cartographie des histoires d'utilisateurs améliore votre activité

Le story mapping permet d'atteindre divers objectifs auxquels les chefs de produit sont fréquemment confrontés. Vous pouvez communiquer les buts et objectifs généraux à vos collègues sans leur faire la morale. Vous pouvez favoriser un environnement collaboratif où chacun est impliqué dans le développement du produit. Vous pouvez utiliser des idées et des pensées possibles qui passeraient autrement inaperçues. Avant que votre équipe ne crée une seule ligne de code, vous pouvez parvenir à un consensus et à une compréhension commune des objectifs.

D'un autre côté, la cartographie des histoires n'est pas rapide - après tout, vous devez cartographier chaque histoire d'utilisateur - et vous aurez besoin de la zone physique appropriée pour la réaliser. Vous devrez peut-être persuader la direction que le temps de chacun est mieux utilisé que les programmes prévus.

Cependant, si votre produit n'aide pas les clients à achever leur voyage, ils iront ailleurs ou l'annuleront complètement. Une story map permet à chacun de se rallier au même objectif et produit un environnement riche en contexte dans lequel il est clair où les ressources doivent être allouées.

The post User Story Mapping: Process, Tips, Advantages – The Complete Guide appeared first on Startup Oasis.

Si le concept n'est pas bien validé, il y a de fortes chances que le produit à part entière échoue. Lorsqu'il s'agit de phases de développement, vous aurez besoin des plans de développement appropriés. Quoi qu'il en soit, il vous sera utile de valider vos progrès auprès de vos utilisateurs.

Il existe trois possibilités pour vous aider : La preuve de concept, les prototypes et les MVP. Les entreprises mélangent fréquemment ces trois approches en fonction de l'utilisation prévue et du moment. Toutefois, cet article de blogue explique les différences entre les trois approches. Preuve du concept ou prototype et MVP et vous aider à choisir celle qui vous convient le mieux.

Preuve du concept (POC)

POC est l'abréviation de proof of concept. Il s'agit d'une méthode permettant de déterminer si une idée d'application est réalisable ou non. Une méthodologie de preuve de concept dans le développement de logiciels peut être utilisée pour vérifier que le concept fonctionnera comme prévu. Les startups peuvent l'utiliser pour établir leur viabilité financière.

Une preuve de concept n'est pas un composant plus léger ou moins avancé de votre produit fonctionnel. Il s'agit d'une initiative autonome qui vous indique uniquement si votre concept est réalisable ou non. Cette approche ne consiste pas à déterminer la demande d'idées sur le marché.

Un POC ne montre pas le processus de production le plus efficace. Il s'agit d'une initiative qui se concentre sur les capacités techniques d'un projet. Il vous permet d'évaluer si l'une de vos hypothèses technologiques, vos idées, vos connexions, etc. sont mises en œuvre.

Par conséquent, si vous devez authentifier deux composants techniques dans différentes sections de votre projet interne, vous aurez besoin de deux POC. Un POC ne signifie pas que votre application est parfaite puisqu'elle ne sera probablement pas réutilisée. Ses composants critiques comprennent les données codées en dur, les API simulées, etc.

Vous risquez de négliger la qualité du code et la sécurité et de réduire la complexité de l'interface utilisateur. Vous devriez commencer par créer un projet POC avant le processus de prototypage et Développement MVP. Une approche de preuve de concept nécessite généralement du temps et un investissement financier. Mais la création d'un produit numérique irréalisable entraîne inévitablement des dépenses importantes.

Les caractéristiques

• Intérêt précoce des investisseurs : Vous pouvez utiliser une preuve de concept pour présenter votre idée d'entreprise à des investisseurs et obtenir des fonds de démarrage pour un développement futur.
• Innover : C'est à l'intersection de la capacité technique et de la demande du marché que se produit l'innovation. Un POC vous aidera à déterminer si votre concept peut ou non être mis en œuvre à l'aide des différentes technologies actuellement disponibles.
• Il permet de gagner du temps : Vous gagnez du temps en vérifiant si le concept de votre produit est réalisable. Vous évitez de perdre du temps si vous découvrez des problèmes de faisabilité technique après avoir embauché des développeurs et engagé des ressources et un temps considérables.
• Choisissez la technologie qui vous convient le mieux : Le développement de plusieurs POC avec diverses technologies peut vous aider à déterminer la pile technologique spécifique qui convient le mieux à votre projet. Ainsi, vous serez en mesure de voir ce qui est faisable et comment établir la feuille de route de votre produit le plus tôt possible.
• Comparez avec la concurrence : Si vous lancez une application mobile sur un marché très concurrentiel, un POC peut vous aider à identifier des caractéristiques uniques pour renforcer votre offre. Pour être compétitive, votre solution doit constituer une alternative supérieure à ce qui est actuellement disponible en combinant une stratégie distincte pour résoudre le même problème.

Une preuve de concept n'est pas un composant plus léger ou moins avancé de votre produit fonctionnel. Il s'agit d'une initiative autonome qui vous indique uniquement si votre concept est réalisable ou non.

Comment fonctionne le CEP ?

Si vous n'êtes pas sûr qu'une idée soit réalisable, la validation du concept peut fournir deux réponses possibles : oui ou non. Une réponse négative ne vous permettra pas de poursuivre un projet qui risque d'échouer. Vous pouvez continuer à développer votre projet s'il dispose d'une preuve de concept convaincante.

Une preuve de concept - flux de processus ou résultats - n'a pas pour but de montrer vos utilisateurs. Il s'agit d'une méthode permettant de traiter des problèmes importants de l'intérieur. Cependant, le fait de le montrer à des investisseurs potentiels peut permettre d'obtenir des fonds de démarrage. Ainsi, vous pouvez démontrer que vous êtes un acteur majeur avec un concept réalisable en pratique.

Raisons d'utiliser le CEP

Les entreprises qui veulent savoir si leur concept est viable réalisent généralement des POC. Un concept innovant, par nature, génère de l'incertitude, ce qui peut nécessiter des tests. Il est également facile d'appliquer le même raisonnement pour développer une solution comparable à une solution existante à faible coût.

L'approche des concurrents peut être mise en œuvre avec un investissement plus important que celui dont vous disposez actuellement. C'est pourquoi il est préférable d'utiliser une méthode POC pour évaluer la viabilité de votre concept. Une preuve de concept n'est pas obligatoire dans le processus de développement. Cependant, elle est fortement recommandée car elle peut aider à résoudre des problèmes techniques avant votre échéance.

Les avantages du CEP

1. Atténuer les risques

Une preuve de concept est une démonstration du potentiel de développement futur. Se lancer directement dans le processus de développement comporte plusieurs risques. Si une certaine idée n'est pas techniquement réalisable, vous renoncez aux coûts de développement. Il est toujours préférable d'être prudent avant, surtout lorsque de l'argent est en jeu.

Vous pourrez tester votre POC dans une situation réelle, comme pour le développement d'un produit. Vous saurez ainsi si les concepts sont réalisables. Si ce n'est pas le cas, vous abandonnez le concept et cherchez autre chose. Par conséquent, le POC permet d'atténuer les facteurs de risque.

2. Gagner des investisseurs

Aucun investisseur n'est prêt à mettre de l'argent dans quoi que ce soit avant d'être sûr que cela va marcher. Ils ont besoin d'une confirmation qui leur permettra d'offrir de l'argent.

Les tests POC sont la technique la plus efficace pour démontrer si votre invention va réussir ou non. Ils peuvent vous aider à convaincre vos investisseurs que vos nouvelles idées sont valables et suffisamment sûres pour être poursuivies.

3. Il permet le développement de nouvelles idées

Les personnes ayant des concepts innovants sont à la recherche de financements. Les investisseurs sont désireux de financer des idées créatives. Toutefois, les deux parties sont profondément préoccupées par ce qui se passera - que se passera-t-il si le projet n'est pas réalisable ou excellent ?

Les idées peuvent sembler excellentes sur le papier, mais les problèmes réels se révèlent après la mise en œuvre. Le POC est un pont qui relie les innovateurs et les investisseurs, leur permettant de surmonter leurs hésitations. Cela permet à davantage d'entrepreneurs de poursuivre leurs nouvelles idées sans craindre l'échec ou la critique.

Exemple de preuve de concept

Blockchain tech est un outil utile pour enregistrer et suivre les transactions en crypto-monnaies. Walmart a examiné comment utiliser les capacités de suivi de cette technologie dans la gestion de la chaîne d'approvisionnement.

Elle a collaboré avec IBM pour créer des POC pour la technologie de suivi des aliments, l'un pour les mangues aux États-Unis et l'autre pour la viande en Chine. C'était techniquement faisable. En 2018, Walmart pourrait retracer la source de plus de 25 articles provenant de cinq fournisseurs différents.

Qu'est-ce qu'un prototype ?

Vous pouvez commencer le prototypage dès que vous obtenez un bon résultat de la preuve de concept. Dans le domaine de l'ingénierie logicielle, le prototypage permet de créer un modèle préliminaire d'un produit afin d'observer comment il apparaîtra une fois terminé.

Un POC porte généralement sur les aspects techniques, tandis que le prototypage concerne l'interface utilisateur et l'expérience. Il vous permet d'imaginer comment l'utilisateur utilisera votre produit. Un prototype est destiné à vous aider à comprendre les processus du projet et à identifier les fonctionnalités à inclure.

Le processus de création d'un prototype commence par le développement d'un modèle de votre produit basé sur des vues du web ou de l'application. Il permet d'exposer les défauts d'étude et de conception. Le prototypage consiste à créer une structure ou une conception préliminaire d'un prototype de produit qui peut être testé et modifié jusqu'à ce que les effets escomptés soient obtenus. Le prototypage, tout comme le POC, a une courte durée de vie.

Caractéristiques d'un prototype

• Convaincre les investisseurs : Un prototype peut vous aider à attirer l'attention des investisseurs et à obtenir leur approbation pour votre invention, en particulier lors des dernières étapes du financement.
• Optimiser les ressources : Lorsque vous commencez avec un prototype, vous pouvez repérer les composants indésirables de l'interface utilisateur qui doivent être supprimés avant que le travail de développement complet ne commence.
• Iterate designs : Les solutions de prototypage interactif comme Figma permettent aux concepteurs de créer de nombreuses variantes de conception en peu de temps. En procédant ainsi, vous pouvez choisir le design le plus efficace et effectuer des tests internes.
• Recueillir des informations : Un prototype vous donne l'occasion d'envoyer votre produit pour qu'il soit testé par les utilisateurs afin de recueillir leurs premières réactions. À ce stade, les tests peuvent contribuer à améliorer et à affiner la conception, tout en laissant suffisamment de temps pour corriger les problèmes.
• Polissez le concept de l'entreprise : Le prototype vous permet de réduire la complexité de votre concept de produit et de le convertir en une forme visuellement attrayante. Après qu'une preuve de concept ait validé une idée, le prototype lui donnera une forme plus raffinée.

Comment cela fonctionne-t-il ?

Le propriétaire du produit détermine tous les besoins du système pour produire une conception préliminaire simplifiée. Le premier prototype d'application mobile est construit et évalué. Une fois les principaux problèmes et points forts déterminés, le développeur évalue les commentaires des utilisateurs.

Il est temps de déterminer ce qui doit être inclus et éliminé. Le développement d'un nouveau système suit chaque nouveau prototype d'application mobile. La conception du système suivant est itérée jusqu'à sa finalisation, en démontrant toutes les exigences et l'approbation de l'utilisateur.

Raisons d'utiliser des prototypes

Le développement d'un prototype de produit peut être utile dans certaines circonstances, notamment lorsque certains critères du projet manquent de spécificité. Vous pouvez créer des maquettes pour vous faire une idée de l'apparence de votre produit.

Les principaux avantages du prototypage sont l'interaction avec les utilisateurs et l'obtention d'un retour d'information précoce. La meilleure approche pour commencer votre MVP est un prototype plus solide et plus détaillé qui répond aux exigences des utilisateurs.

Les avantages du prototype

1. Valider l'expérience utilisateur

La meilleure approche pour évaluer l'expérience utilisateur que vous avez développée est de la prototyper. Vous pouvez également utiliser des utilisateurs et des clients réels pour tester votre prototype. Vous apprendrez ainsi à connaître les performances de votre Design UX sur la base de leurs commentaires. Faire participer les utilisateurs aux tests de prototypes peut conduire à une conception plus centrée sur l'utilisateur.

2. Collaborer avec les parties prenantes

Les prototypes créent un potentiel d'interactions positives avec les parties prenantes. Lorsque vous vous engagez avec les parties prenantes et les clients, vous pouvez être ouvert à diverses idées.

Un prototype permet d'expliquer plus clairement les changements ainsi que les attentes car il fonctionne. En outre, il s'agit de la méthode la plus efficace pour s'assurer que vous êtes tous sur la même longueur d'onde.

3. Aide à la recherche de fonds d'amorçage

Les prototypes peuvent vous aider à démontrer l'efficacité de l'UX de votre produit. Veillez à évaluer votre prototype en fonction des commentaires des utilisateurs. Vous pouvez ensuite montrer le prototype d'application mobile aux investisseurs lorsque vous êtes satisfait. Les prototypes vous aident à gagner la confiance des investisseurs pour financer votre produit numérique.

Exemple de prototype

Zappos est un détaillant de chaussures sur Internet. Nick Swinmurn (fondateur de Zappos) n'arrivait pas à trouver les chaussures qu'il voulait dans un centre commercial. C'est alors qu'il a eu l'inspiration de vendre des chaussures en ligne. Il a créé un prototype numérique et lui ont donné vie. Zappos a été fondé en tant que prototype et a été racheté par Amazon pour $1,2 milliard dix ans plus tard.

MVP (Minimum Viable Product)

La version MVP a suffisamment de capacités pour communiquer son concept et répondre aux problèmes des premiers utilisateurs. Un produit minimum viable est une solution fonctionnelle dotée d'un minimum de fonctionnalités pour répondre aux demandes de ses premiers utilisateurs.

Il diffère du POC ou du prototype en ce qu'il s'agit d'un produit fonctionnel aux capacités minimales. Il vous permet de déterminer comment vos clients utilisent votre service ou votre produit. Quel est l'intérêt d'investir dans quelque chose dont ils ne se soucient pas ou dont ils n'ont pas besoin ?

Votre MVP ne doit mettre en évidence que les éléments de votre solution qui la rendent attrayante pour les clients. Cependant, la seule question que pose un MVP (Minimum Viable Product) est la suivante : "les clients seront-ils prêts à payer pour mon produit ou service ?". Malheureusement, la réponse n'est généralement pas aussi simple qu'avec un POC.

Un MVP (Minimum Viable Product) vous permet d'apprendre, de grandir et de comprendre le développement futur. Un MVP révèle comment construire rapidement un produit suffisamment décent. Ce n'est pas un produit à part entière, mais c'est une technique utile pour tester l'adéquation produit-marché. En outre, vous dépensez moins d'argent que si vous deviez créer un produit complet.

De l'autre côté, vous obtenez une réponse, vous savez ce que les gens veulent et vous pouvez enfin commencer à formuler votre modèle commercial. Un MVP (Minimum Viable Product) ne consiste pas à créer un produit de moindre qualité. Il s'agit de donner aux utilisateurs un avant-goût de votre produit et de décider s'ils veulent le consommer.

Caractéristiques d'un MVP (Minimum Viable Product)

• Obtenez les commentaires des utilisateurs : Un MVP est une technique merveilleuse pour découvrir ce que vos premiers utilisateurs pensent de votre produit et pour avoir un aperçu de leurs réactions afin de vous aider à améliorer les futures versions de votre produit.
• Évitez de gaspiller les ressources : Le temps de développement est réduit car vous n'avez pas à intégrer toutes les fonctionnalités de base dans votre MVP. En outre, lorsque vous évaluez les commentaires des utilisateurs, vous pouvez créer une feuille de route et une voie de développement claires pour le produit - le risque de surconstruire des fonctionnalités sera réduit. Un produit minimal viable vous permet également de faire évoluer progressivement votre produit, en autorisant l'introduction d'une version ultérieure après avoir reçu un soutien financier.
• Attirer les investisseurs : Alors qu'un POC et un prototype peuvent vous aider à obtenir un capital de départ, un MVP peut vous aider à obtenir un investissement plus important, car les investisseurs sont plus susceptibles d'être convaincus de soutenir votre idée commerciale avec de l'argent si votre MVP gagne du terrain et reçoit des réactions positives.

Les raisons d'utiliser MVP

Les entrepreneurs sont rarement enclins à parler de leurs échecs, mais cela arrive de temps en temps. Cela est dû à certains facteurs. La réalité est que si votre produit est voué à l'échec, vous voudriez être le premier à le savoir. C'est la première et la plus importante raison pour laquelle les entrepreneurs préfèrent opter pour un produit minimum viable (MVP).

La technique la plus efficace et la plus efficiente pour fournir à un public cible une solution à son problème est le produit minimum viable (PMV). Seul un projet sur cinq présentant un concept innovant aboutit en raison de la longueur du temps de développement. Ils n'établissent pas de MVP et n'obtiennent pas le feedback d'un client potentiel.

Un MVP est le moyen le plus rapide de déterminer si les gens n'aiment pas une solution et d'éviter de perdre du temps et des ressources. S'ils sont prêts à payer, un MVP vous permet de déterminer comment aller dans la bonne direction.

Les avantages de MVP

1. Réactions précoces

Vous avez basé votre produit sur les résultats des recherches menées auprès des utilisateurs. Cependant, le processus de développement est toujours influencé par les objectifs de l'entreprise et les concepts des différentes équipes. Par conséquent, vous ne connaîtrez les lacunes de votre produit qu'après son utilisation par les utilisateurs.

Imaginez ce qui se passerait si les utilisateurs découvraient des problèmes avec votre produit final après sa mise en ligne. Cela nuirait à l'image de votre entreprise. Cependant, le cas est différent avec MVP et il est toujours possible d'améliorer le produit. Les MVP vous permettent d'obtenir un retour d'information précoce de la part des utilisateurs cibles et de répondre à leurs préoccupations. Il vous permet d'affiner votre produit.

2. Engagement précoce avec les utilisateurs

Après avoir développé votre MVP, vous voudrez le faire tester par des utilisateurs bêta. Les premiers utilisateurs sont généralement des bêta-testeurs. S'ils aiment votre MVP, il y a de fortes chances qu'ils deviennent de bons clients.

Et ce n'est pas tout. La plupart des bêta-testeurs sont généralement des techniciens. Lorsqu'ils découvrent quelque chose de fantastique, ils aiment en parler aux autres. Cela leur permet de diffuser la nouvelle de votre produit. Cela permet également de gagner encore plus de clients. Ainsi, avec MVP, vous aurez une grande connexion avec eux avant même qu'ils ne le deviennent.

3. Rapidité de mise sur le marché

L'agonie des utilisateurs est la source de toutes les idées de produits. Cela signifie qu'il y a de fortes chances que quelqu'un d'autre pense à quelque chose de similaire à ce que vous proposez. Le premier à commercialiser un produit est souvent considéré comme innovant et a plus de chances de gagner.

Vous pouvez créer rapidement un MVP et le mettre sur le marché pour obtenir les réactions des utilisateurs. Par conséquent, le MVP est une approche qui vous permet de garder une longueur d'avance sur la concurrence et d'acquérir une base solide sur le marché.

Exemple d'un MVP

Amazon est aujourd'hui l'un des principaux acteurs du secteur du commerce électronique. Il vend de tout, des vêtements aux livres, en passant par l'électronique et même l'électroménager. Lorsque Jeff Bezos a créé un MVP pour Amazon et l'a lancé dans les années 1990, le MVP était uniquement constitué de listes de livres. Lorsque quelqu'un passait une commande sur Amazon, il achetait le livre au distributeur et le livrait au client.

Cependant, Jeff a apporté plusieurs modifications au MVP au fur et à mesure qu'il apportait les améliorations nécessaires. C'est ainsi que l'entreprise a commencé à ajouter des articles supplémentaires. Aujourd'hui, Amazon est l'une des plus grandes sociétés commerciales des États-Unis, aux côtés de Google, Apple et Facebook.

POC, prototype ou MVP : comment choisir la meilleure approche ?

Les entrepreneurs ne peuvent pas choisir entre les approches pour parvenir à une adéquation produit-marché. Ils choisiront plutôt l'une des approches en fonction des progrès de leur application ou les considéreront comme des étapes. Voyons cela en détail :

Scénario 1 : lorsque vous êtes encore au stade de la validation du concept

Vous êtes dans une situation idéale si vous n'avez pas encore commencé à développer l'une ou l'autre technique. C'est une étape où vous avez plus de temps pour documenter le cycle de vie de la validation de l'application. Il existe de nombreuses possibilités d'investir dans un cycle de vie qui commence par le POC et se poursuit par le Prototype, puis le Processus MVP.

• Test légitime de l'idée du produit : Le but de commencer par l'étape du POC, puis de passer au prototype et au MVP, est de valider le concept. Cela aide les entrepreneurs à ajuster leur concept en fonction de la réaction de leurs clients.
• Développement rapide : Lorsque vous utilisez cette méthode, votre entreprise de développement d'applications mobiles ne travaille qu'avec les fonctionnalités les plus basiques - celles qui ont été préalablement commercialisées. Cela implique qu'il y a beaucoup de profit potentiel dans une période très courte.
• Faible risque d'investissement : Lorsque vous créez une application qui est passée par trois phases de test, vous donnez aux investisseurs la garantie qu'elle est sûre. Ce qui, à son tour, conduit à un investissement important.

Scénario 2 : lorsque vous êtes déjà au stade de la validation de l'idée

Lorsque vous êtes au stade de la validation de l'idée, la possibilité de suivre un processus étape par étape pour atteindre l'adéquation produit-marché est assez mince. Dans cette situation, vous devez choisir entre la preuve de concept et le prototype ou MVP.

Il y a beaucoup d'éléments à prendre en compte avant de prendre cette décision - des éléments qui peuvent être facilement convertis en possibilités IFTTT (If This Then That).

Voici quelques critères fondamentaux pour chaque technique :

Choisissez POC :

• Quand vous cherchez un capital d'amorçage
• Lorsque vous devez évaluer si une invention est techniquement efficace
• Si vous souhaitez échanger des connaissances internes avec votre équipe de développement
• Lorsque vous voulez évaluer un projet ou l'efficacité des fonctionnalités

Sélectionnez Prototype :

• Lorsque vous cherchez un aperçu du fonctionnement de l'application
• Si vous avez des ressources limitées mais que vous voulez montrer aux parties prenantes votre application
• Lorsque les ressources techniques sont extrêmement limitées
• Quand vous avez besoin d'une visualisation rapide de l'application

Choisissez MVP :

• Lorsque vous devez démontrer une application fonctionnelle à vos clients
• Lorsque vous créez une application pour générer de l'argent
• Si vous avez besoin d'une application sans bogue et prête à être utilisée par le grand public
• Lorsque vous avez besoin d'une meilleure rétention à un coût avantageux
• Lorsque vous souhaitez améliorer votre application en découvrant ce que le public cible en pense.
• Lorsque vous souhaitez améliorer les fonctionnalités d'une application, il est bon de savoir ce que pense le marché.

L'importance du POC, du prototype et du MVP

Dans toutes les situations, le POC, le prototype et le MVP vous permettent de mener des recherches importantes avant de faire un gros investissement. Sur le marché actuel, aucune entreprise ne peut se permettre de gaspiller du temps ou de l'argent à poursuivre un concept voué à l'échec.

Les trois approches vous aident à mener des recherches significatives sur la viabilité de la réussite d'un projet :

• Le CEP détermine si le concept est réalisable ou non.
• Le prototype donne un aperçu de la manière dont il pourrait être développé.
• Le MVP vous aide à évaluer si les consommateurs sont intéressés par l'idée du produit et s'ils sont prêts à payer pour l'utiliser (ou une partie de celui-ci).

Sur le marché actuel, aucune entreprise ne peut se permettre de gaspiller du temps ou de l'argent à poursuivre un concept perdant.

Conclusion : Comment le POC, le prototype et le MVP peuvent améliorer votre entreprise en démarrage.

Tout projet commence par des recherches et une planification. Les startups élaborent des plans, organisent des séances de brainstorming et consacrent beaucoup de temps à éviter les erreurs pour lancer un produit réussi et très demandé par les consommateurs.

Si vous vous lancez dans le développement d'un produit personnalisé unique, les trois techniques : POC, Prototype, et MVP peuvent être utiles. Toutes sont uniques et ont des objectifs différents, mais elles peuvent toutes être utilisées au mieux pour obtenir les meilleurs résultats possibles.

The post How to Decide When to Use an MVP, POC, or Prototype appeared first on Startup Oasis.

Le produit doit commencer par un niveau de test, puis passer au suivant pour obtenir la validation du client et évaluer la convivialité du produit. Cependant, ces tests peuvent aider à développer un produit minimal viable tout en tenant compte des limitations budgétaires. Par conséquent, la simple création d'un MVP n'est pas suffisante ; il est également essentiel de tester un MVP à l'aide d'une stratégie de test.

Une entreprise peut croire que le produit peut répondre aux demandes des consommateurs, mais on ne peut l'affirmer avec certitude qu'après les tests MVP. Toutefois, cet article de blog explorera sept stratégies éprouvées pour les tests MVP. Ces stratégies de test MVP vous aideront à créer un produit MVP réussi. Test MVP et s'assurer que votre produit est prêt pour le marché.

Ce que vous devez savoir sur le produit minimum viable

Un MVP (minimum viable product) est la première version de votre produit destinée à évaluer la réaction du marché à votre concept commercial. Le MVP implique un développement rapide et de faibles dépenses de mise en œuvre. L'expression MVP (minimum viable product) est née dans les pays suivants Lean Startupune méthode pour le développement rapide de produits.

Au lieu d'investir des années dans le développement d'une application compliquée qui risque d'échouer, la technique suggère de créer un logiciel pour évaluer les besoins des clients cibles. Dans le contexte de la développement de logicielsMVP signifie créer un produit simple sans développer au préalable la version finale.

La création d'un MVP a été utilisée par des géants tels que Twitter, Instagram et Spotify pour commencer. Il s'agit d'un programme à part entière avec des fonctionnalités de base. Il est essentiel de limiter la portée de votre MVP aux fonctionnalités de base car, sans elles, le produit ne serait pas possible. En développant un MVP, une entreprise peut expérimenter diverses méthodes pour un développement ultérieur.

En développant un MVP, une entreprise peut expérimenter différentes méthodes pour un développement ultérieur.

Pourquoi est-il nécessaire de tester le MVP ?

C'est un gros pari que de lancer un produit sur le marché sans l'avoir testé au préalable. Les résultats des tests d'un produit minimum viable et les commentaires des clients peuvent vous aider à déterminer s'il vaut la peine ou non de poursuivre le projet. Voici le résultat que vous obtiendrez après avoir testé votre MVP :

• les changements dans l'approche de test qui doivent être pris en compte
• des décisions appropriées concernant le produit actuel
• moins d'erreurs
• amélioration du produit
• elle réduit les coûts par rapport à un lancement de produit à part entière

Les 7 meilleures façons de tester un MVP

Construire un produit minimum viable est sans aucun doute un processus essentiel. Mais après avoir obtenu le produit fini, il est trop tôt pour s'arrêter. L'étape critique suivante est le lancement et l'évaluation du produit.

Les tests visent à comprendre comment une idée commerciale répond aux besoins du marché et comment vous pouvez continuer à développer votre produit. Les étapes de la validation d'un MVP diffèrent selon son type et les besoins de l'entreprise. Mais voici les principales approches permettant d'évaluer la demande pour le produit.

1. Entretiens avec les clients

Les entretiens avec les clients sont une mine de données précieuses. Ils peuvent vous aider à obtenir de vos clients réels des informations sur votre MVP qu'il serait impossible de recueillir autrement. Par conséquent, il n'y a pas de meilleure approche pour évaluer un MVP que de demander à ceux qui vont l'utiliser.

Les entretiens avec les clients peuvent vous aider à découvrir quels sont les défis auxquels votre public cible est confronté et si votre produit actuel y répond. En outre, ils offrent la possibilité de montrer aux clients la valeur de votre produit.

Un autre avantage des entretiens avec les clients pour la validation MVP est que vous pouvez anticiper des commentaires honnêtes de leur part. Les clients peuvent mentir, édulcorer ou fournir de fausses critiques lorsqu'ils écrivent ce qu'ils pensent des produits en ligne. Mais il est plus probable qu'ils donnent un avis honnête.

Toutefois, pour tirer le meilleur parti des enquêtes auprès des clients, rassemblez une base de données d'utilisateurs potentiels en ligne et offrez-leur la possibilité de tester votre MVP. Ensuite, dressez la liste de tous les problèmes que vous pensez que vos clients peuvent rencontrer. Après l'avoir complétée, demandez à chaque client comment il évaluerait ces problèmes et si votre MVP les résout.

Prenez des notes sur tous les commentaires que vous recevez. Vous serez étonné de ce que vous trouverez. Voici quelques éléments à garder à l'esprit :

• Commencez l'entretien sur une note légère, puis entrez progressivement dans les détails.
• Formulez toutes les hypothèses que vous pensez pouvoir exister et obtenez un retour honnête sur celles-ci.
• Évitez de faire des déclarations comme "notre produit est un MVP sans marketing" lorsque vous parlez du MVP. Il est préférable de vous concentrer sur la communication de la valeur.

Vous pouvez également mener une enquête pour savoir si votre produit a répondu aux besoins des consommateurs visés et ce qu'ils souhaiteraient voir à l'avenir. Il y a de fortes chances que le client ne se préoccupe pas de situations qui ne semblent pas critiques. Cependant, vous disposerez de suffisamment d'informations précieuses pour créer un produit de meilleure qualité.

2. Pages d'atterrissage

Buffer, la célèbre plate-forme de médias sociaux, a commencé par une simple page d'accueil - en fait deux. La première page fournissait des informations sur le produit, et la seconde était une page d'inscription. C'est tout ce que Joel Gascoigne, le cofondateur de l'entreprise, a fait pour valider son MVP.

Les pages d'atterrissage sont une option populaire pour tester un MVP. Une page de renvoi peut être utilisée pour voir si votre MVP plaît à votre public cible. Elle peut également vous indiquer si votre produit attire certains types d'acheteurs, ce qui peut être utile si vous avez plusieurs options et que vous ne savez pas comment les atteindre.

Vous pourriez trouver un nouveau trésor de possibilités grâce à une page d'atterrissage MVP. Les pages d'atterrissage sont considérées comme un moyen de recueillir les adresses électroniques de clients potentiels. Mais les pages d'atterrissage sont bien plus que cela. Même si les pages d'atterrissage sont assez célèbres, peu d'entreprises émergentes les utilisent à leur plein potentiel.

Les pages d'atterrissage peuvent vous fournir un trésor d'informations. Par exemple, vous pouvez tester quelques versions différentes de pages d'atterrissage. Celles-ci pourraient être affichées de différentes manières en fonction de la combinaison, du design aux caractéristiques et aux modèles de prix.

Vous allez maintenant comparer la popularité des différentes versions en fonction du nombre et du type de personnes qui s'y inscrivent, ce qui vous permettra d'évaluer la viabilité de votre MVP et le type de personnes qu'il attire le plus. Pour une collecte influente de données importantes sur le trafic et les inscriptions, Google Analytics peut faire l'affaire.

3. Campagnes publicitaires

Une campagne publicitaire peut être un instrument d'étude de marché complet si vous savez comment l'utiliser correctement. Les campagnes publicitaires sur les sites de réseaux sociaux, comme les pages de renvoi, peuvent également vous fournir des analyses précieuses. Néanmoins, le type d'analyse que vous recevez par le biais d'une campagne publicitaire est assez sophistiqué.

Les campagnes publicitaires vous permettent de tirer pleinement parti de votre buyer persona développé pour votre MVP au cours des premières phases. Les campagnes publicitaires vous permettent de cibler votre MVP sur des parties spécifiques du public que vous souhaitez engager. Vous pouvez cibler vos publicités en fonction du sexe, de la région, de la tranche d'âge et même des intérêts de vos cibles.

En outre, une campagne publicitaire vous permet de réaliser des tests A/B sur votre MVP. Vous pouvez lancer différentes campagnes publicitaires pour différents publics cibles. Vous pouvez également choisir de développer une publicité qui met en avant divers éléments du MVP afin de déterminer ce qui plaît le plus à votre public cible.

4. Les MVPs manuels d'abord

Une autre approche de test de MVP fonctionnel consiste à créer un MVP manuel (également connu sous le nom de Magicien d'Oz) qui semble être entièrement fonctionnel. Vous livrez le produit/service manuellement lorsque le client l'achète. L'utilisateur reçoit exactement ce qu'il veut et croit recevoir, tandis que l'effort réel se fait en coulisse.

L'aspect le plus important des MVP manuels est qu'ils vous permettent de tester votre MVP à plusieurs niveaux avec un peu d'investissement. En outre, vous pouvez vérifier si votre MVP valide les idées préconçues que vous pouvez avoir à son sujet et si votre produit peut ou non répondre aux problèmes des consommateurs.

ZeroCater est un exemple d'un test MVP de type Manual-first. Arram Sabeti (fondateur de ZeroCater), l'entrepreneur qui a commencé avec une grande feuille de calcul pour suivre les entreprises et les traiteurs avec lesquels il pouvait interagir, a lancé son entreprise en créant une liste de contacts.

Zappos a commencé de la même manière. Pour déterminer la demande de magasins sur Internet, Nick Swinmurn, le créateur de Zappos, a mis en ligne des photos de commerces locaux sur un site Web. Nick retournait au magasin lorsque quelqu'un passait une commande de chaussures sur Internet, allait les chercher et les livrait.

C'était un moyen pour lui de déterminer s'il existait une demande pour l'achat de chaussures en ligne avant d'investir dans l'infrastructure et les stocks. Il n'est pas surprenant que Zappos ait connu un tel succès qu'Amazon l'a racheté pour $1,2 milliard d'euros en 2009.

5. Des MVPs au coup par coup

Les MVP fragmentaires - une combinaison du Magicien d'Oz et des tactiques de conciergerie - sont le processus de développement d'une démo pour votre produit en utilisant les outils existants. Plutôt que d'essayer de créer une application de A à Z, utilisez les plates-formes et services existants pour réaliser un MVP.

L'exemple le plus notable d'un MVP fragmentaire est celui de Groupon. La première version de Groupon a été développée sur WordPress, Apple Mail et un AppleScript qui générait manuellement des PDF à mesure que les commandes étaient reçues sur le site. Par conséquent, le temps et l'argent nécessaires à la création d'un MVP se sont avérés moins importants que prévu.

6. Prototypage numérique

Les prototypes numériques sont une excellente méthode pour examiner votre MVP. Vous pouvez démontrer comment votre produit fonctionnera dans des situations réelles en générant des maquettes, des wireframes et des prototypes. Vous pouvez les utiliser pour illustrer l'attrait du produit pour les consommateurs potentiels et vérifier l'expérience utilisateur.

Les nombreux prototypes numériques vont des simples aperçus de captures d'écran et des croquis de basse fidélité aux applications factices qui tentent de reproduire l'expérience utilisateur. À cette fin, vous pouvez utiliser des outils tels que Figma, InvisionApp et MarvelApp.

7. MVPs à fonction unique

Il est parfois plus efficace de se concentrer sur une seule fonctionnalité pendant les tests MVP que sur plusieurs. Cela peut aider à Processus de développement MVP vitesse et vous aider à restreindre votre clientèle.

De plus, les clients sont plus susceptibles de consacrer leur temps à un MVP à fonctionnalité unique, car cela leur permet de se concentrer uniquement sur l'objectif principal du produit. C'est pourquoi la fonctionnalité unique est l'une des méthodes les plus efficaces pour tester un MVP.

Foursquare a fait de même pour ses MVPs. Au lieu d'inonder les utilisateurs de nombreuses fonctionnalités, ils ont commencé par leur permettre de s'enregistrer sur le réseau social en fonction de leur position.

Quelques autres techniques de test MVP à essayer

Les approches décrites ci-dessus font partie des meilleures techniques de test MVP. Cependant, il existe d'autres méthodes de test MVP que vous pouvez essayer :

• Examinez les produits de vos concurrents pour découvrir les caractéristiques qui manquent à votre MVP et comment vous pouvez vous démarquer.
• Pour évaluer votre MVP, utilisez des outils tels que OpenHallway, QuickMVP et Five-second test.
• Lancez une campagne PPC pour évaluer les progrès de vos MVPs et l'intérêt des utilisateurs.
• Pour dialoguer avec votre public et évaluer sa réaction, utilisez des plateformes SaaS et PaaS pour interagir avec lui.
• Créez un prototype papier de votre MVP pour mieux comprendre l'expérience utilisateur. C'est bénéfique pour les biens physiques, comme les téléphones portables.

Sortir par la porte

Dans certains cas, le développement d'un MVP ajoute à la charge de travail car il implique un investissement important en temps et en efforts. Lors de la création de MVP, il est essentiel de ne pas se laisser entraîner par des détails sans importance et des frais généraux.

L'objectif est de déterminer si le temps et les efforts que vous investissez en valent la peine après un certain temps, et vous ne voulez pas perdre votre temps sur quelque chose que les utilisateurs ne trouveront pas utile ou ne paieront pas. Il est également essentiel de noter que lorsque vous testez vos hypothèses, vous pouvez utiliser diverses approches de test MVP.

Celle qui est la plus adaptée à la stratégie de votre entreprise et au marché variera sans aucun doute. Ce qu'il faut retenir, c'est que vous devez vous lancer et le créer. Réfléchissez à l'hypothèse la plus importante de votre produit et créez un bon produit minimum viable (MVP) qui le teste sur le marché. 

FAQs

Pourquoi les tests MVP sont-ils nécessaires ?

Les tests MVP vous permettent de tester la viabilité de votre concept commercial et d'établir son potentiel commercial avant de le mettre en œuvre. Si vous procédez ainsi, vous économiserez du temps et des ressources pour trouver la mauvaise solution.

Comment puis-je savoir si mon MVP est un succès ?

Vous pouvez évaluer le succès de votre MVP tout au long du processus d'essai du produit en suivant plusieurs éléments Indicateurs de succès MVPy compris :

• Le nombre total de personnes qui se sont inscrites
• Le nombre de personnes qui ont commandé votre produit avant qu'il ne soit disponible.
• Coût d'acquisition des clients
• Le revenu moyen par utilisateur
• Nombre d'utilisateurs actifs sur vos articles de blog MVP
• Part de marché
• Réactions positives des utilisateurs au cours de l'entretien
• Le montant collecté dans le cadre d'initiatives de crowdfunding

Les tests MVP vous permettent de tester la viabilité de votre concept commercial et d'établir son potentiel commercial avant de le mettre en œuvre. Si vous procédez ainsi, vous économiserez du temps et des ressources pour trouver la mauvaise solution.

Que faire si mon MVP échoue pendant les tests ?

Même si votre MVP n'est pas un succès, vous pourrez recueillir suffisamment d'avis de clients pour vous aider à le transformer en quelque chose que le marché désire. Vous pourrez utiliser les données recueillies pour modifier votre point de vue et lancer un meilleur produit commercial.

Quelles sont les erreurs les plus courantes à éviter en matière de MVP ?

• Ne pas réaliser d'études de marché
• Choisir la mauvaise équipe de développement
• Sauter le processus de validation et de test du MVP
• Utiliser le mauvais public pour tester votre MVP
• Ne pas tenir compte des statistiques et des commentaires des utilisateurs

The post 7 Time-Tested Strategies For An MVP Test appeared first on Startup Oasis.