Construction et autres sujets

Au cours des deux dernières années, 31 832 personnes ont postulé pour devenir chef de produit chez Whatnot. Nous en avons embauché un. Vous avez deux fois plus de chances de réussir un trou d'un coup que d'obtenir un emploi en postulant simplement.

Ce n'est pas un échec de processus. Je construis des produits – et des équipes produit – depuis plus d'une décennie, et l'un des plus grands facteurs qui m'a poussé à rejoindre Whatnot il y a environ 3 ans était la culture produit très délibérée culture produit. Personne ne sait ce que signifie être PM dans le monde de l'IA, mais tout ce que je vois indique que l'industrie se dirige vers nous et notre façon de construire ici – car aucun outil ne vous rendra utile si vous ne faites pas le bon travail.

D'abord, il faut reconnaître : le PM moyen est profondément moyen.

La fonction produit est née en réponse à l'échelle – les équipes d'ingénierie sont devenues trop grandes pour que les PDG ou directeurs généraux les gèrent directement, d'où le besoin d'un conduit entre levier entre le business et la tech. Au fil du temps, nous avons paresseusement généralisé le rôle en « chaque fois que vous embauchez un Engineering Manager, vous embauchez un PM ». Mais là où un Directeur d'ingénierie gérait 30-40 personnes via ses EM, un Directeur PM n'en gérait que cinq. Les incitations régissent le monde, donc le travail de ces directeurs est devenu « justifier la croissance de l'augmentation des effectifs de mes partenaires d'ingénierie » pour pouvoir, à leur tour, augmenter les leurs et devenir VP. Lentement, le rôle des PM juniors est passé de « PDG d'un produit » à « baby-sitters de boutons » et les ingénieurs orientés produit sont devenus des preneurs d'ordres infantilisés.

Puis le COVID a frappé et l'industrie a embauché un nombre ahurissant de 500 000 nouveaux ingénieurs logiciels en seulement quatre ans, et environ 80 000 nouveaux PM ont été créés pour correspondre. Cela fait 80 000 PM enfouis dans des équipes gargantuesques chez FAANG, loin de tout client, à 50 couches de la réunion où ça se passe, formés à faire du PM au numéro dans une école de produit, à une époque de croissance d'engagement non méritée où tout semblait fonctionner.

La probabilité que quelqu'un en ressorte avec de grands instincts produit, de l'expérience et du cran semble en fait moins probable que de réussir un trou d'un coup.

Deuxièmement : nous avons rendu nos meilleurs éléments, pires.

Quand votre travail consiste à superviser cinq personnes, tout ce que vous pouvez faire de votre journée est de vous mêler du travail des autres. Ils n'aiment pas ça et le qualifient cela de micro-gestion dans un sondage anonyme, alors vous reculez. Comment passez-vous votre temps ? Vous racontez des histoires, guidez les choses travers les revues pour que vos équipes « réussissent », justifiez les ressources. Mais vous ne savez pas quelle histoire raconter, alors vous mettez en place une équipe de recherche utilisateur pour vous dire les tâches à accomplir, puis une fonction PMM pour raconter cette histoire aux clients. La fonction qui était devenue stratégiquement importante parce qu'elle rassembl'importance parce qu'elle rassemblait du contexte et diffusait la clarté s'est abstraite dans des tours d'ivoire de plus en plus hautes.

Mais la vérité réelle se trouve dans les modèles de données de vos systèmes, dans les appels commerciaux, les tickets CX, dans les analyses – pas dans le joli 2x2x2 fait pour tout simplifier.

Tout le temps que vous passez à faire du management signifie que votre compréhension innée des problèmes devient obsolète, vos instincts pour votre client s'émoussent, la probabilité que vous ayez raison diminue.

Notre moyenne au bâton en tant que fonction a chuté à la fois parce que le dénominateur s'est élargi ET parce que cette expansion a fait que tous ceux qui étaient bons en produit il y a sept ans ont été promus hors du travail réel (ou sont devenus assez riches pour que l'incitation à rester et à faire de la politique soit faible).

La méthode Whatnot

Depuis ses débuts, l'équipe produit de Whatnot repose sur un principe assez simple : nous regrettons que la gestion de produit existe. Les ventes et l'ingénierie s'en sortaient très bien avant notre embauche, donc là où elles le peuvent, elles devraient simplement livrer sans barrières procédurales ni paperasse inutile. Le produit est un métier, pas une qualification. Quiconque le fait bien a appris en faisant et en côtoyant des côtés de gens formidables qui le font.

