O Lado Difícil das Situações Difíceis

O que gerentes de produto podem aprender com as experiências de Ben Horowitz descritas nesse livro?

Há tempos que escuto recomendações de Hard Thing About Hard Things como leitura obrigatória para PMs: nele, baseado em suas experiências, o autor traz conselhos para aquelas situações para as quais não há resolução fácil. Principalmente no contexto de (criar e fazer crescer) empresas de tecnologia.

Fui conferir e, como de costume, anotei alguns pontos para que eu possa retornar aos principais aprendizados de forma mais fácil posteriormente. Compartilho, a seguir, essas reflexões a partir de informações do livro. (Ou seja, esse não é um resumo do livro, mas um apanhado de passagens que podem ser úteis para gerentes de produto).

Ao longo dos anos, procurei não me deixar ser influenciado pelas primeiras impressões e não aderir cegamente às convenções.

Ben Horowitz escreve isso mais no contexto das experiências pessoais dele e que ajudaram a formar quem ele é do que no contexto de gestão empresarial. No entanto, acho exercícios valiosos para qualquer PM.

Não se influenciar pelas primeiras impressões é a famosa curiosidade do PM, é o "futricar um pouco mais", é o "buscar alguns dados para ajudar na decisão", é o product discovery para validar ou não uma hipótese, é o conversar com a usuária (ou adicionar mais usuários ao estudo) para entender um pouco melhor. Quando trabalhamos com produto, superficialmente muita coisa parece importante e óbvia, mas olhemos uma segunda vez.

Não aderir cegamente às convenções é um lembrete para questionar se o framework da moda faz sentido para o seu contexto. Ou se não existe uma forma mais simples de fazer algo. Ou se não vale a pena experimentar uma forma de trabalhar diferente, uma estrutura de time diferente, um layout diferente para o produto, etc. É um convite para enxergarmos o nosso produto (e o processo de construí-lo) dentro do seu contexto específico, e ter a coragem de fazer diferente se fizer sentido.

Impressionava-me o fato de que as diferentes perspectivas mudavam o significado dos acontecimentos importantes. […] Ter visto o mundo sob pontos de vista tão diferentes me ajudou a aprender a separar os fatos da percepção que se tem deles. […] Em circunstâncias complicadas […], aprendi a procurar conhecer outras experiências e explicações, com pontos de vista diferentes, antes de formar uma opinião.

Fazemos produtos para pessoas diferentes de nós. Conversar com o usuário não significa tentar entender o que ele quer. Significa primeiro tentar entender ele, para a partir do ponto de vista dele com relação ao mundo, construir uma solução para seus problemas. Se um problema está difícil demais de resolver no produto, talvez a nossa perspectiva sozinha sobre ele não seja a suficiente. E não falo apenas de falar com o usuário, que é o óbvio, mas com diferentes grupos de usuários, com outras pessoas do time, com outras áreas da empresa, e por aí vai.

[…] Esse é o preço que pagamos ao não parar para entender o que está acontecendo.

Novamente, o autor traz essa frase em um contexto de experiências pessoais, mas sublinhei a passagem para eu lembrar de fazer isso no meu trabalho. A rotina da gerente de produto é dinâmica e emocionante, e às vezes me pego "parando para entender o que está acontecendo" de menos: é bug que surge, é cliente grande que reclama, é o pessoal de customer success em saia justa, e bate aquela vontade de resolver tudo de uma vez.

Acredito no meio termo entre o agir por impulso (desviando mil vezes do foco) e o terrível "fazer um estudo aprofundado" sobre tudo (que resulta em um documento de 55 páginas com links para outros 34 documentos de 29 páginas cada). Ou seja, parar para entender o que está acontecendo, mas de forma produtiva.

Achava que tinha possibilidades ilimitadas e podia fazer ao mesmo tempo todas as coisas que quisesse.

As possibilidades em produto geralmente tendem ao ilimitado, e reside justamente aí a arte de ser PM: determinar o que é mais importante.

