Português

Estilo de Liderança de Shreyas Doshi: Pensamento de Produto Sobre Product Management

Perfil de Liderança de Shreyas Doshi

Shreyas Doshi passou 10 anos dentro de três das organizações de produto mais estudadas na internet — Yahoo, Twitter e Stripe — e depois abandonou títulos executivos para pensar e escrever em público.

Essa decisão é ou um risco de carreira ou uma estratégia, dependendo do que você está tentando construir.

No caso de Doshi, é uma estratégia. Ele deixou Stripe por volta de 2019 sem um próximo trabalho e se tornou uma das vozes mais citadas em estratégia de produto dentro de 18 meses. Ele fez isso através de threads no X (Twitter) que foram específicas o bastante para serem úteis e honestas o bastante para serem incômodas. Ele agora tem mais de 500 mil seguidores e mais influência sobre como product managers pensam sobre seu trabalho do que a maioria dos CPOs em empresas públicas. Sua escrita estendida está coletada em seu Substack, onde publica frameworks de forma mais longa que seus threads do Twitter comprimem.

Isso não é coincidência. Os frameworks que Doshi construiu — priorização de tarefas LNO, a distinção product manager versus product thinker, disciplina de pre-mortem — são diretamente aplicáveis a decisões que você está tomando essa semana. Eles não vieram de pesquisa acadêmica ou engajamentos de consultoria. Eles vieram de anos operando dentro de problemas difíceis em empresas em rápido movimento.

Fatos-Chave

  • Antigo Diretor de Product Management no Stripe — liderou product orgs antes de partir por volta de 2019 para ensinar e escrever independentemente
  • Papéis anteriores no Google, Twitter, Yahoo e Nokia — mais de uma década dentro de quatro das organizações de produto mais estudadas dos anos 2000–2010s
  • Conselheiro independente de produto e consultor para organizações de PM de tech e startups
  • LinkedIn Top Voice e um dos product thinkers mais seguidos no X (Twitter), com mais de 500 mil seguidores
  • Autor de frameworks de PM amplamente compartilhados — LNO (Leverage/Neutral/Overhead), product thinker vs. product manager, disciplina de pre-mortem, anti-goals, "product sense"
  • Contribuidor para Lenny's Newsletter e publicador de frameworks de forma longa em shreyasdoshi.substack.com

O Framework LNO (Modelo de Pensamento de Produto de Doshi)

O Framework LNO é o sistema de classificação de tarefas em três buckets de Shreyas Doshi que ordena cada unidade de trabalho de um product manager em tarefas Leverage (decisões de impacto desproporcional e artefatos estratégicos que merecem aproximadamente 80% da atenção), tarefas Neutral (coordenação necessária e reporte que deveriam consumir o tempo viável mínimo), e tarefas Overhead (reuniões redundantes, aprovações e rituais de status que ativamente deslocam trabalho leverage e devem ser agressivamente eliminadas). A disciplina do framework é que overhead nunca é reduzido por tentar mais — é reduzido nomeando-o, categorizando-o publicamente e dando permissão explícita aos times para cortá-lo.

Análise do Estilo de Liderança

Estilo Peso Como aparecia
Arquiteta de Frameworks 55% A contribuição primária de Doshi é conceitual. Ele pega problemas que praticantes sentem intuitivamente mas não conseguem nomear precisamente e dá a eles frameworks que tornam o problema acionável. LNO não descreve nada novo sobre priorização de tarefas — pessoas sempre souberam que alguns trabalhos importam mais que outro trabalho. Mas nomear as categorias (Leverage, Neutral, Overhead) e insistir nas distinções cria uma ferramenta de decisão. A distinção product manager versus product thinker funciona do mesmo jeito: a diferença existia antes de Doshi nomeá-la, mas nomeá-la deu aos líderes de produto uma linguagem compartilhada para um gap que tinham estado trabalhando sem conseguir abordar diretamente.
Operadora de Clareza Radical 45% Doshi operou dentro de organizações onde clareza estratégica era genuinamente difícil de manter. A direção de produto do Twitter durante seu tempo lá foi contestada no nível executivo. As ambições do Stripe estavam expandindo mais rápido que alinhamento organizacional. Nesses ambientes, seu estilo operacional era sobre remover ambiguidade — estar disposto a dizer coisas incômodas claramente em vez de gerenciar ao redor delas. Sua escrita pública reflete a mesma qualidade. Ele regularmente publica threads que nomeiam modos de falha em product management que a maioria dos praticantes reconhece mas não diz em reuniões. A combinação de precisão de framework e diretividade é o que dá à sua persona pública credibilidade.

