Construção e afins

Nos últimos dois anos, 31.832 pessoas se candidataram para ser Product Manager na Whatnot. Contratamos uma. Você tem o dobro de chances de acertar um hole-in-one do que de conseguir um emprego simplesmente se candidatando.

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

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

A função de produto surgiu como resposta ao escala – os times de engenharia ficaram grandes demais para CEOs ou GMs gerenciarem diretamente, então foi necessário um canal de negócios <> tecnologia. Com o tempo, generalizamos preguiçosamente o papel para "toda vez que você contratação de um Engineering Manager, contrate um PM". Mas, enquanto um Diretor de Engenharia gerenciava 30-40 pessoas por meio de seus EMs, um Diretor de PM gerenciava apenas cinco. Incentivos governam o mundo, então o trabalho desses Diretores se tornou "justificar o crescimento do headcount dos meus parceiro de engenharia" para que eles, por sua vez, pudessem crescer e se tornar VPs. Lentamente, o papel dos PMs juniores mudou de "CEOs do produto" para "babás de botões", e engenheiros com visão de produto se tornaram tomadores de ordens infantilizados.

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

A probabilidade de alguém sair disso com ótimos instintos instintos de produto, experiência e determinação parece menor do que acertar um hole-in-one.

Segundo: tornamos nossos melhores, pioramos.

Quando seu trabalho é supervisionar cinco pessoas, tudo o que você pode fazer no seu dia é interferir no trabalho dos outros. Eles não gostam disso e rotulam como microgestão em uma pesquisa anônima, então você recua. Como então você gasta seu tempo? Você conta histórias, conduz as coisas pelas revisões para que seus times estejam "tendo sucesso", justifica recursos. Mas você não sabe que história contar, então monta um time de pesquisa de usuário para lhe dizer quais jobs to be done, depois uma função de PMM para contar essa história aos clientes. A função que se tornou estrategicamente importante por reunir contexto e disseminar clareza se abstraiu em torres de marfim cada vez mais altas.

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 2x2 feito para simplificar tudo.

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

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

O Jeito Whatnot

Desde seu início, o time de produto da Whatnot foi construído sobre uma premissa um tanto simples: lamentamos que a gestão de produto exista. Vendas e engenharia se davam muito bem antes de sermos contratados, então, onde puderem, devem simplesmente entregar sem barreiras processuais ou papelada sem sentido. Produto é um ofício, não uma qualificação. Quem faz bem aprendeu fazendo e convivendo com pessoas ótimas fazendo.

Estava em uma entrevista recentemente onde alguém me disse que a Whatnot parecia o filho da Twitch com o eBay - culturalmente, não poderia estar mais errado, mas em termos de escopo de produto, é uma comparação razoável. 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 estão mapeados para problemas, não para EMs. Esses dois frequentemente se sobrepõem, mas não são a mesma coisa. Se você está construindo um novo formato de venda para vendedores de moda, vai trabalhar de perto dos EMs que gerenciam como funcionam os anúncios e o estoque, mas igualmente com os EMs de logística e pagamentos.

Ter que trabalhar em várias pilhas e pesar os impactos em diferentes clientes não é fácil – exige um contexto amplo do negócio, a capacidade de prever impactos downstream de mudanças em qualquer recurso, habilidade em alternar contextos, a 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 sêniores. 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 que aprendam fazendo. Estamos sempre em busca da 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 entrega, inclusive eu. Estou sempre trabalhando diretamente com um time de engenheiros e designers para entregar funcionalidades como um IC, e o mesmo acontece com nossos dois cofundadores. Quando foi hora de testar se era viável para PMs "vibecode" funcionalidades pequenas, fui a cobaia. Quando foi hora de embarcar nosso primeiro vendedor na Austrália, foi nosso cofundador Logan quem fez. Quando o Zendesk começou a deixar cair tickets de clientes, foi nosso CEO Grant quem falou 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, precisamos ser profundos em como as coisas funcionam e amplos no porquê. Chamamos isso de "ser em T" – ter amplitude de contexto e profundidade na sua área, simultaneamente. Profundidade e experiência permitem que você tome decisões rapidamente; não ter que esperar por 5 camadas de gestão revisarem significa que essas decisões se tornam ações.

Membros do Corpo Técnico

Há tanto barulho agora sobre "construir"... Não, os documentos de requisitos de produto não estão mortos. Um PRD é apenas um recipiente para pensar claramente sobre um problema e articular isso para os outros. Torne-o interativo se quiser, ninguém se importa. Não, o custo de entregar um produto ruim não foi a zero, ainda é pago pelos seus clientes. Jogar espaguete neles 16 vezes mais rápido não é, na verdade, uma revolução, é simplesmente irritante. E não, todo mundo não vai ser um Eng, 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 no que são boas – ainda ditarão como trabalhamos.

O que está mudando é a constataçã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 passa 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, pois 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 para entender dados que antes exigiam um cientista de dados para desembaraçar ou transformar um PRD em todas as permutações de SOPs de CX que normalmente seriam assunto de longas noites longas no escritório na semana de lançamento. Posso construir um bot para triar para triar as 100 perguntas semanais de vendas ou para encontrar as lacunas de localização que deixamos em um experimento recente.