Quanto a fazer várias coisas ao mesmo tempo no produto/feature/squad, acredito que é possível fazer mais de uma coisa ao mesmo tempo (com parcimônia, organização e um bom motivo para isso), mas longe de podermos fazer ao mesmo tempo todas as coisas que queremos. Por mais que bata a tentação.

[…] as [empresas] de tecnologia buscam desenvolver maneiras melhores de fazer as coisas.

Achei isso maravilhoso porque me parece servir como uma "missão universal" para todas as empresas de tecnologia. Acima da missão específica de cada empresa, essencialmente é isso que estamos fazendo: melhorando a maneira como X sempre foi feito.

Me encanta a simplicidade dessa frase, e me impressiona a quantidade de vezes que parecemos esquecer disso no dia a dia. Às vezes, queremos um produto mais completo, mas é um produto mais completo que vai melhorar a forma como o usuário faz X? Ou não sabemos interpretar o que "melhor" significa para o nosso usuário: é fazer X mais rápido? É fazer X mais barato? É fazer X sem precisar ser um expert em X?

E vejo essa frase sendo verdade para dentro e para fora da companhia: desenvolver maneiras melhores de fazer as coisas nos processos (argh!) da empresa, e o produto em si fazendo isso pelos usuários.

Fazer um software funcionar para milhões de usuários era muito complicado.

Pois é. Só que a grande maioria das startups quer justamente ter milhões de usuários. Então não tem jeito fácil, uma hora vai escalar e a estrutura precisa aguentar. Na minha opinião, o caminho é conseguir perceber quando esse ponto de virada entre "a versão mais lean inicial" e a versão para escala está chegando, e traçar um plano.

Se todos os times vão "parar para ver isso daí", se vai ter um time focado nisso, se vai ter outra solução, enfim, cada empresa vai achar seu jeito. O que não dá é ser pego de surpresa ou então ficar tapando o sol com a peneira e fingindo que a situação não está ficando tensa. É raro mas acontece muito.

Há certas coisas que é mais fácil ver nos outros do que em nós mesmos.

É natural que, depois de um tempo colaborando na construção de um produto, seja difícil para a PM ver as falhas do mesmo. Já estamos tão imersos no nosso universo que não conseguimos nota-las.

Por várias razões, é importante que utilizemos os produtos concorrentes, e essa é uma delas: por vezes, algo que julgamos falho em um produto concorrente pode estar acontecendo de forma muito similar no nosso. No produto do outro é algo tosco, e no nosso é “algo que faz parte da curva de aprendizado do usuário”. Isso é humano.

Ou, ainda, decisões erradas tomadas por outras empresas podem dar dicas sobre o caminho que a nossa própria empresa está tomando, e assim podemos corrigir o rumo.

A necessidade sempre ganha da vontade […].

No livro, essa frase tem a ver com fusões e aquisições. Mas julgo fazer total sentido para a gestão de produtos, também.

Há uns dias escutei esse episódio do podcast "Produto pelo mundo", e gostei bastante de uma colocação da Catarina Lima: existem fases da vida de um produto que exigem um "modo execução", onde não cabe tanto discovery, mas sim a "simples" adequação para entrar em um mercado X, por exemplo.

Mesmo que estejamos em uma fase onde já encontramos market fit e estejamos em pleno discovery para expansão, sempre pode surgir uma nova lei (alou LGPD) ou a coisa toda pode começar a ruir pois a estrutura não suporta a quantidade de usuários que estamos conquistando (conforme falamos lá em cima).

É importante saber identificar quando a necessidade ganha da vontade.

[…] precisaríamos entrar num mercado maior para conhecê-lo bem o suficiente de forma a poder criar o melhor produto. Paradoxalmente, a única maneira de fazer isso consistia em montar e tentar vender um produto que não fosse muito bom. Daríamos com os burros n'água, mas rapidamente aprenderíamos o que deveríamos fazer para sobreviver.

A frase fala por si só. Conhecer o mercado é essencial para criar o melhor produto, mas não vamos conhecê-lo magicamente. A ordem é: produto suficiente, aprendizado de mercado, produto excelente.

