Nous continuons à parler des qualités clés d'un chef de produit performant, selon l'équipe produit Wrike. Dans la sixième (!) Partie de cette série, nous parlerons avec Anton Stozhko. Anton travaille en tant que chef de produit associé depuis 1,5 an, où il a quitté l'équipe de support client.
- Salut Anton! Je suggère de commencer immédiatement par une question clé: quelles sont, selon vous, les trois qualités clés d'un chef de produit qui veut réussir dans son rôle?
- Le sommet est la capacité de planifier et de hiérarchiser. Le plan et la priorité ne sont pas tant la gestion des produits, mais la culture personnelle ou même l'hygiène. Le plan est important car il aide à combattre l'inconnu, et peu de gens qui l'aiment et la plupart essaient de l'éviter. Mais si vous voulez développer une entreprise, vous devez y faire face. Et la priorité est importante, car il n'y aura jamais de ressources pour tout faire complètement (bonne nouvelle - ce n'est pas obligatoire). L'essentiel est de faire la chose la plus importante en temps voulu.
- Et comment pouvez-vous développer ces compétences? Est-il possible de dire qu'ils proviennent d'un sens des responsabilités de ce qui se passe dans votre équipe et votre entreprise?
"Eh bien, certainement pas pour tout ce qui se passe, mais seulement pour ce qui relève de votre domaine de responsabilité." Vous pouvez les développer, comme tout le reste - par la répétition. Une petite mise en garde: il est difficile d'apprendre à bien planifier jusqu'à ce que vous deveniez vous-même un produit. La nécessité de telle ou telle activité n'est pas particulièrement visible, la valeur réelle n'est pas claire. Wrike m'a fortement secoué ici: j'ai réalisé qu'il n'y avait pas autant de temps personnel que je le pensais, et la liste des tâches prioritaires tend à l'infini. J'ai encore devant mes yeux une file d'attente de demandes dans le support, où j'ai commencé.
Pour développer ces compétences, vous devez essayer d'appliquer ces principes à tout ce qui se passe. Cas pour la journée, plans de vacances, réponses aux messages de trois ou quatre canaux, plans d'équipe pour le trimestre. Ensuite, vous devez apprendre à transférer des compétences aux activités des autres: sur les équipes et leur planning, sur les chefs de produit et leur vision.
J'ai remarqué qu'une impulsion fraîche à la planification et à la priorisation donne la possibilité d'imaginer d'abord un «état parfait». Lorsque les choses sont faites, les décisions sont prises, les fonctionnalités sont aplanies, les mesures sont atteintes. Une fois que l'état idéal s'est formé dans la tête à un certain moment, vous pouvez commencer à dérouler la balle.
- Et comment le dérouler?
- Poser des questions, bien sûr. Ce n'est que la deuxième compétence clé - la capacité de se poser des questions à vous-même et aux autres: «De quoi avez-vous besoin pour que cela se produise?», «Qu'est-ce qui manque? Les grandes questions inarticulées se rembobinent en petites questions spécifiques. Encore une fois, ne répondez pas à la fois. Rappelez-vous le premier principe.
L'importance de la capacité de poser des questions est probablement écrite dans tous les livres sur le produit, mais l'accent est mis sur la question "Pourquoi?". Je ne contesterai pas - la recherche auprès des clients est un sujet utile, mais d'autres questions ne sont pas moins importantes. Les parties prenantes sont souvent intéressées par «quoi et quand?», L'équipe s'intéresse à «pourquoi et dans quel ordre?», Tout le monde est intéressé par «quoi et pourquoi?».
La particularité du travail du produit est qu'il n'y a pas toujours dans votre poche plus de réponses que de questions. Mais le désir de recevoir des réponses est le secret de la lutte contre la routine.
- Dans quelle mesure les tâches sont-elles formulées sur lesquelles vous devez travailler en tant que produit d'un oouner dans le cadre d'une stratégie? Diffusez-vous seulement une vision générale ou des choses plus spécifiques? Par exemple, est la situation typique quand ils se tournent vers vous: «Nous voulons que cette partie du produit soit comme ça». Et puis vous avez mis sur pied une équipe et dites: "Les gars, faites-le de cette façon."
- J'ai une métaphore préférée sur le marteau et l'enclume. Ici, le produit vit où ils se rencontrent et des étincelles volent. Le marteau est un mouvement descendant. Ici et une vision de haut niveau, une stratégie et des OKR, et parfois des tâches très spécifiques. Les idées descendent sous différentes formes avec des degrés divers d'importance et de sophistication. Ce ne sont que des désirs. L'enclume est un mouvement ascendant. Il s'agit de la base de code, des ressources, de l'humeur des membres de l'équipe, des priorités actuelles et des plans existants. C'est une réalité. Là où les désirs rencontrent la réalité, il faut gérer les deux.
Donc, la réponse à la question: "Comment cela se produit-il?" - "De différentes manières!"
Il arrive que vous dérouliez une idée d'un cadre supérieur et que vous compreniez qu'il y a potentiellement une grande valeur dans une sorte de flux. Ma tâche consiste à identifier cette valeur, à comprendre comment l'intégrer dans le workflow et à vérifier si elle n'interfère pas avec les tâches prioritaires existantes.
Il arrive qu'une tâche très spécifique se déroule, et elle doit être prise et accomplie.
Soit dit en passant, au sens profond, une tâche directement définie à partir d'une idée, d'un aperçu ou d'une stratégie ne se distingue que par le degré d'approximation et de sophistication.
- Et dites-moi, s'il vous plaît, quelle est la différence entre un produit et un produit associé dans le contexte de Wrike?
- Tout d'abord, c'est le niveau de décisions que vous prenez. Regardez: je suis venu et je suis devenu chef de produit associé, et mon directeur me dit: «Faisons des calendriers pour que les agences de marketing qui utilisent Wrike se sentent bien» (je veux dire la fonction «Calendriers» dans le produit Wrike). Et je réponds: «Eh bien, si nous les avons vus, alors ils devraient être comme ça. Il devrait y avoir des filtres, la possibilité de créer un lien externe pour le partage, et bien plus encore. » Je décris les détails d'une fonctionnalité qui n'existe pas encore, mais la fonctionnalité elle-même est vendue. Pour quelque chose, j'obtiens l'approbation, et quelque part je réponds à des questions supplémentaires.
En même temps, comment la fonctionnalité fonctionnera et pourquoi elle est nécessaire - tout le monde comprend. Par conséquent, à ce stade, vous obtenez une tâche sous la forme: "Allez, fais-le." La gestion opérationnelle de l'équipe vous appartient, le remplissage du backlog. Ce n'est pas le composant principal du produit, mais un excellent point de départ.
Remplissez l'arriéré que beaucoup savent faire. Il n'y a rien de compliqué à écrire comment une fonctionnalité devrait fonctionner lorsque vous la créez, puis à en discuter avec les développeurs. Tout ce qui suit est une question d'évaluation et de planification.
Tout ce que j'ai décrit, c'est le niveau de départ. À l'étape suivante de la prise de décision, vous avez déjà d'autres questions. Pas "quelle fonctionnalité sera?", Mais "que dois-je faire?" C'est la question que je me suis posée lorsque j'ai commencé à travailler sur Blueprints (note - l'une des nouvelles fonctionnalités du produit). Personne ne m'a dit: "Faites des plans et décidez de ce qu'ils seront." On m'a dit: «Il y a un problème avec le travail récurrent. Que ferons-nous? "
Vient ensuite le troisième niveau de prise de décision. Ici, ils ne vous désignent plus de problème, mais disent: "Nous pensons qu'il y a peut-être un problème quelque part ici." Et votre tâche trouve déjà un problème.
- Autrement dit, au troisième niveau, vous commencez par mettre en évidence le problème vous-même, puis vous proposez vous-même une solution et ensuite vous terminez?
- Oui. Et pour moi, cela ressemble déjà à un travail de fin d'études. Quand vous avez fait la recherche vous-même, vous avez tout compris, parlé avec tout le monde, fusionné votre vision avec la réalité, tout montré à tout le monde, convaincu tout le monde de tout. Pour résumer, à chaque étape, on vous donne toujours une sorte d'introduction. La question est de savoir comment ils sont définis. Et à chaque nouveau niveau de prise de décision, l'horizon de l'immense s'élargit.
- J'ai compris. Vous avez dit qu'au niveau du plan directeur, il travaillait déjà au deuxième niveau de prise de décision et au troisième pour résoudre le problème d'intégration. Y a-t-il un quatrième, cinquième niveau, etc.? Ou y a-t-il encore une fin?
- Le quatrième est probablement lorsque vous avez un groupe de chefs de produit. Travailler dans une équipe Scrum cesse d'être votre routine, et vous avez une nouvelle équipe composée de produits. Chacun d'eux a une sorte de vision et de problème qu'il essaie de résoudre. Et votre tâche devient une gestion efficace des désirs avec les réalités de chacun de ces produits.
Autrement dit, la mise à l'échelle va plus loin: le nombre d'horizons à embrasser augmente. C'est possible grâce à la délégation. Et à ce quatrième niveau, vous devez vous assurer que ceux qui sont maintenant au troisième viennent à vous avec de telles propositions et présentations, sur la base desquelles vous pouvez prendre une décision ou donner des conseils pour que la roue tourne.
- Bien. Revenons à la question d'origine. Vous avez déjà mentionné les plans, la priorisation et la possibilité de poser des questions. Et quelle est, selon vous, la troisième qualité pour un chef de produit performant?
- Comme mon mentor aime dire: «La seule ressource produit est la relation avec les autres», c'est-à-dire la communication.
- Et dans le cadre de la communication, quels problèmes avez-vous à gérer au quotidien?
- Au niveau quotidien, il y a deux problèmes communs: la mauvaise communication et la sous-communication. Les informations ne sont pas reçues en quantité suffisante ou sont transformées en informations malignes. En conséquence, des mouvements supplémentaires sont effectués et certains processus sont arrêtés. La correction des deux entraîne des frais supplémentaires.
Ces problèmes peuvent être pertinents à tous les niveaux. Juste plus le niveau est élevé, plus le correctif est cher. Un exemple à l'intérieur d'une commande Scrum: un employé n'était pas sur le plan, et aucune information ne lui a été transmise, ou le produit a été défini de manière tortueuse comme défini. Tout peut arriver. En conséquence, le sprint a une tâche pour laquelle toutes les étapes n'ont pas été accomplies afin qu'il puisse être pris en compte dans le développement. Supposons que son développement soit assez simple: ils l'implémentent, puis il s'avère que cela a commencé à être fait trop tôt ou n'a pas dû être fait du tout. Le prochain niveau de plaisir est la gestion de la communication entre les équipes ou les départements.
- Je voudrais poser quelques questions. Dites-moi, s'il vous plaît, votre parcours est-il initialement original ou non?
- Non. Je n'ai jamais écrit de ligne de code de ma vie. Eh bien, peut-être à BASIC lors d'un cours d'informatique en 6e année il y a 100 ans. Dans mon travail, ce n'est pas un facteur clé.
- Beaucoup de gens sont en désaccord sur cette question. Pensez-vous qu'avoir une formation technique vous aidera à devenir un meilleur chef de produit?
"Cela vous aidera à mettre le nez dans les affaires de vos développeurs." Si cela les aide, c'est un plus. Si cela les empêche, vous ou vous, de faire votre travail plus rapidement et plus efficacement, alors c'est un inconvénient. Dans tous les cas, le produit n'est pas un loup solitaire. J'adore le dicton de Game of Thrones: Quand l'hiver arrive, le loup solitaire meurt mais la meute survit. Il s'agit de la valeur du jeu dans une équipe. Je n'ai pas besoin de connaître JavaScript, mais ils ont besoin de savoir comment remplir un dossier d'épicerie.
- Si vous ne comprenez pas bien un sujet, vous posez des questions à votre équipe et prenez des décisions en fonction de leurs réponses?
- C'est exactement ce qui se passe. Je suis convaincu que nous faisons maintenant la chose la plus importante et je sais combien cela coûte. Je dois toujours garder à l'esprit et corréler la complexité avec le résultat.
Ceci est défini à chaque étape par un système d'équilibres particulier, où vous devez regarder s'il est trop coûteux de franchir cette étape par rapport à la valeur qui en sortira, et si vous n'avez pas manqué une étape à partir de laquelle vous pouvez obtenir beaucoup de valeur et en même temps faire c'est pas cher. Le point important ici est que je détermine le montant de la valeur obtenue - c'est mon solde. Et combien cela coûte, les développeurs pèsent. Nous communiquons et déterminons quelle étape prendre.
- Autrement dit, la situation suivante est possible: vous effectuez des recherches et trouvez un point où la valeur est énorme. Ensuite, vous venez donner le problème ou la solution décrit, et les développeurs vous disent que le poids est trop grand et incommensurable. Ensuite, vous pouvez refuser de poursuivre les travaux sur cette décision, non?
- Dans une telle situation, tout espoir est pour les développeurs, car la valeur unitaire ne peut pas être modifiée. Mais il y a peut-être une chance de changer le coût unitaire.
Cela revient souvent à la façon dont vous formulez le problème. Vous pouvez dire: «Nous devons nous assurer que la sous-tâche répétitive peut être copiée dans la tâche répétitive.» Et vous pouvez aller un peu de l'autre côté: "Nous essayons de résoudre un problème quand il y a une sous-tâche et nous devons le faire pour qu'il soit créé et mémorisé avec une certaine régularité dans la tâche parent."
Les tâches énoncées semblent très similaires. Mais dans le premier cas, je dis aux développeurs qu'ils doivent réparer le mécanisme existant des tâches répétitives, et dans le second cas, je ne fais pas une telle restriction. Et aussi la sémantique. Pas «nécessaire», mais «nous». Cela fonctionne bien pour venir avec un problème, et comment le résoudre est le domaine de responsabilité de l'équipe. C'est leur liberté créatrice et leur possibilité de réalisation de soi.
- Et s'ils proposent plusieurs solutions au problème, alors qui estime le mieux? Timlide?
- Je l'apprécie. De plus, si je ne comprends pas quelle solution est la plus efficace, cela signifie que je n'ai pas posé à l'équipe les questions nécessaires. Cela m'amène d'ailleurs à un sujet très important - à propos de l'équipe. Il est important de placer l'équipe au-dessus du but.
Dans certains cas, bien sûr, des exceptions peuvent être faites. Si, par exemple, un délai très serré est fixé, qui est fixé de l'extérieur: développement urgent pour un gros client, release pour un partenaire stratégique, avec lequel il faut synchroniser la sortie d'intégration, etc. Ensuite, nous devons juste nous asseoir et le faire.
Mais le plus souvent, vous vous rendez compte que le délai est un peu plus doux que le train qui se rend à la réunion. Ensuite, vous devez choisir le côté de l'équipe. Dans Wrike, je le ressens vraiment, car il est plus coûteux de secouer une équipe que de changer un produit.