Ethan Ding de TextQL : Les 5 habitudes qui peuvent accélérer le cycle de développement produit

Avez-vous des mentors ou des expériences qui ont particulièrement influencé votre approche du développement produit et de l'expérience utilisateur ?

Au cours de ma carrière, j'ai croisé plusieurs leaders en ingénierie talentueux, du type à dire des choses comme « comment ce projet peut-il prendre 3 mois à l'équipe—je peux le faire moi-même en un week-end ! » Cela caractérise la façon dont nous développons les choses chez TextQL. Chaque fois que nous planifions un produit, nous nous efforçons de réaliser les tâches en moitié moins de temps que ce qui a été estimé pour le projet.

On dit parfois que nos erreurs sont nos meilleurs enseignants. Pouvez-vous partager l'erreur la plus drôle que vous ayez faite à vos débuts ? Quelle leçon en avez-vous tirée ?

Au début, j’ai organisé beaucoup d’appels juste pour demander conseil à des personnes à succès, mais je ne savais pas vraiment quelles questions poser. Quand j'étais au téléphone, je restais silencieux avec le CEO d'une entreprise licorne. Aujourd’hui, j’apprécie d’autant plus la gestion de mon temps. Je remarque que ceux qui accordent le plus de valeur à leur temps demandent toujours quel est l’objectif de chaque réunion. J’ai appris qu’il est important de respecter le temps des autres.

Quel a été selon vous le moment « phare » de votre carrière ? Nous aimerions connaître le contexte, ce qui s’est passé, et l’impact que cela a eu sur votre parcours.

Lorsque le COVID a débuté, mon stage a été annulé. Je n’ai plus eu de nouvelles. Le fonds de capital-risque qui m’avait présenté à cette entreprise a fini par m’embaucher sur un projet d’été, puis m’a recruté pour un an ensuite. Ce poste m’a donné le goût d’entreprendre et m’a permis de rejoindre l’entreprise où j’ai travaillé par la suite.

Pouvez-vous nous raconter une période difficile à vos débuts ? Avez-vous envisagé d’abandonner ? Où avez-vous puisé la force de continuer malgré les difficultés ?

J’ai réalisé que nous avons lancé notre levée de fonds à la période la plus compliquée—pendant Noël, quand la plupart des gens prennent des vacances. À ce moment-là, j’ai compris que mon visa expirait en janvier. J’ai reçu au moins deux douzaines de refus de VCs car, à l’approche de Noël, plus aucun VC ne travaillait. Mais le simple fait de ne pas vouloir être expulsé m’a poussé à persévérer ; nous avons continué, et nous avons obtenu une lettre d’intention avant Noël.

Comment faites-vous pour rester à la pointe des tendances et évolutions du secteur du management produit ?

Twitter.

Quel rôle joue la collaboration interdisciplinaire dans l'accélération des cycles de développement produit, et comment favorisez-vous une collaboration efficace entre les différentes équipes et départements ?

Je pense qu’il ne faut construire aucune fonctionnalité tant que le client n’a pas engagé de capital pour celle-ci. Attendez d’avoir cet engagement avant de développer quoi que ce soit. Il appartient aux équipes commerciales de ne promettre des choses que si l'effort à fournir pour les réaliser en vaut la peine. Toute l’équipe doit être alignée sur ce principe.

D’après votre expérience, quelles sont « Les 5 habitudes qui accélèrent les cycles de développement produit » ?

1 . Utilisez intensément votre propre produit — parce qu'innombrables sont les choses qui peuvent mal tourner et que vous ne pouvez pas anticiper. Il ne faut pas que ces surprises vous échappent.

2 . Échangez avec les ingénieurs pour déterminer ce qui est réellement nécessaire dans les estimations. Les bons ingénieurs anticipent beaucoup de problèmes potentiels dans le futur, ce qui les pousse parfois à surestimer le temps nécessaire à l’aboutissement d’un projet. Nous avons réduit un projet de deux mois à une semaine en procédant ainsi.

3 . Soyez franc lors des discussions avec les clients. Cela change le ton d’une conversation lorsque vous savez si vous pouvez réellement les aider. Lors des phases de découverte, donnez-leur la possibilité de se rétracter, pour éviter de consacrer du temps à élaborer des solutions qui n’aboutiraient nulle part.

4 . Limitez dans le temps les preuves de concept. Cela vous aide à éviter de passer énormément de temps à ajouter de nombreuses fonctionnalités à quelque chose dont vous n'êtes pas sûr qu'il fonctionnera.

5 . Demandez aux clients combien ils sont prêts à payer. Si le montant qu'ils sont prêts à débourser ne dépasse pas le coût de développement, il est probable que votre client préférera que vous travailliez sur autre chose.

Quelles sont certaines des erreurs courantes que vous voyez les équipes produit commettre lorsqu'elles essaient d'accélérer leurs cycles de développement, et comment peuvent-elles être évitées ?

Il vous faut une seule personne responsable, chargée de la délégation, de l'attribution des responsabilités et de mener le projet. Cette personne doit se montrer confiante et maîtriser la situation, sinon vous risquez de sombrer dans une analyse interminable des décisions à prendre.

Pouvez-vous partager un exemple d'un moment où vous avez dû faire un choix difficile entre la rapidité et la qualité lors d'un cycle de développement produit, et quel a été le résultat de cette décision ?

Ce n'est jamais un choix difficile : nous privilégions toujours la rapidité. Nous sommes très satisfaits de notre processus de vente, mais nous n'avions pas une chaîne de production vraiment évolutive, et les ingénieurs n'étaient pas tous à l'aise avec le fait que tous nos cas limites n'étaient pas couverts. Malgré cela, le fait d'avoir mis si peu de temps à le mettre en ligne nous a permis de justifier l'allocation de davantage de ressources d'ingénierie pour l'améliorer et le faire évoluer de la bonne manière.

Quelle est l'importance d'une approche axée sur les données dans le développement produit, et pouvez-vous partager une histoire où les données ont significativement influencé votre processus de décision ?

Les entreprises du secteur de l'entreprise n'ont pas vraiment le choix d'adopter une approche axée sur les données pour le développement produit. Vos clients n'ont pas tant d'interactions que cela avec les produits. Les clients grands comptes savent généralement ce qu'ils font et n'ont pas besoin d'être accompagnés. S'ils sont informés qu'ils peuvent accomplir quelque chose avec un produit, ils le feront.

Pouvez-vous partager un exemple où le retour utilisateur a conduit à un changement stratégique majeur dans votre développement produit ?

L’hésitation d’un client à payer nous a amenés à complètement réinitialiser un produit en cours de développement et à revoir nos priorités fixées. Cela s’est produit d’autres fois avec des prospects également. Si vous n’êtes pas à l’aise d’aborder la question du paiement, c’est pour une raison : c’est que vous savez que votre produit ne résout pas vraiment leur problème.

Y a-t-il une personne dans le monde avec qui vous aimeriez avoir un petit-déjeuner ou un déjeuner privé, et pourquoi ?

DJ D-Sol (David Solomon). Il a l’air d’être quelqu’un de cool qui sait s’amuser, malgré une très grande responsabilité qui pèse sur ses épaules en permanence.

Pour plus de contenu comme celui-ci, abonnez-vous à la newsletter du Chef de Produit.