[…] você está encarregado, agora, de descobrir algo que eles não esperam, mas querem. Está encarregado de descobrir qual valor vai acrescentar o elemento entusiasmo.

Gostei especialmente dessa passagem pois, no geral, consideramos o elemento entusiasmo um luxo, quando na verdade ele pode ser uma peça importante para ganhar o jogo.

Claro que isso depende do momento da empresa/produto, mas balancear aquilo que resolve a dor do cliente com aquilo que brilha os olhos dele é parte da arte de fazer produto. E é uma virtude saber entender o que é firula e o que de fato vai impactar positivamente na experiência do usuário.

[…] pequenas hesitações, aparentemente insignificantes, podem causar terríveis atrasos. […] O objetivo era remover todos os obstáculos.

Apesar de "impedimentos para que eu realize o meu trabalho" ser um dos pontos clássicos da daily, na prática eu vejo muito mais peso "no que eu fiz e o que eu vou fazer" do que na remoção de obstáculos. Eu acredito que muitas vezes a gente incorpora os obstáculos como algo inevitável e isso desacelera o processo de removê-los.

Penso ser um exercício saudável para todos os membros do time fazerem constantemente: por que está demorando? Preciso de algo que eu não tenho? Existe alguém que pode me ajudar? Tem um jeito mais simples? Em resumo: todos do time devem se importar e serem críticos com o ritmo com que as coisas estão andando, buscando melhorar.

[…] descobrir o produto correto é tarefa da empresa, não do cliente. O cliente sabe apenas o que quer do produto, baseado em sua experiência. A empresa pode levar em conta todas as informações possíveis e, muitas vezes, ser obrigada a contrariar aquilo que sabe ser verdade. Por isso, a inovação pressupõe uma combinação de conhecimento, habilidade e coragem.

Eu acho isso especialmente importante porque podemos confundir "conversar com o cliente" com "conversar com o cliente e fazer o que ele pede/diz". Em certas situações, cabe arriscar em algo que achamos que vai funcionar (com base em algo concreto, claro), no lugar de algo que sabemos que, em tese, vai funcionar, porque o concorrente tem ou porque o cliente pediu explicitamente.

As exigências que nos foram feitas até agora podem não levar o produto para o lugar certo. É trabalho da empresa (e muito mais da PM) colher informações e entender como é o produto que resolve o problema a que se propõe resolver.

Às vezes […] as coisas que não estamos fazendo são aquelas nas quais deveríamos nos concentrar.

Há a tendência de dedicarmos bastante energia analisando e melhorando aquilo que o produto já faz, o que nos cega de pensarmos sobre o que ele ainda não faz.

Acredito que isso seja agravado pelo fato de que a nossa usuária só conhece o produto do jeito que ele existe, então é mais fácil pra ela pedir para que as coisas que estão lá sejam melhores/diferentes, em vez de pensar em algo que não existe mais melhoraria muito a vida dela. E, como vimos acima, esse não é o trabalho dela.

Mais um exercício saudável pro PM fazer com frequência: o que o meu produto não faz? O quanto e como isso mudaria a vida de quem o usa? O que falta no nosso produto para resolver o problema da pessoa que o usa de forma mais completa?

[…] todas as decisões parecem objetivas até ser escrita a primeira linha de programação. Depois disso, todas se tornam emocionais.

Me parece que boa parte das coisas na vida seja assim. Ao planejar algo, tudo parece bem objetivo, organizado, prático e certeiro. Quando começamos a fazer de fato, mil variáveis interferem e a coisa simplesmente vai para vários lados diferentes.

Em produto, eu acredito que faz parte do trabalho do PM (em conjunto com o líder técnico) organizar essa "emoção" e ir conduzindo o time para dentro da objetividade inicial. Aprendizados no caminho vão existir e, dependendo deles, podemos até descobrir desvios da decisão inicial que podem ser inteligentes. Mas é preciso um bom senso crítico para separar isso de um possível desvio de foco, por exemplo.

