Lições do produto aprendidas: uma conversa com Shreyas Doshi e John Cutler

Publicados: 2021-07-13

Em um período de tempo relativamente curto, Shreyas Doshi se tornou um dos distribuidores mais populares de conselhos de produtos no Twitter. Por quê? Sua escrita é clara, humilde e autoconsciente – traços que muitas vezes faltam em meio ao fogo das tomadas quentes. Seu formato de escolha? Tópicos. E muitos deles. Entrelaçados mas organizados. O valor de uma carreira de sabedoria embalado em seqüências de 280 caracteres. Disponível para todos aqui.

Eu estava muito curioso sobre a pessoa por trás do (bom tipo de) loucura. Então marcamos uma entrevista! Cobrimos tópicos como liderança, tornar-se um melhor ouvinte, o papel da gerência intermediária, carreira e identidade própria, teimosia, teatro de calendário e tratar seus painéis como produtos.

O que se destacou? Shreyas tem uma vasta experiência em gerenciamento de produtos. Ele trabalhou como gerente de produto de linha de frente e gerente de gerentes de produto em empresas como Stripe, Google, Twitter e Yahoo. Ele é um grande escritor e palestrante. Mas é sua humildade e consideração que realmente brilha. Ele adverte as pessoas a não copiarem cegamente seus conselhos e admite abertamente que aprendeu muitas dessas lições da maneira mais difícil.

A entrevista tem 1h30m (veja o player de áudio abaixo). Se você quiser pular, criamos um esboço da entrevista abaixo com carimbos de data/hora. Para cada seção, Shreyas teve a gentileza de fornecer links para tópicos relacionados.

Tem perguntas de acompanhamento para Shreyas? Por favor, tweet suas perguntas incluindo @Amplitude_HQ, @shreyas e #shreyasinterview. Se houver interesse suficiente, tentaremos agendar uma AMA de acompanhamento.

Eu tenho uma pergunta para @shreyas e @johncutlefish #shreyasentreview Click To Tweet

E se você quiser saber mais sobre estratégia de produtos e liderança em gerenciamento de produtos, faça o download de uma cópia do guia North Star. Está repleto de orientações e estruturas para ajudá-lo a gerar impacto para seus negócios e sua equipe imediatamente.

Índice da Entrevista

A transcrição completa inclui tweets relacionados para contextualizar. Obrigado a Shreyas pela curadoria para todos!

  • Introdução [00:00:00]
  • “Não acredite em tudo que escrevo…” [00:01:07]
  • Entendendo a nós mesmos [00:04:03]
  • Tornando-se um melhor ouvinte [00:05:13]
  • Transição de IC para gerente [00:11:49]
  • Discutindo incerteza e cultura organizacional [00:14:10]
  • A gerência intermediária e a “verdade real” [00:16:52]
  • O papel da liderança do produto [00:18:01]
  • Identidade profissional (e a mudança para papéis de liderança) [00:21:56]
  • O papel do gerente em ajudar as pessoas a adotarem comportamentos não padrão [00:25:39]
  • Mentalidade, princípios e táticas (e ficar preso às táticas) [00:30:29]
  • O básico/fundamentos para uma equipe de alto desempenho [00:35:11]
  • Por que equipes com o básico atendido produzem produtos ruins? [00:37:31]
  • Intencionalidade e teimosia (com a empresa que você quer ser) [00:39:24]
  • Inteligência analítica e criativa [00:44:14]
  • Nível de impacto, nível de execução e nível de óptica [00:49:13]
  • Preconceitos cognitivos e vocabulário compartilhado [00:54:37]
  • Tratando painéis como um produto [01:01:51]
  • Calendários cheios, reatividade, auto-identidade e hábitos positivos/negativos [01:08:20]
  • Melhorar a situação atual (e lacuna versus pensamento atual) [01:14:24]
  • LNO: Tarefas de Alavancagem, Neutro e Sobrecarga [01:18:10]
  • Conclusão [01:21:23]

Transcrição da entrevista

Introdução [00:00:00]

John Cutler: Bom dia, Shreyas.

Shreyas Doshi: Bom dia, John.

John Cutler: Como vai?

Shreyas Doshi: Muito bom. Bom estar aqui.

John Cutler: Então esta é a segunda vez que nos falamos. E eu me lembro quando conversamos pela primeira vez, você estava tipo, devo continuar fazendo essa coisa do Twitter? Ou, que tal um livro? Não sei quantos meses foram. Quero dizer, parece que o tempo de pandemia esmaga as coisas em geral, mas já faz algum tempo e as coisas explodiram para você.

Então, eu só gosto de notar a diferença desde a última vez que nos falamos. Então eu acho, parabéns.

Shreyas Doshi: Obrigado. Tem sido divertido. Apenas escrevendo alguns pensamentos sobre o produto e outros enfeites. 280 caracteres por vez.

John Cutler: Para quem não sabe, Shreyas Doshi, vou fazer a introdução mais rápida. Ele é um gerente de produto. Então, mais recentemente na Stripe, ele tem experiência no Twitter e no Google, no Yahoo. É um escritor prolífico. E acho que é isso.

Eu queria perfurar o véu da invencibilidade, para começar, se estiver tudo bem. Porque sua escrita é tão concisa. Qual é o erro com o qual você estava lutando nos últimos dois meses.

“Não acredite em tudo que escrevo…” [00:01:07]


Shreyas Doshi: Sim. Então, uma coisa que eu gosto de dizer sobre minha escrita, é antes de tudo, não acredite em tudo que eu escrevo e não pegue tudo que eu escrevo e apenas implemente porque você gosta de meus escritos, ou porque a coisa tem um monte de curtidas , então deve ser verdade. John, isso é algo que ao longo do ano passado eu realmente comecei a escrever sobre meus pensamentos sobre produto e estratégia e organizações e outros enfeites.

Antes de clicar no tweet ou, ou no botão enviar, a maior apreensão que costumo ter é oh, aqui estão as seis maneiras pelas quais o que acabei de dizer pode ser prejudicial, se for tirado do contexto ou se implementado no contexto errado. Essa é uma preocupação constante que tenho sobre o que escrevo e, às vezes, parte da precisão e talvez parte do poder da escrita, se houver, pode parecer mais verdadeira do que realmente é em sua situação específica.

A escrita está longe de ser perfeita. Porque provavelmente perde muitas, muitas nuances, mesmo quando tento torná-lo mais claro ou em algum lugar no piso. Então isso é um. A segunda coisa é que eu acho que twittei isso algumas semanas atrás que você sabe, eu tendo a falar muito sobre coisas antipadrões que não se deve fazer. E a razão pela qual eu falo sobre isso e às vezes as pessoas me dizem, oh, isso criou uma grande clareza. Eu vi esse antipadrão dentro da minha equipe, dentro da minha empresa, dentro de mim mesmo, dentro do meu gerente, seja lá o que for. E como você chegou lá? E então, eu twittei esse ponto, que é, você sabe, muitos desses antipadrões sobre os quais escrevo, eu tenho sido esse antipadrão. Direita?

Eu tenho visto isso dentro de mim.

Às vezes é apenas por algumas horas que tipo, oh, estou entrando nesse antipadrão como, oh, eu senti isso, e parei, e tive sucesso em pará-lo. Às vezes, tenho um certo antipadrão sobre o qual escrevo há muitos meses. E há outros que eu tenho há muitos anos e coisas que eu não faço um ótimo trabalho por mim mesmo.

E então há esse aspecto de, você sabe, muito do que eu escrevo, eu vi partes disso dentro de mim, ou tudo dentro de mim por diferentes períodos de tempo. E, acho que a única diferença talvez seja que você sabe, é o tipo de auto-observação, certo? Uma das coisas que gosto de compartilhar também é que podemos falar sobre táticas e podemos falar sobre frameworks, estruturas e templates para gerenciamento de produtos.

Entendendo a nós mesmos [00:04:03]

Mas pelo lado suave, acho que uma coisa muito importante para todos nós, como gerentes de produto, percebermos e melhorarmos como gerentes de produto é entender a nós mesmos. Você sabe, o hub que eles falam, ah, entenda o usuário, entenda o cliente, entenda o mercado, entenda o concorrente.

Eu concordo com tudo isso. Mas também entenda a si mesmo. Comece entendendo a si mesmo. Agora você não vai entender tudo de si mesmo de uma vez. Mas se você começar entendendo a si mesmo, descobrirá que alguns desses outros entendimentos do usuário e outros enfeites se tornam mais fáceis.

Há muitas, muitas coisas em que não sou muito bom. Recentemente, acho que estava, mais uma vez, conversando no Twitter e alguém me perguntou oh Shreyas, como alguém deve se comportar bem dentro de uma organização?

Eu disse, olha, eu não tenho uma resposta para isso, porque eu tenho sido muito ruim em gerenciar por muitos, muitos anos. Andrew Yu havia me enviado um livro sobre gerenciamento. E então eu disse: Ei, Andrew, você provavelmente deveria responder a este tweet em vez de eu responder. Então isso é apenas um exemplo de uma coisa que você sabe, eu ainda não entendi.

Tornando-se um melhor ouvinte [00:05:13]

John Cutler: Uma coisa que eu realmente gosto é que através de seus tópicos, você é vulnerável e humilde. Lembro-me de um tweet que eu realmente gostei, onde você observou que seu eu mais jovem era um ouvinte melhor e que você caiu em um período em que não estava ouvindo tão bem.

E isso foi extremamente impactante para mim. Porque eu pensei, eu passei por essas fases na minha vida, e não é uma situação estática. Você está sempre aprendendo. Eu estava me perguntando especificamente com essa situação, como era essa auto-realização? Você sabe, quando você percebe isso e como você lida com isso? E então, quais os passos que você tomou? E você começou a detalhar no tópico, mas eu estaria realmente interessado em você explicar e ouvir pessoalmente.

