Construire un MVP et lancer un produit est en fait la partie facile. Il est beaucoup plus difficile de gérer un produit à son stade de maturité ou de déclin, donc je voulais relever les défis d’un produit qui a dépassé son stade de croissance initial et partager quelques conseils sur:
– Comment éviter de devenir une fabrique de fonctionnalités, tout en apprivoisant votre bête d’un backlog
– Comment utiliser votre feuille de route pour stimuler l’expérimentation et atteindre les objectifs de l’entreprise
– Comment vous perturber avant que quelqu’un d’autre ne le fasse
Le cycle de vie du produit
Nous connaissons tous le graphique du cycle de vie du produit. Alors que beaucoup d’entre nous connaissent la bataille difficile et les efforts nécessaires pour obtenir la traction et toute croissance vers l’adéquation produit / marché, les phases de lancement et de croissance représentent une petite fraction de la durée de vie globale d’un produit.
Le MVP et les itérations et pivots rapides initiaux dont nous parlons habituellement? Cela se produit généralement au tout début. Mais en réalité, ce n’est pas là que la plupart des chefs de produit passent leur temps. La plupart des chefs de produit ont adopté un produit existant plus proche de la fin de maturité du graphique; celui qui a un tas de clients et de contraintes existants, une bonne partie de la dette technologique, et invariablement un arriéré désordonné de fonctionnalités et de bugs qu’ils ne pourront jamais entièrement traiter.
Mais si vous regardez le volume des ventes, c’est à ce stade de maturité où la plupart de l’argent est gagné. Et c’est à ce stade où le taux de désabonnement commence vraiment à faire mal. Après tout, il est facile de cacher un taux de désabonnement laid lorsque vous accélérez une croissance rapide, mais c’est un fait mathématique que tout taux de désabonnement supérieur à 0, lorsque vous commencez à saturer le marché, finira par aplatir cette courbe. C’est lorsque votre produit est arrivé à maturité que le barattage commence vraiment à mordre.
Et pourtant, si vous regardez ce que vous lisez habituellement Moyen et d’autres publications adaptées aux startups, vous en apprendrez principalement sur le lancement de produits et l’optimisation de la croissance. Personne ne semble écrire sur la gestion des produits qui arrivent à maturité, ou à Dieu ne plaise, les étapes de déclin.
C’est dommage, car c’est exactement à ces étapes où les choses commencent à vraiment difficile.
La réalité est que si vous voulez que les gens utilisent votre produit à long terme, votre produit devra évoluer avec eux.
Chaque jour que votre produit existe, les personnes qui l’utilisent changent et progressent. Ils s’habituent à son fonctionnement et l’intègrent à leurs processus. Ils s’améliorent à l’utiliser et développent des besoins pour une utilisation plus avancée.
Et chaque jour, de nouvelles personnes entrent dans votre monde en tant que nouveaux utilisateurs. C’est formidable pour la croissance, mais ils représentent un type d’utilisateur complètement différent.
Lorsque nous avons lancé ProdPad pour la première fois, nos utilisateurs étaient simples: des adopteurs précoces désireux d’essayer un nouveau produit et ravis de subir les tests bêta. Ils ont donné une rétroaction prolifique et établi des relations avec notre équipe. Heureusement, certains de ces utilisateurs sont toujours avec nous aujourd’hui, mais leurs besoins ont complètement changé. Ces jours-ci, ils montrent fièrement des exemples de la façon dont ils ont construit leurs processus autour de notre outil, sont capables d’enseigner aux autres (et à nous!) Comment l’utiliser. Ils demandent régulièrement un ensemble de fonctionnalités de plus en plus complexes pour répondre à leurs besoins évolutifs. Ce sont les mêmes personnes qu’elles étaient il y a plusieurs années, mais elles représentent maintenant des personnages différents.
Et pourtant, de nouveaux utilisateurs se joignent chaque jour. Ce sont des gens qui n’ont jamais essayé le produit auparavant et qui ne connaissent pas leur chemin. Et contrairement aux premiers adoptants, ils sortent de la porte avec des attentes plus élevées que les gens que nous avons rencontrés il y a des années.
C’est comme devoir construire deux produits différents en même temps.
Au stade de la croissance, votre équipe se concentre sur l’adéquation produit / marché. Il s’agit de réussir ces gains rapides et d’augmenter le facteur wow. Tout ce qu’il faut pour obtenir une traction et prouver que votre produit a une place dans le monde.
Au stade de la maturité, vous avez des utilisateurs existants et nouveaux à construire, des contraintes et une complexité technique intégrées, des politiques et des personnes à contourner.
La maturité pose problème
Problème: vous êtes une fabrique de fonctionnalités
Si vous êtes une entreprise qui arrive à maturité, vous pourriez constater que vous êtes devenu usine de fonctionnalités. Cela découle souvent d’anciennes habitudes qui étaient autrefois bonnes, mais qui sont maintenant malavisées. Au début, chaque nouvelle fonctionnalité a généré plus de téléchargements, d’inscriptions et de ventes et vous a propulsé au-delà de la concurrence. Vous étiez hyper agile et avez poussé le code et les nouvelles fonctionnalités chaque semaine, sinon quotidiennement! Vous avez dépassé vos concurrents et savez vous déplacer rapidement.
Mais dans les étapes ultérieures, l’objectif n’est pas seulement de proposer des fonctionnalités! En fait, chaque nouvelle fonctionnalité vous alourdit, résultant en un Frankenstein d’un produit. Vos vieilles habitudes agiles vous ont égaré.
C’est pourquoi il est si important de penser des objectifs, pas des caractéristiques! Pour survivre, vous devrez vous concentrer de nouveau sur l’atteinte des objectifs de l’entreprise et la résolution de problèmes réels, au lieu de simplement proposer des fonctionnalités. En soi, les équipes le comprennent. Ils savent qu’un tas de fonctionnalités n’est pas ce que veulent leurs clients ou ce dont leur entreprise a besoin. Et pourtant, c’est un schéma qui se répète encore et encore.
Je blâme la feuille de route. Les feuilles de route ne sont pas intrinsèquement mauvaises… en fait, elles peuvent être un outil remarquablement efficace pour communiquer la stratégie produit! Et pourtant, une feuille de route mal faite peut ouvrir la voie à une mort de produit remplie de fonctionnalités.
Alors je vous implore tous de faire ça avec moi: Abandonnez votre feuille de route chronologique.
Bien sûr, ce format de la feuille de route vous fait bien paraître aujourd’hui… Votre planche et votre patron adorent voir ce niveau de certitude cloué au mur. mais cela vous prépare à l’échec.
Voir, le problème avec une feuille de route typique est qu’elle s’oppose Temps contre. Choses à faire, avec Temps représenté sur l’axe des x, créant cette chronologie en haut. Tout va bien au début, surtout lorsque vous représentez vos projets à court terme et vos prochaines versions, où votre équipe a donné des estimations décentes et est d’accord avec les dates de sortie données. Mais plus vous ajoutez à la feuille de route et plus vous descendez, plus il devient difficile à gérer.
Bientôt, vous vous retrouvez avec une pile de fonctionnalités, chacune avec des durées et des dates d’échéance données, impliquées simplement par la disposition même de la feuille de route, avec cette chronologie, marchant toujours en avant le long du sommet. Et nous savons tous que ces projets ne sont pas des estimations précises à portée fixe. Ces estimations et dates d’échéance découlent d’hypothèses empilées en plus des hypothèses.
Hypothèse n ° 1
Vous supposez que vous savez combien de temps chacune de ces fonctionnalités va prendre. Ce jeu est facile à court terme, lorsque vous avez une compréhension claire de ce que les développeurs de votre équipe peuvent entreprendre et qu’ils vous ont aidé à élaborer vos estimations, mais plus vous allez loin, moins vous allez pour être sûr.
Hypothèse n ° 2
Vous supposez que rien d’autre ne va venir perturber cette chronologie. Pas de changements sur le marché, pas de nouveaux concurrents, pas de nouvelles idées venant des clients, pas besoin d’itération.
Hypothèse n ° 3
Vous supposez que chacune de ces fonctionnalités fonctionnera dès leur lancement. Vous avez accordé trois semaines pour créer cette page de paiement? Ensuite, au bout de trois semaines, la conversion sera exactement aussi bonne que prévu, et maintenant vous êtes libre de passer à la chose suivante.
Hypothèse n ° 4
Vous supposez que chacune de ces fonctionnalités mérite réellement d’exister! Qu’elles font partie de la stratégie et devraient donc être codifiées.
Dans l’ensemble, vous faites une hypothèse importante et dangereuse: Que rien ne va changer. Qu’est ce qui pourrait aller mal?
Cette pile d’hypothèses pourrait vous conduire vers un tas de moments malheureux. Les dates de sortie inventées finissent par vous envoyer, vous et vos développeurs, des marches de la mort, essayant de respecter la date limite. Votre équipe commerciale et vos clients ont fixé des attentes sur ce qui va être livré et quand, alors que vous manquez des opportunités de marché et peut-être même construisez entièrement les mauvaises choses. Tout cela fait de tristes chefs de produit.
Alors, y a-t-il une meilleure façon?
3 étapes pour abandonner votre feuille de route chronologique et sortir de la fabrique de fonctionnalités
Étape 1: définissez votre vision du produit
Étape 2: définissez vos objectifs. Ce sont des objectifs basés sur les résultats qui sont liés à la stratégie de votre entreprise. Vous les connaissez peut-être en tant que KPI ou OKR, ou simplement en tant qu’objectifs. Peu importe comment vous les appelez – ce qui fonctionne le mieux pour vous et votre équipe. Vos objectifs agissent comme des garde-corps pour que tout le monde pointe dans la même direction et travaille sur les bonnes choses.
Étape 3: Modifiez votre chronologie pour les horizons temporels. C’est subtil, mais au lieu d’une seule ligne qui avance, pensez en termes de ces trois seaux:
La future colonne porte moins sur des initiatives spécifiques, mais plutôt sur les problèmes qui, selon vous, doivent être résolus afin de réaliser votre vision, mais doivent encore être validés.
Et c’est la clé: votre feuille de route est à valider. Votre feuille de route est un prototype de votre stratégie.
Tout comme vous pouvez valider une fonctionnalité en élaborant des prototypes papier et en les montrant à vos clients, puis en recommençant en fonction des commentaires, votre feuille de route est un point de départ pour des conversations sur ce qui doit être inclus dans votre stratégie.
Résultat: Lean Product Roadmap
En réunissant ces trois éléments – votre vision, vos objectifs et vos horizons temporels – vous pouvez construire une feuille de route Lean.
La valeur de ce format de feuille de route est qu’il détourne l’attention des fonctionnalités de construction et des dates de livraison, et aide votre équipe à s’efforcer de résoudre les problèmes.
Problème: votre backlog est une bête
Rien n’empêche l’innovation comme une liste de choses à faire aussi longtemps que votre bras. Et pourtant, c’est un état dans lequel tant d’équipes sont coincées. Dans leur tableau Trello ou leur mur JIRA, ils peuvent travailler à travers une poignée de billets à la fois, et pourtant il y a toujours une colonne de billets massive, gonflée et provoquant des vertiges qui sont alignés pour faire ensuite.
Cela met l’accent sur l’équipe de développement qui regarde dans le baril d’un million de tâches à venir, dont beaucoup ne sont même pas correctement définies, et cela fait peur à l’équipe non technique qui se demande simplement pourquoi aucune de leurs idées ne semble jamais voir la lumière du jour.
La solution est remarquablement simple. Divisez le backlog en deux parties: le backlog de produit et le backlog de développement.
C’est là que beaucoup de gens se perdent, car «arriéré» est un terme large. Voici ce que je veux dire par chacun:
Carnet de développement: Une petite liste de spécifications autonomes et estimées, qui sont approuvées pour le développement, hiérarchisées et prêtes pour le prochain développeur disponible.
Carnet de produit: Une liste de toutes les choses que vous pourrait faire. Vous ne terminerez jamais tout sur cette liste et elle sera toujours dans un état constant de flux. Il comprendra les demandes des clients, les suggestions de votre équipe, jusqu’aux informations provenant de vos expériences et prototypes. Il doit être accessible par votre équipe, à la fois pour contribuer et suivre les progrès – votre équipe devrait aider à construire et à étoffer les idées de votre carnet de commandes. C’est votre espace pour prototyper et spécifier des idées, les mettre en correspondance avec vos objectifs et suivre leur progression jusqu’à ce qu’ils soient prêts pour la production.
Un backlog de développement soigné est crucial pour une exécution solide, tandis qu’un backlog de produit transparent est la clé de votre stratégie. Divisez votre carnet de commandes en ces deux parties pour éviter d’avoir une bête de somme et de ne pas tirer le meilleur parti de l’un ou l’autre monde.
Problème: l’expérimentation vous fait peur
Nous connaissons tous le cycle Build-Measure-Learn. Cela semble simple; il est Facile. C’est-à-dire, jusqu’à ce que vous ayez la concurrence sur vos talons, une base croissante de clients demandant de plus en plus, la dette technologique se glissant à la périphérie. Votre entreprise entre en mode panique, essayant de pelleter des fonctionnalités et de réparer la porte, et néglige de se concentrer sur autre chose que la partie Build.
Ils oublient les deux autres parties du flux: mesurer et apprendre!
Et donc au lieu de Build-Measure-Learn, cela devient Build-Build-Build, également connu sous le nom de Build Trap.
Il est important de lutter contre cette envie de construire en permanence, d’autant plus que le produit mûrit. L’élément clé qui manque souvent est simplement de créer le temps et l’espace pour valider le travail en cours. Ce n’est pas que les membres de l’équipe ne comprennent pas qu’il est important de s’assurer que les bonnes mesures se déplacent, c’est qu’elles n’ont souvent pas la permission et le temps d’arrêter de construire, et en fait faire les mesures.
Une façon solide de procéder consiste à adopter une forme de agile double piste. Il y a beaucoup de façons d’interpréter l’agile dual track, mais l’essentiel est que vous donniez une idée quoi construire autant d’importance que le processus de construction lui-même. Vous commencez par une piste de découverte pour savoir si une idée de produit est bonne et si elle a du sens à construire. Les résultats réussis de la piste de découverte sont ajoutés à l’arriéré de la piste de livraison.
Avoir une approche à deux voies vous donne la permission de passer du temps à découvrir, au lieu de ressentir la pression de livrer constamment. Bien fait, cela vous donne le meilleur combo de vitesse et d’apprentissage.
Ne jetez pas votre feuille de route!
Je vois une mauvaise habitude tout le temps: vous avez sorti quelque chose, alors vous fermez tous les billets dans JIRA, froissez toutes les notes autocollantes sur le mur et commencez à passer à la chose suivante. Cela peut sembler bon pour maintenir la cadence, mais mauvais pour vous assurer que vous avez un impact.
Après tout, ce n’est pas parce que quelque chose a été lancé que cela a résolu le problème que vous vouliez!
Heureusement, votre feuille de route peut vous donner cet espace. Comme je l’ai montré précédemment, chaque carte est un problème à résoudre et est liée à un objectif.
Chaque carte, à son tour, sera connectée à une liste d’expériences qui pourraient être exécutées afin de résoudre ce problème et d’avoir un impact sur cet objectif.
Vous pouvez utiliser votre feuille de route pour vous donner un aperçu des progrès des expériences en cours. Et une fois qu’un projet est en cours de développement, ne vous contentez pas de jeter ces résultats ou de les ranger quelque part où vous ne les retrouverez plus…
Au lieu de cela, déplacez-les vers une liste de cartes terminées.
Le but est de vous donner un espace pour suivre ce qui a été publié et quand, puis décrire les résultats. Cela a-t-il résolu le problème et déplacé la métrique que vous espériez?
En faisant de la section Terminé de la feuille de route une partie de votre processus, il fournit un espace pour montrer la valeur du travail effectué.
Vous ne savez rien.
Il est utile de se rappeler que ce n’est pas votre travail d’avoir toutes les réponses. Vous êtes censé en savoir moins que vos collègues. Au lieu de cela, concentrez-vous sur le fait de poser les meilleures questions et de créer un espace sûr pour que chacun puisse y contribuer.
Il est important pour une équipe, à n’importe quelle étape du cycle de vie du produit, d’avoir une sécurité psychologique. Il s’agit de rendre les gens plus à l’aise pour parler,
signaler les erreurs et participer au produit.
Vous pouvez aider à créer cette sécurité au sein de votre propre équipe avec quelques ajustements à votre langue, ce qui vous aidera à créer le bon environnement:
Comment pourrions-nous? Formulez les questions pour qu’elles commencent par «Comment pourrions-nous…». Cela transforme la question en problème collectif; il suppose au lieu de affirme. Et cela fonctionne très bien avec:
Je parie… En tant que chef de produit, vous allez souvent vous tromper. “Je parie” vous donne la permission d’échouer et de réessayer. Après tout, ce n’était pas vous c’était faux
– c’était votre hypothèse. Et maintenant que vous savez ce qui ne fonctionne pas, vous êtes libre de tester le prochain pari.
C’est subtil, mais ces ajustements en cours et ces changements de langage ouvrent la voie à la sécurité psychologique, vous permettant de renforcer la confiance dans les expériences que vous menez.
Problème: vous êtes sur le point d’être perturbé
Si vous avez été si tenace et si chanceux de vous retrouver avec un produit mature qui rapporte de l’argent, vous pouvez être sûr que vous avez des startups au pied de la flotte à vos trousses.
La plupart des entreprises démarrent à l’extrémité de cette échelle, où elles sont incroyablement agiles. Ils n’ont pas encore de clients, il n’y a pas de dette technologique ou d’autres obstacles à une itération rapide. Les fondateurs ont lu Démarrage Lean et sont prêts à l’utiliser avec colère.
À l’opposé de cette échelle, vous avez vos géants. Des organisations lentes et peu enclines à prendre des risques qui sont fixées par des réglementations et des obligations gouvernementales envers leur vaste bassin de parties prenantes. Lents ou non, ces organisations n’ont souvent pas d’incitation immédiate à devenir plus agiles. Ces réglementations sont un obstacle à l’entrée pour d’autres sociétés, et la valeur qu’elles ajoutent à leurs actionnaires existants se traduit par d’énormes tas de liquidités. C’est agréable d’être au sommet.
Mais le domaine concurrentiel est en constante évolution. Les nouveaux arrivants sont toujours en train de ronger les bords, profitant des failles et des nouvelles technologies pour capturer les petits parcs du marché massif. Les entreprises plus grandes et plus lentes doivent être à l’affût, sinon ces nouveaux produits rendront finalement leur portefeuille mature obsolète.
Le passage d’agile à lent est à peu près inévitable pour tout produit arrivant à maturité, mais les entreprises les plus performantes ont trouvé des moyens de concurrencer ces nouveaux arrivants.
Ils doivent se perturber avant que quelqu’un d’autre ne le fasse.
J’ai proposé quatre modèles pour ce faire:
Google: Google est célèbre pour son temps de 20%. Cela donne au personnel l’équivalent d’une journée par semaine pour travailler ce qu’il veut. Cela peut sembler un gaspillage de ressources, mais certains de ses principaux produits, comme Gmail et Maps, en sont sortis. Maintenant, 20% pourrait être trop pour beaucoup d’entreprises. Vous pouvez peut-être essayer de ne faire que 2%, voire 0,2%, et voir ce qui en ressort.
Le Hackathon: Le Hackathon est tout aussi bon pour la construction de produits perturbateurs que pour le team building. Donnez à votre équipe une semaine de liberté dans le temps pour assembler un produit simple. Cela pourrait très bien être le début d’une nouvelle activité rentable!
Le labo: Le Lab est une approche utilisée par de nombreuses grandes entreprises, essayant généralement de passer par une «transformation numérique». Le laboratoire est une petite division d’une grande entreprise qui ressemble et agit comme une start-up, mais bénéficie du soutien de la société mère pour alimenter la croissance de tout prototype qui montre de l’intérêt.
Le Facebook: Facebook possède l’une des plus grandes bases d’utilisateurs au monde. Mais cela ne révèle jamais quelque chose à tout le monde en même temps. En fait, il peut segmenter ses utilisateurs en petits groupes et tester et publier de nouvelles fonctionnalités à un seul groupe à la fois. Cela supprime le risque de lancer quelque chose à tout le monde et lui permet d’expérimenter plus facilement en conséquence.
Ce sont toutes des tactiques qui peuvent aider votre entreprise à perturber votre propre produit arrivant à maturité avant qu’il n’entre dans la phase de déclin.
Votre objectif est de donner un nouveau souffle à votre produit en cours de maturation, en ajoutant plus de valeur ou en élargissant votre marché.
Si cela est fait correctement, vous pouvez prolonger la durée de vie de votre produit et augmenter encore vos revenus.
Battez l’usine de fonctionnalités en abandonnant votre feuille de route chronologique et concentrez-vous sur la résolution de problèmes réels. Conquérir cette bête d’un carnet de commandes en séparant la stratégie de la livraison et en excellant dans les deux. Apprenez à aimer expérimenter à nouveau en construisant dans l’espace et en autorisant la validation. Et remodelez votre entreprise afin de pouvoir vous perturber avant tout le monde.
Et c’est comment vous pouvez grandir Lean et rester agile même lorsque vous atteignez la maturité.
