Construção e outras coisas

Nos últimos dois anos, 31.832 pessoas se candidataram para ser Gerente de Produto na Whatnot. Contratamos uma. Você tem duas vezes mais chances de acertar um hole-in-one do que conseguir um emprego simplesmente se candidatando.

Isso não é uma falha de processo. Eu construo produtos – e times de produto – há mais de uma década e um dos maiores fatores para decidir vir para a Whatnot há ~3 anos foi a cultura de produto muito deliberada. Ninguém sabe o que significa ser um PM significa no mundo da IA, mas tudo que vejo indica que o setor está se movendo em nossa direção e em como construímos aqui - porque nenhuma ferramenta vai te tornar útil se você não estiver fazendo o trabalho certo.

Primeiro, temos que reconhecer: o PM médio é profundamente mediano.

A função de produto surgiu em resposta à escala – os times de engenharia ficaram grandes demais para CEOs ou GMs gerenciarem diretamente, então um conduto de negócios <> tecnologia foi necessário. Com o tempo, generalizamos preguiçosamente o papel para "toda vez que você contrata um Gerente de Engenharia, você contrata um PM". Mas onde um Diretor de Engenharia geria 30-40 pessoas através de seus GEs, um Diretor de PM gerenciava apenas cinco. Incentivos governam o mundo, então o trabalho desses Diretores se tornou "justificar o crescimento do headcount de aumentar a equipe de engenharia parceira" para que eles, por sua vez, pudessem crescer e se tornar VP. Lentamente, o papel dos PMs juniores mudou de "CEOs do produto" para "babás de botões" e engenheiros com mentalidade de produto para tomadores de ordens infantilizados.

Então veio a pandemia e o setor contratou impressionantes 500.000 novos engenheiros de software em apenas quatro anos e ~80.000 novos PMs foram criados para acompanhar. São 80.000 PMs enterrados em times gigantescos nas FAANG, longe de qualquer cliente, a 50 camadas do zoom onde as coisas acontecem as coisas, ensinados a fazer PM "pintar por números" em uma escola de produto, em uma era de crescimento de engajamento imerecido onde qualquer coisa parecia funcionar.

A probabilidade de alguém emergir disso com ótimos instintos de produto, experiência e garra parece menos provável do que acertar um hole-in-one.

Segundo: tornamos nossos melhores, piores.

Quando seu trabalho é supervisionar cinco pessoas, tudo que você pode fazer no seu dia é se intrometer no trabalho dos outros. Eles não gostam disso e classificam como microgerenciamento em uma pesquisa anônima, então você recua. Como então você gasta seu tempo? Você conta histórias, conduz as coisas através de revisões para que seus times estejam 'tendo sucesso', justifica recursos. Mas você não sabe qual história contar, então monta um time de pesquisa de usuários para te dizer os jobs to be done, depois uma função de uma função de PMM para contar essa história aos clientes. A função que se tornou estrategicamente importante porque reunia contexto e disseminava clareza, se abstraiu em torres de marfim cada vez maiores.

Mas a verdade real está nos modelos de dados dos seus sistemas, nas ligações de vendas, nos tickets de CX, nas análises – não no lindo 2x2x2 feito para simplificar tudo.

Todo o tempo que você gasta jogando gestão significa que sua compreensão inata dos problemas está ficando obsoleta, seus instintos para seu cliente mais embotados, a probabilidade de você estar certo está caindo.

Nossa média de acertos como função caiu tanto porque o denominador se expandiu QUANTO porque sua expansão significou que todos que eram bons em produto há sete anos foram promovidos para fora de fazer qualquer trabalho real (ou ficaram ricos o suficiente para que o incentivo de ficar e jogar política fosse baixo).

O Jeito Whatnot

Desde seu início, o time de produto da Whatnot foi construído em uma premissa um tanto simples: nos arrependemos de que a gestão de produto exista. Vendas e engenharia se davam muito bem antes de sermos contratados, então, onde puderem, devem apenas enviar sem barreiras processuais ou papelada sem sentido. Produto é um ofício, não uma qualificação. Qualquer um que faz bem aprendeu fazendo e estando perto de pessoas ótimas fazendo.