Shreyas Doshi: Então, eu costumava ser um excelente ouvinte quando criança. No início da minha infância, eu também tinha uma memória muito forte. Isso não é mais o caso. Eu esqueço as coisas o tempo todo agora. Mas eu comecei assim. E tantas coisas na escola, por exemplo, eram muito cedo, fáceis para mim porque eu estava apenas ouvindo o que o professor dizia.

E então eu consegui retê-lo por muito tempo. Isso mudou na minha adolescência e vinte e poucos anos. Você sabe, eu não sei por quê. Deve ter sido exatamente o que você passou em sua juventude. Onde você apenas, em algum momento, eu simplesmente desligava completamente na faculdade.

E eu não tinha ideia, eu estava sentado lá fisicamente, mas não tinha ideia do que estava sendo dito. E isso continuou. Acabou de se tornar este padrão. Considerando que quando eu comecei minha carreira como engenheiro de software, não era mais aquele grau de apatia sobre o que está sendo dito em uma reunião ou o que, o que outra pessoa está dizendo. Mas acabei perdendo essa habilidade, devido a não usá-la por cinco, seis anos naquele momento.

John Cutler: Houve um momento em que você ficou tipo, espere, eu perdi isso? Tipo, como você fez, como surgiu em você, ou foi como uma queimadura lenta. Ou talvez foi um gerente ou alguém que compartilhou a notícia com você? Como, como você percebeu isso?

Shreyas Doshi: Sabe, John, percebi isso muito tarde. Então, quero dizer que estava no estado de ser um bom ouvinte, por cerca de 12 anos ou mais, quando comecei minha carreira. O que isso significava era, é claro, que eu estava ouvindo. Eu estava processando, etc. Mas eu estava nesse modo do clássico formando meus próprios pensamentos. Formando minha resposta e preparando minha resposta. Ou, não realmente ouvindo o que foi dito, mas ouvindo o que eu queria ouvir.

Então eu estava nessa fase por pelo menos 12 anos na minha carreira. Em algum momento, a maior percepção para mim foi que a chave para entender a outra pessoa será ter certeza de que ela sabe que eu a entendo. Direita? Então eu comecei com esse primeiro passo. E esse foi um tipo muito tático, não foi baseado em nenhum princípio. Foi uma tática como ok.

John Cutler: Você teve que pensar em sua cabeça que…

Shreyas Doshi: Sim. Para ser um bom gerente, preciso ter certeza de que a outra pessoa entende que eu entendo o que ela está dizendo. Esse é o lugar que eu comecei. E, e então eu fiz isso, e eu diria tipo, isso talvez tenha me levado de um quatro em dez para um seis em dez. O que é bom. É uma melhoria.

Mas então, a próxima grande realização, e a mudança quântica que pude fazer, foi quando percebi que quando você ouve apenas o que está sendo dito, e está totalmente presente, as respostas são criadas. Direita? Então eu realmente não tenho que pensar enquanto você está falando. Ou nem preciso pensar em como vou resumir o que você está dizendo, só para ter certeza de que entendi.

Eu só quero estar cem por cento presente. E eu quero ser curioso. Essa foi a mudança. Foi essa curiosidade genuína e desenvolver essa curiosidade genuína, juntamente com a habilidade de estar presente e ser capaz de observar minhas partes, e meio que me trazer de volta exatamente às palavras que estavam sendo pronunciadas.

Então, quando eu fiz isso, quando me aproximei dessa curiosidade e presença genuínas, foi quando eu vi, oh, uau, quando estou fazendo isso, duas coisas estão acontecendo. Uma é que estou [00:10:00] apenas me deparando com essa outra pessoa como muito mais interessada no que ela está dizendo. E segundo, a qualidade da minha resposta é muito maior.

Considerando que anteriormente, muitas vezes, a resposta tendia a ter uma sensação de, ok, eu ouvi você, e dado o meu papel, muitas vezes é como eu ouvi você, e aqui está o meu conselho. Ou aqui está minha resposta. A resposta tornou-se uma pergunta, em vez de uma afirmação.

Foi assim que eles entenderam que eu realmente os estava entendendo. E eu estava fazendo uma tentativa genuína de entendê-los melhor. Eles me disseram algo. Eu estava realmente presente. Eu estava genuinamente curioso. E por causa disso, fiz uma pergunta que, de outra forma, não teria feito. E essa pergunta nos levou mais perto de poder entender melhor a situação. Quando comecei a fazer isso, percebi cada vez mais que, oh, isso é realmente eficaz. Fazer perguntas às pessoas é muito mais eficaz, se forem as perguntas certas. E, se eles são baseados em uma compreensão profunda, ou tão profunda quanto você pode e compreensão, do que a outra pessoa está tentando dizer sobre a situação.

John Cutler: Parece que você desenvolveu algo, ao longo do tempo, e ficou muito melhor nisso dessa maneira. Tipo, você pode fazer perguntas melhores em um para um, etc.

Shreyas Doshi: Claro. E, você sabe, fui gerente de PMs em cada uma das quatro empresas nas quais fui PM. Três dessas quatro empresas, entrei como contribuinte individual, incluindo meu empregador mais recente Stripe. Entrei como colaborador individual e depois comecei a gerenciar pessoas.

Transição de IC para gerente [00:11:49]


Então eu passei por essa transição de IC para gerente. Muitas pessoas passam por isso uma vez ou talvez duas vezes. Uh, e então eles permanecem gerentes. Já passei por isso várias vezes. E eu não me importo de estar no IC onde faz sentido. Então tem funcionado bem para mim.

Cada vez que tem sido diferente. Porque como eu cresci como gerente. Acho que quando comecei a gerenciar, foram nove meses como gerente de produto. Foi-me dito, oh, nós gostamos do que você está fazendo. Por que você não gerencia uma equipe pequena? Olhando para trás, eu não percebi isso na época, mas olhando para trás, eu me senti como se eu fosse um péssimo gerente de PMs. Isso remonta a muitos desses antipadrões. Eu fui isso. Porque me lembro desde cedo, eu tinha tanta certeza de que tinha a resposta.

E então esse foi um. E segundo, pensei que meu trabalho era fornecer a resposta. Se eu encontrei resistência dentro da minha equipe para aceitar ou aceitar essa resposta, então senti que meu trabalho era convencê-los por meios muito analíticos, por que essa é a resposta certa, certo?

Eu era horrível como gerente naquela época. E é claro que agora eu adoto uma abordagem muito diferente. Muito disso tem a ver com apenas, você sabe, cultivar essa curiosidade genuína, eu acho, maturidade de vida geral também. Mas também ser capaz de observar meus pensamentos e também entender o que um gerente de PM deve fazer.

Qual é o seu trabalho e qual é o seu papel? Eu tenho uma melhor compreensão agora, enquanto anteriormente me pediram para começar a gerenciar pessoas, como se eu não tivesse ideia do que realmente deveria fazer.

John Cutler: Quando você pensa nas empresas em que esteve envolvido, quero dizer, acho que uma coisa que notei sobre certas culturas de empresas é que elas lidam de maneira muito diferente com a discussão da incerteza. Em alguns, você sabe, nunca, nunca mencione a incerteza, a menos que você tenha um plano absoluto para reduzi-la.

E em outras culturas, eles parecem muito mais abertos para um líder dizer, só não sei agora. Então, qual é o seu plano de jogo para isso? Como você já passou por essas organizações, mas como você entendeu a cultura de vulnerabilidade para os líderes?

Porque é obviamente importante, mas se manifesta de maneira diferente em diferentes culturas.

Discutindo incerteza e cultura organizacional [00:14:10]

Shreyas Doshi: Eu gosto que você mencionou cultura lá, John, porque tudo remonta a isso. Existem culturas onde. Sim, você deveria ter certeza. E se você não tem certeza, e se você não tem toda a justificativa, a justificativa analítica, você é considerado incompetente.

Existem outras culturas, onde uma certa quantidade de incerteza é vista como apenas parte do que fazemos, o que é, sim, não saberemos como isso vai funcionar e tudo bem.

Isso não significa que a segunda categoria de cultura seja menos rigorosa. Eu diria que é mais rigoroso. Porque não é baseado em ilusões sobre resultados matemáticos estritos baseados em certas entradas. Ele entende a aleatoriedade envolvida quando você pega um produto [00:15:00] e o traz para o mundo exterior. Ele entende outras aleatoriedades, o próprio sistema no mercado e outros enfeites.

Funciona dentro desse tipo de compreensão do mundo real dessas coisas. Contra alguns idealizados, você sabe, ah sim, devemos ser capazes de provar isso em uma abordagem tipo planilha. Stripe é um bom exemplo. Onde, você sabe, teríamos análises de produtos onde nossos fundadores, ou nossos líderes, diriam, sim, não há como ter certeza sobre isso.

Vamos entender qual é o feedback do cliente. Vamos entender qual é o contexto do mercado. E então, com base nisso, tomaremos a melhor decisão de acordo com as circunstâncias. Mas, você sabe, não temos que ter certeza de que isso vai funcionar

John Cutler: Certo. Isso é modelagem incrível, certo? Como do ponto de vista do líder. E isso significa que vai longe. Se um líder diz isso, com certeza.

Shreyas Doshi: Sim. Sim. E, você sabe, há também a clássica porta de sentido único, porta de dois sentidos, que eu realmente vi praticada no Stripe. Esta é uma decisão que podemos desfazer. Direita?

Então vamos fazer isso. Está bem. Se estivermos errados, vamos apenas desfazê-lo. O custo de desfazê-lo não será substancial. E talvez haja outras decisões que serão mais difíceis de desfazer, ou que não podemos desfazer. Vamos realmente gastar nosso tempo para acertar isso. Então, novamente, todas as coisas que estou dizendo aqui, John, parecem óbvias, tipo sim, é claro que você deve fazer isso na maioria dos casos.