A divisão 55/45 importa porque Doshi está operando diferentemente da maioria dos pensadores de produto. Ele não é principalmente um coach (como Torres) ou um crítico de sistemas (como Cagan). Ele está construindo frameworks em público e testando-os contra um grande público de praticantes que empurram para trás, aplicam e reportam de volta. Esse loop de feedback é o mecanismo que mantém seus frameworks honestos.

Principais Traços de Liderança

Traço Avaliação O que significa na prática
Disciplina de pre-mortem Excepcional O hábito operacional mais útil de Doshi é executar pre-mortems antes de se comprometer com iniciativas maiores. Um pre-mortem pergunta: se esse projeto falhar um ano a partir de agora, qual é a história de falha mais provável? Essa pergunta superficializa assunções que otimismo esconde. A maioria dos processos de planejamento é estruturada para construir confiança em um plano. Um pre-mortem é estruturado para encontrar o ponto fraco do plano antes de estar investido nele. Doshi aplica isso à estratégia de produto, a decisões de carreira, e a design organizacional. É transferível para qualquer decisão de apostas altas com resultados incertos.
Priorização de tarefas LNO Muito Alta O framework LNO de Doshi — Leverage, Neutral, Overhead — é uma ferramenta diária para gerenciar para onde a atenção vai. Tarefas Leverage são as que produzem resultados desproporcionais: uma decisão que desbloqueia cinco pessoas, uma conversa que clarifica a estratégia para o trimestre, um documento que substitui dez reuniões. Tarefas Neutral são necessárias mas não multiplicadoras: revisões, reporte, comunicação rotineira. Tarefas Overhead são drag organizacional: reuniões que poderiam ser emails, processos que existem porque ninguém as removeu, trabalho de coordenação que não produz output direto. A maioria das pessoas sabe que está gastando tempo em overhead. LNO dá a você um rótulo e um mandato para eliminá-lo.
Tolerância por dizer verdades incômodas publicamente Alta Threads públicos de Doshi regularmente nomeiam coisas que praticantes concordam mas não dizem no trabalho. "Seu time de PM é principalmente project managers" não é algo que a maioria dos CPOs vai dizer em um all-hands. Doshi o diz no X com exemplos específicos. "A maioria dos roadmaps de produto são documentos de vaidade" não é uma opinião segura dentro de uma empresa com um roadmap recentemente aprovado. A disposição de Doshi em publicar especificidades incômodas é o que distingue sua escrita de conselho genérico de product management — e é o que gera o engagement que faz sua audiência confiar nos frameworks.
Distinguindo product managers de product thinkers Alta A distinção product manager versus product thinker de Doshi é sua contribuição intelectual mais precisa. Um product manager executa um processo: discovery, priorização, roadmap, entrega. Um product thinker pergunta se o processo está construindo a coisa certa — se o resultado sendo otimizado é o resultado que importa, se o problema de cliente sendo resolvido é o problema real, se a estratégia que o roadmap serve é correta. A maioria das organizações contrata para competência de product management e espera outputs de product thinking. Essa desconexão é uma fonte persistente de frustração dos dois lados.

Os 3 Frameworks Que Definiram Shreyas Doshi

1. Framework LNO — Leverage, Neutral, Overhead

Doshi desenvolveu o framework LNO como resposta a um problema que observou através de múltiplas organizações: pessoas inteligentes e capazes trabalhando muito duro e produzindo resultados medíocres. O problema não era esforço. Era para onde o esforço estava direcionado.

LNO é um sistema de classificação para tarefas. Cada tarefa que um PM faz cai em uma de três categorias. Tarefas Leverage são as que produzem resultados desproporcionais ao tempo investido — decisões que desbloqueiam times, documentos estratégicos que criam alinhamento entre funções, conversas de cliente que mudam a direção de uma feature. Essas são as tarefas que merecem 80% do tempo de um PM.