J'étais récemment dans un entretien où quelqu'un m'a dit que Whatnot ressemblait à Twitch et eBay qui auraient un bébé – culturellement, c'est impossible, mais en termes de périmètre produit, c'est une comparaison décente. Une estimation prudente dit que ces deux organisations combinées ont plus de 400 PM. Nous en avons 20. 20 PM pour plus de 1200 employés au total.

Nos PM sont associés à des problèmes, pas à des EM. Ces deux choses se chevauchent souvent, mais ne sont pas identiques. Si vous construisez un nouveau format de vente pour les vendeurs de mode, vous serez en étroite collaboration avec les EM qui gèrent comment les annonces et l'inventaire fonctionnent, mais aussi avec les EM de la logistique et des paiements.

Devoir travailler sur plusieurs stacks et peser les impacts sur différents clients n'est pas facile – cela nécessite une large contexte de l'entreprise, la capacité de prévoir les impacts en aval des modifications apportées à toute fonctionnalité, la maîtrise changement de contexte, la capacité de construire et de dépenser la confiance dans toute une organisation plutôt qu'avec un seul partenaire. C'est pourquoi nous embauchons presque exclusivement des PM seniors. Des PM qui en ont assez des réunions d'alignement sans fin et qui brûlent de reconstruire. Ou nous convertissons des talents prometteurs des ventes ou de l'exploitation et les laissons apprendre en faisant. Nous cherchons toujours le trou d'un coup en milieu de carrière (L5/L6, mais les statistiques ne mentent pas sur la fréquence à laquelle nous les trouvons.

Enfin, tout le monde livre, y compris moi. Je travaille toujours directement avec une équipe d'ingénieurs et de designers pour livrer des fonctionnalités en tant qu'IC, et nos deux cofondateurs aussi. Quand il a fallu tester s'il était possible pour les PM de « vibecoder » de petites fonctionnalités, j'ai été le cobaye. Quand il a fallu intégrer notre premier vendeur en Australie, c'est notre cofondateur Logan qui l'a fait. Quand Zendesk a commencé à laisser tomber des tickets clients, c'est notre PDG Grant qui parlait à leur ingénieur support.

En tant qu'entreprise, nous exigeons que chaque employé vende, achète et traite des tickets CX ou nous leur donnons une évaluation en dessous des attentes. Si les PM doivent diriger dans une entreprise avec un tel engagement envers la centricité client, nous devons être profonds dans le comment des choses fonctionnent les choses et larges dans le pourquoi. Nous appelons cela « être en forme de T » – avoir une largeur de contexte et la profondeur de votre domaine, simultanément. La profondeur et l'expérience vous permettent de prendre des décisions rapidement, et ne pas avoir à attendre 5 niveaux de direction pour les décisions deviennent des actions.

Membres du personnel technique

Il y a tellement de bruit en ce moment sur « construire »... Non, les documents d'exigences produit ne sont pas morts. Un PRD n'est qu'un récipient pour réfléchir clairement à un problème et l'articuler aux autres. Rendez le vôtre le vôtre interactif si vous voulez, personne ne s'en soucie. Non, le coût de livrer un mauvais produit n'est pas tombé à zéro, il est toujours payé par vos clients. Leur jeter des pâtes 16 fois plus vite n'est pas, en fait, une révolution, c'est simplement agaçant. Et non, tout le monde ne va pas être un ingénieur de niveau S, un designer et un PM tout en un. Quelques-uns le seront, mais les mêmes moteurs de spécialisation – ce que les gens aiment et ce dans quoi ils sont bons – continueront à guider notre travail.

Ce qui change, c'est la prise de conscience qu'être un IC est une bien meilleure utilisation des compétences, l'expérience et le temps limité sur cette terre que de rédiger le même document pour la 5ème fois pour correspondre au formatage préféré des pédants. Quelques PM chez Whatnot sont des managers, mais chacun d'eux passe 90%+ de son temps en tant qu'IC. Il n'y a pas de distinction dans nos titres ou notre rémunération pour ceux qui gèrent ou non, car nous ne voyons aucune vertu inhérente à cela. L'IA nous donne un levier incroyable – je peux aller plus vite dans presque chaque tâche du processus de développement, que ce soit comprendre des données qui nécessitaient auparavant un data scientist pour les démêler ou transformer un PRD en toutes les permutations de SOP CX qui auraient normalement feraient l'objet de longues nuits au bureau la semaine de lancement. Je peux construire un bot pour trier les 100 questions par semaine des ventes ou pour trouver les lacunes de localisation que nous avons laissées dans une expérience récente.