Tipo, é claro que você deveria fazer isso. A questão é por que isso não acontece? Por que a maioria das organizações é muito, meio que imperfeita nesse sentido? E, eu acho, você e eu discutimos esse tema do teatro de certeza. E acho que isso tem muito a ver com a segurança psicológica que a cultura cria para a gerência intermediária em particular.

A gerência intermediária e a “verdade real” [00:16:52]

A maneira como eu vejo a gerência intermediária é que eles são a maneira da organização de garantir que você seja capaz de chegar à verdade real. Existe a verdade no terreno e, você sabe, as pessoas trabalhando muito diretamente nessa verdade. E então, quando virem essa verdade, eles a transmitirão à gerência intermediária. E então a gerência intermediária está agindo como esse proxy, bem entre a verdade que você vê no terreno. E então a verdade que os executivos da empresa estão vendo em uma escala macro.

Então eu acho que é muito importante para a gerência intermediária se sentir livre para expressar as verdades que estão vendo em ambos os lados. Sem ter que se preocupar que seu trabalho será prejudicado, ou sua posição será prejudicada, ou o sucesso de sua carreira será prejudicado.

E se eles podem fazer isso, essa é, eu acho, a chave para liberar um tipo melhor de fluxo de verdade em ambas as direções dentro de uma organização.

John Cutler: A gerência intermediária não é apenas uma camada. Em muitos casos, são várias camadas. Então, como você mantém a verdade fluindo em ambas as direções através de duas ou três camadas disso?

O papel da liderança do produto [00:18:01]

Shreyas Doshi: A primeira observação é que não estamos realmente falando sobre qual é o trabalho e qual é o papel de um líder de produto. Direita?

Minha observação é que a maioria desses líderes de produtos tem, você sabe, uma tremenda experiência, ótimos currículos. Se você perguntar a eles, qual é o seu papel? Tipo, qual é o seu verdadeiro papel? Eles vão lutar. E eu não os culpo porque, você sabe, ninguém os ensinou qual é o papel deles. Então eles começaram a fazer as coisas e então o que quer que eles estivessem fazendo, se funcionasse, se eles obtivessem alguma validação externa, eles faziam mais disso. E então eles suprimiram as coisas para as quais não obtiveram validação.

Então, de alguma forma, chegou a um certo estilo, ou uma certa abordagem, ou alguma definição de papel implícita. Isso agora está tão profundamente enraizado em seus hábitos, que eles não conseguem descrevê-lo. Tipo, ok, meu papel é X, Y e Z.

E eu acho isso tão importante. Depois de entender o papel, fica claro o que você precisa fazer, certo? O que você precisa fazer é possibilitar o sucesso do produto por meio de outros, certo? Assim é efetivamente o que você precisa fazer como líder de produto na gerência intermediária em algum lugar.

E para possibilitar o sucesso desse produto por meio de outros, e eu falo sobre isso em termos de, e criar equipes autogerenciadas, certo? Portanto, criar equipes autogerenciadas é tão vital. O que, idealmente, como líder de produto, você sabe, você não é apenas como apagar incêndios e ter que aparecer em oito avaliações porque precisa estar lá e precisa examinar tudo, e nada acontece sem você estar lá.

E sei que essa é a realidade de muitos líderes de produto, nosso trabalho do dia a dia, por isso muitas vezes é muito estressante. E eu treino muitos desses líderes de produtos com bastante regularidade, e é [00:20:00] surpreendente para eles que não precisa ser assim. Não precisa ser do jeito que você está fazendo, sabe, literalmente 40 reuniões ou 50 reuniões por semana.

Tem essa piada que eu já ouvi muitas vezes. Que é como, oh, então você é um líder de produto, então você nunca estará em sua mesa, certo? Como se você sempre estivesse em reuniões. Ha ha. Aceitamos isso como realidade. Eu absolutamente rejeito essa premissa. Na verdade, como líder de produto, você deve passar muito tempo em sua mesa. E se você não está fazendo isso, significa que você não está cumprindo o segundo aspecto do seu papel, que é criar equipes autogerenciadas. Direita?

Então eu acho que isso remonta a entender o papel. E uma vez que você entenda o papel, suas ações serão bem diferentes em termos de como você delega, como você não apenas diz, bem, eu não gosto dessa abordagem para esse fluxo que você está me mostrando, mas gosto de outra coisa, mas em vez disso diga, olhe aqui, eis como eu penso sobre isso.

Aqui está como eu penso sobre os objetivos do usuário. Veja como eu penso sobre as metas de conversão que temos. E então aqui estão talvez alguns princípios para nós considerarmos. Aqui estão algumas métricas para procurarmos para descobrir qual é a resposta certa, certo? Essa é a conversa que você precisa ter como líder de produto com sua equipe, porque é assim que você cria uma equipe autogerenciada versus oh, Bob, Bob gosta de um fluxo de página única, certo? Curtir ou etapas de página única. E assim é apenas uma peculiaridade de Bob. E então certifique-se, este é o gerente de produto dizendo ao designer, apenas certifique-se de fazer isso, certo? Tipo, mas o porquê disso está faltando. É mais sobre, oh, se você quiser obtê-lo com sucesso através da revisão de Bob, precisará fazer isso. direita. O que não tem sentido porque agora você criou o oposto de uma equipe autogerenciada.

Identidade profissional (e a mudança para papéis de liderança) [00:21:56]

John Cutler: Uma coisa que me vem à mente também é que muitas vezes os gerentes de produto parecem apreciar essa natureza nebulosa de seu papel, começando até mesmo pelo IC PM. Eles quase se identificam como o metamorfo. Tipo de empurrar-se em tudo o que precisa ser feito.

E eu poderia imaginar que essa pessoa, quando se torna diretor, sobe. Talvez às vezes eles não consigam abrir mão disso. Talvez isso seja uma coisa que leva a uma incapacidade de esclarecer seu papel.

Shreyas Doshi: Oh, você sabe, John, o que você acabou de dizer ressoa tão fortemente. Eu quero compartilhar duas coisas em resposta a isso. A primeira é que você tem esse exemplo clássico. E, novamente, este era eu muitos, muitos anos atrás. Este era eu 12, 13 anos atrás. Gerente de produto aparentemente competente, alguém que é realmente bom no trabalho principal de gerenciamento de produto.

Quem disse, ok, queremos que você gerencie PMs. Certo, agora, o que acontece nessa situação é realmente interessante. E acho que se isso acontecer com muitos, muitos PMs competentes. O que os torna líderes de produto um pouco menos competentes, pelo menos o primeiro ou o segundo…

John Cutler: Você está dizendo que os PMs ficam cada vez menos competentes à medida que sobem na organização?

Shreyas Doshi: Bem, os requisitos, a barra muda. Direita? Então, por exemplo, no meu caso, eu ainda estava construindo e desenvolvendo meu conjunto principal de habilidades de gerenciamento de produtos. Não foi totalmente construído, mas me pediram para gerenciar, o que é bom, isso acontece em muitas outras funções também. Mas o desafio é que eu também não estava mentalmente lá, certo?

Como se eu soubesse que tinha essas lacunas e, em algum lugar dentro de mim, ainda tinha essa vontade de provar que sou um ótimo gerente de produto. Não um gerente de gerentes de produto, mas um gerente de produto realmente ótimo. E a maneira como isso se manifestou com minha equipe é, você sabe, algo surge e eu digo, oh, essa claramente não é a resposta certa. É assim que devemos pensar sobre isso. Tipo, apenas observe meu idioma. Direita? Como estas são as palavras que eu costumava usar.

E o que eu estava realmente fazendo, agora eu entendo, eu não entendia naquela época. O que eu estava realmente fazendo era apenas tentar provar a mim mesmo que eu ainda entendia. E tentando provar e mostrar para os outros, assim como eu sou ótimo no trabalho de contribuinte individual do IC. Ah, e eu vejo isso com gerentes de produto, especialmente em seus primeiros três, quatro anos, o tempo todo quando eles entram na gestão de gerentes de produto. Eles ainda estão tentando desempenhar a função de gerenciamento de produtos, a função central do IC, em vez da função de gerente.

E então isso cria todos os tipos de desafios para eles mesmos. Porque, você sabe, quando você adota esse tipo de abordagem IC, você vai ser o gerente que diz, [00:25:00] oh sim, eu preciso ir a essa reunião. Você pode por favor me convidar. Porque você precisa desse contexto no terreno para poder formar sua opinião sobre a estratégia do produto ou a direção do produto, certo?

Versus, desenvolvendo a habilidade de entender isso através de seu pessoal. E então isso irrita a pessoa da sua equipe porque é como, por que meu chefe está aparecendo para esta reunião? Isso não faz sentido. E oh, meu chefe é um microgerente. Ou olhe, oh, porque meu chefe está aparecendo nesta reunião, agora eu preciso me apresentar nesta reunião em vez de apenas ser vulnerável, eu mesma, fazendo perguntas legítimas e genuínas e outros enfeites.

O papel do gerente em ajudar as pessoas a adotarem comportamentos não padrão [00:25:39]

Eu vou te dizer uma coisa relacionada a este tópico que estamos discutindo que está em minha mente, é ver o papel do gerente, especificamente no contexto de gerenciamento de produtos, ver o papel do gerente, o papel do diretor, o papel do VP, o papel do CPO como sendo sobre ajudar as pessoas a entender quando devem adotar seus comportamentos não padrão.

Vamos dar um exemplo específico. Você vai encontrar, você sabe, em algum lugar em um post de blog, ou talvez um tópico do Twitter, esse tipo de, oh, aqui está o que um gerente de produto precisa…

John Cutler: A propósito, poderíamos ter sido co-responsáveis ​​por isso. Então eu acho que podemos,

Shreyas Doshi: Com certeza. Essa é a coisa em que eu fico tipo, oh, estou nervoso ao apertar enviar…

John Cutler: ...Eu tenho pesadelos com isso, então vou segurar minha...

