paint-brush
J'ai pris possession d'une caractéristique majeure du produit en tant que stagiaire PMby@courier
440
440

J'ai pris possession d'une caractéristique majeure du produit en tant que stagiaire PM

Courier11m2022/09/09
Read on Terminal Reader
Read this story w/o Javascript

Denis Tatar était chef de produit pour la fonction Préférences de Courier. Il a travaillé sur le projet pendant quelques mois en tant que stagiaire chez Courier. Il explique comment la stratégie de la fonctionnalité Préférences n'a pas été entièrement étoffée. La V3 des Préférences permettait uniquement aux utilisateurs d'activer/de désactiver les notifications, et les clients du monde entier pouvaient également décider si certaines notifications étaient requises ou non. Avec la V4, nous avons résolu le problème de visibilité, qui était le principal "fail" de la V3. La V4 était un bon moyen d'informer stratégiquement les utilisateurs finaux.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail

Coin Mentioned

Mention Thumbnail
featured image - J'ai pris possession d'une caractéristique majeure du produit en tant que stagiaire PM
Courier HackerNoon profile picture
0-item


* La gestion des préférences fait partie intégrante d'une excellente infrastructure de notification, ce qui en fait une pièce très importante du puzzle chez Courier. Cela signifie également qu'il y avait beaucoup d'opportunités d'apprentissage et d'acquisition d'expérience pour le stagiaire du projet, Denis Tatar. Le stage de Denis n'a duré que quelques mois, mais il a pu avoir un impact énorme en tant que chef de produit pour la fonction Préférences de Courier.


Nous voulions en savoir plus sur l'expérience de Denis, alors nous lui avons demandé s'il accepterait de travailler sur un article pour nous. Ensuite, ce qu'il a trouvé était si bon que nous avons pensé que ce serait une bonne idée de le partager avec vous tous ! Ce poste couvrira le flux de travail de Denis, de la planification à l'exécution autour du projet Préférences, ainsi que son expérience de travail avec l'équipe Courier en particulier. On va laisser Denis s'en charger à partir d'ici !

Quel était le problème?

Le problème que nous avons rencontré chez Courier était que nous offrions Préférences (V3) à nos clients, mais la stratégie de l'ensemble des fonctionnalités du produit n'était pas entièrement étoffée. Je pense que la V3 a été un excellent tremplin pour la V4, mais qu'elle présentait fondamentalement des défauts dans certaines parties de sa stratégie. Autoriser uniquement l'opt-in/out global en est un exemple. Un autre problème était que la V3 n'a pas gagné beaucoup de traction, ce qui, je pense, renvoie à l'absence d'une stratégie bien pensée.


En mai, les Préférences (V3) permettraient uniquement aux utilisateurs d'activer et de désactiver leurs préférences de choix à l'échelle mondiale. La V3 de Préférences permettait uniquement à nos clients (et à leurs clients) d'activer/désactiver les notifications, et les clients du monde entier pouvaient également décider si certaines notifications étaient requises ou non. La V3 a permis à nos clients de commencer à jouer avec l'idée d'avoir des préférences. Cependant, l'opt/in out global est un problème car il limite les options de notification des utilisateurs finaux. C'était soit tout soit rien, pas d'entre-deux. Similaire en théorie au dicton Pokémon, "Attrapez-en un, attrapez-les tous." Un problème avec cela, cependant, est l'inondation de la boîte de réception. L'opt-in global permettrait au concept d'inonder les boîtes de réception des utilisateurs finaux avec chaque notification de produit, ce qui est problématique car il peut facilement éloigner les utilisateurs de votre produit.


L'opt-in/out global a été rapidement résolu en permettant aux utilisateurs de sélectionner le contenu dont ils souhaitaient être informés et les canaux qu'ils préféraient. Cette tendance générale du marché est utilisée par des milliers d'entreprises (produits B2B et B2C), en particulier dans le domaine technologique.

Capture d'écran des préférences du produit