Tarefas Neutral são necessárias mas não multiplicadoras. Cerimônias de sprint, atualizações de status, reuniões de revisão regular, comunicação rotineira de stakeholder. Essas precisam acontecer. Não deveriam consumir mais tempo que o mínimo necessário para mantê-las funcionando.

Tarefas Overhead são a categoria cara. São o trabalho que leva tempo sem produzir output que importa: processos de aprovação redundantes, coordenação que poderia ser substituída com uma decisão, reuniões que não produzem decisões e poderiam ter sido um email. Overhead é corrosivo não apenas porque consome tempo, mas porque desloca trabalho Leverage. Um PM que gasta 4 horas em reuniões de atualização de status não está gastando 4 horas a menos em trabalho neutral. Está gastando 4 horas a menos em decisões e pensamento estratégico que realmente avançam o produto.

A aplicação prática do framework LNO requer a disposição de fazer algo que a maioria das organizações resiste: explicitamente categorizar overhead e eliminá-lo. Isso é mais difícil do que parece porque overhead é frequentemente apresentado como accountability — a reunião de status existe porque liderança quer visibilidade, o processo de aprovação existe porque algo deu errado uma vez. O argumento de Doshi é que accountability alcançado através de overhead é uma troca ruim. A visibilidade que você consegue custa mais em trabalho Leverage do que vale a pena.

2. Product Manager Versus Product Thinker

A contribuição conceitual mais influente de Doshi não é um framework que você preenche. É uma distinção que força um tipo diferente de auto-avaliação. Seth Godin aplica disciplina similar a marketing — perguntando se você está construindo para a audiência viável mais pequena que sentiria sua falta, em vez de otimizar para alcance. O movimento estrutural é idêntico: questionar a premissa antes de otimizar a execução.

Um product manager executa um conjunto de práticas. Discovery, definição, priorização, entrega, medição. Eles sabem como executar um sprint, escrever um PRD, conduzir uma entrevista de usuário, analisar um funil. Essas são habilidades aprendíveis e a maioria dos PMs que fazem o trabalho por dois ou três anos as tem razoavelmente bem.

Um product thinker pergunta a questão upstream de todas essas práticas: estamos resolvendo o problema certo? O resultado que estamos otimizando é o resultado que importa? O segmento de cliente que estamos construindo é aquele cujo problema vale a pena resolver? Estamos capturando valor em proporção ao valor que estamos criando?

A distinção é importante porque a maioria das organizações contrata para habilidades de product management e espera outputs de product thinking. Elas querem um PM que consiga executar o processo eficientemente, mas também querem um PM que saiba quando o processo está apontado para coisa errada. Essas são pessoas diferentes — ou melhor, as mesmas pessoas em estágios diferentes de desenvolvimento. Você pode ser um PM tecnicamente proficiente sem ser um product thinker. Mas você não consegue ser um PM de alto impacto sem isso.

O argumento de Doshi é que a diferença entre PMs que têm impacto de tamanho grande e PMs que são competentes mas intercambiáveis é quase sempre essa distinção. Os de alto impacto estão perguntando se o que estamos construindo é certo antes de perguntar se estamos construindo-o corretamente.

Para líderes de produto, a implicação é diagnóstica: olhe as perguntas que seus PMs fazem em revisões. Se toda pergunta é sobre execução — qual é o timeline, quais são as dependências, qual é o risco — e nenhuma delas é sobre estratégia — por que estamos fazendo isso, o que acontece se não fizermos, o que teria que ser verdade para isso suceder — você tem um time de product managers capazes que não estão fazendo product thinking. O fix não é um programa de treinamento. É mudar quais perguntas você faz em revisões, o que muda quais perguntas sentem seguras de fazer.

3. Pre-Mortem e Pensamento de Anti-Goals

A prática de pre-mortem de Doshi vem do trabalho de Gary Klein em decision science, publicado em HBR, mas Doshi a aplicou e popularizou especificamente no contexto de product management. Peter Drucker enquadrou a mesma disciplina décadas antes como "o executivo efetivo" — o gerente que toma decisões perguntando primeiro o que teria que ser verdade para isso estar errado, não o que teria que ser verdade para estar certo. O exercício é simples: antes de se comprometer com uma iniciativa maior, projete-se um ano para frente para um estado de falha. O projeto lançou, não funcionou, e agora você está fazendo uma retrospectiva. Qual foi a razão de falha mais provável?