Depois de confirmarmos que seria melhor adquirir do que desenvolver o produto, […].

É claro que a aquisição de uma empresa não é tarefa simples/barata, mas e fazer produto é? Em muitos casos (features específicas que fogem do core business da empresa, por exemplo), não.

Apesar de que em tecnologia (quase) tudo "dá", às vezes desenvolver determinadas features ou produtos internamente não é o caminho mais produtivo. Creio que é também papel da PM identificar quando é esse o caso, e definir se é algo que não será feito agora, se é viável estudar uma aquisição, se é algo que pode ser feito em parceria, etc.

[…] os cenários da competição e da tecnologia mudavam com rapidez. […] a rapidez das mudanças nos obrigaria a fazer modificações substantivas na arquitetura do nosso produto para que continuássemos por cima.

Eu gosto desse lembrete de que a arquitetura do produto também é algo a considerar para que um produto fique "por cima". Considero um desafio grande da posição de PM achar o equilíbrio entre iniciativas funcionais e não-funcionais do produto, coloquemos assim.

Há bastante tempo reflito sobre a melhor forma de conduzir essa decisão (devo lançar novas funcionalidades que os clientes "podem ver", ou devo reforçar/modificar a estrutura do produto para ganhar, por exemplo, performance e escala?), mas a conclusão a que chego é que não tem resposta fácil. Cada PM vai precisar avaliar o momento do produto, do mercado e do quão crítica está a situação. Mas uma coisa á fato: tecnologia, concorrentes e mercado vão se mover rápido, e é melhor decidirmos um rumo e nos movermos também.

Reúna o maior número possível de cérebros ao redor dos problemas. […] nenhum cérebro, por mais brilhante que seja, consegue resolver um problema que desconhece.

Apesar de trabalharmos em um squad multidisciplinar e conversarmos com pessoas (clientes, customer success, designers, pessoal de engenharia, marketing, etc) o tempo todo, já passei por várias decisões solitárias como produteira, por diversas razões.

Mesmo que tenhamos muito contexto do nosso produto, acho que esse é um bom post-it para colar no monitor, para lembrarmos de reunir mais cérebros em todas as etapas de gestão e desenvolvimento de produto.

As empresas de tecnologia tendem a ser extremamente complexas. A tecnologia em si se modifica, a concorrência se modifica, assim como o mercado e as pessoas. […] No jogo da tecnologia, o amanhã é muito diferente do hoje. Se você conseguir sobreviver até amanhã, o novo dia poderá trazer a solução que lhe parece impossível hoje.

Essa parte do livro me fez refletir sobre os frameworks e práticas de produto que sempre estão mais alta. Geralmente, elas tendem a olhar para dentro da empresa e do produto e/ou para os seus clientes e usuários. Qual é o problema do meu usuário? Qual é a sua jornada? Qual é o problema do meu produto? Qual é o objetivo da minha empresa? Quais são os nossos desafios técnicos? Etc. Todas essas questões importantíssimas, mas creio que falta falarmos mais sobre como podemos olhar para tudo isso ao mesmo tempo em que olhamos para um cenário mais macro.

Apesar de não devermos obcecar com a concorrência, vejo pouco conteúdo de produto sobre melhores práticas para a PM abordar a concorrência em suas decisões de produto, por exemplo. Também falamos pouco sobre estudo do mercado onde a empresa atua. Esse é um quesito que vem sendo abordado em nossos product discoveries, de alguma outra forma, ou está simplesmente mais esquecido? Em podcasts, por exemplo, vejo muitas perguntas sobre discovery, sobre documentação, sobre uso de dados, processo seletivo de produto, gestão de times, etc., mas (pelo menos do que eu tenho escutado), não se faz muito a pergunta "como você faz para conhecer profundamente sobre a indústria onde sua empresa atua?".

