You can find many definitions of a good Product Manager (for SaaS and other digital products) on Google. I don’t want to spin another version of it. I want to highlight one skill we don’t write much about product management: the ability to ask the right questions in order to make good product decisions.

Why Product Managers should master the art of asking questions

As a Product manager, I am responsible for the market-fit of the product(s) I manage. I quickly understood what it meant: putting myself in my users’ shoes, understand their needs and answer them the best way possible.

What I didn’t know then is that understanding customers needs is not as easy as it seems. It takes time and a lot of humility. In my career, I often started by building a product without having a full understanding of my users. With my teams, we built our knowledge of our users by iterating on the product we work on and we improved the solution by iterations.

It’s simple on the paper: we ask questions, we make hypothesis, we test them, we learn from them and we adapt. Again and again. Until we succeed.

The reality I only figured out later is that if we ask the wrong questions over and over again, we get wrong answers and we make wrong hypothesis. Again and again. Until we fail.

This is why it’s important to master the art of asking the right questions! Here are a few hypothesis ;)

Don’t Jump on Empathy Just Now.

The right questions are the one that will help your team understand the mindset of your customers, get to the root of their problems and understand what are the cause of their problems (and the potential solutions to fix them). That’s empathy.

But Empathy is useless if you don’t define which persons you want to address. Let’s say you build a marketplace for freelancers. Your research will depend on the type of freelancer you are talking to. The way you will conduct discovery should be different if you talk to a 22 years-old student who just got out of school compare to a 35-years-old freelance with strong professional experiences and a family to feed. And the single 33-years old freelance will be different as well.

So please, work your persona before you jump into the discovery phase because the quality of the assumptions you will make depends on your understanding of the persona you interview.

Fight Basic Cognitive Bias.

A cognitive bias is a systematic error in thinking that affects the decisions and judgments that people make.

Product Managers often make quick decisions. For that, they rely on schemas and short cuts learned from standardized schools courses, series & movies, etc. These shortcuts are frequently correct but they are also prone to error due to our brain’s attempt to simplify information processing.

As a Product Manager, it’s very important to be aware of some of the most common cognitive short cuts we do and fight them. You can find a long list of cognitive Bias on Wikipedia.

Take the time to discover your personal recurrent cognitive bias and keep them close to you!

As a Product Manager, I personally make sure I don’t fall into the following biais : anchoring, bandwagon, belief bias, clustering illusion, confirmation biais, availability heuristic, focusing effect, Semmelweis reflex, Normalcy bias and false consensus.

Let’s reuse the example of the marketplace for freelancers. I want to know what are the main needs of my persona in order to define the vision of my product for the next 5 years. Due to my own but short experience as a freelancer, my knowledge of the competitions and my love for automation, I believe the future of my product is around the simplification of administrative tasks (invoicing, tax declaration, accounting, expenses, payments, etc). Because of this belief, I narrow the scope of the interviews around administration questions. I get a tone of answers but they all focus on the need for administrative features. I have some “our-of-scope” answers I don’t put much attention. Doing that, I miss the most important things for freelancers such as (1) getting support to find customers, (2) helping them to build a local community and (3) provide missions requiring multiple freelancers to work in group and fight loneliness. My cognitive biases blocked me from finding the real pains I should work on to stay in the game.

Make Radical Assumptions

Having clear persona and the right questions to ask them is not enough to build a competitive product. To differentiate and develop a unique product, you need to dig deeper into your persona specificities and their behaviors.

I encourage all product managers to make radical hypothesis (Radical means risky) and test them. Radical hypothesis generate radical results. You will probably invalidate 95% of the hypothesis you made but the 5% left will provide interesting (and probably unique) learnings to explore further. Out of this 5%, you could have the feature that will make your product outstanding !

Let me know what you think of this last part and feel free to say what tricks you use to make sure you ask yourself, your team and your customers the right questions !

Arrêtez-vous, réunissez toute votre équipe — product managers, product owners, scrum masters et développeurs — et prenez le temps de vous donner des feedbacks constructifs, réfléchir aux améliorations possibles et les appliquer, ensemble.

A propos de la rétrospective

La rétrospective, c’est un peu comme une thérapie de groupe mais avec des bénéfices actionnables immédiatement. Laissez tout le monde prendre la parole, n’acceptez pas que les gens se coupent et prenez le temps qu’il faut pour ressortir les problèmes pour les corriger dans le futur.

