Costruire, e tutto il resto

Negli ultimi due anni, 31.832 persone hanno fatto domanda per diventare Product Manager in Whatnot. Ne abbiamo assunta una. È due volte più probabile fare una buca in un colpo solo che ottenere un lavoro semplicemente candidandosi.

Non è un fallimento del processo. Costruisco prodotti – e team di prodotto – da oltre un decennio, e uno dei fattori principali che mi ha spinto a venire in Whatnot circa 3 anni fa è stata la cultura di prodotto molto deliberata. Nessuno sa cosa significhi essere un PM nel mondo dell'IA, ma tutto ciò che vedo mi dice che il settore si sta muovendo verso di noi e verso il modo in cui modo in cui costruiamo qui – perché nessuno strumento ti renderà utile se non stai facendo il lavoro giusto.

Prima di tutto, dobbiamo riconoscere: il PM medio è profondamente mediocre.

La funzione di prodotto è emersa in risposta alla scala – i team di ingegneria sono diventati troppo grandi perché CEO o GM potessero gestirli direttamente, quindi è stato necessario un condotto business <> tech. Col tempo abbiamo generalizzato pigramente il ruolo a "ogni volta che assumi un Engineering Manager, assumi un PM". Ma dove un Eng Director gestiva 30-40 persone attraverso i suoi EM, un PM Director ne gestiva solo cinque. Gli incentivi governano il mondo, quindi il lavoro di quei Director è diventato "giustificare la crescita del headcount dei miei partner ingegneri" in modo che loro, a loro volta, potessero crescere per diventare VP. Lentamente, il ruolo dei PM junior è passato da "CEO del prodotto" a "baby-sitter dei bottoni" e gli ingegneri con mentalità da prodotto sono diventati ordini infantilizzati.

Poi è arrivato il COVID e il settore ha assunto la sbalorditiva cifra di 500.000 nuovi ingegneri software in soli quattro anni, e sono stati creati circa 80 nuovi PM per stare al passo. Sono 80 PM sepolti all'interno di team giganteschi in FAANG, lontani da qualsiasi cliente, a 50 livelli di distanza dalla riunione in cui si decide, a cui è stato insegnato fare il PM seguendo lo schema prestabilito in una scuola di prodotto, in un'epoca di crescita del coinvolgimento immeritata in cui sembrava funzionasse tutto.

La probabilità che qualcuno emerga da tutto ciò con grandi istinti di prodotto, esperienza e grinta sembra in realtà inferiore a quella di fare una buca in un colpo solo.

Secondo: abbiamo reso i nostri migliori, peggiori.

Quando il tuo lavoro è supervisionare cinque persone, tutto ciò che puoi fare con la tua giornata è intrometterti nel lavoro degli altri. A loro non piace e lo etichettano come microgestione in un sondaggio anonimo, quindi ti tiri indietro. Come passi allora il tuo tempo? Racconti storie, accompagni le cose attraverso le revisioni in modo che i tuoi team abbiano 'successo', giustifichi le risorse. Ma non sai quale storia raccontare, quindi istituisci un team di user research per dirti quali sono i compiti da svolgere, poi una funzione di PMM per raccontare quella storia ai clienti. La funzione che era diventata strategicamente importante perché raccoglieva contesto e diffondeva chiarezza si è astratta in torri d'avorio sempre più alte.

Ma la verità vera è nei modelli di dati dei tuoi sistemi, nelle chiamate di vendita, nei ticket CX, nell'analisi – non nella bella matrice 2x2 fatta per semplificare il tutto.

Tutto il tempo che passi a fare gestione significa che la tua comprensione innata dei problemi sta diventando obsoleta, i tuoi istinti per il tuo cliente si affievoliscono, la probabilità che tu abbia ragione diminuisce.

La nostra media come funzione è diminuita sia perché il denominatore si è espanso, sia perché la sua espansione ha significato che tutti coloro che erano bravi nel prodotto sette anni fa sono stati promossi fuori dal fare qualsiasi lavoro reale (o sono diventati abbastanza ricchi da avere pochi incentivi a restare e fare politica).

Il Metodo Whatnot

Fin dal suo inizio, il team di prodotto di Whatnot è stato costruito su una premessa piuttosto semplice: ci dispiace che la gestione del prodotto esista. Vendite e ingegneria andavano d'accordo prima che fossimo assunti, quindi dove possono, dovrebbero semplicemente spedire senza barriere procedurali o scartoffie inutili. Il prodotto è un mestiere, non una qualifica. Chiunque lo faccia bene ha imparato facendo e stando vicino a grandi persone che lo fanno.