[…] a ideia de eu ser o único a me preocupar com o fato de um produto apresentar um defeito, por exemplo, não tinha sentido, pois não era eu quem iria procurar um modo para consertá-lo. Seria muito melhor transferir o problema às pessoas que, além se serem capazes de solucioná-lo, também se sentem animadas e motivadas a fazê-lo.

O autor coloca isso no contexto dele (CEO), mas acredito que parte disso também aconteça com o product manager. Eu, pelo menos, já centralizei muito em mim os problemas do produto, com a sensação de que era eu quem devia solucionar. Muitas pessoas da empresa já olharam para mim esperando que eu solucionasse.

A PM é parte da solução, facilita a solução, mas dificilmente trará sozinha a solução. Não é para isso que ela está lá. Sabemos que a atuação de produto está muito mais no problema, inclusive. A responsabilidade do PM sobre o produto passa por saber qual é a melhor contribuição de cada um do time para o mesmo.

Em qualquer interação humana, a quantidade necessária de comunicação é inversamente proporcional ao nível de confiança.

Apesar de defender bastante a comunicação dentro de um squad de produto, considero esse um ponto importantíssimo, pois em um time onde as pessoas confiam umas nas outras não é necessário explicar o porquê de toda e qualquer decisão tomada.

Sim, todos no time devem compartilhar, trocar, pedir opiniões, etc. Mas existem situações onde a designer vai tomar as suas decisões, a PM as suas, a engenheira as suas e é saudável que confiemos e estejamos comprometidos com essas escolhas dos outros, sem que tenhamos que necessariamente receber uma explicação detalhada de tudo o que é definido.

Uma cultura empresarial sadia encoraja as pessoas a partilhar as más notícias. A empresa que discute seus problemas com liberdade e abertura é capaz de solucioná-los com maior rapidez.

Quem trabalha com produto sabe que o que mais surge pra gente é problema para solucionar (afinal, como diz o clichê, devemos nos apaixonar por eles). É bonito imaginar que discutir sobre eles vai ser benéfico, mas na prática é natural postergar o momento de admitir que algo está muito errado e precisa ser corrigido.

Sim, a gente participa do processo de trazer à vida novas features maravilhosas que vão melhorar a vida dos clientes. Mas, sim, a gente também precisa saber a hora de trazer o elefante pra sala e falar logo sobre algo desagradável para que a solução também seja rápida.

Se você cria um produto que o mercado quer comprar, terá de fazer a sua empresa crescer com rapidez.

É primordial a sensibilidade do time de produto de entender quando se está no momento de achar o PMF e quando se está no momento de ganho de escala. As decisões de produto são completamente diferentes em um momento e no outro.

Ao meu ver, de forma resumida, no primeiro você está muito mais focado em entender o problema, o usuário e focar nas features de MVP (talvez em algumas funcionalidades um pouco além do mínimo). No segundo, é o momento de focar em infraestrutura para o produto aguentar o volume, sem perder o timing de iterar o produto de acordo com as necessidades dos usuários e, idealmente, fazer ele se vender sozinho. Pois é.

[…] os seres humanos, em particular os criadores, só dão importância a indicadores de boas notícias. […] só agiu diante do indicador positivo; diante do negativo, ele procurou explicações plausíveis.

Times de produto são muito orientados por dados, mas o que estamos fazendo com eles? Como estamos utilizando os dados?

Há essa tendência natural contra a qual convém lutar, de usar indicadores positivos para tomar ações (expandir equipe, expandir mercado, criar novos produtos…) e negativos para trazer justificativas (esse mês tivemos aquela instabilidade pontual, o perfil de usuários que estamos prospectando não condiz com o produto…)

[…] nosso problema não era um problema de mercado: os clientes estavam comprando, apenas não estavam comprando nosso produto. Não era hora de mudar de foco. […] ficou claro que precisávamos de um produto melhor.

Alguns perfis de PM são extremamente duros consigo e com o seu produto, e esquecem que às vezes é o PMF que não fechou. Outros buscam explicações para os momentos difíceis fora da empresa, quando o produto simplesmente precisa ser melhor. Quando temos um desafio, acho valiosa essa forma de separar as abordagens para acertar no diagnóstico do que precisa ser melhorado: a aderência com o mercado ou o produto em si.