Estive em uma entrevista recentemente onde alguém me disse que a Whatnot parecia que Twitch e eBay tiveram um bebê - culturalmente não poderia estar mais errado, mas em termos de escopo de produto é uma comparação decente. Uma estimativa conservadora diz que essas duas organizações combinadas têm >400 PMs. Nós temos 20. 20 PMs para mais de 1200 funcionários no total.

Nossos PMs são mapeados para problemas, não para GEs. Esses dois frequentemente se sobrepõem, mas não são a mesma coisa. Se você está construindo um novo formato de vendas para vendedores de moda, vai estar muito próximo dos GEs que gerenciam como listagens e estoque funcionam, mas igualmente com os GEs de logística e pagamentos.

Ter que trabalhar em várias pilhas e pesar impactos para diferentes clientes não é fácil – requer um contexto amplo do negócio, a capacidade de preensão de impactos a jusante de mudanças em qualquer recurso, habilidade em alternar contextos, capacidade de construir e gastar confiança em toda uma organização em vez de com um único parceiro. É por isso que contratamos quase exclusivamente PMs seniores. PMs que estão cansados de reuniões intermináveis de alinhamento e ansiosos para construir novamente. Ou, convertemos pessoas promissoras de vendas ou operações e deixamos aprender fazendo. Estamos sempre procurando a contratação hole-in-one de meio de carreira L5/L6, mas as estatísticas não mentem sobre a frequência com que os encontramos.

Finalmente, todo mundo envia, inclusive eu. Estou sempre trabalhando diretamente com um time de engenheiros e designers para enviar recursos como um IC, e o mesmo acontece com nossos dois cofundadores. Quando foi hora de testar se era viável para PMs "vibecode" recursos pequenos, eu fui a cobaia. Quando foi hora de embarcar nosso primeiro vendedor na Austrália, foi nosso cofundador Logan fazendo isso. Quando o Zendesk começou a deixar cair tickets de clientes, foi nosso CEO Grant falando com o engenheiro de suporte deles.

Como empresa, exigimos que todo funcionário venda, compre e faça tickets de CX ou damos a eles uma avaliação abaixo das expectativas. Se os PMs devem liderar em uma empresa com esse compromisso com a centralidade no cliente, temos que estar profundamente em como as coisas funcionam e amplamente no porquê. Chamamos isso de "ser em forma de T" – ter amplitude de contexto e profundidade na sua área, simultaneamente. Profundidade e experiência permitem permitem que você tome decisões rapidamente, não ter que esperar por 5 camadas de gestão para revisar significa que essas decisões se tornam ações.

Membros do Corpo Técnico

Há tanto barulho agora sobre "construir"... Não, documentos de requisitos de produto não estão mortos. Um PRD é apenas um recipiente para pensar claramente sobre um problema e articulá-lo para outros. Faça o seu interativo se quiser, ninguém se importa. Não, o custo de enviar um produto ruim não foi a zero, ainda é pago pelos seus clientes. Jogar espaguete 16x mais rápido neles não é, de fato, uma revolução, é simplesmente irritante. E não, todo mundo não vai ser um Eng e Designer e PM nível S tudo em um. Algumas pessoas serão, mas os mesmos impulsionadores da especialização – o que as pessoas gostam e são bons – ainda vão impulsionar como trabalhamos trabalhamos.

O que está mudando é a percepção de que ser um IC é um uso muito melhor das habilidades, experiência e tempo limitado de muitas pessoas do que redigir o mesmo documento pela 5ª vez para se adequar à formatação preferida dos pedantes atuais. Alguns PMs na Whatnot são gerentes, mas cada um deles gasta 90%+ do seu tempo como IC. Não há distinção em nossos títulos ou remuneração para aqueles que gerenciam ou não, porque não vemos virtude inerente nisso. IA nos dá uma alavancagem incrível – posso me mover mais rápido em quase todas as tarefas no processo de desenvolvimento, seja entendendo dados que antes exigiam um cientista de dados para desembaraçar ou transformar um PRD em cada permutação de SOPs de CX que normalmente seriam assunto de longas noites no escritório na semana de lançamento. Posso construir um bot para triar as 100 perguntas por semana de vendas ou para encontrar as lacunas de localização que deixamos em um experimento recente.