La visibilité est devenue un problème sérieux avec la V3. Les utilisateurs finaux n'ont jamais eu la possibilité de sélectionner le type de contenu et le canal qu'ils souhaitaient. Il serait demandé aux utilisateurs s'ils souhaitaient recevoir des notifications en général. Ne pas proposer d'options est problématique car cela limite la visibilité sur ce que vous recevrez via les notifications. Les utilisateurs finaux n'aiment pas non plus les surprises en ce qui concerne les notifications de produits. La clarté est essentielle car elle permet aux utilisateurs finaux de contrôler leurs notifications.


Avec la V4, nous avons résolu le problème de visibilité, qui était le principal "fail" de la V3. Nos clients et leurs utilisateurs finaux avaient désormais la possibilité de contrôler le contenu qu'ils recevaient et les canaux qu'ils préféraient.


La V4 était un bon moyen d'informer stratégiquement les utilisateurs finaux.

Planifier


Il y a eu trois phases que nous avons suivies en équipe lors de la création des préférences.


  1. Recherche Dans la première phase, j'ai passé un temps décent à regarder ce qui est actuellement disponible sur le marché en termes de centres de préférences. Je me posais constamment les deux questions suivantes :

    "Comment [insérer le nom de l'entreprise] gère-t-il les notifications ? À quoi ressemble leur centre de préférences ? »

    Ces questions étaient essentielles. Ils m'ont aidé à me plonger dans les recherches nécessaires, ce qui m'a aidé à saisir de nombreuses tendances importantes du marché. De toutes les tendances trouvées, il y en a une qui se démarque le plus.

  2. Tendance : la sélection de chaînes et de contenus via une disposition de style bascule/grille pour les centres de préférences est un incontournable. Cette tendance est devenue l'épine dorsale de notre projet d'été. Il était important d'offrir des options de préférence aux utilisateurs.


Au cours de cette phase, j'ai lu de nombreuses études de cas. J'ai été surpris de voir combien existaient sur ce sujet. Chacun m'a aidé à m'éclairer avec des solutions au problème auquel nous nous attaquions. J'ai appris à travers les erreurs des autres, absorbant des leçons précieuses.


Parler aux clients a été extrêmement utile dans cette phase. J'ai pu participer à de nombreux appels avec nos clients et entendre leurs points de vue sur ce problème. Je posais des questions et montrais des exemples de ce que nous avions en tête comme solution. Cela a aidé à personnaliser un POC. Mieux nous comprenons les perspectives de nos clients, plus il est facile de commencer à concevoir quelque chose qu'ils utiliseraient.


  1. Concevoir un POC J'ai vraiment apprécié cette phase. Voir la recherche devenir un véritable POC était incroyable et tellement amusant. Nous avons pris tous les commentaires que j'avais recueillis, puis avons créé plusieurs itérations de conceptions.


Une fois que nous avons créé un POC, il était essentiel de revenir vers nos clients et de s'assurer que c'était quelque chose qu'ils envisageaient pour Preferences. Nos clients étaient également des personnes agréables avec qui travailler, toujours là pour fournir leurs commentaires indispensables.


Souvent, j'avais une quantité décente de séances de remue-méninges avec Ian. Nous examinions nos recherches et ce que nos clients avaient à dire, et combinions ces sources dans un POC. Ce fut un processus perspicace auquel participer.


Cette phase a duré plusieurs semaines jusqu'à ce que nous arrivions enfin à un POC qui satisfaisait tous les clients avec qui nous avions parlé depuis mai 2022.


  1. Construire un MVP Une fois que nous avons eu un POC et des conceptions entièrement terminées, nous avons commencé à construire notre fonctionnalité de produit. Cette phase m'a appris deux leçons essentielles…


Être organisé est extrêmement important.

et...


En tant que chef de produit, vous devez garder une semaine d'avance sur votre équipe.


