Nous continuons notre série d'articles sur les qualités clés d'un chef de produit performant. Nous avons déjà réussi à discuter avec Anton Danilov , Yuri Golikov , Dmitry Orlov et Alexei Korotich . Aujourd'hui, nous allons parler avec Alexander Belyaev. Sasha est responsable de l'un des modules complémentaires les plus ambitieux - Wrike Resource .
- Salut, Sasha. Dites-moi, depuis combien d'années travaillez-vous chez Wrike et depuis combien d'années travaillez-vous dans la gestion des produits?
- Je travaille chez Wrike depuis 4,5 ans, et pour la durée totale de service, c'est un point discutable. L'un des premiers postes de ma carrière s'appelait chef de projet, mais même à ce moment-là, j'ai participé au lancement du produit.
Ce n'est peut-être que dans Wrike que je peux dire avec certitude que je suis un produit: ici l'ensemble des pouvoirs, des ressources, des capacités et du format de travail est exactement la façon dont j'imagine la position correspondante d'un chef de produit. Et avant cela, il me semble parfois que tout allait un peu mal. Mais c'est plutôt mon point de vue critique sur le début de ma carrière: néanmoins, ce sont différentes étapes de la carrière qui se poursuit depuis 2010.
- Puisque nous parlons de chefs de projet et chefs de produit, quelle est la différence clé entre les rôles et où se croisent-ils, au contraire?
- Disons simplement que la tâche principale de la gestion de projet est de fournir à temps le résultat souhaité. En général, qu'est-ce qu'un projet? C'est quelque chose qui a un début et une fin. Un produit n'est pas un projet.
Par exemple, dans notre région, il s'agit d'une solution logicielle, d'une sorte d'application ou d'une sorte de fonctionnalité. Elle a son propre cycle de vie, y compris les stades d'origine, de développement et, à un certain moment, d'extinction. Le cycle de vie du produit n'est pas du tout le même que le début et la fin d'un projet, ce sont des choses complètement différentes. Pour le chef de produit, le cycle de vie du produit doit être la clé. Le chef de projet, quant à lui, ne s'intéresse qu'à une étape spécifique, car l'introduction de chaque fonctionnalité individuelle dans le produit est également un mini-projet. Mais posséder complètement le produit et le conduire de la génération à la floraison et le développer constamment est beaucoup plus difficile.
- Dois-je bien comprendre que la gestion de projet peut être considérée comme l'une des composantes de la gestion des produits?
"Oui, je pense que oui." Mais en même temps, je pense que c'est l'un des examens les plus facilement aliénés. La fonction de gestion de projet directe et de contrôle des résultats peut être assurée par l'équipe de développement avec laquelle vous travaillez. Un Scrum Master, un développeur senior ou un chef d'équipe peut également le faire. C'est-à-dire que le simple fait de veiller à ce que les délais ne soient pas respectés et que tout soit sous contrôle n'est, me semble-t-il, pas une grande tâche. Et je pense que le chef de produit devrait déléguer cette tâche aux membres de son équipe en qui il a confiance. Et vous devriez consacrer votre temps à des choses de niveau supérieur et regarder plus largement tout ce qui se passe.
- Veuillez nous parler de l'expérience dans le développement et la sortie de l'addon Wrike Resource, avec lequel vous et l'équipe travaillez depuis sa création et travaillez toujours dessus. Quels sont les principaux défis auxquels vous et votre équipe avez été confrontés lorsque vous avez travaillé sur ce module complémentaire à différentes étapes?
- Le premier défi est de prioriser dans une situation avec des ressources et un temps limités. Il est clair que beaucoup reste à faire pour créer un produit compétitif. Mais la question est par où commencer?
Ensuite, vous devez prouver au reste des membres de l'équipe et de la direction que votre choix est bon et qu'il vaut la peine de commencer par lui. Ces preuves peuvent prendre beaucoup de temps, car tout le monde est en situation de surcharge d'informations.
C'était très difficile avec la «gestion des ressources», puisque c'est un travail sur l'architecture de notre application, et c'est assez compliqué avec nous. La gestion de projet elle-même n'est pas une simple discipline, elle est guidée par les pratiques du PMI Guidebook et du PMBOK, donc répondre à cette tâche n'est pas anodin. Par conséquent, il était très difficile de comprendre comment le concept d '«effort de tâche» s'intègre dans notre système ou quels modes il devrait avoir. Près d'un quart y a consacré.
En conséquence, l'étape la plus difficile a été de choisir et de réaliser ce qui doit être fait. De plus, lorsque vous mettez déjà en œuvre toutes les idées, cela devient plus facile.
- C'est-à-dire qu'après cette étape créative, l'équipe a déjà compris comment faire cela, quels sont les termes approximatifs et ainsi de suite?
- Il existe différentes options pour ce qu'il faut faire. Vous pouvez exécuter une version bêta rapide. Ou commencez par définir l'ensemble de ce que vous voulez faire cette année, prenez une part et faites-le d'abord. Par exemple, c'est ce que nous avons fait avec le sélecteur de date. Ensuite, nous avons lancé une version bêta de la gestion des ressources, dans laquelle il y avait un sélecteur de dates et des efforts. Autrement dit, nous venons de choisir quelque chose de petit, qui est plus facile à concevoir et à dessiner et à commencer à travailler dessus.
- Veuillez me dire dans quelle mesure le travail du produit dans Wrike est spécifique.
- Je ne pense pas que le travail chez Wrike soit très spécifique. Il me semble que, en général, il est similaire au travail des produits dans d'autres organisations, à peu près de la même manière que les produits fonctionnent dans les entreprises occidentales.
- Et maintenant à notre sujet, qui passe par toutes les dernières interviews. J'ai discuté avec un certain nombre de personnes qui voulaient nous trouver un poste de chef de produit. Et de tout cela, j'ai entendu deux questions clés: "Quel type d'expertise est nécessaire?" et "Quelles qualités doit-on posséder?" Si je comprends bien, la question de l'expertise est très spécifique, alors passons tout de suite aux qualités.
- A propos de l'examen peut également être répondu. Par exemple, prenez l'expertise de l'utilisation des données. L'approche fondée sur les données, c'est-à-dire la capacité de mener des expériences, de formuler des hypothèses, de choisir des paramètres que ces hypothèses confirment ou réfutent, est un examen assez large, qui, il me semble, n'est spécifique à aucune industrie.
- Selon vous, est-il possible de devenir un chef de produit efficace sans formation en développement et en général dans les entreprises informatiques? Est-ce que, par exemple, une sorte de distributeur ou de vendeur peut devenir un produit?
- Marketing et ventes de l'informatique - oui, il le peut. Si ce n'est pas votre premier jour à l'informatique, vous avez déjà de nombreuses compétences. Si vous avez regardé autour de vous, vous comprenez comment cela se produit, quelles sont les étapes: conception, spécifications techniques, etc. Marketing et ventes dans un autre domaine - je ne pense pas.
Si vous êtes un marketeur ou un commercial non informatique, la question se pose: «Pourquoi vous intéressez-vous à ce domaine, mais vous n'avez aucune expérience?». Venir à l'informatique sans rien faire de technique est une histoire controversée. Vous voyez, cette expérience n'est pas si difficile à obtenir. Rien n'empêche un spécialiste de réunir des amis, d'embaucher des pigistes et, par exemple, de faire une demande, de gérer tous les processus. Et après l'avoir fait, vous plongerez un peu dans le développement et vous comprendrez comment tout fonctionne. Sinon, la question se pose: «Êtes-vous vraiment intéressé à créer des produits en informatique?»
- Dans chaque entretien, tous les produits parlent de qualités et d'expertises différentes. Donc, à chaque discours et tout le monde a raison.
- C'est peut-être la preuve que la gestion des produits n'est pas une science, mais un art.
"Vous devez avoir raison, oui."
- C'est une chose éternelle dans la gestion des produits: il est très difficile de tout classer, de développer des approches claires.
Par exemple, dans le développement, il existe des langages de programmation avec certains ensembles d'outils, d'approches et de cadres. Et, en fait, soit vous les connaissez, soit vous ne les connaissez pas.
Et dans la gestion des produits, tout le monde vient tout de suite avec des approches complètement différentes. Il n'y a pas d'outils clairs. Il existe un certain ensemble de cadres, mais l'attitude à leur égard varie de l'amour à la haine. Donc, au final, il s'avère que personne ne peut dire en toute confiance qui est le chef de produit et ce qu'il peut faire. Dans le même temps, les avis s'accordent à environ 66% et le tiers restant est le domaine où tout peut être différent.
- Je veux aborder le problème principal. Quelles sont, selon vous, les trois qualités qui permettent à un chef de produit de réussir dans son rôle et pourquoi exactement ces qualités?
- La première qualité est une sorte de netteté commerciale, c'est-à-dire une compréhension du fonctionnement d'une entreprise, de la manière dont elle y gagne de l'argent, de son type de modèle commercial. C'est la prise de conscience que parfois vous pouvez faire quelque chose de bon marché et tordu, mais vous pouvez toujours gagner de l'argent.
Il y a une blague classique sur ce sujet:
Vasya a lancé MVP en un mois, a commencé à gagner un public et a développé son produit en quelque chose de cool, et Petya a été tourmenté pendant un an en essayant de faire quelque chose de génial, il a dilapidé tous les budgets, et rien n'en est sorti.
Il s'agit d'une compréhension du principe de Pareto (20% des efforts donnent 80% du résultat), comment l'argent est fait en général, les problèmes commerciaux sont résolus et les résultats sont atteints.
- Peut-on dire que ces qualités dérivent indirectement de la curiosité?
- Certainement, oui. Vous voulez savoir comment tout fonctionne. Et les affaires ne sont que l'un des domaines sur lesquels vous apprendrez les détails.
Cependant, souvent, de nombreuses personnes, même du secteur informatique, ne le font pas. Il me semble que la plupart des développeurs ne le font pas. Ils ne sont pas intéressés par le fonctionnement d'une entreprise, mais par le fonctionnement des systèmes et des produits. Ils chérissent l'épicerie et veulent qu'ils en profitent. Mais, malheureusement, les avantages ne sont pas toujours les mêmes que le succès commercial d'une entreprise.
La deuxième qualité est l'empathie pour les utilisateurs. Je crois qu'être un bon produit, c'est créer des produits qui sont vraiment utiles pour les gens, et ils aiment interagir avec eux.
- C'est une question importante. Mais, néanmoins, profiter ou bénéficier?
- Je crois que les deux. Tout d'abord, l'avantage. Si vous imaginez le produit comme une pyramide, alors au niveau inférieur il y aura des avantages et au niveau supérieur - le plaisir. Ce sont des choses cohérentes. Je pense que les produits doivent s'efforcer de garantir que les utilisateurs apprécient et ressentent des émotions positives en interagissant avec le produit. Cela et un autre sont encore convertis en indicateurs commerciaux. Les utilisateurs éprouvent des émotions positives, naturellement, deviennent beaucoup plus attachés à ce produit et, par conséquent, plus fidèles. Cependant, cela n'est pas possible si le produit ne leur profite pas.
Et vous, en tant que chef de produit, pouvez obtenir ces résultats si vous avez développé de l'empathie et une compréhension de la psychologie humaine. Vous pouvez écouter les gens et comprendre ce qu'ils n'aiment pas, vous pouvez entendre entre les lignes ce qu'ils disent et pas directement, vous pouvez traduire ce qu'ils vous demandent directement en ce qu'ils devraient réellement donner.
Et ces deux premières qualités doivent s'équilibrer. Si vous pensez trop aux affaires, vous pouvez oublier les utilisateurs et vous arrêter tout le temps au niveau "c'est très utile, cela signifie qu'ils l'achèteront".
Et si, à son tour, vous pensez trop aux utilisateurs et ne comprenez pas que vous devez créer un produit commercialement réussi pour un budget raisonnable, alors vous pouvez vous asseoir sur des tâches pendant une année entière et, en fin de compte, l'entreprise ne recevra aucun revenu de cela.
La troisième qualité est la pensée systématique et une approche analytique. Travailler avec un logiciel, c'est travailler avec des systèmes. Vous devez comprendre en quoi consistent les systèmes afin d'écrire des savoirs traditionnels, de prendre des décisions sur l'architecture d'interface, les entités et l'expérience utilisateur. C'est tout - une pensée systématique, une mentalité analytique.
Afin de mener des expériences et de formuler des hypothèses, brisez la feuille de route qui se trouve devant vous en itérations et comprenez quel chemin optimal et quelles étapes avancer - tout cela nécessite une réflexion systématique et analytique. Et à chaque fois, vous devez vous poser la question: «Suis-je en train de penser correctement? Cette option est-elle vraie? », Essayez de la réfuter, de proposer autre chose ou de vous y attarder. Ici, nous ajoutons également la possibilité d'évaluer de manière critique à la fois notre travail et l'équipe.
- Intéressant. De tous les collègues avec qui j'ai déjà réussi à parler, j'ai entendu un ensemble différent de qualités. Mais une chose a été trouvée dans presque tout le monde - c'est la communication. Et c'est curieux que la seule chose que vous n'ayez pas sonnée.
- L'empathie est, en un sens, la base de la communication. Je n'aime pas vraiment l'interprétation commune de la communication. Il me semble que ça sent à nouveau quelque chose de trop manipulateur et de tellement technique. Je pense que la base d'une bonne communication est l'empathie. Si vous sentez les autres, vous comprenez ce dont ils ont besoin et ce qui est utile et ce qui est désagréable, alors votre dialogue sera construit.
"Je veux vous poser une autre question." Que recommanderiez-vous à quelqu'un qui souhaite devenir chef de produit chez Wrike? À quoi se préparer et à quoi s'attendre?
- S'il n'y a aucune expérience - je vous conseille de travailler d'abord comme produit ailleurs. Wrike a des exigences très élevées et un rythme de travail rapide, et ce n'est pas le meilleur endroit pour acquérir une expérience de départ.
Bien sûr, il existe des cas uniques pour lesquels la situation sera normale lorsque le processus d'accumulation d'expérience sera étroitement lié à la livraison et à l'exécution, et qu'une personne pourra tout apprendre en déplacement. Mais je crois à peine que de telles étoiles existent. J'essaie de conseiller une personne moyenne, pas une personne sur dix mille.
Si une personne a quelques années d'expérience réussie en tant que produit ou en périphérie, alors je lui conseillerais de ne pas avoir peur et de venir, nous n'avons rien de super-spécifique dans l'entreprise. Essayez-le.
- Je vois. Merci beaucoup, en fait, c'est très intéressant de parler.
"Pas du tout." Je suis heureux de formuler et de dire certaines choses.