Comme en thérapie, pour faire une rétrospective réussie, il faut avoir l’intention d’améliorer ce qui n’a pas été, d’acter des améliorations, de les appliquer et de suivre leurs performances. Sinon, ce n’est qu’une simple réunion où l’on dit ce qu’on a refoulé : c’est peut-être amusant sur le moment mais inutile.

Les objectifs d’une réunion rétrospective sont les suivants :

1. Identification des problèmes — quels problèmes avons-nous rencontré “as a team” ? Utilisez la méthode des 5 pourquoi pour bien couvrir la source des problèmes.
2. Proposition de solutions — comment pourrions nous régler ces problèmes ? Soyez créatif et ne rejetez aucune idée :) C’est l’occasion de faire du bottom-up :)
3. Suivi des solutions — vos solutions doivent suivre la logique SMART (détaillée plus bas). Une solution doit toujours être suivie et mesurée sinon cela ne sert à rien de la mettre en place. Comparez les améliorations attendues depuis la dernière rétrospective et ce qui a été accompli réellement.

Enfin, c’est le rôle du Scrum Master (ou du Product Manager en fonction de votre organisation) d’organiser cette réunion, de s’assurer que des actions sont prises et de suivre leurs applications. En revanche, ce n’est pas le rôle du Scrum Master de mettre en application les décisions prises. Distribuez à l’ensemble de l’équipe les responsabilités.

Le déroulé d’une rétrospective réussie

La rétrospective se fait en trois temps : ce qui s’est bien passé, ce qui ne s’est pas bien passé et les actions ou nouvelles procédures à mettre en oeuvre.

Parce qu’une réunion est toujours plus réussie lors qu’elle est interactive, donnez à tous les participants deux lots de post-it de couleurs différentes (disons vert et rose). Demandez à chacun d’indiquer ce qui s’est bien passé sur les post-it vert et ce qui ne s’est pas bien passé sur les post-it rose. C’est le temps de la réflexion. Chacun prend 10 minutes pour se reposer sur le sprint.

Pendant ce temps là, faites un tableau à trois colonne visible de tous et collez les post-it comme indiqué ci-dessous. Lorsque vous collez les post-it, essayez de mettre les retours similaires ensemble (sur la même ligne).

Addentum : si vous avez des personnes en remote, travaillez sur un board trello.

Commencez par parler de ce qui s’est bien passé

Pour chaque post-it, demandez à celui qui l’a écrit de préciser sa pensée. Groupez les retours similaires ensemble

En commençant par le positif, vous mettez l’équipe dans de bonnes dispositions. Cela permet de booster le moral avant d’attaquer les mauvais points.

Prenez ensuite tous les retours concernant ce qui ne s’est pas bien passé

Faites pareil avec les post-it qui indiquent ce qui ne s’est pas bien passé.

Normalement, les participant seront moins virulents et auront pris un peu de recule grâce à la revue des “choses qui se sont bien passées”. Laissez les échanges se faire en calmant les ardeurs si besoin. Essayez toujours d’aller au coeur du problème. Souvent on se rend compte que la cause n’est pas là où nous l’avions perçue.

Dès qu’une solution se dessine, proposez là. Si tout le monde est d’accord, notez-la sur un post-it (nouvelle couleur) et mettez la dans la colonne des améliorations

Enfin, définissez ensemble les améliorations et actions à mettre en oeuvre au sein de l’équipe

Lorsque vous aurez passé en revue tous les problèmes, vous devriez avoir un bon nombre de post-its dans cette colonne. Il est important d’être explicite sur la raison pour laquelle vous définissez ces actions. Echangez ensemble pour vous accorder sur ces actions. Essayez de ne définir que des actions SMART : spécifiques, mesurables, atteignables, réalistes, temporelles.

Rappelez à chacun les décisions prises pour vous assurer que tout le monde est aligné et définissez pour chaque action :

• Un objectif clair et identifié — quantitatif si possible
• Un ou plusieurs responsables en charge de définir la procédure dans le détail, de la mettre en application et de suivre son efficacité
• Une deadline

Parfois, aucune solution ne se dessine clairement. Si vous ne trouvez pas ensemble une solution claire et actionnable, désignez un responsable pour réfléchir à une solution et la proposer à tous dans un second temps (nouveau système de gestion de projet, nouvelle organisation pour le traitement des bugs,etc.).

Par ailleurs, n’oubliez pas de tirer des améliorations des post-it positifs! Les améliorations et la mise en place de routines peuvent aussi venir de là :)

En début de rétrospective, revoyez les actions décidées lors de la dernière session

Commencez la session par revoir les actions et améliorations qui avaient été convenues lors de la dernière rétrospective. Cette étape est à préparer en amont de la réunion.