Di recente ero a un colloquio in cui qualcuno mi ha detto che Whatnot sembrava il figlio di Twitch eBay - culturalmente non potrebbe essere più sbagliato, ma in termini di ambito del prodotto è un paragone decente. Una stima prudente dice che quelle due organizzazioni combinate hanno >400 PM. Noi ne abbiamo 20. 20 PM per oltre 1200 dipendenti totali.

I nostri PM sono mappati ai problemi, non agli EM. Queste due cose spesso si sovrappongono, ma non sono la stessa cosa. Se stai costruendo un nuovo formato di vendita per i venditori di moda, sarai molto affiatato con gli EM che gestiscono il funzionamento di inserzioni e inventario, ma altrettanto con gli EM di logistica e pagamenti.

Dover lavorare su più stack e valutare gli impatti su diversi clienti non è facile – richiede un ampio contesto del business, la capacità di prevedere le conseguenze a valle delle modifiche a qualsiasi funzionalità, abilità nel cambiare contesto, la capacità di costruire e spendere fiducia in tutta l'organizzazione piuttosto che con un solo partner. Ecco perché assumiamo quasi esclusivamente PM senior. PM che sono stanchi di infinite riunioni di allineamento e non vedono l'ora di costruire di nuovo. Oppure, convertiamo persone promettenti delle vendite o delle operations e lasciamo che imparino facendo. Siamo sempre alla ricerca del colpo da buca in un colpo solo a metà intermedia L5/L6, ma le statistiche non mentono sulla frequenza con cui li troviamo.

Infine, tutti spediscono, me compreso. Lavoro sempre direttamente con un team di ingegneri e designer per spedire funzionalità come IC, e così fanno entrambi i nostri cofondatori. Quando è stato il momento di testare se fosse fattibile per i PM "vibecodare" piccole funzionalità, sono stato la cavia. Quando è stato il momento di imbarcare manualmente il nostro primo venditore in Australia, è stato il nostro cofondatore Logan a farlo. Quando Zendesk ha iniziato a far cadere i ticket dei clienti, è stato il nostro CEO Grant, il nostro CEO, a parlare con il loro tecnico dell'assistenza.

Come azienda, richiediamo che ogni dipendente venda, acquisti e gestisca ticket CX altrimenti diamo loro una valutazione al di "sotto le aspettative". Se i PM devono guidare in un'azienda con questo impegno verso la centralità del cliente, dobbiamo essere profondi nel come funzionano le cose e ampi nel perché. Lo chiamiamo "essere a forma di T" – avere un'ampiezza di contesto e la profondità della propria area, simultaneamente. Profondità ed esperienza ti permettono di prendere decisioni rapidamente; non dover aspettare 5 livelli di gestione per la revisione significa che quelle decisioni diventano azioni.

Membri dello Staff Tecnico

C'è così tanto rumore in questo momento sul "costruire"... No, i documenti dei requisiti di prodotto non sono morti. Un PRD è solo un veicolo per pensare chiaramente a un problema e articolarlo agli altri. Rendilo interattivo se vuoi, a nessuno importa. No, il costo di spedire un prodotto scadente non è andato a zero, è ancora pagato dai tuoi clienti. Lanciare spaghetti contro di loro 16 volte più velocemente non è, in realtà, una rivoluzione, è semplicemente fastidioso. E no, non tutti diventeranno un Eng, unico Eng, Designer e PM di livello S. Alcuni lo faranno, ma gli stessi fattori di specializzazione – ciò che le persone apprezzano e in cui sono brave – continueranno a guidare il modo in cui lavoriamo.

Ciò che sta cambiando è la consape che essere un IC è un modo molto migliore di utilizzare le capacità, esperienza e il tempo limitato su questa terra di molte persone, piuttosto che riscrivere la stessa bozza dello stesso documento per la quinta volta per adattarsi alla formattazione preferita dai pedanti del momento. Alcuni PM in Whatnot sono manager, ma ognuno di loro passa il 90%+ del suo tempo come IC. Non c'è distinzione nei nostri titoli o nella retribuzione per chi gestisce o non gestisce, perché non vediamo alcuna virtù intrinseca in questo. L'IA ci dà una leva incredibile – posso muovermi più velocemente in quasi ogni compito del processo di sviluppo, che si tratti di comprendere dati che prima richiedevano un data scientist per districarli o trasformare un PRD in ogni permutazione di SOP CX che normalmente sarebbero oggetto di lunghe notti in ufficio durante la settimana di lancio. Posso costruire un bot per smistare le 100 domande settimanali delle vendite o per trovare le lacune di localizzazione che abbiamo lasciato in un esperimento recente.