Shreyas Doshi: Com certeza! Então, vamos fazer um post de blog hipotético sobre o que os gerentes de produto devem fazer. E é como se um gerente de produto estivesse lá para sua equipe. O gerente de produto desbloqueia a equipe. O gerente de produto verifica com a equipe o que a equipe precisa e entrega o que eles precisam para que possam ser eficientes.

Eles podem ser eficazes. Um gerente de produto garante que eles estão fazendo check-ins regulares com engenheiros individuais para garantir que eles estejam recebendo o que precisam blá, blá, blá. Direita. Então você pode imaginar esse tipo de post de blog hipotético.

E dizer que sou um gerente de produto, ou um novo gerente de produto, e dizer, ok, tudo isso faz sentido. E eu vou começar a fazer isso. E, adivinha o que acontece? Como eu comecei a fazer isso, e funciona muito bem. As pessoas dizem, oh, você sabe, Alice se juntou como PM para nossa equipe. E tem sido incrível. Tem sido uma diferença de noite e dia. Não acredito que estávamos operando sem PM, e isso é incrível, mais PMs, sabe?

Vamos nos certificar de que reconhecemos Alice por nossas contribuições como gerente de produto, etc., etc. Direita. OK. Funciona bem. Então agora o que acontece? Se eu for o gerente de produto, faço desse meu comportamento padrão. Porque este é o meu primeiro ano fazendo o trabalho. Eu não sei nada sobre gerenciamento de produtos em vários contextos diferentes.

Presumo que estou recebendo validação para essas ações. So I've got to do the same amount or more of these actions, right? Now, transport me to a different team. Or a different company. OK. Now, in this company, or on this team, let's just say on this team, well the engineers are very independent. They are already talking to customers directly, right?

They're talking to sales directly to understand requirements. They are talking to marketing. You know, the designers are doing end to end research and validation as well as again, kind of very customer centric. And it's generally a very high agency team, right?

Like again, the tech lead, or the lead designer, isn't afraid to go to the VP or the CEO and ask questions or ask for what they need and whatnot. Right? You can bring in this product manager, who's performing these defaults, in this situation, what happens, right?

Same product manager, different teams. And the feedback is, oh, you know, we think Alice needs to create more room for ideas. We think Alice can sometimes create an unnecessary obstacle for us. We think that is a lot more process. We think there are many more check-ins than there need to be. We don't have to provide status on a daily basis for what we are doing, et cetera, et cetera. Right? Same product managers, same actions, different contexts. Doesn't work. So with this now let's get back to the thing I've been mulling over recently, which is where is the failure here?

I don't think the failure is at the level of the PM. It's not Alice's failure. It's the manager's failure, right? It's the manager's responsibility to help a PM understand the context within which they are [00:30:00] operating and then nudge them towards non-default behaviors.

John Cutler: It's funny you had that conversation. I think there was a thread with Dee Hawk where he said, I talk about principles and these deep things, and you actually made the point where you said most people just want to get ahead.

You know, so talking about principles is a little tougher. I'm paraphrasing. I think I remember this in the back of my mind. But I thought what was interesting — that point — is it's also the toughest thing, right?

Mindset, principles, and tactics (and getting stuck on tactics) [00:30:29]

Shreyas Doshi: So, so a couple of thoughts there. One is it does depend on where one is at, right? There are three things that one needs to understand and use in order to get really good at something.

There's mindset, there's principles, and tactics, right?

People often will start with tactics. Which is here is a recipe for how to run this meeting, right? Here's the template for a product review. Here's a template for a product strategy doc, or what have you, right. Tactics are amazing. You need tactics to figure out the basics of a role and to be productive in that role and to learn by doing right. So tactics are really, really important.

What happens though, is for many people, they get stuck at tactics for the majority, if not the entirety, of their career. And that's where there is a problem. Right? Which is once you have reached a certain degree of proficiency, you are not going to be able to, you know, seek the 37th tactic for doing this thing in order to actually be effective. Direita. And, and so what you need at that point, is a better understanding of the principles. Because with the principles, what you will do is you'll know which tactic to employ. But even more amazingly, once you start understanding these principles, you can create your own tactics, right?

And then mindset is the most important thing. All of us know we need to do certain things. I know I need to write that PRD, why am I not writing that PRD? And instead, spending my time on Slack, and replying to email, and convincing myself that I'm being productive by doing that.

And there is a very good reason why I'm not writing that PRD. I need to understand myself. I need to understand what is really going on. What I'm really fearful of when I'm avoiding writing that PRD that I really should be writing. So there's much more to mindset than that, but the point is to achieve the highest degree of competence in a certain field — and particularly, I think, I can only speak for product management really to achieve the highest degree of competence in product management — you do need to understand each of these three extremely well.

Depending on the context, some of this is just not possible. Look, a lot of what I talk about the implicit background there is it's, we're talking about you know, like Marty Cagan calls it empowered teams, right? Where people are given the right tools, and the freedom to arrive at the right answer. Without taking tremendous personal risk in order to do so. I have been fortunate to have largely worked at organizations where the teams have just been empowered by default. My perspective comes from that. I frankly don't know what it's like, and what success is like, in environments where teams are not empowered, where individuals are not empowered. A lot of what I might say in that context can probably be boiled down to, grow as much as you can in the environment, such that now you will have the optionality to move to an empowered environment where you can really exercise your skill and achieve, hopefully greater potential.

But even as I say that I'm in two minds, right? Like, I feel like, okay, it makes sense to try to grow as much as one can, based on the cards one is dealt. Right? It seems to make sense to do that. My own personal experience. I was very early in my career. I was in these highly disempowered teams. That's sort of what I tried to do, but again, I'm a sample size of one. What works for me doesn't necessarily work [00:35:00] for everybody. So that part of me says, okay, yeah, maybe this should work. But the other part I'm not quite sure about is just like is it possible in every environment where teams are disempowered? .

The basics/foundations for a high-performance team [00:35:11]

There are some basics that you need to have in order to have a chance of being a high-performance team or a successful team. Without those basics, yeah, with survivorship bias, you can find one team that managed to, against all odds, to succeed without those basics. But we can't really bank on that. Direita. Because we have one life, we have, you know, we are single threaded. We can't run a hundred simulations and then just pick the winning simulation. Direita. Or even like thread, like do three jobs on a given day. Direita. And see which one, see which one worked out better. And just like, uh….

John Cutler: A multivariate job experiment. That's really

Shreyas Doshi: So, so we can't do that. So, you know, any kind of like, oh, there's all these problems and they, yet we succeeded. So learn from us. Direita. Like there's very little to learn from that in my opinion. Because you're so single-threaded as a team, as a person, as a company it makes sense to just make bets that have a high expected value.

So let's assume that the basics are met. And what are some examples of basics that you have the right people in the right roles as an example, Right. It doesn't have to be the world's best people doing whatever, but at least there is some match to what the job is, and the people, who are supposed to do the job, as one thing.

You might even put a certain bar of empowerment. It doesn't necessarily have to be the highest empowered team ever. Because like that could have its own issues. But like a certain bar of empowerment. So anyway, you can make up some reasonable basics around, okay, any team or any situation needs to satisfy these basics, for it to have a shot at creating something that makes an impact, creating something that's remarkable.

OK. Now that these basics are covered, what's next? What do we need to do to increase the probability that we can meet our potential as a team? You know, as a thinker I have been thinking a little bit about a lot of my writing and what the general theme is. And one of the themes that I've been able to extract after the fact, is that really I'm trying to answer the following question in many different ways.

Why do teams with the basics met produce poor products? [00:37:31]

And the question is why do smart teams with sufficient resources– by resources I mean, money, all of that, right, not number of people necessarily– so why do smart teams with sufficient resources still produce mediocre or poor products? The current environment, again, sort of certainly you know, with startups and high growth tech companies, is that we all like to think we have smart teams. In this current funding environment, we do have somewhat sufficient resources in most cases, perhaps too many resources in some cases, and yet, many teams are not as successful as they ought to be.

And so why does that happen? Right? I don't think I've answered that question just for myself. First trying to do this for myself, and then for everybody else. But I think the answer lies in a lot of different things that we just talked about. Around, oh, you know, one of the aspects of success is understanding the truth.

A lot of this goes back to things like decision-making, how do you collect inputs, how do you determine outputs? How do you get to those outputs? And then what are the right outcomes for us to achieve? Are we being sufficiently both logical and creative about how we get there?

I don't have an answer to sort of like the overall question of what distinguishes, you know, either poorly performing teams or high-performing teams and how are they different. I like to think about it as like, you know, this concept of assuming the basics are met, what needs to happen in order to maximize chances of success? And that's where I think context also plays a pretty large role.

Intentionality and stubbornness (with the company you want to be) [00:39:24]


John Cutler: What I've observed, at least in some of the companies that I admire the most is that someone is around who is just really stubborn about something, you know. They are stubborn about maybe engineering quality, or they're stubborn about connecting with customers. So anyway, that's, I'm offering that up as maybe an area that I'm looking into. That's what I've been thinking a lot about lately is stubbornness. We should connect our threads of research on this because I think it'd be interesting.

Shreyas Doshi: Yeah. I want to take that and do a live mashup of what you're talking about, uh, with this other idea that I [00:40:00] often bring up in conversations with startups, particularly as they're kind of starting to think about scaling that product development efforts. As they're thinking of adding product management. One of the questions I will often ask is what type of company do you want to create? Concretely. This is in the context of, you know, oh, I'm looking to scale my engineering team, looking to scale my product management. And I ask people to be quite intentional about what type of company you want to…

John Cutler: Because it's easy to give non-answers to that. I've heard a lot of non answers to that question.

Shreyas Doshi: Yes. And as it pertains to product work, right? Like what is going to be your focus? So that's one way to look at it. Do you want to be a customer focused company? Do you want to be an infrastructure focused company? Do you want to be a growth focused company? Do you want to be a product focus company?

Do you want to be a sales focused company…

