FAQ de l’équipe produit

De temps en temps, l’un de mes articles semble faire écho, et ce dernier sur la différence entre les équipes de produits et les équipes de fonctionnalités semble certainement le faire. Je suis reconnaissant de la réponse très positive. Ce matin, je me suis réveillé avec plus d’une centaine de personnes qui ont pris le temps de m’envoyer un e-mail de remerciement personnel, et souvent avec des questions de suivi.

Comme c’est ma pratique (et celle que je préconise pour les chefs de produit en général), j’aime considérer les questions, essayer de trouver une réponse utile, puis la partager afin que tout le monde avec cette question, y compris à l’avenir, puisse bénéficier de la boîte de dialogue.

– Vous avez dit que le concepteur est responsable de l’utilisabilité et que les ingénieurs sont responsables de la faisabilité, mais est-ce vraiment pour cela qu’ils sont là?

C’est extrêmement important, et je sais que je dois en écrire davantage. J’ai essayé de saisir une partie de cela dans le récent article sur ce que l’on entend par véritable collaboration, mais permettez-moi d’être très clair: la conception ne se limite pas à la convivialité et l’ingénierie ne se limite pas à la faisabilité.

Je reviendrai sur ce point dans une minute, mais je voudrais d’abord répondre à ce que j’essayais de faire valoir.

Si quelque chose est expédié par l’une des sociétés que je conseille et qu’il est pratiquement inutilisable en raison d’une mauvaise conception (ce qui, comme nous le savons tous, arrive parfois), vous pouvez parier que je vais directement chez le concepteur et lui demande comment cela s’est produit? Il appartient absolument au concepteur de s’assurer que cela ne se produise pas, donc quelque chose s’est mal passé.

De même, si le produit est livré et que les performances sont terribles, vous pouvez parier que je vais directement au responsable technique avec la même question.

Et le plus souvent, si quelque chose est expédié et que les analyses montrent qu’il n’est pas acheté ou non utilisé, ou s’il s’avère qu’il viole certaines contraintes commerciales telles que la conformité ou la confidentialité, vous pouvez parier que je vais directement au chef de produit avec cette question.

Sachez qu’en tant que conseiller, je n’ai aucun pouvoir ni contrôle réels. Mais la plupart des équipes savent que mon seul objectif est de les aider à devenir une équipe plus efficace, et ce sont des opportunités d’apprentissage de premier ordre et je ne vais pas les laisser passer.

Il est donc essentiel, pour une équipe de produits autonome, que nous possédions les compétences dont nous avons besoin et que ces personnes soient responsables de leur travail.

Tout cela étant dit, et pour revenir au cœur de la question, la manière dont nous proposons de bonnes solutions consiste en un intense va-et-vient.

Les concepteurs ont souvent des idées basées sur une compréhension approfondie de nos utilisateurs et de leurs comportements qui nous conduisent dans une direction différente en termes de problème que nous résolvons ou de notre approche du problème. Ces informations auront souvent un impact important sur la valeur et des impacts indirects sur des choses comme les performances.

De même, des ingénieurs solides ont une connaissance approfondie de la technologie habilitante qui nous conduit souvent à des solutions entièrement différentes aux problèmes qui nous ont été attribués, souvent bien mieux que tout ce que le chef de produit, le concepteur ou en particulier le client aurait pu imaginer.

Si je devais choisir la seule chose que j’aime le plus dans le sentiment de travailler dans une équipe de produits véritablement autonome, c’est la forme de magie qui se produit lorsque vous avez des gens qui sont a) motivés et b) qualifiés dans leur discipline respective – produit, conception et ingénierie – et ils s’assoient autour d’un prototype ou regardent un utilisateur interagir avec notre prototype, et l’ingénieur souligne de nouvelles possibilités, et le concepteur souligne différentes expériences potentielles, et le chef de produit pèse sur les ventes ou les finances ou implications liées à la vie privée, et après avoir exploré un tas d’approches, ils en trouvent une qui fonctionne réellement – elle est précieuse, elle est utilisable, c’est faisable et c’est viable.

J’espère donc que cela montre clairement qu’il s’agit de deux points différents mais liés. Oui, le concepteur est responsable d’assurer un produit utilisable; et oui, l’ingénieur est responsable d’assurer un produit réalisable; mais l’élaboration de ce produit nécessite leur gamme complète de compétences.

– Pouvez-vous résumer les différences entre les équipes de livraison, de fonctionnalité et de produit?

Équipes de livraison ne sont pas interfonctionnelles (essentiellement des développeurs plus un propriétaire de produit administrateur de backlog), ils ne sont pas axés sur les résultats (ils concernent tous la sortie), et ils ne sont pas autorisés (ils sont là pour coder et expédier).

Équipes vedettes sont généralement interfonctionnelles (au moins une certaine forme de concepteur et une certaine forme de chef de produit), mais elles sont toujours axées sur la production et ne sont pas habilitées.

Équipes de produits sont interfonctionnels, ciblés et mesurés par les résultats, et habilités à proposer des solutions qui fonctionnent.

– Pouvons-nous avoir une équipe de produits autonome sans un chef de produit compétent?