La cosa più dirompente dell'IA per i PM è che ha dimostrato che la leva di fare da mentore alle persone e lavorare attraverso di loro non è più la fonte singolare di leva che era una volta. Soprattutto se quelle persone sono – senza colpa loro – profondamente mediocri. Ma quella leva è disponibile solo per le persone che sanno ancora sanno fare il lavoro.

Ciò che è particolarmente incoraggiante in questa tendenza è che attirerà i migliori PM a tornare a fare il vero lavoro di PM. Pensare ai bisogni bisogni del cliente e del business e il buon gusto per risolverlo nel modo migliore. Come cliente di altre aziende, sono entusiasta di vedere i luminari del nostro settore tornare a costruire – renderà i loro prodotti migliori. Come persona ossessionata dal costruire il team di PM più piccolo e altamente leverage della storia, sono entusiasta che questo liberi gli esseri umani incredibili che hanno partecipato fiaccamente alle revisioni delle roadmap per mezzo decennio.

Mostra, non raccontare

Di seguito copierò (per intero) l'unico documento che abbiamo su come lavoriamo sul Prodotto in Whatnot. Se ci siamo incontrati anche una sola volta, non avrai bisogno che ti dica chi è l'autore – è così che parliamo e così che lavoriamo.

Puoi anche andare a vedere chi lavora nel nostro team – ci sono almeno sei persone nel team oggi che potrebbero essere CPO di una startup serie B-C che passeranno la serata al telefono con i venditori, 400 query in un Hex Thread o a scrivere le comunicazioni v1 per il lancio di domani. Sono quattro ex fondatori che in vita loro non hanno mai concordato che qualcosa fosse al di fuori delle loro competenze. Sono quattro ex direttori FAANG che non passano più le loro giornate a dibattere su dove le persone dovrebbero vivere in una griglia nove box. Sono sei PM di fase iniziale con un gusto incredibile, a cui viene detto che devono provare più cose perché impariamo solo facendo.

Dubito che la nostra dichiarazione passata di massimo 20 PM durerà – l'opportunità che abbiamo davanti in Whatnot è così enorme che non ci limiteremo arbitrariamente – ma l'asticare – ma l'asticella per chi assumerà solo salire man mano che il settore e gli strumenti di IA continueranno a premiare i grandi IC con leva. Se sei una di quelle persone, e ciò che ho descritto sopra è ciò che ti fa andare avanti, troverai il modo di contattarmi.

Costruire in Whatnot

Costruire grandi prodotti è difficile. Non è solo che devi avere l'intuizione giusta sul problema, ottenere i dettagli giusti, portarlo sul mercato nel modo giusto, misurarlo correttamente per capirne le prestazioni o iterare rapidamente. È che devi fare tutte queste cose o non funziona. Peggio ancora, fallire è costoso. Abbiamo pochi team e un'enorme quantità di opportunità di fronte a noi – battere .300 è fantastico se giochi in MLB, ma per realizzare le nostre aspirazioni abbiamo bisogno di avvicinarci a .500. Senza una media alta media, o limitiamo la crescita a breve termine o accoppiamo la crescita del business alla crescita del headcount e ci limitiamo a lungo termine.

Questo documento ha 2 parti:

1. La nostra filosofia – questo non cambierà
2. I nostri processi – questi si evolveranno e lo stato attuale è mantenuto qui

Come costruiamo ci dà leva

Non puoi costruire un edificio una stanza alla volta, devi progettare l'intero edificio in una volta e costruirlo tutto in una volta. Fortunatamente, non lavoriamo nell'edilizia, lavoriamo nel software. Costruire iterativamente è il nostro superpotere. Lanciamo sempre l'unità più piccola che fornisce reale valore per l'utente e una solida esperienza utente, ma progettiamo le cose più avanti per assicurarci di poterle scalare.

Il percorso felice di un prodotto di successo qui segue 7 passaggi in modo coerente:

1) È qualcosa che conta per gli utenti e per il nostro business

Dai priorità in modo spietà alle cose di maggior impatto che risolvono le esigenze degli utenti e del business.

• Devi essere in grado di articolare esplicitamente quel valore: "consentire ai rivenditori su larga scala di vendere prodotti immagazzinati in più sedi in un unico show – aggiornando 'spedito da' per essere un campo del prodotto, non un campo dello show"
• Pensa al sistema.

1. Questo prodotto è immediatamente prezioso quando viene lanciato?
2. È un 'blocco di costruzione' per altre cose?