John Cutler: I want it all…

Shreyas Doshi: And exactly, right!

Like, so that's what people say quite a bit. But then they start getting it, which is like, oh Yeah, Okay. I like, I need to be like, as a founder, my company is my product. And so I need to be quite opinionated or stubborn– so, this is where I'm connecting to your stubbornness– about what I want to create.

Because what happens is you, you can't have it all. And if you're not intentional about it, you are focused on something it's just, you don't know what it is and then there's confusion, right. Like for yourself and for others. And so you take examples, right? It takes time to go through this conversation because, you know, it's, it's an odd

John Cutler: It starts out very high level too. It's like…

Shreyas Doshi: Right, it's, it's very high level…

John Cutler: … e então você tem que se afastar e tomar um café e tipo, espere, precisamos descer outro nível.

Shreyas Doshi: Ok. Direita. E, tipo, então o que eu observei é que 10 minutos em 20 minutos em 30 minutos, há um momento de lâmpada tipicamente para o fundador. Porque o fundador normalmente também está muito próximo do que eles querem fazer. Então, novamente, é uma daquelas coisas em que fazer a pergunta é o principal valor agregado, não necessariamente a resposta.

Mas se você pegar exemplos, fica mais claro, que é o Google, como exemplo, e certamente durante o tempo em que estive lá, que foi há 10, 10 anos atrás, era uma empresa muito focada em infraestrutura. Esse era o foco implícito deles. Quando conversei com um engenheiro e disse, é disso que o usuário precisa, como podemos construir? A resposta seria, oh, isso é muito interessante. É um problema incrível. Vou ter que construir essa infraestrutura de back-end. Levarei seis meses para construir essa infraestrutura de back-end. E então você terá esse recurso. E como uma pessoa de produto, é claro, eu esperaria, mas isso parece muito tempo para gostar, esse não é um recurso enorme.

Tipo, não, não, não. É assim que fazemos as coisas, certo? Tipo, precisamos ter a infraestrutura. E, novamente, não há escolha certa ou errada. Eu também gosto de apontar isso. Direita. O que é como, você sabe, você tem o Facebook, que é muito, pelo menos certamente me parece de fora e das pessoas com quem conversei, é uma empresa muito focada em métricas.

Eles tomam decisões com base no que move as métricas em grande parte. E é por isso que o Google e o Facebook operam de forma muito diferente. Internamente, eles operam de maneira muito diferente por causa desse foco.

A escolha fácil de fazer é oh, queremos ser focados no cliente. E então eu tenho que lembrar às pessoas que, tudo bem, se você está dizendo que quer ser uma empresa focada no cliente, mas está vendendo software empresarial, saiba que com o tempo, o que você realmente se tornará é um empresa focada em vendas. E, novamente, há exemplos de empresas tremendamente bem-sucedidas focadas em vendas.

Então, eu não estou dizendo que é necessariamente uma escolha errada. Mas apenas sendo intencional sobre isso e amarrando novamente ao seu ponto de teimosia, essa é uma maneira de ver as coisas, certo? Que é como, é assim que fazemos as coisas. Eu sei que soa mais negativo do que deveria ser, ou isso funciona para nós, certo? Isso funciona com a cultura que temos. Isso funciona com as pessoas e as habilidades que contratamos e assim por diante. E isso pode ser bastante poderoso, especialmente se você for intencional sobre isso.

Inteligência analítica e criativa [00:44:14]


John Cutler: Algumas vezes em nossa conversa, você mencionou a palavra analítico. E então você falou sobre a alternativa para isso, talvez uma inteligência criativa. Você poderia se aprofundar um pouco nisso?

E especificamente, estou pensando no meu trabalho diário, onde pensamos em medição. E uma coisa que observei é que há uma enorme diferença entre usar a medição para controlar as pessoas, ou controlar a narrativa, ou obter a resposta perfeita, e usar a medição para aprender. Eles se sentem muito, muito diferentes.

Qual é a diferença entre inteligência analítica e inteligência criativa em sua mente?

Shreyas Doshi: Na raiz eles constroem um no outro.

No entanto, não é assim que a maioria da indústria vê isso. E acho que as práticas em várias empresas, incluindo empresas altamente bem-sucedidas [00:45:00], tendem a ver uma como melhor que a outra. E geralmente – e novamente, meu contexto é muito de, você sabe, empresas sediadas em Vales ou empresas semelhantes a vales, não importa onde estejam geograficamente – é que de alguma forma tendemos a ver as razões analíticas como extremamente importantes e corretas.

Nós tendemos a desconsiderar a criatividade do produto, e tendemos a desconsiderar o instinto e o julgamento e vários outros tipos de aspectos

John Cutler: Existe uma dualidade, certo? Como também exageramos muito o instinto das pessoas, o instinto de certas pessoas, mas eu sei o que você quer dizer.

Shreyas Doshi: Sim. Então esse é um tipo interessante de questão que eu acho, novamente, que volta para aquela questão central de como, por que equipes inteligentes com recursos adequados ainda produzem produtos medíocres ou ruins. O que esquecemos é que muitas equipes e muitas culturas de empresas tornam muito difícil para as pessoas terem ideias criativas. Mesmo novamente, em empresas muito bem sucedidas em geral.

Onde começa muito disso? Começa na reunião, certo? Então você leva sua reunião de produto típica em qualquer nível. Você vai se deparar, na maioria dessas empresas, como muito mais competente se mostrar cinco gráficos diferentes. Você mostra algumas tabelas. E então alguns insights qualitativos. E então você diz, e, portanto, aqui está o que precisa acontecer. Acho que não há nada de errado com nada disso. Direita.

Mas o que acontece com essa abordagem, e essa mentalidade, é que você é, portanto, as conclusões ou recomendações são realmente bastante restritivas. Eles estão nesta caixa. Você não sabe que eles são realmente como nesta caixa. Mas eles são, certo? Agora, se você permitisse a inteligência criativa da mesma maneira, o que aconteceria se as conclusões conteriam algumas ideias malucas, certo? Como algo que não segue estritamente os dados, sejam eles qualitativos ou quantitativos. Talvez esteja até naquele envelope de tipo, oh, não temos uma forte convicção sobre isso, mas devemos tentar isso. O que acontece, mais uma vez, na reunião, fazer uma reunião de revisão de produto, é que o gerente de produto ficará confuso ou com olhares estranhos quando apresentar uma ideia criativa.

Ou qualquer um, estou apenas escolhendo o gerente de produto como um papel, mas o engenheiro ou quem quer que seja. Segunda coisa, eles provavelmente receberão feedback depois do gerente do like – e a forma como seria enquadrado como não tanto, não traga ideias criativas, porque ninguém quer dizer isso – seria como, você precisa faça backup de sua proposta com dados.

Você precisa fazer um backup melhor das coisas, e esse é o feedback que estou dando a você como gerente, certo? Esse fenômeno ocorre com muita regularidade, mesmo em empresas muito bem-sucedidas. E isso impede as equipes de criar esses produtos que realmente atingem o potencial, uh….

John Cutler: Alguém disse recentemente que tomamos muitas decisões de hipopótamos na minha empresa. Temos que usar dados, certo? Temos que usar dados para fazer os hipopótamos irem embora. E então eu disse, bem, o que vai acontecer quando você tiver uma ideia instintiva?

E eles disseram, bem, bem, claro, você sabe, é claro que vamos usar a mesma abordagem. Temos que ter todos os dados para fazer isso. E eu fiquei tipo, olha, seu problema não são os hipopótamos. Porque eventualmente você vai querer ter ideias criativas.

Se você só tem uma ideia, isso é terrível. Se você tem 50 ideias, isso é paralisante. Você tem talvez três? E meu amigo Dan North disse, não, você quer sete. Porque a primeira, a primeira é a sua ideia, as segundas duas, três ou quatro ideias basicamente apoiam a sua ideia. Então você quer sete porque na quarta, quinta, sexta e sétima são quando você sai da sua zona de conforto

Nível de impacto, nível de execução e nível de óptica [00:49:13]

Shreyas Doshi: Sim. Uma estrutura que eu acho que é uma estrutura muito fundamental que abrange a maioria dos contextos de produtos, e certamente todos os contextos de produtos com os quais me deparei, que acho que precisamos reconhecer melhor, é o que chamo de estrutura fundamental do trabalho do produto.

Então nós fazemos todo esse trabalho de produto, certo? Como devemos pensar sobre isso? Como pensamos sobre o trabalho deste produto? O insight que tive recentemente foi que existem três níveis de trabalho de produto. Existe o nível de impacto. Há o nível de execução. E depois há o nível ótico. E muitos desafios [00:50:00] dentro das equipes de produtos, culturas de produtos, são devido a uma incompatibilidade ou incompreensão do nível em que estamos discutindo. Ou o nível em que estamos operando.

Muitas vezes você descobre que uma pessoa da equipe está operando e pensando no nível de impacto. E outra pessoa está pensando no nível de execução. Mas eles não estão falando sobre isso. Eles estão litigando a minúcia da situação, certo? Então, um exemplo clássico é um PM que trabalha muito duro. Por assim dizer, um PM operando no nível de execução trabalha muito contra todas as probabilidades.

Eles não receberam boas cartas, mas fizeram esse produto acontecer, certo? Como se o produto fosse uma realidade. Eles estão felizes. A equipe está feliz. Engenharia, gerenciamento de produtos, design, ciência de dados, todos eles são, as pessoas que trabalham no produto principal estão muito animadas por construírem algo.

Direita. E eles levam para sua revisão executiva, certo. Ou uma revisão de lançamento. Claro que há alguma demonstração envolvida na revisão de lançamento. E, novamente, as táticas não importam como são feitas de forma síncrona ou assíncrona. O ponto é que é revisto. Você tem um executivo de produto que está operando no nível de impacto. E assim o executivo de produto olha para o produto, e a mensagem básica é que isso não é bom o suficiente.