Dans l’article Empowered Product Teams, j’ai essayé de décrire le contexte qui doit être en place pour que les équipes habilitées se produisent, mais l’un des éléments les plus critiques est que les équipes produit habilitées dépendent d’un chef de produit compétent. Sans cela, le premier problème est qu’il est peu probable que l’équipe soit confiée par la direction. Le deuxième problème est que l’équipe ne disposera pas de l’ensemble des compétences nécessaires pour trouver des solutions aux problèmes qui lui ont été demandés. Et je crois également que le manque d’un chef de produit compétent est l’obstacle le plus courant à des équipes de produits autonomes. Veuillez noter que je tiens le chef de produit responsable de s’assurer que chaque équipe produit a un chef de produit compétent.

– Je ne suis toujours pas à l’aise avec le concept de chef de produit en tant que PDG du produit.

Dans l’article, je souligne que le chef de produit est responsable de valeur et viabilité. C’est de là que vient cette analogie, et pour ceux qui ont été fondateurs ou PDG d’une startup, vous savez que c’est le cœur du métier. C’est pourquoi je continue de croire qu’il s’agit d’une analogie importante et pertinente. Si cette responsabilité vous fait vraiment peur, envisagez la possibilité que vous soyez plus à l’aise en tant que chef de produit d’une équipe technique.

– Pourquoi les gens seraient-ils contrariés?

Je passe une grande partie de mon temps sous une forme ou une autre à encadrer des chefs de produit et des chefs de produit, et je continue de rencontrer des chefs de produit qui ne font pas le travail dont ils ont besoin. Je leur demande souvent où ils ont appris le produit et ils citent souvent des livres, des conférences et des cours de formation.

J’ai été très public en dénonçant le problème que nous avons lorsque les chefs de produit pensent qu’une classe CSPO leur apprendra le travail sur le produit, mais c’est bien pire que cela.

Il existe de nombreux endroits aujourd’hui qui offrent une «formation en gestion de produits», et certains promeuvent même leurs «programmes de certification», mais quand je rencontre des gens qui ont suivi bon nombre de ces programmes, puis quand je suis incrédule, je regarde le programme, il devient clair moi qu’ils apprenaient comment être un chef de produit d’une équipe de fonctionnalités.

Au cours des dernières années, alors que l’importance du produit est devenue plus largement reconnue, la formation des chefs de produit est devenue une entreprise relativement importante. Et je savais que mon article appellerait essentiellement des conneries sur bon nombre de ces programmes.

Je tiens à être clair, au cours des dernières années, il y a eu quelques livres vraiment bons et des conférences qui sont sortis, et je fais ce que je peux pour les promouvoir. Mais ils sont minoritaires. Je ne peux même pas assister à la plupart des conférences sur les produits, car cela me fait physiquement mal d’entendre ce qui est souvent préconisé.

L’autre chose sur laquelle j’appelais des conneries, mais il est vrai que c’était un peu moins explicite dans ma note, c’était l’idée que «nous sommes tous des designers». (En passant, je trouve amusant que vous n’entendiez pas les équipes dire “nous sommes tous des développeurs”). Sur de bonnes équipes produits, nous ne sommes pas tous des designers. Nous avons la chance d’avoir un concepteur de produit professionnel. Il est vrai que nous tous (parties prenantes, chefs de produit et ingénieurs notamment) apportons contraintes au travail du concepteur, mais les bons concepteurs sont tous sur la résolution des contraintes.

– Existe-t-il un moyen d’avoir de véritables équipes de produits autonomes avec SAFe?

Je suis certain que les armées de consultants et de formateurs soutiendront oui, tout comme elles le font avec tous les autres mots à la mode qui semblent attrayants, mais je ne vois vraiment pas comment. Il s’agit d’un modèle de logiciel d’usine, et au niveau de l’équipe, il n’y a même pas de véritable chef de produit ou concepteur. Ce sont de pures équipes de livraison. J’ai écrit beaucoup plus de détails à ce sujet dans Revenge of the PMO.

– Pourquoi n’aimez-vous pas vous engager sur les réseaux sociaux / Twitter?

La vérité est qu’il y a des choses pour lesquelles Twitter est vraiment bon (comme informer les personnes qui pourraient se soucier que je viens d’écrire un nouvel article). Et il y a d’autres choses pour lesquelles Twitter est horrible (comme discuter de cet article).

Cela arrive à chaque fois. Je publie un article, et les gens citent souvent quelque chose qu’ils aiment, ce qui est bien, mais d’autres qui n’ont pas lu l’article répondront à cette citation, sans aucun contexte, et les choses dégénéreront à partir de là.

Et je pense que le médium fait ressortir le pire des gens. Le modèle d’interaction n’encourage pas le type de pensée et de dialogue nécessaire pour faire face à des problèmes difficiles (Twitter est en fait ce qui a inspiré l’article sur la nécessité pour les gens du produit de réfléchir profondément).

De plus, même lorsque je cède et que je m’engage occasionnellement, le lendemain, la semaine, le mois, l’année, les mêmes questions reviennent sans cesse. En fin de compte, il y a tellement de bêtises sur Twitter et je ne vois pas cela changer.

Tout cela pour dire que si vous souhaitez une réponse de ma part, veuillez m’envoyer un e-mail directement.