Mettez en avant les actions qui ont été mises en application avec succès. Félicitez l’équipe pour les améliorations qui ont été appliquées avec succès. Donnez des exemples si certaines équipes n’ont pas eu le même succès dans l’application de cette action.

Revoyez ensuite les actions qui n’ont pas eu l’impact attendues ou qui n’ont pas été appliquées du tout et identifier ensemble pourquoi. Vous pourrez alors décider de changer de responsable, de changer la méthode d’application ou simplement d‘arrêter l’expérimentation.

Après la rétrospective

Après la rétrospective, envoyez un email récapitulatif de ce qui a été dit à tous les participants. Pour cela, je vous invite à copier le tableau sur un board trello si vous ne l’avez pas déjà consolidé pendant la session.

Enfin, si des actions prises nécessitent des réunions ou un suivi, réservez immédiatement les meetings avec les personnes concernées.

L’appliquer c’est l’approuver ! A bon entendeur ;) !

Exemple de board Rétrospective
https://trello.com/b/3IRRt8oC/mai-2018-r%C3%A9trospective-example

Pourtant, on oublie trop souvent de les impliquer. Pire encore, on leur demande de nous présenter les solutions à mettre en place. Ce faisant, on met en place des solutions sans avoir vraiment creusé les problèmes.

En tant que PM, il est essentiel de bien interroger vos utilisateurs internes. J’ai testé pas mal de choses (sondages, immersion, etc.), avec plus ou moins de succès. Au final, le plus pertinent des exercices reste le Stakeholders Requirements Gathering meeting, dont je vais vous présenter le déroulé. Bien organisé, ce meeting est un point de départ qui garantira le succès de lancement de vos outils internes. En outre, ces échanges permettent de créer une culture produit et de rappeler le rôle et la valeur ajoutée de l’équipe produit.

Le Stakeholders Requirements Gathering Meeting, qu’est ce que c’est ?

Quel que soit le nom que vous lui donnez, cette réunion tient en trois points majeurs :

1. Identifier les problèmes — quels problèmes les parties prenantes réunies rencontrent aujourd’hui et rencontreront demain ?
2. Relativiser les problèmes — pourquoi ces problèmes sont-ils important ? Qu’est ce que leur résolution peut apporter
3. Définir les solutions potentielles — Quelles solutions pouvons-nous mettre en place ? A quoi peuvent ressembler ces solutions ?

Avant de rentrer dans le déroulé du meeting, voici quelques conseils clés nécessaire au succès de la session :

L’invitation

Il faut inviter toutes les personnes ayant des informations permettant de creuser dans les problèmes et de trouver des solutions innovantes que personne n’aurait pu trouvé seul. La réunion réunit des experts des différents départements concernés, des développeurs senior et des product managers et designers.

Attention, le problème de ces réunions est qu’on part généralement trop vite sur les solutions sans prendre le temps de bien analyser les problèmes qu’on veut résoudre. Or, la solution est souvent déjà dans le titre de votre réunion : “Product Meeting meeting — Onboarding Automation”. Vous assumez que la solution est dans l’automatisation mais rien n’est moins sûr et vous ne voulez pas guider les participants sur les solutions trop tôt. Préférez quelque chose de plus large comme : “Product Meeting — Onboarding improvements”.

La préparation

Demandez aux participants de lister leurs problèmes en amont de la réunion. Et parce que la meilleure manière de comprendre un problème, c’est l’exemple, allez voir ce qu’il se passe du coté du call center, passez une heure avec l’équipe Sales dans son environnement, etc. Cela peut vous apporter une expérience de grande qualité, bien plus que des retours emails.

Le déroulé meeting

Je vous invite à découper votre Stakeholders Requirements Gathering Meeting en 4 étapes. La quatrième étape est facultative, à faire un uniquement si les participants présents sont assez bien câblés pour se prêter à l’exercice :

• Etape 1 : récolter les problèmes (15 minutes)
• Etape 2 : grouper les problèmes en thématiques (15 minutes)
• Etape 3 : contextualiser les problèmes (30 minutes)
• Etape 4 : définir les solutions potentielles (30 minutes)

Les participants ont plus de facilité à identifier les problèmes lorsqu’ils ont la vision et leurs missions sous les yeux. Avant le début du meeting, je rappelle aux participants la vision produit et je fais un tour de table pour que chacun rappelle son rôle, ses objectifs et ses “tâches à fortes valeurs ajoutées” et je les note sur le tableau (ou sur un powerpoint diffusé pendant la réunion).