John Cutler: O medidor de ameaça dispara.

Shreyas Doshi: Os níveis de cortisol aumentam.

John Cutler: …aumentar…

Shreyas Doshi: E o PM está frustrado, talvez o gerente do PM também esteja confuso. Você pode imaginar toda a dificuldade que tivemos que enfrentar para chegar até aqui? Nós deveríamos apenas ser autorizados a lançar isso. Eu sei que são todas essas falhas, mas não, não, não, não. Nós deveríamos apenas ser autorizados a lançar isso.

Então a questão aqui é o executivo – eles estão operando no nível de impacto e estão pensando no impacto para a marca, né, de lançar um produto com essa qualidade, que é, digamos, inferior à barra que eles tiveram . E essa é uma situação interessante porque as pessoas começam imediatamente a falar sobre correções, certo?

Que é como, oh, você sabe, talvez nós mudemos uma coisa ou a segunda coisa – novamente, é importante falar sobre tudo isso – mas primeiro é importante reconhecer essa incompatibilidade. E também direi que será difícil para o PM, ou o líder de engenharia, ou o líder de design. Vai ser difícil para as pessoas lá sinalizarem isso, certo, apenas do ponto de vista da segurança psicológica.

Assim, a maneira como os executivos podem operar melhor, e isso se aplica a pessoas em todos os níveis, é reconhecer por que a equipe se orgulha do que fez, eles realmente executaram contra grandes probabilidades. E, e eles estão operando nesse nível de execução. E então chame explicitamente – em vez de tipo, ah, isso não é bom o suficiente, ou isso não atende a barra ou qualquer outra coisa – isso é ótimo no nível de execução, isso fica aquém no nível de impacto, como podemos alcançá-lo sabe, um resultado melhor aqui?

A última coisa que direi sobre isso, como parte do exemplo aqui, é que você descobre que, em muitos lugares, as pessoas estão otimizando o nível ótico quando estão trabalhando com produtos. O CEO, o fundador ou o executivo poderoso tendo um instinto, ou alguma ideia criativa, que as pessoas simplesmente engolem. Direita? Bob disse isso, então vamos trabalhar nisso porque tipo, isso é realmente…

John Cutler: … e eles foram muito decisivos. É como, bem, é claro que eles foram decisivos. Eles são o CEO e todos vocês os estão ouvindo.

Shreyas Doshi: Então a outra coisa é que as conversas paralelas são, muitas vezes, sim, eu não acho que isso vai funcionar. Mas tipo, isso é o que Bob quer, então vamos fazer isso. E nem sempre tem que ser de cima para baixo, a propósito. Direita? Como às vezes também é na direção oposta. Direita? Você constrói algo, e está meio que enquadrando-o como sendo mais bem-sucedido do que realmente é para gerenciar a ótica.

Então não estou dizendo que a ótica é ruim. Na verdade, você precisa gerenciar uma certa quantidade de óticas, apenas para poder expressar fielmente o impacto do seu trabalho e a qualidade da sua execução. O nível ótico deve ajudar os outros dois níveis. E então você precisa fazer um trabalho suficiente lá. Mas há muitas equipes que otimizam principalmente para óptica.

As pessoas falam sobre incentivos e como as pessoas basicamente seguirão os incentivos. E assim por diante. Eu não uso a linguagem de incentivo. Eu acho que uma questão mais fundamental aqui é o quanto sua cultura e sua organização estão levando as pessoas a gerenciarem em direção à ótica, versus gerenciar em direção à execução ou gerenciar em direção ao impacto.

Preconceitos cognitivos e vocabulário compartilhado [00:54:37]

John Cutler: Então, uma parte da minha jornada com o mundo do viés cognitivo, porque eu estava super envolvido em um certo ponto. Comecei a tentar pesquisar maneiras pelas quais fomos eficazes em neutralizar o viés cognitivo, mesmo quando sabemos disso. E não ajudou muito na minha capacidade de combater a falácia do custo irrecuperável toda vez que a encontrei. O que você viu não funcionar, e o que você viu funcionar em termos [00:55:00] de tentar neutralizar essas coisas?

Shreyas Doshi: Então eu acho que é sobre o vocabulário compartilhado que você cria para a equipe. E acho que apenas o vocabulário compartilhado é apenas outro tópico muito mais amplo do que apenas preconceitos cognitivos, que acho tão vital.

Se você quiser tornar sua equipe saudável, ou mais saudável, talvez pense em qual é o vocabulário compartilhado de sua equipe em torno do trabalho que você faz? E não me refiro apenas aos chavões da indústria como Scrum ou qualquer outra coisa, certo? Tipo, quero dizer, não, não, não. Qual é o vocabulário que você não está vendo como parte da literatura padrão de gerenciamento de produtos, mas que você vai compartilhar com a equipe. Por que isso funciona no contexto de vieses cognitivos, é muito difícil alguém dizer Bob, você está sendo vítima de uma falácia de custo irrecuperável, ou heurística de disponibilidade, ou o que quer que seja. É muito difícil na maioria das organizações alguém ser capaz de…

John Cutler: ...não é a conversa de reunião de tarifa padrão que você está dizendo, não é como, obrigado, sim, eu gostaria apenas de apontar a falácia do custo irrecuperável... a reunião de zoom é encerrada rapidamente. Se essa pessoa começar...

Shreyas Doshi: Exatamente! Uh, e é como, oh, essa pessoa não trabalha bem com as pessoas. Como queiras. Direita. Como as pessoas ficam…

John Cutler: …eles leram muitos livros. Uh,

Shreyas Doshi: Eles recebem rótulos atribuídos. Então acho importante divulgar. É por isso que não falo sobre vieses cognitivos individuais. Costumo falar sobre nossos vieses cognitivos no nível das equipes. Direita. Porque aí fica muito mais fácil ter aquela conversa de tipo, em equipe, isso pode acontecer com a gente. Podemos cair na falácia da orientação de execução. Que é onde decidimos fazer algo que sabemos ser fácil de executar, mesmo que não seja a equipe certa para executar, mas nos dá a satisfação de começar. E a satisfação de criar algo.

Uma vez que você dê a conhecer a todos, e em segundo lugar como líder – o ônus do que estou prestes a dizer é inteiramente do líder – é dizer, olhe, vou ser vítima disso. E como grupo, podemos ser vítimas disso. Eu só quero definir a expectativa de que vamos conversar sobre isso. E vamos sinalizar isso quando virmos isso acontecendo.

Não é uma fraqueza se sinalizarmos isso. Na verdade é o oposto disso. Que somos capazes de estar cientes do que realmente está acontecendo e, talvez, tomar uma decisão melhor ou chegar a uma conclusão melhor. E então acho que o vocabulário compartilhado, e o que acabei de dizer é responsabilidade compartilhada

Eu geralmente odeio a palavra responsabilidade, mas isso é um tópico separado. Mas eu gosto disso neste contexto, que é um tipo de responsabilidade compartilhada como uma equipe, lembrando uns aos outros e nos lembrando como equipe, sobre os erros que podemos estar cometendo. Ou uma falta de clareza que possamos ter.

Como exemplo, há este projeto que eu estava fazendo recentemente, que era um projeto extremamente ambicioso com muitas incógnitas. Eu compartilhei com a equipe antecipadamente, na verdade, nesse caso, compartilhei duas coisas. Um estava relacionado ao viés cognitivo, que é, veja você sabe, provavelmente seremos vítimas desses, esses vieses cognitivos ou vieses cognitivos da equipe.

E então vamos apenas estar cientes disso. A segunda coisa que sinalizei também foi – os detalhes não são importantes, mas era um tipo de situação muito complexa, várias equipes envolvidas, e essas equipes não trabalhavam muito umas com as outras. Eles eram como trabalhar pela primeira vez.

E então eu compartilhei com eles que uma das principais coisas que vão nos atrapalhar aqui, é que não seremos diretos e abertos um com o outro, especialmente através desses limites de equipe. Isso provavelmente fará com que esse projeto não funcione do que qualquer tipo de erro analítico que cometemos.

Deixei ainda mais explícito com aquele grupo. Estou mais preocupado com a nossa capacidade de trabalhar bem um com o outro, de ser direto um com o outro e de entender as perspectivas um do outro, do que qualquer outra coisa. Qualquer um dos outros tipos de coisas analíticas sobre as quais estamos falando, que é como, oh, como nos encaixamos nessas três opções de navegação dentro desse espaço limitado ou qualquer outra coisa. Isso não vai determinar o nosso sucesso. O que vai determinar nossos sucessos é se estamos dispostos a ter as conversas difíceis uns com os outros sobre essas coisas? E estamos dispostos a ouvir uns aos outros e as perspectivas uns dos outros? A outra tática que eu gosto é, eu também aponto como, eu também quero dizer que talvez você esteja pensando que esta é uma conversa boba de se ter porque é muito fofo, certo?

Como se não fosse o material analítico. Mas se você está pensando isso, então meu pedido [01:00:00] é que, por favor, fale comigo sobre isso. Todos nós precisamos ser abertos uns com os outros. Se você está achando que isso não é um uso útil do tempo, então essa é a primeira coisa que você precisa estar realmente aberto para mim. E entao…

John Cutler: Você está antecipando o ceticismo deles de você instá-los a… Eu gosto disso!

Shreyas Doshi: Sim.

John Cutler: Você está tentando cobrir todas as suas bases aqui, essencialmente.

Shreyas Doshi: A outra coisa que eu tive que fazer nessa situação é como, porque, novamente, eu não tinha trabalhado com alguns dos membros da equipe com quem íamos trabalhar, então eu configurei, você sabe, um-a-um com alguns dos principais membros da equipe, apenas para enfatizar isso novamente. É como, olha, essa é a minha preocupação como líder da equipe.