A coisa mais disruptiva sobre IA para PMs é que ela mostrou que a alavancagem de treinar pessoas e trabalhar através delas não é mais a fonte singular de alavancagem que já foi. Especialmente se essas pessoas são – sem culpa própria – profundamente medíocê só está disponível para pessoas que ainda sabem fazer o trabalho.

O que é especialmente encorajador sobre essa tendência é que ela vai atrair os melhores PMs de volta ao trabalho real de PM. Pensar sobre as necessidades do cliente e do negócio e o bom gosto para resolver da melhor maneira. Como cliente de outras empresas, estou animado para ver os luminares do nosso setor voltando a construir – vai tornar seus produtos melhores. Como alguém obcecado em construir o menor time de PM mais alavancado da história, estou animado por isso liberar os seres humanos incríveis humanos que têm feito o mínimo nas revisões de roadmap por meia década.

Mostre, não conte

Abaixo vou copiar (na íntegra) o único documento que temos sobre como trabalhamos em Produto na Whatnot. Se nos encontramos mesmo uma vez, você não vai precisar que eu diga quem é o autor – é assim que falamos e como trabalhamos.

Você também pode olhar quem trabalha no nosso time – há pelo menos seis pessoas no time hoje que poderiam ser CPO em uma startup série B-C que vão passar a noite no telefone com vendedores, 400 consultas em uma Hex Thread ou rascunhando comunicações v1 para o lançamento de amanhã. São quatro ex-fundadores que nunca na vida concordaram que algo está fora de sua alçada. São quatro ex-diretores de FAANG que não passam mais seus dias debatendo onde as pessoas deveriam viver em uma grade nove box. São seis PMs de estágio inicial com um gosto incrível, sendo informados de que precisam tentar mais coisas porque só aprendemos fazendo.

Duvido que nossa declaração de no máximo 20 PMs dure – a oportunidade à nossa frente na Whatnot é tão enorme que não vamos nos restringir arbitrariamente - mas o padrão para quem contratamos só vai subir à medida que o setor e as ferramentas de IA continuarem a recompensar ótimos ICs com alavancagem. Se você é uma dessas pessoas, e o que descrevi acima é o que te motiva, você vai descobrir como entrar em contato comigo.

Construindo na Whatnot

Construir ótimos produtos é difícil. Não é só que você precisa ter a visão certa do problema, acertar os detalhes, levar ao mercado certo, medir corretamente para entender seu desempenho ou iterar rapidamente. É que você precisa fazer todas essas coisas ou não funciona. Pior, falhar é caro. Temos poucos times e uma quantidade enorme de oportunidade à nossa frente - bater .300 é ótimo se você joga na MLB, mas para realizar nossas aspirações precisamos de perto de .500. Sem uma média alta, ou restringimos o crescimento no curto prazo ou acoplamos o crescimento do negócio ao crescimento de pessoal e nos restringimos no longo prazo.

Este documento tem 2 partes:

1. Nossa filosofia - isso não vai mudar
2. Nossos processos - estes vão evoluir e o SOT atual mantido aqui

Como construímos nos dá alavancagem

Você pode construir um edifício um cômodo de cada vez, você tem que projetar o edifício inteiro de uma vez e construí-lo tudo de uma vez. Felizmente, não trabalhamos na construção civil, trabalhamos em software. Construir iterativamente é nosso superpoder. Sempre lançamos a menor unidade que fornece valor real ao usuário e uma experiência sólida, mas projetamos as coisas mais adiante para garantir que possamos escalá-la.

O caminho feliz de um produto bem-sucedido aqui percorre 7 etapas consistentemente:

1) É algo que importa para os usuários e para o nosso negócio

Priorize impiedosamente as coisas mais impactantes que resolvem para nossos usuários e necessidades do negócio.

• Você deve ser capaz de articular esse valor explicitamente "permitir que varejistas em escala vendam produtos armazenados em vários locais em um único show - atualizando 'envia de' para ser um campo de produto, não um campo de show"
• Pense no sistema.

1. Este produto é imediatamente valioso quando lançado?
2. É um 'bloco de construção' para outras coisas?