En travaillant chez Courrier et en déléguant des tâches, j'ai remarqué que plus vous étiez organisé, plus il était facile de travailler avec les autres. Mes compétences organisationnelles auraient un impact sur la clarté avec laquelle nos concepteurs et ingénieurs comprenaient nos objectifs et les tâches déléguées individuellement. Plus nous étions organisés, plus nous travaillions rapidement et efficacement. Décrire les tâches que notre équipe devait accomplir et expliquer pourquoi ces tâches étaient nécessaires a beaucoup aidé. Cela a apporté de la clarté à tout le monde, y compris moi-même.


La deuxième leçon ici m'a été donnée par notre PDG, Troy. Il m'a appris à quel point il était important de penser à la semaine en cours et à la suivante. Troy a soulevé cette question car, en tant que chef de produit, vous souhaitez tenir votre équipe informée des projets et des tâches en cours. Un chef de produit qui n'est pas dans cet état d'esprit peut rapidement devenir un obstacle pour son équipe. Adopter cet état d'esprit m'a apporté de la clarté et m'a rendu moins stressé par notre projet. Je passais du temps à planifier chaque semaine et à estimer où l'équipe devrait être à la fin de chaque semaine (cycle).


Ces deux leçons ont aidé lorsque nous avons construit un MVP. Nous avons progressé chaque semaine en équipe, avec les tâches de chaque semaine décrites, ainsi que les objectifs hebdomadaires que nous devions atteindre. Travailler avec l'équipe de Courier était incroyable, tout le monde était compréhensif et absolument génial. Ce que j'ai le plus aimé, c'est que tout le monde avait une opinion. Les ingénieurs et les concepteurs demandaient si des tâches spécifiques étaient prioritaires avant de les construire, ce qui nous a permis de construire le MVP et de le faire fonctionner rapidement. Ces questions ont aidé à orienter les priorités et la prise de décision.

Exécution : ce que j'ai fait exactement

Tout au long de ce stage, chaque jour était différent. Ma semaine impliquait de parler aux clients, de déléguer des tâches à nos ingénieurs et concepteurs et de prendre le temps de réfléchir à l'avenir, deux à trois semaines avant la semaine en cours. J'ai également travaillé en étroite collaboration avec les ingénieurs et les designers, assurant une grande synergie entre les deux équipes.


J'ai incarné quatre responsabilités principales tout au long de mon stage de chef de produit chez Courier :


Être l'expert interne sur ce que le marché (clients et prospects) veut dans mon domaine d'intérêt.


Être l'expert interne sur ce que la fonctionnalité de mon produit fournit déjà (et donc le delta par rapport à la responsabilité principale ci-dessus). La capacité de prioriser le chemin qui fait passer Courier de notre état actuel à notre état souhaité.


La capacité d'éduquer le reste de l'entreprise sur le produit actuel, le produit en cours de construction et notre vision ultime du produit afin que tout le monde puisse être sur la même longueur d'onde sans être des experts.

En tant que ciment qui garantit que l'équipe travaille ensemble sur la bonne chose pour les bonnes raisons, leur succès est finalement limité par mon efficacité en un et deux. Je ne peux pas éduquer avec précision mes coéquipiers sur ce que je ne comprends pas profondément moi-même.


Troy a été un mentor fantastique tout au long de mon séjour chez Courier. Il a porté ces quatre responsabilités fondamentales à mon attention, qui sont devenues partie intégrante de mon stage. Ce qui m'a le plus marqué, c'est d'être le ciment entre toutes les équipes. Au début, j'ai regardé ce concept et j'en ai été intimidé. Mais, je me suis éclaté à devenir cette figure ressemblant à de la colle entre les équipes. Ce n'était certainement pas quelque chose de facile à réaliser, mais j'ai apprécié le défi. J'ai aussi réussi à me faire beaucoup de bons amis en cours de route!

Quels compromis ai-je subis ?

Il y a eu de nombreux compromis tout au long de mon stage. Les principaux que j'ai vécus étaient liés au concept suivant "faites-le fonctionner -> faites-le bien -> faites-le vite", que j'ai souvent entendu tout au long de mon stage. Il y avait de nombreuses fois où de petites fonctionnalités qui pouvaient faire ressortir notre UI/UX ralentissaient en fait l'équipe.