E geralmente conhecê-los o suficiente para que eles sintam a capacidade e a capacidade de se abrir e compartilhar quando as coisas não estiverem funcionando. Então, você sabe, este é um exemplo de ir contra os padrões. Geralmente, evito esses tipos de check-ins individuais regulares, certo? Continuamos adicionando e, em algum escopo, isso meio que toma conta do seu calendário.

John Cutler: Você não teria feito muitos amigos se tivesse feito isso toda semana, nos últimos cinco anos. Acho que a parte brilhante dessa resposta é que quando as pessoas aprendem sobre vieses cognitivos, é uma loucura. O que eles fazem é sempre tipo, bem, isso explica o comportamento maluco de todo mundo. Ah. Agora eu sei por que os executivos se comportam do jeito que são. É como se todos primeiro, ao pensar em vieses cognitivos, todos experimentam viés de atribuição fundamental, certo?

Shreyas Doshi: Eu acho que se você não quer acreditar se – se como um indivíduo, ou como uma equipe, você não quer acreditar na maioria dos vieses cognitivos – talvez esteja tudo bem. Contanto que você acredite firmemente em dois: viés de confirmação e viés de atribuição fundamental.

Tratando painéis como um produto [01:01:51]

John Cutler: Sim!

Mudando de assunto por um tempo, eu queria te perguntar isso há muito tempo. Você tinha essa coisa de tratar painéis como um produto. Como qual foi a inspiração para isso, esse pensamento?

Shreyas Doshi: Essa foi uma coleção de algumas observações diferentes que fiz ao longo dos anos sobre como os painéis são usados. E como as pessoas geralmente, equipes de produto, pensam sobre painéis.

John Cutler: ...as pessoas altamente analíticas de que estamos falando.

Shreyas Doshi: Sim. E é tipo, ah. você deveria ter um painel. Tão bem que eu vou ter um painel. Então deixe-me compartilhar algumas dessas observações que fiz ao longo do caminho.

Primeiro, há muitos PRDs que são escritos sobre um recurso ou produto não trivial, que não cobrem como será o painel para esse recurso ou para o produto. E está tudo bem. Tipo, o que estou pedindo não está aqui como uma maquete detalhada para isso.

Mostre-me uma lista com marcadores, certo? Como aqui estão as métricas que vamos rastrear para entender as métricas de uso, que é como esse recurso está sendo usado? O que os usuários estão fazendo com isso? E, o segundo sendo o impacto. Às vezes, há muito foco nas métricas de impacto e pouco foco nas métricas de uso.

John Cutler: Com certeza.

Shreyas Doshi: Mas tipo, eu diria que...

John Cutler: Não chame isso de métrica de sucesso. Porque então fale sobre segurança psicológica! Está tudo feito nesse ponto. Indicador chave de desempenho, você sabe, é…

Shreyas Doshi: Sim.

John Cutler: …deixa pra lá neste momento.

Shreyas Doshi: Então, novamente, o vocabulário é muito importante. Esse é um ótimo ponto. Ele precisa ser de propriedade do gerente de produto ou de quem está desempenhando essa função.

John Cutler: Você precisa de muito conhecimento de domínio para conseguir isso, certo…

Shreyas Doshi: Certo.

John Cutler: ...há a natureza única do uso .

Shreyas Doshi: E a maioria das equipes tem a outra categoria de métricas, que é a métrica de saúde. Porque normalmente as equipes de engenharia garantirão que tenham a instrumentação certa e o painel certo para isso.

Essa é a primeira observação, não especificamos isso adequadamente. direita. Então, a segunda coisa é vamos supor que uma equipe especifica isso, e um painel, ou algum e-mail de métricas, não me importo com o que seja. Como se algo fosse construído que agora começa a lhe dar uma visão das coisas que importam. Como as pessoas estão usando, qual é a adoção, qual é o impacto, é isso, ótimo.

A segunda observação que fiz é que ninguém está olhando para aquele painel.

John Cutler: Posso confirmar essa dinâmica com base em alguém que oferece uma dessas ferramentas que muitas delas são como árvores caindo na floresta. Há cemitérios de painéis. Vamos colocar assim.

Shreyas Doshi: Com certeza. Se este é você e sua equipe, tipo, não se sinta mal. Isso é 90% do que eu encontrei em diferentes pontos. Direita. Sim. Nós gastamos todo esse esforço criando este painel. Quase ninguém está olhando para ele.

Então, esse foi o segundo tipo de observação. Ao perceber isso, o que percebi é, oh, espere um minuto. Não estamos fazendo com nosso painel de métricas, [01:05:00] o que dizemos ser a coisa certa a fazer para nossos produtos. Portanto, há um certo tipo de auto-referência aqui. Ou seja, se construímos um produto, você sabe claramente que a coisa certa a fazer é rastrear seu uso, rastrear métricas etc.

Portanto, se você estiver visualizando o painel, que está fornecendo informações sobre seu produto, por que não ver isso como o próprio produto. E acompanhe as métricas de uso do seu painel. Como um contador simples, por exemplo. Quantas pessoas viram este painel que passamos muito tempo criando na semana passada.

Direita? Apenas algo tão simples quanto isso, apenas uma contagem de visualizações, como exemplo. E então você pode olhar para isso e ver, oh, espere um minuto, ninguém está realmente olhando para as métricas. Então isso cria duas possibilidades. Uma é que não é útil em termos de insights ou tomada de decisões. Ou tem algum problema né, tipo com a gente e assim a gente precisa resolver. Mas você só pode começar a fazer isso se pensar nisso como um produto, certo?

Depois de começar a pensar no painel como o produto, é claro, você criará requisitos para o painel e o tornará parte do PRD original. Ou seja, é isso que precisamos rastrear. É por isso que precisamos rastreá-lo. É assim que vamos rastreá-lo. E então você obviamente instrumentará as coisas no painel de uma maneira que você entenda seu uso e assim por diante.

E a última parte que direi, é que grande parte de tudo isso não é intenção ou competência ou qualquer outra coisa. Eu não acho que é porque as pessoas são incompetentes que essas coisas acontecem. Acho que é porque é difícil. Eu acho que na verdade é tão simples quanto fricção, certo? Esta é mais uma coisa que você tem que pensar em fazer durante o seu dia atarefado. Você sabe que é a coisa certa a fazer. Para gostar, visualize suas métricas de uso de vez em quando. Ou pelo menos consulte-os quando for tomar a próxima decisão.

Mas há atrito. Há uma carga cognitiva que você precisa gerenciar. E agora, novamente, pensando nisso como um produto, agora você pode começar a pensar sobre como eliminar o atrito? Porque é isso que fazemos em nossos próprios produtos, certo? Como pensamos sobre qual é o atrito do usuário e como podemos eliminá-lo?

E isso leva a possibilidades interessantes. Como um dos hábitos que tenho há muitos anos, neste momento, tenho minhas guias de pinos no Chrome. E eu tenho meu e-mail, meu Slack e meu calendário, que estão fixados. Uma das outras coisas fixadas é meu painel de métricas principal. Então está lá. Não preciso abrir uma nova guia, digitar qualquer URL, simplesmente está lá. Outra coisa que notei é que as pessoas adoram métricas de e-mail. Por quê? Porque remove o atrito, certo? Simplesmente aparece. E existe esse tipo de contrato que pelo menos fizemos com nós mesmos de que devemos olhar os e-mails. Então, o que acaba acontecendo é que as pessoas olham muito mais de perto as métricas que são enviadas por e-mail do que, mais ou menos, as métricas que elas precisam buscar proativamente.

Muitas vezes, para projetos importantes, eu diria, ah, você sabe, vamos também enviar um e-mail de resumo. Pode ser tão simples quanto algumas estatísticas de alto nível de teaser e apenas um link para o painel. Mesmo aquele link que é enviado por e-mail para você tornará muito mais fácil para você e eliminará o atrito. Contra ter que pensar sobre isso e fazê-lo.

Calendários cheios, reatividade, auto-identidade e hábitos positivos/negativos [01:08:20]


John Cutler: Quando você vê esses calendários de pessoas e vê esses PMs que estão em modo reativo o tempo todo. Que eles nem têm um momento para pensar sobre essas coisas. Qual é o primeiro conselho que você dá a eles? Como eles reinam isso?

Shreyas Doshi: Passei os primeiros cinco anos da minha carreira de PM em estresse extremo e um grau razoável de estar na defensiva, o tempo todo. Eu preciso ter certeza de que as coisas não desmoronam. Isso é tudo o que estou fazendo, e isso está consumindo toda a minha energia. E acho que grande parte disso é, claro, que eu provavelmente era muito menos competente no papel. E assim as coisas costumavam me levar mais tempo, e assim por diante. E então eu não quero desconsiderar isso, você sabe, que há uma curva de aprendizado, e há um custo para essa curva de aprendizado. E é uma jornada pela qual todos precisam passar. Direita. Então. Sim.

Não acho que seja necessariamente uma coisa ruim. Você usa a palavra hábito e acho que aí está o problema. O que acontece é que nesses primeiros anos, nossos anos de formação como gerentes de produto, adquirimos certos hábitos. Assumindo que somos realmente bons no que estamos fazendo, vemos o sucesso. E então você certamente pensa, ok, sim, eu pareço estar fazendo as coisas certas. E então eu deveria fazer mais dessas coisas. É realmente útil ter encontros individuais com todos os engenheiros da equipe semanalmente, verificar com eles o que está acontecendo e também se conectar com eles em um nível pessoal, etc., etc. Então eu vou fazer mais e mais disso. Excelente. Funciona quando você tem 10 engenheiros na equipe, agora você tem mais escopo. Agora tem 20, depois tem 30. [01:10:00] O que, o que você faz?

John Cutler: Certo? Então, enquanto isso, eles se orgulham, se auto-identificam, como tendo ótimos relacionamentos com todos os engenheiros. O buraco negro um-para-um de…