Se (1) não for verdade, não prossiga. Se (1) for verdade, descubra como pode se tornar (2) ao longo do tempo.

2) É algo que as pessoas querem

Entenda seus pontos problemáticos, desejos e comportamentos para criar um produto para eles.

• Você não sabe disso a menos que entenda o usuário para quem está construindo em detalhes. Case qual e quant.
• Pense no seu produto no contexto do fluxo de trabalho existente.
• Não coloque camadas sobre porcaria.
• Não exploda um fluxo de trabalho que resolve o problema B porque você está focado no problema A
• Se o problema é real - você sabe como eles estão contornando hoje?
• Cuidado com objetos brilhantes. Especialmente objetos brilhantes que você construiu em outro lugar no passado.

3) As necessidades do cliente não se alinham com nossos organogramas / nunca são atendidas com um único recurso.

Se você está construindo localmente, está construindo ingenuamente.

• Você deve trabalhar a partir de uma experiência completa do cliente, não da propriedade do código. Vá resolver o problema, ponto final.
• O inverso também é verdade - outros PMs precisarão empurrar para "sua área". Ajude-os.
• Este princípio é por que nos esforçamos para ter o menor time possível de Produto e Design. Quanto mais pessoas cujo papel é definido de forma estreita, mais míopes os roadmaps se tornam e mais tempo perdemos em coordenação e consulta.

4) É a solução mais simples possível que resolve o problema.

A chave para construir produtos rápidos e confiáveis que os usuários amam é evitar trabalho desnecessário e sem impacto

• Simples não é apenas rápido de construir, é tipicamente também o mais bem-sucedido.
• Pensar no sistema não significa construir o sistema inteiro de uma vez.
• Quanto mais você constrói antes de saber que está certo, mais caro é quando você está errado.

5) Foi validado com o menor público possível.

Você está apenas chutando até que alguém esteja usando.

• Coloque protótipos de papel ou clicáveis nas mãos dos vendedores o mais rápido possível. O dogfooding da equipega bugs melhor do que valida uma solução porque não somos nossos clientes.
• Pense na sua estratégia de GTM
• Produtos voltados para Vendedores: Comece com <10 vendedores, escale por número de vendedores ou para algumas categorias antes de ir para GA.
• Produtos para Compradores: Comece com uma categoria ou uma pequena % e aumente com sinal.
• Produtos de Ecossistema (visíveis para ambos): Comece com uma categoria ou um pequeno mercado
• Se você está em modo de validação, resolver para conscientização (interna ou externa) é um modo de falha.
• É tão subescala que não impacta realmente as pessoas
• Você não sabe se vai funcionar ainda - não perca tempo das pessoas

6) Uma vez validado, iteramos loucamente.

Uma vez ao vivo para os clientes, estamos enviando melhorias semanalmente, se não diariamente.

• Se você ouvir "assim que enviarmos X podemos ir para Y" é uma bandeira vermelha gigante.
• Uma vez que sabemos que vai ser uma coisa, você precisa voltar e resolver para Catex e CX
• Lance, valide, meça, itere, itere, itere, itere, itere > então vá para a próxima prioridade.

7) Atravessamos paredes uma vez em beta

Conseguir uma faísca é difícil. Uma vez que você tem uma, precisa derrama combustível ou ela morre.

• O maior risco de lançar produtos hiper-simples hiper-cedo é que eles são incompletos e, portanto, não verdadeiramente úteis a longo prazo. Uma vez que você lança, está no relógio para ir de alto potencial a alto impacto.
• Concentre-se em maximizar o valor que está criando e não gerenciar cada pequena reclamação, risco ou repercussão.
• Descobrir com quais reclamações, riscos e repercussões se preocupar é uma questão de julgamento para cada lançamento. Preocupar-se com não-riscos é tão perigoso quanto falhar em se preocupar com eles

8) Isso não é o bachelor - desacople tudo

Há uma tendência natural ao projetar um sistema de querer enviar várias partes de uma vez. Em um sistema suficientemente complexo como o nosso, chances são de times estão trabalhando em componentes de um sistema em paralelo e pode parecer sensato enviá-los juntos para ser uma grande mudança vs duas. Também é uma armadilha.