[…] contratação de executivos, levando em conta seus pontos fortes, e não a ausência de pontos fracos.

Apesar disso não ter relação direta com produto, e sim com a contratação de executivos, achei essa dica sobre contratações uma das grandes inspirações desse livro, e pode se aplicar a qualquer posição.

Faz mais sentido buscar alguém que tem o que a gente precisa e trabalhar posteriormente os pontos fracos do que selecionar alguém por não ter demonstrado fraquezas e depois tentar desenvolver na pessoa talentos e habilidades essenciais para determinada missão.

"Nós cuidamos das pessoas, dos produtos e dos lucros — nesta ordem."

Pessoas infelizes não fazem bons produtos, e uma empresa com produtos fracos não resulta em uma boa lucratividade. Parece simples, mas muitas empresas se perdem nessa ordem. Quando a coisa estiver confusa, tanto empresa quanto squad de produto podem olhar para essa proposição para se organizarem.

O sucesso obriga as empresa a contratar novos engenheiros em ritmo acelerado, e elas nem sempre treinam de maneira adequada os recém-contratados. À medida que os engenheiros recebem suas tarefas, eles as cumprem da forma que lhes parece melhor. […] O usuário vê-se então às voltas com um produto com problemas de desempenho e com uma bagunça generalizada.

Arquiteturas Frankenstein de produtos é uma constante por aí, e o desafio fica ainda maior com a rotatividade que vemos no mercado de tecnologia. E não creio que a problemática se limite à equipe de engenharia. Todos os membros de um squad de produto, se chegarem sem muito contexto, vão acabar criando um produto possivelmente inconsistente e de forma ineficiente.

Vejo esse ponto como uma responsabilidade compartilhada entre a empresa, que deve treinar e possibilitar a contextualização das pessoas, e delas próprias, de entenderem onde estão entrando para trazer as melhorias de forma sustentável e coerente.

O bom gerente de produto define de modo conciso e exato o alvo, o que (e não como) […].

O autor reproduz no livro esse difundido texto de sua autoria, que provavelmente toda PM já leu, mas coloquei aqui talvez a parte que eu mais goste/concorde.

É comum vermos perguntas em podcasts de produto como "como é, no seu time, a separação das responsabilidades…", e eu acho essa uma forma simples de definir. PM está muito mais ao lado do que, engenharia muito mais ao lado do como, e enxergo design como um elo entre eles.

É importante que a visão de um grande produto seja suplementada por uma forte disciplina métrica, mas se a visão for substituída pela métrica você jamais conseguirá o que quer.

O autor sugere que o número funcione como um incentivo. Um time de produto obcecado por um número geralmente se perde na visão macro do que aquele produto está entregando para o usuário de forma geral. O número deve estar ancorado em uma visão consistente de produto. O que, de fato, queremos? Todos querem retenção, por exemplo. Mas qual exatamente é o produto que vai gerar essa retenção?

[…] havia muitos outros números que teriam nos ajudado a avaliar a situação: […] O que nossos engenheiros pensavam sobre os produtos?

Muito se fala sobre a importância de envolver todo o time no product discovery, principalmente engenharia, já que a PM e designer já estão muito imersas nesse processo. Mas na prática, nem sempre é fácil.

Recentemente escutei esse episódio do podcast "Produto pelo mundo" (de novo ele aí) com a PM Liza Mello, onde ela relata o seu processo: logo quando começa a trabalhar em um discovery X, ela explica para todo o time no que ela vai começar a trabalhar (para estarem por dentro), e depois ela envolve o pessoal de engenharia em dois momentos — na listagem de questions and assumptions, e para gerar ideias de fato para uma nova funcionalidade (geralmente com um crazy 8).

Como no caso da dívida técnica, optar pelo curto prazo às vezes faz sentido, mas, na maioria das vezes, não.