A coisa mais disruptiva sobre a IA para PMs é que ela mostrou que a alavancagem de orientar 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íocres. Mas essa alavancagem só está disponível para quem ainda sabe 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 – isso vai tornar seus produtos melhores. Como alguém obcecado em construir o menor e mais alavancado time de PM da história, estou animado por isso libertar os humanos incríveis 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 você me conheceu pelo menos uma vez, não vai precisar que eu diga quem é o autor – é assim que falamos e assim que trabalhamos.

Você também pode olhar quem trabalha em nosso time – há pelo menos seis pessoas no time hoje que poderiam ser CPO de uma startup série B-C e que vão passar a noite no telefone com vendedores, 400 consultas em uma Hex Thread ou redigindo a comunicação 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 9-box. São seis PMs de estágio inicial com um gosto incrível, sendo instruídos a 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 nos limitaremos arbitrariamente - mas o padrão para quem contratamos só vai subir à medida que o setor e as ferramentas de IA continuarem a recompensar bons ICs com alavancagem. Se você é uma dessas pessoas, e o que descrevi acima é o que te motiva, você vai dará um jeito de entrar em contato.

Construindo na Whatnot

Construir grandes produtos é difícil. Não é só 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 tudo isso 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 do headcount e nos restringimos no longo prazo.

Este documento tem 2 partes:

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

Como construímos nos dá alavancagem

Você não pode construir um edifício um cômodo de cada vez, precisa projetar o edifício inteiro de uma vez e construí-lo tudo de uma vez. Felizmente, não trabalhamos na construção civil, trabalhamos com 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á-las.

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

1) É algo que importa 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 'ships from' seja 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 elas.

• Você não sabe disso a menos que entenda o usuário para quem está construindo em detalhes. Combine qual e quant.
• Pense no seu produto no contexto do fluxo de trabalho do produto 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 isso 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 estar trabalhando 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 invadir "sua área". Ajude-os.
• Este princípio é por que nos esforçamos para ter o menor time de Produto e Design possível. 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 é só rápido de construir, é tipicamente também o mais bem-sucedido.
• Pensar no sistema não significa construir o sistema inteiro antecipadamente.
• 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é alguém estar usando.

• Coloque protótipos de papel ou clicáveis nas mãos dos vendedores o mais rápido possível. O dogfooding da equipe pega bugs melhor do que valida uma solução porque não somos nossos clientes.
• Pense no seu movimento de GTM
• Produtos voltados para vendedores: Comece com <10 vendedores, escale pelo número de vendedores ou para algumas categorias antes de ir para GA.
• Produtos voltados para compradores: Comece com uma categoria ou uma pequena % e aumente com o 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.

Assim que estiver ao vivo para os clientes, estamos entregando melhorias semanais, senão diárias.

• Se você ouvir "assim que entregarmos X podemos passar para Y" é uma bandeira vermelha 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 > depois passe 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 derramar combustível ou ela vai morrer.

• O maior risco de lançar produtos hipersimples e hiperprecoces é que eles são incompletos e, portanto, não verdadeiramente úteis a longo prazo. Uma vez lançado, você está no relógio para ir de alto potencial a alto impacto.
• Concentre-se em maximizar o valor que você está criando e não em 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 dele de uma vez. Em um sistema suficientemente complexo como o nosso, é provável que vários times estejam trabalhando em componentes de um sistema em paralelo e pode parecer sensato enviá-los juntos para ser uma grande mudança em vez de duas. Também é uma armadilha.

• Desde 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 por outro é 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 alinhão alinhados.
5. Autonomia na Whatnot é autonomia de implementação. Ninguém tem ou deve esperar autonomia de estratégia. Sem alinhamento, a autonomia é desperdiçada.

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

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 entregar a coisa certa. As etapas 1-3 do caminho feliz são sobre descobrir o que achamos que é a coisa certa, as etapas 4-7 sobre como validamos, iteramos e escalamos essa coisa. Fazemos isso porque:

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

Em 2025, rodamos 750 experimentos em cerca de 250 dias úteis, o que dá cerca de 3 decisões de entregar/não entregar 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 na entrega da coisa certa prejudica nossos clientes, e quanto maiores ficamos, maior o custo de oportunidade da velocidade.

2) Uma vez perdida, nunca volta

Humanos naturalmente se conformam e passam a depender de processos, então mesmo aqueles inventados para casos de uso restritos são aplicados mais liberalmente do que o pretendido. Os incentivos mudam para seguir o sistema em vez de ter o impacto que o sistema foi projetado para garantir, e a memória muscular da organização para "saber, mas ir" se atrofia e se perde. Quase não há erro único que poderíamos prevenir que seria uma boa troca no 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. Entregar com mais frequência constrói nosso julgamento - como um atleta, ficamos mais fortes com as repetições. Enquanto constroem repetições, os times podem alavancar o julgamento daqueles com mais repetições e mais contexto - orientação contínua e 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 a rota, não quando estamos partindo), líderes de categoria ou país que podem servir como proxy de 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/contribuição que recebem. A revisão de produto é o único portão em nosso processo de desenvolvimento.