De tels compromis étaient nécessaires. Ils m'ont demandé si nous nous concentrions sur les moindres détails ou si nous mettions de côté la fonctionnalité et nous concentrions sur la fabrication d'un produit qui fonctionne et fait le travail ? La dernière partie de cette question a souvent été choisie comme notre stratégie. Il est difficile de passer ces appels parce que vous savez que l'équipe peut développer une construction de produit exceptionnelle avec des composants UI/UX phénoménaux, mais notre construction doit accomplir ce qu'elle est censée faire en premier lieu.


L'objectif principal était de publier notre MVP, de nous assurer que nous avions les commentaires des clients, d'améliorer toutes les fonctionnalités de base, puis de nous concentrer sur les priorités mineures qui affectent l'interface utilisateur/UX de ce produit.

Comment était-ce de travailler avec l'équipe ?

J'ai eu beaucoup de plaisir à travailler avec l'équipe Lifecycle sur les préférences. Tout le monde était si gentil et a offert des commentaires fantastiques. Je l'ai mentionné à plusieurs reprises au bureau et lors d'appels avec des collègues. Travailler chez Courier ne ressemblait pas à du travail; j'avais l'impression de travailler sur un projet parallèle avec des amis proches. Je pense sincèrement que c'est pour cela que j'ai pu produire le travail que j'ai fait chez Courier, à cause de l'environnement. Courier est facile à vivre, extrêmement amical et axé sur les résultats.


Une autre chose que j'aimais vraiment dans l'équipe était qu'ils pensaient toujours à moi. S'il y avait des tâches que les ingénieurs ou les concepteurs feraient qui étaient considérées comme une «norme» pour eux, ils me demanderaient si j'aimerais essayer de voir à quoi ça ressemble. J'en ai trois exemples.


Lors de la conception d'une info-bulle spécifique pour une partie du projet Préférences, Ian (Senior Designer) lors d'un de nos appels, m'a demandé si je voulais essayer de concevoir une info-bulle. Cela impliquait de travailler avec Frames in Figma, un concept avec lequel je n'ai jamais travaillé. J'ai vraiment aimé créer cette info-bulle. Cela m'a fait me sentir inclus.


Chaque semaine, l'équipe organisait nos réunions de planification du cycle de vie. Nous parlions de billets et les écrivions. C'était au début de mon stage lorsque Suhas (ingénieur senior) m'a demandé si je voulais essayer de rédiger plusieurs tickets sur Linear. J'étais conscient que c'était quelque chose que la plupart des PM feraient normalement, mais j'avais beaucoup de respect pour Suhas pour avoir soulevé cette question et j'étais prêt à m'apprendre à créer correctement des tickets dans Linear.


Une fois que l'équipe avait quelque chose de solidifié pour Preferences, j'ai commencé à demander en interne pour savoir s'il y avait des entreprises qui seraient intéressées à entendre parler de mon projet. Nathan (responsable de compte) m'a contacté pour me faire part d'un client intéressé par cette fonctionnalité du produit. Nathan m'a encouragé une tonne quand il s'agissait de communiquer avec ce client. J'ai pu sortir de ma zone de confort grâce aux encouragements de Nathan. Je n'ai jamais eu l'occasion de parler à un client auparavant dans aucune de mes expériences de stage précédentes, et j'ai beaucoup appris sur les clients et la façon dont ils perçoivent Courier.


Notez que ce ne sont là que trois exemples des nombreuses opportunités comme celle-ci tout au long de mon stage. Je tiens à remercier Ian, Suhas et Nathan. J'apprécie que vous me donniez des opportunités d'apprendre et de grandir, cela signifie le monde pour moi.

Comment ai-je travaillé avec les designers ?