Essas escolhas relacionadas a débitos técnicos são uma eterna polêmica, e acho que não tem uma resposta única correta. Mas, uma vez que o PM sofre as consequências dessas escolhas, é uma boa ideia ele se envolver com elas.

Também considero crítico avaliar o momento do produto e da empresa ao se pensar em atalhos e se eles fazem sentido, mas concordo com o Ben Horowitz: na maioria das vezes, não. Quando se precisa crescer rápido e atingir PMF, talvez, mas geralmente isso me lembra aquela metáfora da bola de basquete na piscina: se você empurrar ela pro fundo, ela volta bem rápido na sua cara.

[…] um bom serviço de garantia de qualidade não é capaz de construir um produto de alta qualidade, mas é capaz de dar o sinal de alerta quando a equipe de desenvolvimento cria um produto de baixa qualidade.

Sem (muito) mais aqui: ter uma atenção dedicada ao que pode dar errado é quase tão importante quanto buscar aquilo que queremos. As coisas vão dar errado, mas errado mesmo é quando o cliente é a pessoa que percebe isso e avisa você.

A coisa mais importante que qualquer startup de tecnologia deve fazer é construir um produto que seja pelo menos dez vezes melhor em certa tarefa do que o principal produto que as pessoas no momento usam para cumprir a mesma tarefa. Ser duas ou três vezes melhor não basta para que as pessoas adotem o novo produto com rapidez suficiente ou em volume suficiente. A segunda coisa que toda startup de tecnologia deve fazer é dominar o mercado. Se é possível cumprir uma tarefa dez vezes melhor, também é possível que a sua empresa não seja a única a tentar fazer isso. Portanto, você deve dominar o mercado antes que alguma outra empresa o faça.

Aqui, sem mais.

O processo de fazer uma empresa crescer é semelhante ao de aumentar a escala de um produto. As diferenças de tamanho impõem diferentes exigências à arquitetura da empresa. Se você atender a essas exigências cedo demais, sua empresa se tornará lenta e pesada. Se atender tarde demais, é possível que a empresa não resista à pressão.

O maior problema que vejo acontecendo no contexto de produto não é o primeiro — geralmente as empresas começam lean mesmo, por necessidade. O maior problema é o segundo — demorar a reforçar as estruturas quando a escala já está em andamento. Na minha opinião, é um ato de coragem reservar espaço para isso no roadmap, porém necessário.

No setor de tecnologia, é raro sabermos tudo de antemão. A diferença entre a mediocridade e a magia com frequência surge da diferença entre deixar que as pessoas corram riscos de forma criativa e exercer um controle demasiadamente rígido sobre elas. A responsabilidade é uma coisa importantes, mas não a única.

Lembrei, com isso, das frequentes discussões sobre roadmap. Ele deve trazer features? Ele deve trazer problemas? O quão confiável é um documento que traça um caminho em um mercado onde o caminho muda o tempo todo? Devemos sequer ter um roadmap?

Acredito que a frase acima do livro nos traga algumas reflexões nesse sentido. Eu particularmente defendo o roadmap, mas acredito que ele deve dar esse espaço para o "não sabemos tudo de antemão", e para o "correr riscos de forma criativa". Vejo ele como uma forma de indicar para os interessados o caminho que planejamos trilhar. Mas, se o roadmap servir para prestar contas e controlar o time de produto, ao meu ver está errado, e daí é melhor não ter.

[…] foi a própria execução defeituosa do produto que fez encolher o mercado da empresa.

Por fim, achei ótima essa reflexão. Muitas vezes colocamos o mercado na conta de um produto que fracassou, mas não pensamos muito sobre o fato de que um produto mal executado pode ter matado um mercado potencial.

Faz parte da sensibilidade da PM separar esses fatores — no sucesso ou dificuldade que estou passando com meu produto, o que é responsabilidade do mercado, dos concorrentes, de outras áreas da minha empresa, e o que é responsabilidade do meu produto? Identificar essas responsabilidades ajuda a não achar desculpas e achar soluções.