A disciplina do pre-mortem é que ele contorna o viés de otimismo que permeia o planejamento. Quando você está planejando para frente, seu cérebro está pattern-matching em histórias de sucesso e filtrando os modos de falha. Quando você está projetando para trás do fracasso, os modos de falha ficam visíveis porque você deu a si mesmo permissão de levá-los a sério.

Doshi aplica isso à estratégia de produto, a decisões de design organizacional e a escolhas de carreira pessoal. A estrutura é sempre a mesma: nome a história de falha com antecedência, identifique a assunção que essa história de falha revela, e decida se vai mudar o plano ou aceitar o risco explicitamente.

Anti-goals são uma prática relacionada. A maioria do planejamento estratégico define o que você está tentando alcançar. Anti-goals definem o que você está explicitamente não tentando alcançar — resultados que você está disposto a sacrificar, segmentos de cliente que você não está otimizando, métricas que você está disposto a deixar declinar em serviço ao objetivo que escolheu.

Anti-goals importam porque revelam tradeoffs que goal-setting positivo esconde. Se seu objetivo é crescimento em contas enterprise, o que você está de-priorizando? Se você não disser explicitamente, descobrirá implicitamente a resposta quando sua retenção de SMB começar a declinar e ninguém tomou a decisão de deixar isso acontecer. Anti-goals força o tradeoff à superfície onde consegue ser decidido em vez de descoberto.

O Que Shreyas Doshi Faria em Seu Papel

Se você é um CEO, o framework mais útil de Doshi para você é anti-goals. Você quase certamente tem objetivos anuais. Quais são as coisas que você está explicitamente não otimizando esse ano? Se você não consegue responder essa pergunta claramente, sua organização descobrirá a resposta implícita na segunda metade do ano quando prioridades conflitantes criam deadlock de decisão. A lista de anti-goals força você a decidir o que é de menor prioridade antes do momento de conflito, quando a decisão é mais fácil de fazer claramente.

Se você é um COO, o framework LNO se aplica diretamente a como seu time gasta tempo. Rode o exercício com seus diretos: tenha cada pessoa classificar sua última semana de trabalho em Leverage, Neutral e Overhead. Então olhe a coluna de overhead como uma pergunta de liderança, não uma pergunta individual. Se seus diretos estão gastando tempo significativo em reuniões que não produzem decisões, ou em coordenação que existe porque informação não flui automaticamente, essas são falhas estruturais que você consegue corrigir. Não peça para pessoas eliminarem overhead de seus calendários individuais sem mudar as estruturas organizacionais que a criam.

Se você é um líder de produto, a distinção product manager versus product thinker dá a você uma lente diagnóstica para seu time. Para cada um de seus PMs, pergunte: qual foi a última vez que eles desafiaram a premissa de um projeto antes de ele ser aprovado? Qual foi a última vez que eles disseram "Não acho que deveríamos construir isso" baseado em um argumento estratégico em vez de um argumento de capacidade? PMs que só dizem não quando não há capacidade disponível estão executando um processo. PMs que dizem não quando o projeto está errado estão fazendo product thinking. Você quer um time que faz ambos, e você o constrói tornando seguro levantar perguntas de estratégia antes que o planejamento esteja travado.

Se você está em vendas ou marketing, o pre-mortem de Doshi é a prática mais diretamente aplicável. Antes de se comprometer com uma campanha, uma mudança de preço ou um motion de go-to-market, rode a história de falha para frente: é um ano a partir de agora, isso não funcionou. Qual foi a razão de falha mais provável? Essa pergunta superficializará a assunção na qual você está mais desconfortável — que é normalmente aquela que mais importa. A maioria dos fracassos de GTM são previsíveis com antecedência. O pre-mortem não previne fracasso; ele converte assunções não examinadas em riscos conhecidos que você consegue mitigar ou aceitar explicitamente.

Aplicando o Pensamento de Doshi Com Rework