J'ai aimé travailler avec Ian (Senior Designer). Nous aurions des réunions impromptues grâce à la fonctionnalité « Huddle » de Slack (qui a été renommée en interne en « Huggle » à cause d'une faute de frappe que j'ai faite une fois et qui est restée bloquée). Ces réunions étaient vraiment formidables pour le brainstorming et la conception de produits. Parfois, Ian et moi avions des appels plus tard dans la nuit parce qu'il était plus facile de trouver des idées plus créatives. . C'est quelque chose que je n'oublierai jamais.


Lorsque je travaillais avec Ian, j'essayais de rendre les choses aussi simples que possible. Je créerais une liste de tâches via Google docs ou Slack, afin que Ian et moi sachions ce qui devait être accompli chaque semaine.


Lors de nos appels, Ian et moi parlions aussi de beaucoup de sujets différents pas toujours directement liés au travail, ce qui était super. Cela a vraiment aidé à construire notre amitié, ce qui a rendu la collaboration beaucoup plus facile et la création d'une interface utilisateur/UX propre pour les préférences. Je fais souvent une quantité décente de conception de produits en dehors des heures de travail, et Ian me donnait toujours des conseils phénoménaux sur la conception de produits et sur Figma !

Comment ai-je travaillé avec des ingénieurs ?

J'en ai brièvement parlé, mais lorsque je travaillais avec des ingénieurs, j'aidais à créer des tickets et à organiser à quoi ressemblerait chaque semaine. J'aidais nos ingénieurs chaque fois qu'ils étaient confus à propos de tout ce qui concernait les préférences et leur expliquais comment j'avais trouvé des noms spécifiques, pourquoi Ian et moi concevions certaines parties de notre produit et les objectifs derrière ces conceptions. Beaucoup de ces réponses sont venues de mon processus de recherche approfondi avec des clients qui étaient intéressés par les Préférences.


En travaillant avec des ingénieurs, j'ai beaucoup appris sur la façon de décomposer correctement les tickets (eipcs) dans Linear. Je pensais avoir une bonne maîtrise avant de travailler chez Courier, mais j'ai appris beaucoup plus après avoir travaillé avec l'équipe Lifecycle. La clé pour décomposer les tickets est de pouvoir réfléchir à chaque détail avec les ingénieurs. Être dans un petit groupe tout en faisant cela était super important car chaque individu a aidé à apporter une perspective très importante sur la façon de décomposer les tickets.


Pendant mon stage, Seth (Chief Technology Officer), Suhas (Senior Software Engineer) et Christian (Software Engineer) m'ont encouragé à parler à l'équipe Developer Experience de Courier et à leur montrer notre projet. L'objectif principal derrière cela était de tester pour voir si l'interface utilisateur/UX des préférences était intuitive si la conception avait du sens et si l'équipe de l'expérience développeur comprenait l'objectif derrière cette fonctionnalité du produit. J'ai préparé un diaporama expliquant notre projet dans son intégralité. Ce fut une expérience formidable car cela m'a aidé à me préparer à vendre des préférences à nos clients. Faire des présentations perspicaces sur les produits et « vendre » votre produit aux clients est une compétence tellement importante et négligée pour les chefs de produit . Parler à des gens en interne m'a également aidé à pratiquer et à affiner cette compétence.

Comment ai-je résolu le problème ?


Avant les Préférences V4, les clients n'avaient pas la possibilité de choisir le contenu dont ils aimeraient entendre parler et comment ils aimeraient en entendre parler. Avec les préférences V4, les utilisateurs peuvent désormais exprimer leurs opinions sur ces deux questions. Cette nouvelle fonctionnalité du produit permet aux clients de choisir ce qu'ils aiment et dont ils veulent entendre parler. Plus précisément à travers leurs préférences de canaux.

Fini le temps où les boîtes de réception étaient encombrées et où les clients étaient agacés par le nombre de notifications qu'ils recevaient. Les préférences minimisent la frustration ressentie par les utilisateurs finaux avec leurs notifications.


Vous souhaitez postuler pour un poste chez Courier ? Consultez notre page carrières . Pour découvrir ce que Denis a aidé à mettre en place, demandez une démo ici et demandez à voir la fonctionnalité Préférences.