Se (1) non è vero, non procedere. Se (1) è vero, scopri come può diventare (2) nel tempo.

2) È qualcosa che le persone vogliono

Comprendi i loro punti dolenti, desideri e comportamenti per creare un prodotto per loro.

• Non lo sai a meno che non capisca in dettaglio l'utente per cui stai costruendo. Combina dati qualitativi e quantitativi.
• Pensa al tuo prodotto nel contesto del flusso di lavoro del prodotto esistente.
• Non sovrapporre cose scadenti.
• Non far saltare un flusso di lavoro che risolve il problema B perché sei concentrato sul problema A
• Se il problema è reale – sai come lo stanno aggirando oggi?
• Attenzione agli oggetti luccicanti. Soprattutto agli oggetti luccicanti che hai costruito altrove in passato.

3) Le esigenze dei clienti non sono allineate con i nostri organigrammi / non vengono mai soddisfatte con una singola funzionalità.

Se stai costruendo localmente, stai costruendo in modo ingenuo.

• Devi lavorare a partire da un'esperienza cliente completa, non dalla proprietà del codice. Vai a risolvere il problema, punto.
• Vale anche il contrario – altri PM dovranno spingersi nella "tua area". Aiutali.
• Questo principio è il motivo per cui ci sforziamo di avere il team di Prodotto e Design più piccolo possibile. Più persone il cui ruolo è definito in modo ristretto, più miopi diventano le roadmap e più tempo perdiamo in coordinamento e consultazione.

4) È la soluzione più semplice possibile che risolve il problema.

La chiave per costruire prodotti veloci e affidabili che gli utenti amano è evitare lavoro non necessario e di impatto.

• Semplice non è solo veloce da costruire, ma è anche tipicamente il più di successo.
• Pensare al sistema non significa costruire costruire l'intero sistema in anticipo.
• Più costruisci prima di sapere di avere ragione, più costoso è quando hai torto.

5) È stato validato con il pubblico più piccolo possibile.

Stai solo indovinando finché qualcuno non lo usa.

• Metti prototipi cartacei o cliccabili nelle mani dei venditori il prima possibile. Il dogfooding dello staff cattura i bug meglio di quanto validi una soluzione perché non siamo i nostri clienti.
• Pensa al tuo motion GTM
• Prodotti per i venditori: Inizia con <10 venditori, scala per numero di venditori o per poche categorie prima di passare alla disponibilità generale.
• Prodotti per gli acquirenti: Inizia con una categoria o una categoria o una piccola percentuale e aumenta con il segnale.
• Prodotti dell'ecosistema (visibili a entrambi): Inizia con una categoria o un piccolo mercato
• Se sei in modalità di validazione, risolvere per la consapevolezza (interna o esterna) è una modalità di fallimento.
• È così sottoscala che in realtà non ha impatto sulle persone
• Non sai ancora se funzionerà – non perdere tempo alla gente

6) Una volta validato, iteriamo come matti.

Una volta in produzione con i clienti, spediamo miglioramenti settimanalmente, se non quotidianamente.

• Se senti "una volta che spediamo X possiamo passare a Y" è una bandiera rossa gigante.
• Una volta che sappiamo che sarà una cosa, devi tornare indietro e risolvere per Catex e CX
• Lancia, valida, misura, itera, itera, itera, itera > poi passa alla priorità successiva.

7) Una volta in beta, sfondiamo i muri

Ottenere una scintilla è difficile. Una volta che ce l'hai, devi versare benzina o morirà.

• Il rischio più grande nel lanciare prodotti iper-semplici iper-precocemente è che siano incompleti e quindi non veramente utili a lungo termine. Una volta lanciato, sei in corsa per passare da alto potenziale ad alto impatto.
• Concentrati sul massimizzare il valore che stai creando e non gestire ogni piccolo reclamo, rischio o ripercussione.
• Capire quali reclami, rischi e ripercussioni preoccuparsi è una questione di giudizio per ogni lancio. Preoccuparsi dei non-rischi è pericoloso quanto non preoccuparsene

8) Questo non è "The Bachelor" – disaccoppia tutto

C'è una tendenza naturale quando si progetta un sistema a voler spedire più parti contemporaneamente. In un sistema sufficientemente complesso come il nostro, è probabilità che più team stiano lavorando a componenti di un sistema in parallelo e può sembrare sensato spedirli insieme per avere un unico grande cambiamento invece di due. È anche una trappola.