Shreyas Doshi: sim. E então John I, e tipo, acho que desencadeou algo interessante, que é, acho que talvez sejam duas coisas. É o seu hábito e identidade. Esse é quem eu sou. É assim que eu faço as coisas, né. Oh, aquela coisa que você está falando, ou aquela coisa que esta outra pessoa está falando?

Não, não, não, não, isso não funciona para mim. Direita. Como se eu fosse diferente. Esta é a minha identidade, é assim que opero. Portanto, há o hábito e a identidade. E eu vejo o tempo todo, pessoas apenas em situações em que é completamente incontrolável. Eles não sabem o que fazer.

Eles só pensam que é assim. Às vezes, seus gerentes dizem a eles, sim, é assim que é o trabalho de PM. Olhe para o meu calendário, é ainda pior! E depois há essa pequena comparação também, que é como, ah, cujo calendário é pior. E tipo, essa pessoa é mais um PM, certo?

Isso é tão difícil por causa da questão do hábito e da identidade. É difícil para as pessoas aceitarem que existe um caminho alternativo aqui. Se você pensar no público, eles estão ouvindo isso, sempre que isso for lançado. Certamente haverá um conjunto de pessoas que dirão, sim, o que quer que esteja sendo discutido aqui não se aplica à minha situação. E não se aplica à minha empresa por causa do meu chefe, por esse motivo, porque minha equipe é diferente, porque o que quer que eu seja diferente, tenho ambições maiores, seja o que for. Então, você sabe, o que eu diria é que isso não pode ser resolvido até que você aceite que realmente existe uma maneira melhor.

You have to understand that you want to solve this problem, versus thinking this is the way it is. But once you start entertaining that thought, that there are other ways that this problem can be solved or at least should be mitigated, now we can talk. Direita? So now we are at a smaller part of the audience that is really stressed, but it's perhaps more open to sort of exploring those ways.

And then what I would say this goes back to the role of a product manager and particularly the role of a product leader. Remember we talked about building self managing teams. Direita. Well, what happens when you actually build self managing teams? You have to do less management, right? Because they're self managing. That's sort of the goal. Now, it doesn't solve the problem because how do we get to the goal?

The way one needs to think about these situations is you know, yes, I can stay on top of everything. And you know, in some cases, like we talked about, the context requires you to stay on top of everything. But, you don't have to make that your default, and you don't have to do it in every single situation.

So one of the things I like to tell, especially new managers, is assume there are things you are not going to be on top of. Because then you will have to go to every single meeting. You'll have to accept every single input in order to, sort of, figure out what to do.

So assume that's not going to happen. And what you need to do is to figure out ways in which now you're going to get those inputs through people on your team. And you are going to organize your one-on-ones in a way that you're able to get those inputs. You're, uh, you're going to organize rituals on your team, whether it's product reviews, or other rituals on execution check-ins or what have you, in order to get the right signal .

This is all easy for me to say, but it is hard to do, and it requires practice. And it requires trying to identify your unique style of doing it, et cetera, et cetera. But the beautiful part, when you cannot like, do this, and do this with some degree of success, is now all of a sudden you are able to be much more useful, and much more effective, right?

You are able to get more clearly to the thing that matters, right? You are able to help your team members. You are kind of like coaching them through experience around expressing to you the stuff that matters. Direita. And then you are able to also give them the independence, and the leeway, to be able to operate on their own versus kind of handling them through all of this.

Improving the current situation (and gap vs. present thinking) [01:14:24]

So, concretely, the common sort of argument I hear is yeah, yeah, things are horrible right now, but it's because I don't have a full team. Like I have this four or five head count. Once I get these people, and get them to be productive, things will be better. And guess what happens? You get those four or five engineers on the team, or four or five PMs on the team if you're a PM manager. Situation is worse, not better. But at that time, it's like, oh, you know the problem is we are not organized properly. My team should not [01:15:00] belong to this organization. It should be in this other part of this organization. And that's what's creating the problem for me. You know, so it's like this, kind of, basically we are on the treadmill forever right?

I'm not discounting the validity of these reasons. What I am suggesting is that regardless of external factors, which we should try to improve, and we should feel high agency towards making the organization better, and improving whatever situation we are in. But we need to also be very cognizant of how I can best manage the current situation I'm in. Versus like, basically I noticed that especially the managers and product managers that tend to get extremely stressed, and let the work affect all parts of their personal lives and whatnot is… they're constantly looking for the next thing that is outside of them that's going to fix this issue. And then that results in burnout, that results in frustration when it doesn't happen. And they don't pay enough attention to, okay, given this current situation, what do I need to do differently?

John Cutler: My friend Jabe Bloom has this interesting thing, which is gap thinking versus present thinking. And he makes the point that standard business school, standard consulting is all about the gap. What's the current thing? Exactly where do we need to go? How are we going to get across that particular gap?

Like that's a very tried and true way to think about it. And then he presents this other idea that present thinking is not adverse to thinking ahead. It's like, what's going on right now? What do we visualize as the better version of right now? Where do I have agency to act right now? Instead of just the gap, you know, it's like there and you have to go across it. It's kind of like little mini gaps, right. But the one part, the one thing you said that really resonates there is, you know, in some ways, as humans by, gap thinking is always a way to also “other” the problem.

It's the tendency of people to combine gap thinking with fundamental attribution bias, which is like, not only is there a big gap that we need to get across and there's the perfect plan to get across it. But the road involves other things in the org that have to happen, et cetera, to make it to it.

So I don't know if that's, I've liked that distinction between gap thinking and present thinking. One thing that's hard is that a good chunk of modern business is centered around gap thinking. What's the gap, bring me solutions, not problems, you know, like how are we going to get across the gap all the time? Então…

Shreyas Doshi: Yeah, that resonates a lot. One other thing I want to share around this topic of PM stress and this constant feeling of inadequacy, and I'm not doing enough to move the product forward, and and my schedule is crazy, and I'm just not able to perform at the level I need to et cetera, et cetera. All of which, by the way, again, a common theme is this was me for the first five PM career. And I used to share all of this with my wife all the time and like, you know, huge kudos to her to just like, listen…

John Cutler: She taught you how to listen…

LNO: Leverage, Neutral, and Overhead Tasks [01:18:10]

Shreyas Doshi: Exactly. So I think one key thing that was a turning point for me was the understanding of —uh, and I don't even know where I read it, it was some blog posts that I read and what I'm about to share is a paraphrasing of that, I can't find the blog post anymore for whatever reason— but it's what I termed as the LNO framework for PM effectiveness. Which is the observation that there are three kinds of tasks that I tend to do as a PM.

There's a leverage task, there's a neutral task, and then there's an overhead task. The leverage task, you know, as the name suggests, gives greater than what you put in. The neutral task will give you the same. And the overhead tasks will give you less. What most PMs do, and certainly what I did during those highly stressful days of my career as a PM, was I approached every task, any given task in the same way. Which is, oh, I'm going to try to do an awesome job. I was like some, you know, inner perfectionist, et cetera, et cetera. So I would spend a ton of time without understanding whether this is a leverage task, a neutral task, or an overhead task, right?

And, and what's right for the company you work for– and certainly for your team and very likely for you– is for you to understand that upfront. And then, you know, adjust the amount of energy and the amount of time based on that understanding. And I think what that does is, it certainly did for me, is it means spending more time and exerting more energy on certain things.

Because now you understand that this is a leveraged task. So instead of spending two hours on writing that, you know, completing that PRD, maybe you ought to spend four hours today to do that. Now of course, that extra two hours have to come from somewhere else. So find out [01:20:00] what are your neutral tasks or overhead tasks.

And so one example of, you know, usually a neutral, sometimes an overhead task, is you will get some requests for certain reports from finance, like, what's our 24 month projection for how the product is going to– like how much headcount do you need or whatever. Now, you know, I look at those things and, you know, there's the perfect way of doing it. And I see all these sometimes PM leaders, especially going to these meetings, and talk about all the analytical stuff of what's going to happen in September of 2022. And, November of 2023. And people are having all these discussions. Again, it goes back to, oh, we think we, we have certainty around what's going to happen.

They end up spending a ton of time on all of these things. And, what I typically do is like, again, usually– you know, sometimes it's an exception– but usually when I get these requests, I get them done in five, 10 minutes. Direita.

Like these, these are the assumptions. Aqui você vai. And if you need something more detailed, then please let me know how this is going to materially change, you know, things from a budgeting perspective or something else.

So that's just an example of where you kind of get back that time. And what I found is that as I started doing more and more of this, and on a tactical level what I would do is I created the to-do list, I would actually prefix the task just as a reminder to myself with L, N, or O .Right?

So when I started doing the task, I was like, okay, this is a leveraged as to how I'm going to approach

Conclusion [01:21:23]

John Cutler: I love that. I love ending with something really actionable. And so that's something that I'm going to do with the rest of my day too. To do these things. But, Shreyas, I wanted to thank you. We could have gone on for hours cause there's just so much, uh, so many questions I have. And I'm amazed too, about your ability to weave in and out your frameworks too. So you've actually inspired me thinking about how to be more actionable in these types of conversations. Because you've left people with specific frameworks, but we also went really deep into everything about intentionality, and culture, and stuff. So I really, really appreciate it.

And I'm super grateful for the opportunity to chat with you. And yeah, we'll stop now. But we should do it again at some point. Maybe people will have questions. Maybe we could do a follow-up like rapid fire, uh, answers to those questions if that would work for you.

Shreyas Doshi: Yeah, I would love that this was a blast. Você tem razão. We could have gone on for hours and this is fun stuff. So thanks for that.

John Cutler: I want to leave people with that one thing that Shreyas opened with. We've both probably learned the hard way. So when you see us tweeting assume that we've made the mistake 55 times, and we've had to work through it, context always matters, that would probably be like a footnote on those things. And three, I loved your statement too. You know, if you're in an unhealthy environment, you know, don't just assume you can just jump in. I think taking care of yourself, that's my theme, you know, as the tail end of the pandemic, is that people need to take care of themselves too.

Product Analytics for Dummies