La chose la chose la plus perturbatrice de l'IA pour les PM est qu'elle a montré que le levier du coaching des gens et du travail travers d'eux n'est plus la source unique source de levier qu'il était autrefois. Surtout si ces personnes sont – par leur propre faute – profondément moyennes. Mais ce levier n'est disponible que pour les personnes qui savent encore faire le travail.

Ce qui est particulièrement encourageant dans cette tendance, c'est qu'elle va attirer les meilleurs PM à revenir au travail de PM réel. La réflexion sur les besoins du client et de l'entreprise et le bon goût pour résoudre le problème de la meilleure façon. En tant que client d'autres entreprises, je suis ravi de voir les luminaires de notre industrie revenir à la construction – cela va rendre leurs produits meilleurs. En tant que passionné par la construction de la plus petite et la plus fortement équipe de PM de l'histoire, je suis ravi que cela libère les humains incroyables qui ont fait des revues de feuilles de feuille de route pendant cinq ans.

Montrez, ne dites pas

Ci-dessous, je vais copier (en entier) l'unique document que nous avons sur la façon dont nous travaillons sur le produit chez Whatnot. Si nous nous sommes rencontrés ne serait-ce qu'une fois, vous n'aurez pas besoin que je vous dise qui est l'auteur – c'est ainsi que nous parlons et que nous travaillons.

Vous pouvez aussi regarder qui travaille dans notre équipe – il y a moins six personnes dans l'équipe aujourd'hui qui pourraient être CPO dans une startup série B-C et qui passeront leur soirée au téléphone avec des vendeurs, 400 requêtes dans un Hex Thread ou à rédiger la v1 des communications pour le lancement de demain. Ce sont quatre anciens fondateurs qui n'ont jamais, de leur vie, accepté que quelque chose soit hors de leur échappe. Ce sont quatre anciens directeurs de FAANG qui ne passent plus leurs journées à débattre de l'endroit où les gens devraient vivre dans une grille neuf boîtes. Ce sont six PM de début de début de carrière qui ont un goût incroyable, à qui on dit qu'ils doivent essayer plus de choses parce que nous n'apprenons qu'en faisant.

Je doute que notre déclaration d'un maximum de 20 PM tienne – l'opportunité devant nous chez Whatnot est si énorme que nous ne nous limiterons pas arbitrairement – mais la barre pour qui nous embauchons ne fera qu'augmenter à mesure que l'industrie et les outils d'IA continuent de récompenser les grands IC avec un levier. Si vous faites partie de ces personnes, et que ce que j'ai décrit ci-dessus est ce qui vous motive, vous trouverez comment me contacter.

Construire chez Whatnot

Construire de grands produits est difficile. Ce n'est pas seulement que vous devez avoir la bonne intuition sur le problème, les détails, le mettre sur le marché correctement, le mesurer correctement pour comprendre sa performance ou itérer rapidement. C'est que vous devez faire toutes ces choses ou ça ne marche pas. Pire, échouer est coûteux. Nous avons peu d'équipes et une énorme quantité d'opportunités devant nous – battre .300 est excellent si vous jouez en MLB, mais pour réaliser nos aspirations, nous avons besoin de près de .500. Sans une moyenne élevée, nous soit contraignons la croissance à court terme, soit nous couplons la croissance de l'entreprise à la croissance des effectifs et nous contraignons à long terme.

Ce document a 2 parties :

1. Notre philosophie – cela ne changera pas
2. Nos processus – ceux-ci évolueront et l'état actuel est conservé ici

Comment nous construisons nous donne un levier

Vous ne pouvez pas construire un bâtiment pièce par pièce, vous devez concevoir tout le bâtiment à la fois et le construire tout à la fois. Heureusement, nous ne travaillons pas dans la construction, nous travaillons dans le logiciel. Construire de manière itérative est notre superpouvoir. Nous lançons toujours la plus petite unité qui apporte une réelle valeur utilisateur et une expérience utilisateur solide, mais nous concevons les choses plus loin pour nous assurer que nous pouvons le passer réussi d'un produit ici suit 7 étapes de manière cohérentes :

1) C'est quelque chose qui compte pour les utilisateurs et notre entreprise

Priorisez impitoyablement les choses les plus impactantes qui résolvent les besoins de nos utilisateurs et commerciaux.

• Vous devez être capable d'articuler cette valeur explicitement : « permettre aux détaillants à grande échelle de vendre des produits stockés dans plusieurs endroits en un seul show – en mettant à jour 'expédié de' pour être un champ produit, pas un champ show »
• Pensez au système.

1. Ce produit est-il immédiatement utile lors de son lancement ?
2. Est-ce un 'bloc de construction' pour d'autres choses ?

Si (1) n'est pas vrai, ne continuez pas. Si (1) est vrai, trouvez comment il peut devenir (2) au fil du temps.

