Salut salut 😃
Très heureux de te retrouver pendant ce loooong week-end.
Tout va bien pour moi, je t’ai écrit cette newsletter de ma table de salle à manger d’où j’aime beaucoup bosser.
Aujourd’hui on va parler de l’importance des enjeux business pour le Product Manager.
Business et Product Management
Un Product Manager, ça pense à l’argent ?
Pour répondre à cette question, revenons d’abord à la définition d’un Product Manager.
J’aime bien le définir par l’intersection de ces 3 cercles :
En gros, le rôle d’un Product Manager, c’est d’échanger avec trois types d’interlocuteur :
→ Les UX Designers pour identifier les bons problèmes, et définir les interfaces pour les résoudre.
→ Les interlocuteurs Tech (développeurs, architectes) pour assurer que le produit résolve le produit avec des performances techniques suffisantes.
et…
→ Le Business !
C’est donc de là que ça vient. Mais c’est quoi précisément le “Business” ?
En quelques motes : s'assurer qu'on construise un produit rentable. On veut “faire de l'argent”, que le produit ait été développé avec un bon sens “business”.
Si on détaille un petit peu, les compétences Business :
te permettent d’avoir de l’argent qui rentre, pour compenser l’argent qui sort
te permettent d’avoir un produit légal, compliant et autorisé
Le point 2 paraît anecdotique mais rappelez-vous il y a quelques années, on a cru qu’Uber allait être banni dans les capitales européennes. Le rôle du Business, c’est d’empêcher ça. Car la plus belle UX du monde et une Tech géniale ne sauveront pas ton produit s’il est interdit.
Ça serait pas un peu plus compliqué ?
Oui je le pense. En fait il faudrait plutôt avoir un schéma de ce genre :
Donc concrètement, pour s’assurer que le produit soit viable financièrement, on a besoin :
→ Des sales : le monde de la vente, de ceux qui vont pitcher et vendre le produit sur le terrain.
→ Du marketing : le monde du branding et de la comm', pour que ton produit trouve son audience.
→ Du growth : le monde des hacks pour toujours identifier de nouveaux leviers de croissance.
→ Du juridique : le monde du droit pour éviter tout risque juridique et légal à notre produit.
→ De la finance : le monde de l'argent pour trouver le bon équilibre financier et le bon business model.
C’est plus clair, on comprend mieux les termes du sujet (c’est un bon début 😅).
Pourquoi est-ce important ?
Raison 1 : le besoin d'être rentable
Construire des produits informatiques, c’est grisant. Les humains sont des constructeurs ! On adore voir des choses sortir de terre, passer de 0 à 1, créer quelque chose là où il n’y avait rien.
J’en ai d’ailleurs parlé dans l’épisode #5 de Easy Tech.
Mais attention :
→ Construire pour construire, ça ne remplit pas la tirelire.
→ Construire pour construire, ça ne permet pas d’équilibrer ses comptes.
À un moment à un autre donc, si tu dépenses sans compter, tu devras rendre des comptes à quelqu’un.
Suivre ces enjeux business, et notamment ton équilibre financier, te permet d’éviter ce genre de mésaventure.
Raison 2 : le besoin d'efficacité à court terme
Avoir en tête le besoin de “faire du cash” aide souvent à prendre de bonnes décisions au début de la vie de ton produit.
C’est dans cette phase qu’on est le plus à risque d’un point de vue financier :
→ Tu ne peux pas savoir avec certitude si ton produit va intéresser son public et rencontrer son marché
→ Tu ne peux pas savoir avec certitude si tu vas réussir à construire un produit d’une qualité suffisante
C’est pour ça qu’être vigilant sur ces aspects est très bénéfique :
→ tu es incité à te confronter vite à ton marché pour réduire ces éléments d’incertitude
→ tu vas apporter vite de la valeur à l’utilisateur pour le faire payer vite
On va détailler tout ça ensuite, dans les phases de Discovery et Delivery.
Raison 3 : de meilleures décisions long terme
À plus long terme, c’est aussi nécessaire d’avoir ces enjeux financiers en tête. Ça ne veut pas dire être comme Picsou, obsédés par le fait de gagner de l’argent.
Ça veut dire orienter intelligemment ses décisions pour un équilibre financier à long terme :
→ Au niveau de l’utilisateur : viser une relation long terme, “ne pas trop presser le citron”, faire que les gens viennent mais surtout faire qu’ils restent. Ça rend les revenus plus prédictifs et ça sécurise la viabilité
→ Au niveau technique : le système doit être construit pour continuer à être performant dans le temps long. Ça veut donc dire éviter de générer trop de dette technique ! Car une dette technique se transforme très vite en dette financière
Bon, j’espère t’avoir convaincu à ce stade que (malheureusement ou heureusement) on construit des outils pour gagner de l’argent, d’une manière ou d’une autre.
Du coup tu dois te dire “OK il est bien sympa, mais comment je fais en vrai ?”.
On y vient 😃
(petite pause pour te dire que si ça te plaît, n’hésite pas à partager la newsletter 🙏)
Comment faire concrètement ?
Bonne pratique générale : mettre le business dans la boucle
Il faut s’assurer que les profils business (sales, growth, juridique, marketing, finance etc…) soient inclus dans les différents échanges. Le pire qu’on puisse faire ? Aller les voir a posteriori, quand on a fini tout le travail, que le produit est développé.
Échanger avec eux tout du long est bien plus efficace pour ces 3 raisons :
→ 1 : on peut ajuster beaucoup plus vite. S’il y a un problème juridique, mieux vaut le détecter le plus tôt possible. Et les experts légaux seront bien plus efficaces que nous pour repérer ces choses.
→ 2 : bosser ensemble fait monter le business en compétences. À la fin, n’oublie pas que ta capacité à vendre ton produit à toujours plus de monde… ne dépend pas de toi. Les sales vont vendre ton produit. Plus ils sont forts, mieux ça se passera.
→ 3 : ensemble, on génère des idées plus pertinentes. Différents points de vue entraînent plus d’intelligence collective. Plus facile de penser “out of the box”. Et moins de biais. C’est donc important de mettre tout le monde autour de la table.
Plus précisément, on va voir comment ça se matérialise sur les différentes phases de la vie du produit :
En phase de framing / cadrage,
Il faut dès cette phase se poser la question de comment on va équilibrer les charges - dépenses et les ressources - rentrées d’argent.
Attention, ça ne veut pas dire qu’on ne peut pas avoir des modèles économiques à la Uber ou Facebook, qui sont des boîtes qui ont hyper bien fonctionné en attendant des années avant d’être rentables. (D’ailleurs pas sûr qu’Uber le soit aujourd’hui 🤔)
Ça veut dire qu’a minima, il faut se poser la question de comment on va gagner de l’argent à un moment. Quitte à se dire “on vendra de la pub quand on aura beaucoup grossi dans 15 ans”.
Je te conseille d’utiliser un framework comme le Lean Canvas. Il comporte bien ces deux éléments en bas (cost structure / revenue streams). Ça force à se poser de bonnes questions :
En discovery
La phase de discovery est probablement celle qui est le plus intense en termes d’échange avec les utilisateurs.
Pour résumer on va travailler sur 2 aspects principaux :
→ 1- Identifier le bon problème : (a) avec une première phase divergente, où on va essayer de lister tous les problèmes possibles et imaginables ; (b) avec une seconde phase convergente, où on va essayer de se focaliser sur le problème le plus pertinent
→ 2- Identifier la bonne solution : (a) avec une première phase divergente, où on va essayer de lister toutes les solutions possibles et imaginables ; (b) avec une seconde phase convergente, où on va essayer de se focaliser sur la meilleure piste de solution
(oui ça se ressemble et c’est symétrique ! C’est normal 😃)
Au cours de cette phase, l’argent ne doit pas être un sujet tabou ! Inclus des questions sur le sujet avec tes utilisateurs. Parler argent permet de valider deux choses :
→ Que le problème identifié est réel, pénible, récurrent etc… Si tes utilisateurs se disent prêts à payer pour que quelqu’un résolve ce problème, alors ça veut probablement dire qu’on tient quelque chose.
→ Que la solution identifiée a le bon niveau de qualité / finition. Si tes utilisateurs te regardent avec des grands yeux 🤯 lorsque tu présentes le prix que tu avais en tête, c’est probablement qu’il faut que tu le descendes un petit peu.
En delivery
Qui dit delivery dit méfiance. On rentre dans le dur, on écrit des lignes de code, on construit le logiciel à proprement parler.
Changer des choses au stade du cadrage ou de la discovery, c’est assez facile et peu coûteux. En revanche au stade de la delivery, ça devient beaucoup plus coûteux. J’avais un peu parlé de la complexité inhérente à la technique dans l’édition #2 de Easy Tech.
Niveau argent, ça veut dire qu’au cours de cette étape, il faut essayer de monétiser le plus vite possible. Il y a différentes écoles sur le sujet :
→ Certains suggèrent de toujours faire payer les utilisateurs. À partir du moment où ils utilisent, ils payent.
→ D’autres préfèrent travailler avec des partenaires privilégiés au démarrage, avec lesquels ils co-construisent, sans se faire payer.
→ Enfin, il existe des modèles hybrides “freemium” où on va donner accès à des fonctionnalités basiques gratuitement, et où on va demander de payer pour des fonctionnalités plus avancées.
Quelque soit la piste que tu choisis, tu dois t’assurer d’avoir de l’argent de tes utilisateurs qui rentre très rapidement dans cette phase.
On a vu en Discovery que le fait de bien vouloir payer était directement lié au fait qu’on résolvait un problème.
En Delivery c’est exactement le même enjeu : si l’utilisateur est prêt à payer, ton produit fait le job.
En growth
Lors de cette phase, tu as un produit bien fait, mature au niveau technique. Ce produit a rencontré son marché et ça décolle ! Tu peux mettre les gaz.
À cette étape, tu devrais tendre vers une stabilisation de ton modèle économique et vers un équilibrage dépense / recette à court ou moyen terme.
Pourtant, ne t’interdis pas de faire pivoter la manière que tu as de gagner de l’argent. Par contre, ⚠️ ne pivote pas trop brusquement :
→ N’augmente pas tes prix d’un coup sans prévenir (on a vu l’exemple avec Bubble récemment qui a été pas mal critiqué dans la communauté no code)
→ Évite de changer les fondamentaux de ton modèle économique (par exemple passer de freemium à full payant ; ou d’un abonnement mensuel à un payement à l’usage)
Conclusion
📝 Le contenu de la semaine : ce super post sur la user research de Caroline Berger sur les différentes manières de faire de la recherche utilisateur (spoiler : non faire de la recherche n’équivaut pas uniquement à faire des entretiens 😅)
📰 L'actu de la semaine : j’organise un live (encore un 😂) avec Pierre Criulanscy, un super développeur hyper fort sur les enjeux d’architecture. C’est mercredi prochain ! Venez nombreux 🙌 pour s’inscrire, ça se passe ici
😂 Le rire de la semaine : ce post de Félicie Le Dragon sur le couronnement du roi, j’aime beaucoup les contenus que produit Félicie, toujours très piquants et intelligents. Tu me diras ce que tu en pense 😄
À dimanche prochain !
Si tu es trop impatient pour attendre, tu peux :
M'envoyer des actus, contenus ou rires qui ont animé ta semaine et j'essayerai de les inclure dans l'édition de la semaine prochaine (en te citant bien sûr) 💪
Me contacter pour échanger sur le rapport à l’argent dans la tech par mail ou par message LinkedIn 💪
M'envoyer des feedbacks sur ce numéro, positifs... ou négatifs bien sûr ! C'est comme ça qu'on progresse 💪
Partager la newsletter à des personnes susceptibles d'être intéressées 💪
Bon courage pour la semaine (ça va, juste 4 jours et la semaine suivante… c’est l’ascension 🙌) !
Victor