• Finché ogni pezzo è indipendentemente valida e vantaggiosa per i clienti, lanciala il prima possibile
• Ci permette di misurare ciascuna più efficacemente e capire i loro contributi relativi
• Lasciare prodotti benefici in attesa in staging per un altro è dannoso per i clienti

Il ruolo delle revisioni e del feedback

Abbiamo documentato un processo di prodotto il cui scopo è garantire che stiamo lavorando alle cose giuste e nel modo giusto. Questo include funzioni di visibilità, approvazione e responsabilità. Più importante che aderire ciecamente a quel processo, tuttavia, è interiorizzare la filosofia sottostante – che è ben articolata in questo thread su Twitter… (seriamente, leggilo prima di procedere)

1. In un sistema complesso hai bisogno di molto più allineamento di quanto pensi per arrivare effettivamente alla risposta giusta. Perché quella parola può essere fraintesa:
2. Allineamento non significa mai consenso. Il consenso è il nemico del buon processo decisionale.
3. Allineamento non significa accoppiare i flussi di lavoro. Il coordinamento è il nemico della velocità.
4. Il test di allineamento – un piano scritto. Se Grant ne chiede uno, non siamo allineati.
5. L'autonomia in Whatnot è autonomia di implementazione. Nessuno ha o dovrebbe aspettarsi autonomia di strategia. Senza allineamento, l'autonomia è sprecata.

Per soddisfare le aspettative in Whatnot, un PM o Designer

1. Identifica immediatamente le cose che necessità che necessitano di allineamento immediatamente e le cerca attivamente
2. Si muove rapidamente dall'allineamento all'implementazione perché comprende profondamente la discussione e l'allineamento. Non ascoltano per un 'sì'approvazione nelle discussioni discussioni.
3. Sa riempire i dettagli di implementazione con il suo team / sbloccare rapidamente le decisioni che seguono l'allineamento.

Perché la Velocità Conta

Il nostro intero sistema si basa sulla massimizzazione della velocità di spedizione della cosa giusta. I passaggi 1-3 del percorso felice riguardano capire quale pensiamo sia la cosa giusta, i passaggi 4-7 riguardano come validiamo, iteriamo e scaliamo quella cosa. Lo facciamo perché:

1) Tutto nel nostro sistema si accumula – il bene e il male

Nel 2025 abbiamo condotto 750 esperimenti in circa 250 giorni lavorativi, che equivalgono a circa 3 decisioni di spedire/non spedire al giorno. Se simuli l'impatto a lungo termine di prendere ciascuna di queste decisioni solo 3 giorni di calendario più velocemente, l'impatto su un orizzonte di 2 anni è >$1.1 miliardi di guadagni incrementali per i venditori di Whatnot. Non l'impatto di quei prodotti, solo l'impatto di prendere quelle decisioni frazionalmente più velocemente. Ogni ritardo nello spedire la cosa giusta danneggia i nostri clienti, e più diventiamo grandi, maggiore è il costo opportunità/costo della velocità.

2) Una volta persa, la velocità non torna mai indietro

Gli umani si conformano naturalmente e arrivano a fare affidamento sui processi, quindi anche quelli inventati per casi d'uso ristretti vengono applicati più liberalmente del previsto. Gli incentivi si spostano verso il seguire il sistema invece di avere l'impatto che il sistema era progettato per garantire, e la memoria muscolare dell'organizzazione per "sapere, ma vai" si atrofizza e si perde. Quasi nessun singolo errore che potremmo prevenire varrebbe la pena, a lungo termine, di rallentare la velocità con cui costruiamo.

3) La velocità non è la causa di errori/sbagli

I comitati prevengono gli errori solo come sottoprodotto della prevenzione del progresso. Il giudizio è ciò che previene realmente gli errori. Spedire più frequentemente costruisce il nostro giudizio – come un atleta, diventiamo più forti con le ripetizioni. Mentre costruiscono ripetizioni, i team possono sfruttare il giudizio di coloro che hanno più ripetizioni e più contesto – guida continua e ad hoc da parte della leadership di prodotto, visibilità per le mitigazioni dei rischi chiave come legale e comunicazioni nelle prime fasi della pianificazione (se ci sono uragani da evitare nell'Atlantico, dobbiamo saperlo quando stiamo tracciando la rotta, non mentre salpiamo), responsabili di categoria o paese che possono fare da proxy su come specifici clienti potrebbero reagire. Come parte del pensare al sistema, i PM dovrebbero cercare di anticipare gli impatti dei loro lanci, ma non sono mai bloccati né dall'aver cercato, né dall'accettare qualsiasi feedback o input ricevano. La revisione del prodotto è l'unico gate nel nostro processo di sviluppo.