2) C'est quelque chose que les gens veulent

Comprenez leurs points douleur, désirs et comportements pour créer un produit pour eux.

• Vous ne savez pas cela à moins de comprendre en détail l'utilisateur pour lequel vous construisez. Mariez le qualitatif et le quantitatif.
• Pensez à votre produit dans le contexte du flux de travail produit existant.
• Ne superposez pas sur de la merde.
• Ne faites pas exploser un flux de travail qui résout le problème B parce que vous êtes concentré sur le problème A
• Si le problème est réel – savez-vous comment ils le contournent aujourd'hui ?
• Méfiez-vous des objets brillants. Surtout des objets brillants que vous avez construits ailleurs dans le passé.

3) Les besoins des clients ne s'alignent pas sur nos organigrammes / ne sont jamais satisfaits par une seule fonctionnalité.

Si vous construisez localement, vous construisez naïvement.

• Vous devez travailler à partir d'une expérience client complète, pas de la propriété du code. Allez résoudre le problème, point final.
• L'inverse est également vrai – d'autres PM devront empiéter sur « votre domaine ». Aidez-les.
• Ce principe est pourquoi nous nous efforçons d'avoir la plus petite équipe Produit et Design possible. Plus il y a de personnes dont le rôle est étroitement défini, plus les feuilles de route deviennent myopes et plus nous perdons de temps en coordination et en consultation.

4) C'est la solution la plus simple possible qui résout le problème.

La clé pour construire des produits rapides et fiables et rapides que les utilisateurs aiment est d'éviter le travail inutile et sans impact.

• Simple n'est pas seulement rapide à construire, c'est généralement aussi le plus réussi.
• Penser au système ne signifie pas construire tout le système en entier à l'avance.
• Plus vous construisez avant de savoir que vous avez raison, plus c'est cher quand vous avez tort.

5) Il a été validé avec le plus petit public possible.

Vous ne faites que deviner jusqu'à ce que quelqu'un l'utilise.

• Obtenez des prototypes papier ou cliquables entre les mains des vendeurs dès que possible. L'auto-test par les employés détecte mieux les bugs qu'il ne valide une solution car nous ne sommes pas nos clients.

• Pensez votre motion GTM
• Produits destinés aux vendeurs : commencez avec <10 vendeurs, montez en échelle par nombre de vendeurs ou quelques catégories avant le GA.
• Produits destinés aux acheteurs : commencez par une catégorie ou un petit pourcentage et montez en puissance avec le signal.
• Produits écosystémiques (visibles par les deux) : commencez par une catégorie ou un petit marché
• Si vous êtes en mode validation, résoudre la notoriété (interne ou externe) est un mode d'échec.
• C'est tellement sous-échelle que cela n'a pas vraiment d'impact sur les gens
• Vous ne savez pas encore si ça va marcher – ne perdez pas le temps des gens

6) Une fois validé, nous itérons comme des fous.

Une fois en direct chez les clients, nous livrons des améliorations hebdomadaires, voire quotidiennes.

• Si vous entendez « une fois que nous livrons X, nous pouvons passer à Y », c'est un énorme drapeau rouge.
• Une fois que nous savons que ça va être quelque chose, vous devez revenir en arrière et résoudre pour Catex et CX
• Lancez, validez, mesurez, itérez, itérez, itérez > puis passez à la priorité suivante.

7) Nous traversons les murs une fois en bêta

Obtenir une étincelle est difficile. Une fois que vous en avez une, vous devez verser du carburant ou elle mourra.

• Le plus grand risque de lancer des produits hyper-simples et hyper-précoces est qu'ils sont incomplets et donc pas vraiment utiles à long terme. Une fois que vous lancez, vous êtes contre la montre pour passer de haut potentiel à fort impact.
• Concentrez-vous sur la maximisation de la valeur que vous créez et ne gérez pas chaque plainte, risque ou répercussion mineure.
• Déterminer de quelles plaintes, risques et répercussions s'inquiéter est une question de jugement pour chaque lancement. S'inquiéter des non-risques est aussi dangereux que de négliger de s'en inquiéter.

8) Ce n'est pas The Bachelor – découplez tout

Il y a une tendance naturelle lors de la conception d'un système à vouloir livrer plusieurs parties à la fois. Dans un système suffisamment complexe comme le nôtre, il est probable que plusieurs équipes travaillent en parallèle sur des composants d'un système en parallèle et il peut sembler de les livrer ensemble pour que ce soit un grand changement plutôt que deux. C'est aussi un piège.