• Contanto que cada peça seja independentemente viável e benéfica para os clientes, lance-as o mais rápido possível
• Isso nos permite medir cada uma mais efetivamente e entender suas contribuições relativas
• Deixar produtos benéficos esperando em staging para outros é ruim para os clientes

O papel das revisões e feedback

Temos um processo de produto documentado cuja intenção é garantir que estamos trabalhando nas coisas certas e da maneira certa. Isso inclui funções de visibilidade, aprovação e responsabilidade. Mais importante do que aderir cegamente a esse processo, no entanto, é internalizar a filosofia subjacente - que é bem articulada neste thread do Twitter… (sério, leia antes de prosseguir)

1. Em um sistema complexo, você precisa de muito mais alinhamento do que pensa para realmente chegar à resposta certa. Porque essa palavra pode ser mal interpretada:
2. Alinhamento nunca significa consenso. Consenso é o inimigo da boa tomada de decisão.
3. Alinhamento não significa acoplar fluxos de trabalho. Coordenação é o inimigo da velocidade.
4. O teste de alinhamento - um plano escrito. Se Grant está pedindo um, não estamos alinhados.
5. Autonomia na Whatnot é autonomia de implementação. Ninguém tem ou deve esperar autonomia de estratégia. Sem alinhamento, autonomia é desperdiçada.

Para atender às expectativas na Whatnot, um PM ou Designer

1. Identifica coisas que

1. Identifica coisas que precisam de alinhamento imediatamente e as busca ativamente
2. Move-se rapidamente do alinhamento para a implementação porque entende profundamente a discussão e o alinhamento. Eles não ouvem por um 'sim' nas discussões.
3. Pode preencher os detalhes de implementação com seu time / desbloquear rapidamente decisões que seguem o alinhamento.

Por que a Velocidade Importa

Todo o nosso sistema é baseado em maximizar a velocidade de enviar a coisa certa. 1-3 do caminho feliz são sobre descobrir o que achamos que é a coisa certa, 4-7 sobre como validamos, iteramos e escalamos essa coisa. Fazemos isso porque:

1) Tudo no nosso sistema compõe - o bom e o ruim

Em 2025, rodamos 750 experimentos em cerca de 250 dias úteis, o que dá aproximadamente 3 decisões de enviar/não enviar por dia. Se você simular o impacto de longo prazo de tomar cada uma dessas decisões apenas 3 dias corridos mais rápido, o impacto em um horizonte de 2 anos é >$1.1B de ganhos incrementais para os Vendedores da Whatnot. Não o impacto desses produtos, apenas o impacto de tomar essas decisões fracionavelmente mais rápido. Cada atraso em enviar a coisa certa prejudica nossos clientes, e quanto maiores ficamos, maior o custo de oportunidade da velocidade.

2) Uma vez perdida, a velocidade nunca volta

Humanos naturalmente se conformam e passam a confiar no processo, então mesmo aqueles inventados para casos de uso estreitos são aplicados mais liberalmente do que o pretendido. Os incentivos mudam para seguir o sistema vs ter o impacto que o sistema foi projetado para garantir, e a memória muscular da organização para "saber, mas ir" é atrofiada e perdida. Quase não há erro único que poderíamos evitar que seria uma boa troca a longo prazo por desacelerar a velocidade com que construímos.

3) Velocidade não é a razão para erros/enganos

Comitês só previnem erros como subproduto de impedir o progresso. Julgamento é o que realmente previne erros. Enviar com mais frequência constrói nosso julgamento - como um atleta, ficamos mais fortes através das repetições. Enquanto constroem repetições, os times podem alavancar o julgamento daqueles com mais repetições e mais contexto - orientação contínua ad hoc da liderança de produto, visibilidade para mitigações de risco chave como jurídico e comunicações nos estágios iniciais do planejamento (se há furacões que precisamos evitar no Atlântico, precisamos saber disso quando estamos traçando o curso, não quando estamos partindo), líderes de categoria ou país que podem representar como clientes específicos podem reagir. Como parte de pensar no sistema, os PMs devem buscar antecipar impactos de seus lançamentos, mas nunca são barrados por terem buscado, ou por aceitarem qualquer feedback/input que recebem. A revisão de produto é o único portão no nosso processo de desenvolvimento.