Product sense não se desenvolve isoladamente — se desenvolve quando PMs conseguem ver o arc completo de uma decisão, desde sinal de cliente até compromisso de roadmap até resultado entregue. A maioria dos times de produto perde esse arc porque a evidência vive em seis ferramentas: notas de entrevista em um doc, tickets em um tracker, deals em um CRM, temas de suporte em um help desk, decisões em Slack, métricas em um dashboard. Rework colapsa a stack — CRM, project management, conversas de cliente e operações compartilhadas em um workspace começando em $6/usuário/mês — para que o sinal que um product thinker precisa questionar uma premissa seja realmente alcançável. Esse é o pré-requisito para LNO funcionar: você consegue apenas classificar uma tarefa como Leverage vs. Overhead se consegue ver quais tarefas moveram a métrica que importou. Rework dá a PMs, vendas e times de suporte uma superfície compartilhada onde bets de roadmap e seus resultados downstream são visíveis na mesma view, que é exatamente a visibilidade de workflow que os frameworks de Doshi assumem mas a maioria dos orgs nunca constrói.

Citações Notáveis e Lições Além da Sala de Diretores

"A diferença entre PMs ótimos e PMs mediocres não é talento. É como eles pensam sobre problemas." Doshi publicou isso em um thread que recebeu dezenas de milhares de engagements, e o motivo por que aterrou é que é um reframe que a maioria dos praticantes não tinha encontrado. A atribuição normal para qualidade de PM é habilidade de execução. O argumento de Doshi é que habilidade de execução é table stakes. O diferencial é upstream.

Seu enquadramento de "parecer ocupado vs. ser produtivo" vale a pena aplicar literalmente como uma auditoria de calendário. Puxe as últimas duas semanas. Para cada evento e tarefa, pergunte honestamente: foi esse trabalho Leverage que produziu resultados, ou foi Overhead que produziu a aparência de atividade? A maioria dos líderes que fazem esse exercício honestamente encontram que 30-40% de seu tempo era overhead disfarçado de trabalho. Isso não é uma falha pessoal. É um problema de design organizacional. Mas é um problema que você consegue começar a corrigir uma vez que o tenha nomeado.

Seu conselho mais consistentemente aplicável é sobre confiar em dados incômodos cedo. A disciplina de pre-mortem de Doshi vem da mesma fonte que seu enquadramento de product thinker: a maioria dos fracassos de planejamento acontecem porque a informação que teria mudado a decisão estava disponível antes da decisão ser tomada, mas a cultura organizacional não criou espaço para ela. Pesquisa do MIT Sloan Management Review sobre bias de decisão documenta o mesmo padrão — times sistematicamente desconto sinais de aviso inicial sob pressão de planejamento, e exercícios estruturados de pre-mortem melhoram mensuravelmente a qualidade de decisão. Seu princípio operacional é ativamente procurar o sinal incômodo em vez de filtrá-lo.

Onde Este Estilo Falha

Os frameworks de Doshi assumem que você tem pessoas inteligentes que conseguem lidar com honestidade intelectual sobre seu próprio desempenho. LNO quebra em organizações onde a definição de "leverage" é contestada — onde o que o PM acha que é alto leverage difere do que a organização valoriza. Isso não é um problema de framework; é um problema de alinhamento que o framework superficializa mas não consegue resolver.

Seu modo de escrita pública também não se traduz diretamente para operadores que precisam privacidade. A plataforma de ensino de 500 mil seguidores de Doshi funciona porque ele não é empregado pelas empresas que está analisando. Dentro de uma empresa, escrever publicamente sobre fracassos de produto cria riscos diferentes.

E a maioria de seus frameworks é otimizada para times de produto B2B SaaS — empresas de mid-stage com produtos técnicos e PMF estabelecido. Produtos de hardware, indústrias reguladas, e negócios de consumo com dinâmicas de discovery diferentes são menos bem servidos por seu enquadramento específico. Os princípios subjacentes se transferem; as aplicações específicas nem sempre.

Para leitura relacionada sobre estratégia de produto e priorização, veja Estilo de Liderança de Marty Cagan, Estilo de Liderança de Teresa Torres e Priorização Estratégica para Líderes de Produto.