Etape 1 : Récolter les problèmes

Un problème = un post-it.

Il est rare que tout le monde s’entende à merveille. Si c’est le cas tant mieux. Autrement, ça peut vite tourner à l’affrontement et rendre le meeting contre-productif voire frustrant pour certaines personnes soucieuses d’aller de l’avant.

A cette étape, la meilleure approche est celle de Jeff Bezos : Start With Silence. Commencez par15 minutes de silence pendant lesquels chaque personne liste en silence les problèmes qu’il rencontre. Ces problèmes ne doivent pas être obligatoirement liés au produit. Ils peuvent être opérationnels ou humain. L’important à ce stade est de se concentrer sur les problèmes et challenges qu’ils rencontrent.

Etape 2 : confirmer les problèmes et grouper les par thématiques

Prenez chaque problème et collez-les un par un sur le tableau blanc. Si vous avez des participants en remote, reportez les problèmes sur un Trello partagé.

A chaque fois que vous reportez un problème, demandez à la personne qui l’a remonté de préciser/expliquer le problème. Répétez chaque problème à haute voix pour le clarifier et être sûr que tout le monde le comprend avant de passer au problème suivant. Si les gens ont du mal à comprendre ou à expliquer, demandez un exemple concret.

A chaque fois que vous rajoutez un problème sur le board, essayez de le mettre dans une thématique. Créez un groupe à part pour les problèmes transverses. Attention à ne pas avoir trop de thématiques différentes.

Etape 3: contextualiser les problèmes (30 minutes)

Cette étape permet de prendre du recul sur les problèmes, de les relativiser les uns par rapport aux autres et de s’accorder sur leur niveau de priorité.

Ce travail encourage vos parties prenantes à se poser les mêmes questions et à s’aligner entre elles. Voici les filtres recommandés :

• Goal filter — si le problème est résolu, quels objectifs va-t’il permettre d’atteindre? Si l’impact n’est pas clair, il faudra considérer sérieusement sa pertinence.
• Revenue filter — si le problème a un impact sur le revenu, quel est cet impact ? Notez si l’impact est direct ou indirect.
• Customer filter — si le problème a un impact sur les clients, quel est-il ?
• Future filter — Est-ce que le problème est actuel ou futur ? Cela permet de savoir si le problème ne sera pas réglé par lui-même lorsqu’il arrivera car vous avez prévu de changer de système, etc.
• Metrics filter — quelles sont les KPIs qui expriment le mieux ce problème ? Quelles sont les KPIs pour mesurer la solution ?

Une fois les problèmes filtrés, vous pourrez définir, ensemble, lesquels sont prioritaires.

Vous pouvez décider d’arrêter la réunion ici et de revenir plus tard vers les participants avec un plan d’action (que vous aurez défini avec les PO et l’équipe de développement). Si vous pensez que cela peut-être bénéfique, prolongez la réunion pour discuter des solutions potentielles et de leur coût.

Etape 4 (facultative) : définir les solutions potentielles

Il est temps de définir les solutions potentielles sur la base des problèmes découverts et des priorités définies.

L’objectif est de définir des solutions et de les représenter de manière à les associer aux problèmes. Une solution peut résoudre un ou plusieurs problèmes. L’important c’est que tout le monde participe, notamment les développeurs et product managers.

Certains participants se rendront compte que les solutions proposées sont très différentes de ce qu’ils avaient en tête avant de rentrer en réunion. Certains réfléchiront à deux fois la prochaine fois avant de venir vous voir avec une solution :) !

Après le meeting

Envoyez un récapitulatif de ce qui a été dit pendant la réunion à tous les participants. Si vous êtes bien organisé, vous avez eu le temps de reporter — au cours du meeting — tous les problèmes, thématiques et solutions dans un board Trello. Il vous suffit donc de partager ce board aux participants.

Vous devrez aussi convenir d’une date à laquelle vous reviendrez vers eux pour leur indiquer les solutions qui ont été retenues, leur temps de développement, etc.

J’espère que vous prendrez le temps de faire cet exercice et je suis intéressé par vos retours d’expériences et remarques.

Une nouvelle méthode qui s’articule au niveau local

Force est de constaté que les Grands Plans sont inefficaces. Comme vous l’avez souligné avec humour : “ Je ne vais pas annoncer un autre plan banlieues, aussi âgée que moi ».

Il faut mettre en place une nouvelle méthode qui s’articule au niveau local pour s’adapter aux réalités de chaque quartier et apporter un changement profond.