• Tant que chaque pièce est indépendamment viable et bénéfique pour les clients, lancez-les dès que possible
• Cela nous permet de mesurer chacune plus efficacement et de comprendre leurs contributions relatives
• Laisser des produits bénéfiques en attente dans staging pour un autre est mauvais pour les clients

Le rôle des revues et des retours

Nous avons documenté un processus produit dont l'intention est de nous assurer que nous travaillons sur les bonnes choses et de la bonne manière. Cela inclut des fonctions de visibilité, d'approbation et de responsabilité. Plus important que de suivre aveuglément ce processus est d'intérioriser la philosophie sous-jacente – qui est bien articulée dans ce fil Twitter… (sérieusement, lisez-le avant de continuer)

1. Dans un système complexe, vous avez besoin de beaucoup plus d'alignement que vous ne le pensez pour arriver à la bonne réponse. Parce que ce mot peut être mal interprété :
2. L'alignement ne signifie jamais consensus. Le consensus est l'ennemi de la bonne prise de décision.
3. L'alignement ne signifie pas coupler les flux de travail. La coordination est l'ennemie de la vitesse.
4. Le test décisif de l'alignement – un plan écrit. Si Grant en demande un, nous ne sommes pas alignés.
5. L'autonomie chez Whatnot est l'autonomie de mise en œuvre. Personne n'a ou ne devrait attendre l'autonomie de la stratégie. Sans alignement, l'autonomie est gaspillée.

Pour répondre aux attentes chez Whatnot, un PM ou un Designer

1. Identifie immédiatement les choses qui nécessitent un alignement et le recherche activement
2. Passe rapidement de l'alignement à la mise en œuvre parce qu'ils comprennent profondément la discussion et l'alignement. Ils n'écoutent pas un 'oui' dans les discussions.
3. Peut remplir les détails de mise en œuvre avec leur équipe / débloquer rapidement les décisions qui suivent l'alignement.

Pourquoi la vitesse compte

Tout notre système repose sur la maximisation de la vitesse de livraison de la bonne chose. Les étapes 1-3 du chemin heureux concernent la détermination de ce que nous pensons être la bonne chose, 4-7 comment nous validons, itérons et passons à l'échelle. Nous faisons cela parce que :

1) Tout dans notre système se compose – le bon et le mauvais

En 2025, nous avons mené 750 expériences sur environ 250 jours ouvrables, ce qui donne environ 3 décisions de livrer/ne pas livrer par jour. Si vous simulez l'impact à long terme de prendre chacune de ces décisions seulement 3 jours calendaires plus rapidement, l'impact sur un horizon de 2 ans est >1,1 milliard de dollars de bénéfices supplémentaires pour les vendeurs Whatnot. Pas l'impact de ces produits, juste l'impact de prendre ces décisions plus rapidement. Chaque retard dans la livraison de la bonne chose nuit à nos clients, nos clients, et plus nous devenons grands, plus le coût d'opportunité de la vitesse est élevé.

2) Une fois la vitesse perdue, elle ne revient jamais

Les humains se conforment naturellement et finissent par compter sur les processus, donc même ceux inventés pour des cas d'utilisation étroits sont appliqués plus largement que prévu. Les incitations se déplacent vers le suivi du système plutôt que d'avoir l'impact que le système était conçu pour assurer, et la mémoire musculaire de l'organisation pour « savoir, mais agir » s'atrophie et se perd. Il n'y a presque aucune erreur que nous pourrions empêcher qui serait un bon compromis à long terme pour ralentir la vitesse à laquelle nous construisons.

3) La vitesse n'est pas la raison des erreurs

Les comités n'empêchent les erreurs qu'en empêchant le progrès. Le jugement est ce qui empêche réellement les erreurs. Livrer plus fréquemment construit notre jugement – comme un athlète, nous devenons plus forts à travers les répétitions. Tout en construisant des répétitions, les équipes peuvent tirer parti du jugement de ceux qui ont plus de répétitions et plus de contexte – des conseils ad hoc continus ad hoc continus de la direction produit, une visibilité pour les atténuations de risques clés comme les aspects juridiques et les communications dès les premières étapes de la planification (s'il y a des ouragans à éviter dans l'Atlantique, nous devons le savoir lorsque nous traçons la route, pas au moment du départ), des responsables de catégorie ou de pays qui peuvent se faire l'écho de la réaction de clients spécifiques. Dans le cadre de la réflexion sur le système, les PM doivent chercher à anticiper les impacts de leurs lancements, mais ne sont jamais bloqués ni par le fait d'avoir cherché, ou de prendre les retours/contributions qu'ils reçoivent. La revue produit est la seule porte dans notre processus de développement.