Inutile de vous convaincre que pour apporter un changement profond et durable, il est essentiel de focaliser son action sur la jeunesse. Il faut les guider plus tôt, leur montrer la multitude de métiers disponibles, leur prouver qu’ils ont le droit de croire en leurs rêves et qu’ils ont les moyens pour y arriver. Il faut tout faire pour ne pas les enfermer dans le déterminisme social dans lequel on les a mis, consciemment ou pas.

Une approche pluraliste est possible

Dans certain quartier, l’école est le dernier espace républicain encore disponible et c’est le parfait endroit pour articuler l’action de l’Etat et investir dans le futur de ces quartiers dits prioritaires

Vous avez déjà fait beaucoup en réduisant la taille des classes par deux et en proposant de réserver des places pour les stagiaires de troisièmes de quartiers défavorisés.

Cependant, une simple action au stage de troisième ne suffira pas. Il faut aller plus loin, en commençant plus tôt et en travaillant davantage avec les autres services locaux de l’état.

Si vous faites travailler certains organismes publics ensemble (INSEE, Pôle emploi et Chambres de Commerces pour ne citer que les plus évidents), vous pouvez accompagner les jeunes des quartiers mieux et plus tôt.

On fait comment concrètement ?

Prenez la carte de la France et superposez quelques informations déjà connues telles que :

• Les typologies d’offres d’emplois non pourvues par commune
• La typologie des entreprises présentes par commune
• La typologie des écoles / formations présentes par commune
• La typologie d’emplois en disparition / en création

En superposant ces informations, l’Etat est en mesure :

• d’identifier les secteurs en croissance dans les régions
• de mettre en avant les métiers en tensions dans les régions

Une fois ces informations connues, il faut les mettre à disposition des jeunes et leur présenter.

Pour partager le pouvoir, encore faut-il partager le savoir :

• Faire intervenir dans les écoles, et avant la 3ème, les entreprises présentes autours des établissements scolaires et représentant certains secteurs / métiers en tension afin d’ouvrir le champ des possibles des élèves.
• Faire intervenir dans les collèges, avant le choix de l’orientation, les écoles de formations présentes autours des établissements et représentant certains secteurs / métiers en tension
• Orienter plus tôt les élèves en décrochage scolaire grâce aux informations récoltées et en les croisant avec des ateliers d’orientation et de découverte de soi.

Si chaque région s’investit avec les partenaires locaux et travaille avec ses communes, nous n’aideront pas seulement les élèves des quartiers défavorisés mais tous les élèves de France ! A l’époque de la big data, il n’y a pas de raison de laisser leur avenir au hasard.

I am talking about everything we never write on a job description but is prerequisite to be successful in a startup

• Enjoy ambiguous environment: the organisation and process in a startup evolve very fast. The absence of clear hierarchy and the transversal responsibility create complex organisation. We need people that thrive in ambiguous environment and can manage ambiguous situations. Sometimes you don’t even know what the product will look like in six months so you need to love the fact that the future is blurred.
• Low ego: this is definitely something we cannot put in a job description. In startups, we don’t want someone who needs to be the person on top of others or the person that wants to shine. It is even more important when you are working as a product manager because you lead people who don’t report to you and if you want the product to move forward, you should be someone who can take the blame while giving the credit.
• Disagree & commit: the pace is fast and lots of decisions are quickly taken in startups which also result in bad decisions, more often. And that’s ok. You must allow yourself to both question anything and invite people to question your choices and actions (in a constructive way by providing possible solutions). Raise your hand when you disagree — even if it’s not in your direct scope of action. It’s key for a startup to move forward and improve itself. However, disagreement doesn’t mean you should disrespect your colleagues and their decisions. Committment is key. When a decision is taken, whether you agree or disagree, you must be committed to what has been decided ! Don’t loose energy when you don’t own the decision. Anyway, either you are wrong or the subject will come back on the table soon enough.
• Strong decision-making with imperfect information: People afraid of taking decision with imperfect information will not do good in startups. First because we need doers in startups and executions comes from upstream decisions. Secondly because you don’t have the resources and expertises at first to cover all aspects of a decision. Let’s be clear : dealing with imperfect information doesn’t mean you should take decision without information. You must find as many data and insights as you can and be supported by all the intelligence you can find internally AND externally. One should always value intense preparation.

If you have the following skills, you will thrive in a startup. As the company grows, the organisation will scale and experts will onboard. It will be more important than ever — if you came at the beginning of the adventure- let your ego aside and commit to the organisation decisions

Leave me a comment if you think of other skills we don’t ask out-loud.