No episódio #35 do Product Backstage, conversei com Bianca Orsini sobre o impacto do MBA na carreira de produto. A Bia compartilhou sua trajetória desde a formação em engenharia civil, passando por experiências no Nubank e no Y Combinator, até a decisão de fazer um MBA no INSEAD. Discutimos como sua jornada em consultoria, produto e empreendedorismo moldou sua visão sobre a relevância de um MBA para o desenvolvimento pessoal e profissional.

A Bia abordou também os desafios de equilibrar aprendizado técnico e habilidades práticas no MBA, destacando o networking global como um dos principais benefícios. Além disso, refletimos sobre as credenciais profissionais, como o impacto do Y Combinator, do Nubank e agora do Google em sua carreira, e como cada uma delas pode abrir portas para diferentes objetivos.

Esse episódio é uma ótima oportunidade para quem está considerando um MBA como parte da trajetória em produto ou até em usar essa estratégia para migrar para área.

Recomendações desse episódio

Livros:

• Educated (Tara Westover)

Outros:

• Newsletter TLDR

• Série de vídeos de Chris Manning (Stanford), sobre NLP

No episódio #34 conversei com o Dudu Magalhães sobre a importância de mensurar resultados em times de produto. O Dudu compartilhou a trajetória dele, desde o início como UX designer até a posição atual como Head de Product Operations na RD Station, destacando os aprendizados ao longo do caminho e a relevância de alinhar métricas de produto com os objetivos de negócio.

Durante a conversa, discutimos como criar times de alta performance e a implementação de OKRs para garantir que as equipes de produto estejam impactando positivamente os principais indicadores da empresa. Dudu explicou como, na RD Station, sua equipe trabalha não apenas para facilitar a operação dos Product Managers, mas também para conectar as métricas de produto aos resultados financeiros e estratégicos da empresa.

Esse episódio traz insights sobre como uma operação de produto robusta pode alinhar as equipes aos objetivos organizacionais, garantindo que o valor entregue ao cliente esteja sempre no centro das iniciativas.

Recomendações desse episódio

Livros:

• E-book sobre Product Management do Tim Herbig

Outros:

• Cursos - Product Arena

No episódio #33 do Product Backstage, conversei com Lucas Abreu sobre Product Market Fit (PMF), investimentos e muito mais. O Abreu compartilhou sua trajetória desde Aracaju até se tornar uma figura reconhecida no Venture Capital, passando pela FGV, startups e produtor de conteúdo. Discutimos a importância de PMF para startups e as estratégias para avaliar e alcançar esse estágio crucial.

Na conversa exploramos dicas para quem deseja se aventurar como investidor anjo ou entrar no mundo do Venture Capital, destacando a importância do networking e do alinhamento com empreendedores. O Abreu também abordou os desafios de PMF em produtos B2B e B2C, as métricas essenciais para mensurar sucesso e como novas categorias de produtos podem impactar o mercado. Um episódio pra lá de especial, para quem está interessado em tecnologia, startups e investimentos.

Recomendações desse episódio

Livros:

• Alchemy

Outros:

• Abreu Newsletter

• Abreu Podcast

No episódio #32 do Product Backstage, eu tive o prazer de conversar com Juliana Araújo, Group Product Manager no Spotify, sobre o tema "Plataformas de Dados & AI". Juliana compartilhou sua trajetória inspiradora desde o subúrbio do Rio de Janeiro até a Suécia, onde agora lidera equipes no Spotify. Discutimos a importância de dados de qualidade para o sucesso de produtos de AI e como plataformas de dados integradas são essenciais para empresas que desejam utilizar AI de maneira eficaz.

Durante a nossa conversa, exploramos os desafios e as vantagens de trabalhar com plataformas de dados, a transição de Juliana da engenharia para o gerenciamento de produtos e a criação de uma ONG para empoderar mulheres imigrantes na Suécia. Juliana também nos deu uma visão crítica sobre o estado atual da AI e a necessidade de abordar questões éticas e de diversidade dentro do campo. Esse episódio oferece insights valiosos para qualquer pessoa interessada em dados, AI e desenvolvimento de produtos.

Recomendações desse episódio

Livros:

• Escaping the Build Trap

Outros:

• Curso Comunicação Consciente para Líderes (Instituto de Comunicação Não Violenta)

• Beela (http://beela.se)

• Strides

No episódio #31 conversei com o Guilherme Seabra sobre como criar novos produtos. O Seabra compartilhou sua trajetória profissional, desde sua experiência no Itaú até sua jornada empreendedora com a Emily, onde está criando um produto com inteligência artificial. Ele falou sobre os desafios enfrentados, as decisões difíceis que precisou tomar, e as lições aprendidas ao longo do caminho.

Durante a conversa, exploramos a transição do Seabra do ambiente corporativo para o empreendedorismo, a importância de desafiar intelectualmente os times, e como equilibrar a persistência com a necessidade de saber quando é hora de pivotar ou encerrar um projeto. Nesse episódio você vai ter uma visão detalhada e prática para entender melhor os processos e desafios envolvidos na criação de produtos de IA, especialmente em ambientes early-stage.

Recomendações desse episódio

Livros:

• O Gigante Enterrado

• The Lean Startup

Podcasts:

• Astella Playbook

• Canary

• Y Combinator

• Masters of Scale

• Produto pelo Mundo

Outros:

• Emily (https://helloemily.ai/)

Meu primeiro contato com Inteligência Artificial foi ainda na faculdade quando tive a oportunidade de fazer uma cadeira optativa sobre o assunto. Na época (2009 ou talvez 2010), eu lembro que tanto a aula, quanto os livros que eu li me faziam flutuar entre “isso aqui é muito Jetsons” (Black Mirror ainda não tinha sido lançado) quando você estudava a teoria da coisa, pra algum nível de depressão e descrença quando você de fato tentava colocar algo em prática. Ao meu ver, o que tinha de mais interessante e prático naquele momento eram algoritmos de recomendação e coisas nessa linha, que alimentavam sites de e-commerce principalmente.

Uma década mais tarde eu tive a oportunidade de trabalhar com IA na Stilingue, uma empresa pioneira no uso de Inteligência Artificial no Brasil, onde a gente fez uma série de experimentos interessantes com IA, e tínhamos como core do produto em si tecnologias de NLP (Processamento de Linguagem Natural). Na época, tínhamos um time com muitas pessoas com mestrado e doutorado em IA, e profissionais de Machine Learning, Machine Teaching e todo um ecossistema interno e externo, incluindo parcerias com universidades e etc, para viabilizar projetos de pesquisa que nos ajudassem a desenvolver, manter e evoluir nossos modelos proprietários de Inteligência Artificial. Isso foi há menos de 4 anos, mas dada a evolução que tivemos nesse período parece que se passaram outros 10 anos. 

O ponto importante, é que todas essas experiências e aprendizados me levaram a, em 2022, ter a oportunidade de trabalhar na Birdie, uma startup early-stage de Palo Alto. Na Birdie, eu estive nos últimos 2 anos usando Inteligência Artificial para criar um produto para ajudar outras pessoas de Gestão de Produtos a tomarem melhores decisões através de dados qualitativos, especialmente feedback de clientes. Quando começamos a desenvolver o atual produto da Birdie, ainda em 2022, tínhamos um cenário muito parecido com o que descrevi da Stilingue, com estruturas e desafios muito semelhantes. Mas ainda no final daquele ano, mais precisamente em 30 de Novembro, tudo mudou.

Em Junho de 2020 a OpenAI já tinha lançado o GPT3, mas essa tecnologia passou praticamente despercebida pelo público geral até Novembro de 2022 quando o ChatGPT foi lançado. Desde o início de 2022 eu já estava acompanhando uma ou outra empresa que usava o GPT3 para análise de dados qualitativos. Mas, de uma forma geral, o pensamento ainda era de descrença nessas tecnologias, “a gente faz melhor internamente”, “nosso cenário é especial por X ou Y motivo”, “nosso usuário fala português” e por aí vai, eram argumentos normais dentro da Stilingue e da Birdie (eu mesmo usava alguns deles). Eu não sei como as coisas evoluíram dentro da Stilingue, mas dentro da Birdie a gente optou por usar pesadamente essas novas tecnologias, especialmente LLMs, para construir nosso produto. E é especialmente sobre os aprendizados desenvolvidos nesse último período que eu quero falar nesse post.

Conceitos

Antes de começar, vamos só garantir que alguns conceitos estejam claros e alinhados:

1. Inteligência Artificial (IA): IA, ou AI na sigla em inglês, é um conceito amplo, que engloba todos os sistemas e técnicas que permitem que computadores realizem tarefas que normalmente requerem inteligência humana. Isso pode incluir reconhecimento de padrões, tomada de decisões, compreensão de linguagem natural e várias outras coisas.

2. Machine Learning (ML): Aprendizagem de Máquina (Machine Learning) é uma subárea específica da IA que se concentra na capacidade dos sistemas de aprender e melhorar com os dados existentes, sem a necessidade de programação explícita para cada tarefa. Embora seja uma parte importante da IA, nem todas as aplicações de IA envolvem aprendizado de máquina.

3. IA Generativa (GenAI): IA Generativa refere-se a um subcampo de ML que se concentra em criar ou gerar novos conteúdos, como imagens, texto, áudio ou vídeo. Esses conteúdos devem ser originais e não diretamente copiados de exemplos existentes. Isso pode incluir uma variedade de técnicas e modelos, como as LLMs (Large Language Models). Se você quiser entender mais sobre esse assunto eu recomendo começar por esse vídeo introdutório do Henrik Kniberg.

4. LLM (Large Language Model): Este é um tipo específico de modelo generativo que se concentra na geração de linguagem natural em larga escala, geralmente baseados em redes neurais e treinados em grandes volumes de texto. Embora os LLMs se enquadrem na categoria de IA Generativa, eles são uma implementação específica dessa técnica, focada na geração de texto.

Principais aprendizados

#1 Estamos acostumados com software com um resultado objetivo, IA é incerto

Uma das primeiras coisas que é importante entender sobre Inteligência Artificial, é que ela é uma tecnologia que tenta emular a nossa inteligência humana, a forma como a gente pensa. Ok, eu sei que esse não foi o melhor momento eureca desse post, mas o ponto é que ao tentar emular a forma como a gente pensa o resultado que obtemos vem com as partes boas, mas também as partes ruins disso. Um dos principais pontos negativos de se criar um produto usando IA é que diferente do que estamos acostumados, o resultado de um produto desse tipo é “imprevisível” em algum nível. 

Vamos a um exemplo prático: se eu tenho uma série de frases e uso um método determinístico para classificar essas frases em temas, por exemplo, usando palavras-chave (ex.: toda vez que contiver a palavra “atendimento” classifique como “suporte”), o esperado é que 100% das vezes que uma determinada frase contiver uma certa palavra, ela seja classificada com um tema específico. Qualquer resultado diferente disso é considerado um erro. Ao mesmo tempo, se a frase contiver algo como “abri um chamado” ao invés de “solicitei um atendimento”, o software determinístico não vai classificar essa frase como “suporte”, ao menos que a palavra “chamado” seja adicionada na lista de palavras chave… o que vai criar outro problema, porque nem sempre “chamado” é necessariamente relacionado a suporte e por aí vai.

Agora, quando usamos IA para fazer esse mesmo tipo de classificação do exemplo anterior, o resultado passa a ser não determinístico. Ou seja, não temos como garantir que a IA vai classificar os mesmos termos, da mesma forma, todas as vezes, por que dependemos da interpretação da inteligência artificial para definir um resultado. Mas, ao mesmo tempo, podemos contar com essa mesma “interpretação” para não precisar elencar todos os exemplos do que é um termo relacionado a “suporte”, seus sinônimos, etc. 

Outro fator positivo de usar IA é que podemos treiná-la, dando exemplos positivos e negativos do que consideramos frases relacionadas a “suporte” (nesse nosso exemplo), para melhorar a assertividade dela. Mas ainda assim, sempre vai existir uma taxa de erro no que a IA faz. É justamente essa característica que faz com que algumas pessoas não confiem nos modelos de Inteligência Artificial, prejudicando a adoção desse tipo de produto ou fazendo com que o processo de desenvolvimento se alongue demais, na tentativa de buscar um resultado perfeito.

Mas pensa comigo, se você contratar duas pessoas para classificar uma lista de frases em determinados temas, sendo que cada pessoa vai receber exatamente a mesma lista, você acha que o resultado do trabalho de cada uma será 100% igual? Mesmo que seja uma única pessoa, com a mesma lista, mas que classifique duas vezes a lista em dias diferentes, o que você acha que vai acontecer? Muito provavelmente em ambos os casos os resultados não serão os mesmos! Se as pessoas erram e tem opiniões e interpretações diferentes sobre um mesmo assunto, imagina uma máquina!

Lidar com essa variação nos resultados é um dos grandes desafios de se trabalhar com IA, porque apesar de ser uma máquina que está trabalhando pra gente, dando um ganho de produtividade enorme, ela não é determinística como estamos acostumados quando nos referimos a máquinas, programas, algoritmos e etc. Isso quebra muitas expectativas, tanto internamente na empresa, quanto com os clientes finais. Para “resolver” esse problema precisamos investir em tempo para treinar esses algoritmos, educação para que as pessoas usuárias entendam como a IA realmente funciona e muita evolução da experiência que desenhamos para acomodar esse tipo de situação.

#2 Criar um modelo de IA é um processo experimental, tenha paciência

Uma outra diferença que precisa estar clara entre construir um produto tradicional vs. construir um produto de AI, é com relação a estimativas. Estimativas em desenvolvimento de software, tipicamente, já não são uma coisa muito fácil. Um time precisa de bastante maturidade e consistência para conseguir fazer estimativas com qualidade. Quando estamos falando de construir um produto de IA isso é ainda pior.

Entenda que para se chegar em um bom resultado com um novo modelo de Inteligência Artificial é normalmente necessário muitas experimentações. Embora você possa ter uma ideia de quais modelos e tecnologias podem funcionar melhor para o seu caso de uso, é difícil determinar o mais adequado sem testar antes. Geralmente, os times vão apostar em alguns modelos, dependendo do tipo do problema, e então vão fazer uma seleção de alguns candidatos mais promissores com base nos testes iniciais. Durante esse processo, o time pode ter que iterar várias vezes, mudando parâmetros, tecnologias e técnicas de treinamento. Por exemplo, os modelos selecionados podem ser treinados em um conjunto de dados mais diverso para melhorar a abrangência ou, dependendo da aplicação, otimizados para um cenário mais específico. 

O ponto importante de entender aqui é que você vai precisar de paciência. Não vai ser tão simples estimar quando vai se ter um novo modelo de AI pronto, mesmo que seja “simplesmente” fazer um prompt para usar com o GPT ou o Gemini, por exemplo, os times vão precisar de tempo para iterar, testar e validar esses modelos. Esse processo todo pode demorar mais do que você imaginava inicialmente para chegar a um resultado de qualidade, e é importante setar essa expectativa.

Então a dica aqui é simples, com zero novidade, quebre a sua solução em partes pequenas, teste e lance o seu modelo gradativamente, deixando eles o mais específicos possível para resolver cada um dos problemas que você precisa resolver. Dessa forma você reduz a complexidade da sua entrega e aumenta as chances de conseguir ter mais assertividade nas suas estimativas e, claro, na qualidade final do seu produto.

#3 Existe muita expectativa irrealista sobre IA

Até o ChatGPT surgir as pessoas, em geral, tinham uma expectativa bem conservadora com relação ao uso de Inteligência Artificial. Como já citei, um uso bem comum de IA era em algoritmos de recomendação. Tenho certeza que você já recebeu uma recomendação em um e-commerce, na Netflix, ou no Spotify, que você olhou pra ela e se perguntou da onde tiraram essa ideia! Enquanto eu escrevo esse post, por exemplo, meu Spotify está me recomendando Ludmilla! Só quem me conhece sabe o tamanho do absurdo que é isso!! =)

Dentro do universo de NLP (Processamento de Linguagem Natural), modelos para classificação do sentimento de uma frase (positivo, negativo ou neutro) eram um outro uso convencional de IA, e as pessoas aceitavam bem isso. Tanto na Birdie, quanto na Stilingue, usávamos muito de modelos de sentimento, extração de temas, nuvens de palavras e etc e em ambos os casos o mercado nos via como um produto de Inteligência Artificial por causa dessas capacidades.

Hoje, no entanto, a expectativa das pessoas com relação a um produto de IA mudou drasticamente. Com a chegada da IA Generativa, muito representada pelo ChatGPT, as pessoas esperam muito mais de um produto de Inteligência Artificial. Elas querem conversar com esse produto, querem ser compreendidas, querem respostas… querem sentir que estão conversando com uma outra pessoa, ou no mínimo com um robô inteligente. E não apenas que estão recebendo informações de um algoritmo. Isso mudou o jogo por completo!

De um lado, essas novas expectativas ainda são um tanto quanto irreais. No limite, no final do dia, o que as LLMs fazem é prever muito bem qual será a próxima palavra de um texto, então soa como uma conversa inteligente, mas elas ainda são muito limitadas do ponto de vista de inteligência bruta. Escrevi sobre isso recentemente em um post no Linkedin, usando como base um tweet do próprio Sam Altman falando que a IA atualmente ainda é muito melhor em parecer ser inteligente, do que de fato ser. Ou seja, muito do que a gente espera que as LLMs sejam capazes de fazer ainda não é realidade, no começo pode até parecer que é, mas quando chega na página 2 a gente vê que ainda não é bem assim. Falta profundidade e consistência, e especialmente em produtos B2B esse tipo de coisa é necessária.

Mas se olharmos com uma outra perspectiva, estamos em um momento único de novas possibilidades. Pense em quando a App Store surgiu, a gente tinha apps ridiculamente inúteis como um que imitava um copo de cerveja, dando um efeito de movimento do líquido no copo quando você virava o celular, ou um outro app que que custava 1000 dólares só pra aparecer escrito “I’m rich” no seu telefone. Se você olhar para esses exemplos do passado e ver o que conseguimos fazer com o nosso celular hoje, pode imaginar o que ainda vem pela frente em termos de uso de IA! À medida que essas tecnologias vão amadurecendo e a gente vai evoluindo o nosso entendimento de como usá-las da melhor forma, infinitas possibilidades vão se abrindo. Se você ainda não está convencido de que IA é o futuro, recomendo dar uma olhada nesse vídeo da NFX o quanto antes!

#4 O perfil do time mudou, hoje você não precisa tanto de uma pessoa especialista em Machine Learning quanto antes

Eu sei que essa afirmação pode ser um tanto quanto polêmica, mas é impossível não falar dessa mudança nos times que trabalham com produtos de IA. A dois anos atrás era inimaginável alguma empresa criar um produto de Inteligência Artificial sem ter especialistas em Machine Learning, pesquisadores de Inteligência Artificial e etc, como descrevi anteriormente no cenário que eu vivi na Stilingue e no começo da Birdie. Mas hoje, depois da popularização das LLMs, isso mudou drasticamente.

A maioria das pessoas que hoje estão criando produtos de IA utilizando LLMs, por exemplo, são pessoas que trabalham com engenharia de software “convencional”, não especialistas em Machine Learning. A parte positiva disso é que construir produtos de Inteligência Artificial está muito mais acessível hoje em dia. Usando essas novas tecnologias de IA Generativa, muito rapidamente um time de desenvolvimento de software consegue colocar de pé algumas novas funcionalidades muito interessantes. E isso abre uma gama imensa de oportunidades para muitas empresas.

Mas, claro, nem tudo são flores. Construir produtos de AI utilizando essas tecnologias de prateleira, como o GPT, Gemini, Claude, etc é só uma parte do problema. Como vou falar mais pra frente nesse post, existe todo um outro universo de coisas que precisa ser feito para garantir a qualidade do dado que você analisa e para manter e evoluir o seus modelos de AI, que não são tão triviais quanto parecem. Como um exemplo simples, dificilmente pessoas que estão focadas em engenharia de software conhecem de MLOps ou mesmo sabem que métricas utilizar para mensurar a qualidade de um modelo de IA. Produtos mais robustos também precisam de um mix de modelos externos e internos para se chegar em um bom resultado e muitas outras complexidades que, em um primeiro momento, podem passar despercebidas.

Na prática, vivenciando várias situações do dia-a-dia na construção de produtos de IA, minha experiência diz que ainda vale muito a pena ter especialistas em AI/ML no seu time. Entendo que você não precisa mais de tantas pessoas especialistas quanto eram necessárias anteriormente, mas certamente ter algumas dessas pessoas no time vai agregar muito e cortar muitos caminhos. Mas o fato é que você não precisa mais dessas pessoas especialistas para começar a criar seus produtos de IA, e isso facilita muito as coisas!

#5 Apostar em interfaces conversacionais ainda é uma incógnita

Outra tendência que o ChatGPT ajudou a popularizar foi a interface conversacional. Virou a experiência padrão de produtos de IA usar um chat para interagir com um bot inteligente. Muita gente defende inclusive que com o tempo os usuários não vão mais ter que aprender como usar uma interface tradicional (com botões, menus e etc) para navegar em um produto. Nessa realidade, o futuro é a linguagem natural, você vai escrever o que você quer e X coisa vai acontecer. Já vimos esse filme com o surgimento das interfaces de voz, como a Alexa, um momento onde tudo parecia precisar ter comando de voz para se “adaptar” ao futuro. 

Eu particularmente sou cético com relação a essas mudanças, o ser humano é preguiçoso no seu DNA, e acredito que as pessoas querem sempre a opção com menor esforço. Interfaces de texto, como o DOS, já foram substituídas por interfaces gráficas, como o Windows, a muitos anos. E por mais que estejamos falando de linguagem natural hoje em dia, eu não acho que vamos reverter essa realidade. Principalmente para atividades repetitivas.

Na prática o que eu aprendi foram duas coisas: 

1. Interface de chat é legal, todo mundo se interessa e quer brincar de fazer perguntas, mas pouquíssimas pessoas sabem escrever um prompt minimamente decente. O resultado é uma resposta geralmente ruim, que não entrega o valor esperado. As pessoas podem aprender a escrever prompts melhores ou a tecnologia pode evoluir ainda mais para interpretar prompts ruins? Pode ser que aconteça sim! Mas a realidade é que o Google foi lançado em 1998 e até hoje tem gente que não aprendeu a fazer uma boa pesquisa!

2. Chat é legal porque dá liberdade para os usuários perguntarem o que eles quiserem, interagirem com o produto da forma que eles acharem melhor. Nesse sentido, é uma ótima ferramenta de aprendizado para quem está fazendo o produto. Com o tempo você vai identificando padrões de interação, tasks mais solicitadas, perguntas frequentes e etc. Na minha visão o ideal é ir trazendo essas experiências para a interface do produto à medida que esses aprendizados vão se concretizando. Se as pessoas que estão usando o seu produto sempre pedem pro Chat fazer um resumo do resultado de uma determinada pesquisa, por que não colocar um botão de “Gerar resumo”? É muito mais fácil do que ter aprender onde digitar o prompt, digitar o pedido em si e ler o resultado muitas vezes em uma experiência genérica, que não é ideal pra isso. 

#6 Você precisa desenhar a sua experiência com um humano no loop 

Por todos os pontos que citei anteriormente, ainda é irreal acreditar que em atividades minimamente mais complexas a IA vai resolver o problema de forma independente. Na grande maioria dos casos você vai precisar projetar a experiência do seu produto para manter uma pessoa monitorando e revisando o processo, para garantir a qualidade final do resultado. Seja essa pessoa as próprias pessoas usuárias do seu produto ou alguém internamente fazendo isso de forma transparente.

Como já falei aqui, a Inteligência Artificial vai errar. Em alguns casos vai alucinar e trazer resultados totalmente incoerentes, mesmo que na maioria das vezes sejam erros bem menores, trazendo sugestões erradas ou repetidas, por exemplo. Mas o fato é que alguém vai precisar curar isso e ajudar a própria IA a evoluir, dando feedback sobre o que ela produz. Então, desde o início, pense em uma experiência que permita a pessoa usuária dar inputs com relação a qualidade da IA, corrigir o que o que ela faz e descartar o que não fizer sentido. 

Na minha experiência é sempre mais fácil pensar no output da IA como uma sugestão, não como o resultado final do processo em si. Em termos de produto, isso pode ser apresentado na forma de recomendações, insight ou algo nessa linha. Por exemplo, em um produto de dados como o Mixpanel ou o Amplitude, você poderia ter uma IA sugerindo a criação de alguns gráficos, por que a IA detectou alguma mudança consistente no padrão de engajamento dos usuários com determinada feature. Perceba que essa sugestão é diferente de já sair criando um novo gráfico no dashboard do produto de fato. Caso esse novo gráfico não faça sentido pra pessoa que é responsável por esse dashboard, ela deveria poder facilmente descartar essa sugestão. 

O principal ponto aqui é que precisamos controlar as expectativas sobre o que a IA é realmente capaz de fazer. Faz bastante diferença se você comunica que a IA vai ser capaz de sugerir a criação de novos gráficos ao invés de, por exemplo, dizer que ela vai analisar o comportamento da sua base de usuários e automaticamente já vai realizar análises, criar gráficos, propor planos de ação e etc. Porque, reforçando, a sua IA vai errar e você precisa gerenciar essa expectativa de acordo.

Outra forma de contornar esse tipo de problema é, ao invés de prometer que vai entregar pronto algum material, como por exemplo gerar um PRD usando informações contidas em uma pesquisa qualitativa, você pode gerar um rascunho desse PRD, permitindo que as pessoas que estiverem usando o produto editem e reformulem o documento do jeito que acharem melhor. Dessa forma a própria pessoa usuária pode corrigir alguns erros, alterar o formato, adicionar novas informações, etc, antes de enviar o documento para o restante do time. Mas principalmente você vai ter um humano assumindo responsabilidade junto com a AI sobre a qualidade do material gerado, e não, novamente, uma promessa de que tudo será feito automaticamente e de forma perfeita. 

Por esse cenário todo, é que termos como “Copilot” tem se popularizado tanto nesses novos produtos de IA. Comunicando dessa forma é mais fácil calibrar a expectativa de que você tem um copiloto, alguém que está ali pra ajudar a pessoa que de fato está pilotando o produto a fazer o seu trabalho de forma melhor e mais fácil! Mas perceba que é um copiloto, não um piloto automático!

#7 Não é porque algo é possível de ser feito que a gente deveria fazer

Quando a gente tem um time que é muito orientado por engenharia eu sempre brinco que precisamos tomar cuidado pra não criar uma feira de ciências. Feira de ciências, assim como desfiles de moda, são lugares onde você vê muita coisa conceitualmente muito legal, normalmente chamativa, mas que ainda precisa de muita lapidação para ter aplicação prática. E isso tem tudo a ver com o momento que estamos vivendo.

Com as novas tecnologias de Inteligência Artificial, muita coisa que antes não era possível de ser feita, agora é! Algumas dessas coisas vão gerar muito valor para quem vai usar o produto, e de fato elas vão ter capacidade de revolucionar alguns segmentos de mercado. Mas muitas outras coisas que serão construídas com IA vão ser legais em um primeiro momento, vão mostrar o potencial da tecnologia, mas não vão ter muita aplicação prática no momento seguinte. 

Minha mensagem principal aqui é: tenha muito claro qual o objetivo por trás do que você está construindo. Uma vez que você conheça esse objetivo (assumindo que isso quer dizer que ele vai entregar valor para alguém), você pode explorar como as novas tecnologias de Inteligência Artificial podem de fato te ajudar a atingir esse objetivo de uma forma muito melhor. E não o contrário. Afinal, estamos fazendo produto! Como qualquer outra coisa que fazemos a gente deveria partir de um objetivo, e não simplesmente de uma ideia legal que alguém teve.

Eu lembro que quando eu trabalhava na Stilingue, no início, a gente tinha os times de produto e, de forma apartada, um time de IA, que trabalhava sob demanda dos times de produto e/ou fazendo pesquisas baseadas em novas tecnologias, papers e etc. O resultado disso era uma desconexão grande entre o que era produzido por esse time de IA e o que de fato o nosso cliente usava no produto, a gente gerava muito estoque de novas features! Algumas delas eram de fato úteis, mas os times de produto não estavam no momento de incorporá-las no produto, outras eram legais, mas não tão úteis assim. O fato é que existia muito desperdício e até uma desmotivação das pessoas que trabalhavam nesse time de IA, porque muitas coisas que elas faziam não eram utilizadas.

Por mais óbvio que possa parecer, a melhor forma de garantir que o resultado de iniciativas de pesquisa utilizando Inteligência Artificial de fato vai gerar valor para empresa e para os clientes é orientando essas iniciativas a objetivos e dores reais. Idealmente essas pessoas que estão trabalhando com essas iniciativas inovadoras devem estar dentro dos times, e não isoladas dentro da empresa. Dessa forma elas vão saber quais são os reais problemas que precisam ser resolvidos e podem usar os conhecimentos delas para sugerir novas possibilidades de solução, como qualquer time multidisciplinar funciona. Garantindo assim que a gente entregue algo inovador e que também entregue valor.

#8 Seu produto precisa de um workflow que gere valor além da IA

Certamente, em maior ou menor nível, em pouco tempo praticamente todos os produtos que conhecemos vão ter alguma funcionalidade utilizando IA. E isso faz todo sentido dado o momento em que estamos vivendo. Como já discutimos no item #7, o cuidado que precisamos ter é não adicionar features de IA simplesmente por que é possível, mas sim porque ela vai de fato entregar algum valor para nossos usuários.

Mas, especialmente para novos produtos, vale um olhar ainda mais atento sobre esse ponto. Na prática ainda temos muito o que aprender sobre como explorar da melhor forma essas novas tecnologias que estão surgindo. As próprias tecnologias estão amadurecendo e mudando a todo instante, o que torna um desafio à parte acompanhar tudo isso e se adaptar a essas mudanças, enquanto você tenta deixar os atuais serviços estáveis. No fim do dia, como tudo, vamos errar muito mais que acertar e vai precisar de um tempo até que de fato aquela feature bacana que você está lançando com IA realmente funcione bem e entregue todo aquele valor que foi planejado.

Tendo esse cenário claro, o que exatamente significa que vamos precisar de um tempo para lapidar essas novas features de Inteligência Artificial? Significa que o seu produto não pode depender exclusivamente dessas novas funcionalidades para sobreviver e entregar valor para o seu cliente! Porque se depender só disso, você corre o risco de ficar um longo período de tempo sem gerar um valor relevante para os seus clientes e isso pode significar a morte do seu produto e até da sua empresa.

Um dos maiores aprendizados que eu tive no passado recente é que a gente precisa conter a empolgação e garantir que o produto que estamos lançando consiga entregar valor independente de IA. Que esse produto tenha um workflow que mesmo sem usar nenhuma dessas features de IA Generativa, LLMs e etc, nós estejamos resolvendo um problema real para as pessoas usuárias. Fazendo dessa forma, a gente garante que vamos ter tempo para lapidar as features que de fato usam Inteligência Artificial e que essas features realmente possam se tornar grandes diferenciais do nosso produto no futuro, gerando valor interna e externamente da forma que esperamos.

Um exemplo prático disso é o fluxo de geração de oportunidades da Birdie. Atualmente, um dos principais valores que entregamos para os clientes da Birdie é olhar para uma imensidão de dados qualitativos e extrair as principais oportunidades encontradas nestes dados. O objetivo final é ajudar os usuários a aumentar a satisfação dos seus atuais clientes e/ou reduzir os chamados de suporte. No início, tudo que os nossos usuários podiam fazer era analisar essa lista de oportunidades para usar como input para evoluir o seu produto. Mas como falei, isso gerava algum nível de frustração, porque várias dessas sugestões não faziam tanto sentido, algumas eram irrelevantes, outras eram muito óbvias, outras eram repetidas e por aí vai. 

A gente começou a de fato conseguir entregar valor com esse fluxo de geração de oportunidades quando fizemos duas coisas: 

1. Permitimos que as pessoas criassem manualmente suas oportunidades, inserindo coisas que elas já sabiam/queriam validar ou fazendo explorações manuais na ferramenta com buscas e segmentações, e então criando oportunidades baseadas no que elas mesmas encontravam. Ou seja, aqui o nosso produto já entregava valor, mesmo não tendo absolutamente nada de IA envolvido no processo. 

2. As oportunidades geradas automaticamente pela Inteligência Artificial passaram a serem exibidas como sugestões no produto, reforçando o que falei no item #6. Dessa forma, cada pessoa usuária podia aceitar, rejeitar ou modificar essa oportunidade, para de fato ficar com uma lista apenas com coisas que são relevantes para a evolução do produto delas. 

Essas duas mudanças são exemplos de algumas alterações simples, mas que fizeram toda a diferença pra gente, porque passamos a ser um produto que oferece um workflow de gestão de oportunidades, não apenas uma ferramenta de insights.

#9 A sua vida depende da qualidade do seu seu dado

Um produto de IA é fundamentalmente um produto de dados. E como qualquer produto de dados, de forma não surpreendente, a qualidade do valor que você gera está totalmente conectada à qualidade do dado que você tem para analisar (o famoso garbage in = garbage out). A sua vida pode até não depender da qualidade do dado que você tem, mas certamente os modelos de AI que você vai criar ou usar, vão depender e muito! Se o seu dado for ruim, o resultado vai ser igualmente ruim, se o dado for bom, o resultado tem uma boa chance de ser muito bom também!

Nesse cenário, uma coisa que é bem importante ter em mente, é que, o player que tiver o melhor dado, possivelmente vai ser quem vai vencer qualquer concorrência. Ou seja, antes de pensar em como explorar todas essas novas possibilidades que a IA está habilitando, pense em como você pode coletar, armazenar e organizar os seus dados da melhor forma possível. Principalmente coletar esses dados é um grande desafio, porque exceto se você estiver usando crawling de dados públicos (que vem com outros problemas), você precisa convencer o seu usuário a integrar os dados privados dele com você e/ou convencer essas pessoas a gerarem os seus dados dentro do seu produto, possivelmente ainda sem um grande valor entregue através de IA de fato.

Por causa desse tipo de situação é que os produtos que já existem atualmente tem uma certa vantagem nessa corrida com os novos players que estão surgindo, porque esses produtos já têm acesso a uma gama muito grande de informações. É claro que as novas tecnologias de IA estão mudando a forma como fazemos os nossos produtos, da mesma forma que a gente ouvia falar em Mobile-First, vamos cada vez mais ouvir falar em AI-First, para se referir a produtos que são pensados desde o início para explorar da melhor forma a Inteligência Artificial. Mas dessa vez é um pouco diferente, porque se antes uma empresa precisava reescrever toda sua aplicação já existente para Web, para uma plataforma Mobile, e isso abriu uma oportunidade para muitas soluções novas nascerem já prontas para dispositivos móveis, agora essa mudança tem um contrapeso importante que são justamente os dados. 

Pensa comigo, imagina que você queira criar um CRM que vai usar IA pra ter uma interação totalmente diferente com as pessoas de vendas. Possibilitando uma interface conversacional, análises, alertas, ajudando a criar scripts de vendas baseado em discursos que funcionaram e não funcionaram anteriormente, etc. Certamente, começar um produto do zero com esse tipo de proposta vai facilitar muito a criação de uma experiência e de uma arquitetura que facilite a aplicação dessas novas tecnologias de IA. Mas, o problema é que você precisa que as pessoas parem de usar os atuais players e migrem a operação delas pro seu produto, para só então você conseguir entregar valor. Valor esse que possivelmente vai precisar de lapidação, aprendizado e tempo para de fato ser significativo. 

Do outro lado, você tem as empresas que atualmente já estão servindo esses times de vendas, que já tem um produto de CRM funcional e com valor sendo gerado e que, principalmente, já tem muito dado existente para ser trabalhado. Esses players, pelas informações que eles já possuem, vão poder aprender muito mais rápido como usar esses dados para gerar valor para os atuais clientes usando IA. E, por sinal, isso tem se mostrado uma excelente forma de aumentar receita, fazendo cross-sell ou upgrades para essa base existente de clientes, para produtos ou planos que possibilitem o uso de Inteligência Artificial. Isso é uma vantagem enorme para esses atuais players.

Se você quer entrar em um mercado com essas características o seu desafio é muito claro, você precisa conseguir ingerir dados de qualidade. Tanto para treinar o seu modelo, quanto para gerar valor significativo para quem usa o seu produto. Esse é o primeiro grande desafio que você vai precisar resolver, só para conseguir entrar no jogo. Uma das estratégias que essas novas empresas de IA têm usado muito é usar de um modelo freemium. Tentando reduzir ao máximo a barreira de adoção, através de alguma funcionalidade que seja simples, mas atrativa, para fazer um grande número de pessoas e/ou empresas trazerem seus dados para esses novos produtos, para daí então encontrar formas de gerar valor de forma recorrente. Se desruptar uma categoria de produto existente é o desafio que você está vivendo, eu recomendo dar uma olhada nesse post recente que eu fiz no Linkedin sobre o assunto.

#10 Crie um processo para mensurar a qualidade do seu modelo o quanto antes

Como vimos no item anterior, a qualidade do seu modelo de IA, e consequentemente do seu produto, vai depender muito da qualidade do dado que você está ingerindo e tratando. Eu não vou entrar em detalhes aqui porque esse já é um assunto bem batido do ponto de vista de Machine Learning e especialmente NLP. O importante é: desde o início se preocupe bastante com as formas que você vai utilizar para treinar o seu modelo e validar o resultado dele.

Da forma mais simples possível, para treinar o seu modelo você precisa de um “gabarito”. Vamos dizer que você esteja criando um modelo de IA para identificar se um determinado objeto é um cachorro, um pão de forma ou um porco. A primeira coisa que você precisa fazer é ter um conjunto de dados (nesse caso fotos desses 3 tipos de objetos), para passar pelo seu modelo e analisar o resultado. Mas, para saber se o modelo acertou ou errou você precisa de um conjunto verdade, ou seja, do seu gabarito.

Como regra genérica a gente normalmente usa 80% dos dados que temos para treinar o modelo e 20% para testá-lo. Para esses 20% de teste, de alguma forma, você precisa anotar esses dados, nesse caso pegar imagem por imagem e dizer se ela é um cachorro, um pão de forma ou um porco. Esse processo pode ser feito de várias formas diferentes, mas o recomendável é que pelo menos no início seja uma pessoa quem faça esse trabalho. Na Stilingue por exemplo, a gente usava o nosso time de Machine Teachers pra fazer o trabalho de anotação e qualidade. Na Birdie a gente já testou várias formas diferentes, mas em algum nível nunca escapamos de ter algumas pessoas anotando manualmente esse conjunto verdade.

Uma possibilidade que tem surgido mais recentemente, que testamos com sucesso na Birdie, foi usar modelos mais caros e robustos, como o GPT4, para treinar modelos mais baratos e simples, como o GPT3.5. Usando essa estratégia a gente conseguiu manter um bom resultado, com um custo mais baixo de operação e reduzindo bastante o esforço manual de anotação que tínhamos anteriormente. Mas, novamente, seja qual for a estratégia que você utilize e quais ferramentas você escolha para fazer esse processo de anotação, é fundamental que você invista tempo nessa atividade para garantir a qualidade do seu modelo de AI. Além disso, você precisa pensar em uma forma de manter esse processo rodando continuamente, porque você sempre vai precisar mensurar a qualidade do seu modelo e evoluí-lo.

#11 Valide seu produto com dados reais, mock é sempre lindo

Como discutimos no item #9, tendo em vista que produtos de Inteligência Artificial são também normalmente produtos de dados, precisamos ter isso em mente também na hora de validar nosso produto. Em outras palavras, se você quer validar a sua proposta de valor, você precisa validar a qualidade da informação que sai do seu produto, ou seja, o resultado do seu modelo de IA. 

Novamente, vamos voltar ao básico da gestão de produtos aqui, mas sempre que estamos validando algo a gente precisa ter claro qual risco estamos querendo mitigar, os 4 riscos do Marty Cagan são um bom framework para identificar isso. Na prática, na grande maioria das vezes as pessoas tentam validar 2 riscos: usabilidade e execução, ou seja, se eu consigo usar IA Generativa, LLMs e etc para executar a ideia que tivemos em termos de software e se, uma vez que isso esteja construído, as pessoas conseguem usar o produto. Esses sem dúvidas são riscos válidos, mas tem outros dois riscos que são tão ou mais importantes, principalmente em um produto em estágio inicial: 1) Será que as pessoas vão ver valor no que estou construindo? 2) O negócio para de pé em termos de custo, receita, modelo e etc?

Esses dois últimos riscos, risco de valor e de negócio, não vão ser validados com mockups e protótipos (se quiser saber mais sobre isso tenho uma talk sobre esse assunto aqui)! Acho que o risco de negócio é meio óbvio pra todo mundo, mas o risco de valor não é tão claro quanto deveria ser. Eu mesmo já passei por essa curva de aprendizado, mas parece intuitivo apresentar para alguns clientes um protótipo do produto funcionando e fazer uma série de questionamentos sobre o valor que eles percebem, se as informações apresentadas são relevantes, se algo está faltando e etc. 

Às vezes até caímos na ilusão de ir junto com a empolgação de quem estamos entrevistando, que estão vendo uma série de informações legais, e ficamos escutando impressões do tipo “isso facilitaria muito a minha vida”, “eu demoro dias pra fazer isso manualmente”,  “é incrível ter isso pronto de forma automática” e etc. O problema desse tipo de coisa, é que em um teste com um protótipo a gente tem dado mockado, não é dado real! E isso faz muita diferença quando você tem um produto de dados! Onde essencialmente, o que você precisa validar são os dados e não a experiência de uso do produto em si.

Então a minha dica pra você é, se você está criando um produto de dados com IA, esqueça em um primeiro momento os protótipos padrões, deixe para mitigar o risco de usabilidade em um segundo momento. Primeiro mitigue o risco de valor desse novo produto ou nova feature, pode ser a interface mais simples que você imaginar, a gente usou o Google Sheets e o Notion na Birdie, por exemplo. Uma vez que você tenha validado a qualidade da informação que você gera, aí sim vai ser hora de validar o workflow e a experiência de chegar até esse resultado. Mas nesse caso é o tipo de validação que já sabemos fazer há muitos anos e possivelmente você vai tirar de letra! 

#12 Não se iluda com os números de adoção do seu produto

Como já discutimos aqui nos itens anteriores, atualmente existe muita curiosidade por parte das pessoas em geral sobre Inteligência Artificial. Essa característica faz com que muitos usuários queiram testar novos produtos de IA apenas para conhecer as funcionalidades do produto e ver do que ele é capaz. Somado a isso, como conversamos no item #9, uma estratégia muito utilizada por algumas empresas para conseguir atrair usuários e fazer com que esses usuários tragam ou produzam dados para o produto é oferecendo uma versão gratuita desse produto, com baixa barreira de entrada. 

Com todo esse cenário que eu acabei de descrever, não é difícil imaginar que o seu produto pode gerar um interesse muito grande em um primeiro momento. Fazendo com que muitos usuários comecem a usar a sua solução, gerando uma alta taxa de “adoção”. Mas aqui vai uma dica: não se iluda com essa eventual alta taxa de uso inicial, porque pode ser que você esteja conseguindo gerar curiosidade nesses usuários e nada mais além disso.

Nesse contexto eu enfrentei três problemas: 

1. Algumas pessoas usuárias nem tinham de fato a dor que estávamos tentando resolver, essas pessoas realmente só tinham a curiosidade de testar um novo produto de IA e ver do que ele era capaz. 

2. Mesmo quando existia uma dor real, em muitos casos o produto ainda não conseguia resolver essa dor de uma forma eficiente. Por ser um produto em estágio inicial, algumas coisas simplesmente não funcionavam como deveriam funcionar. O que gerava uma baixa retenção. 

3. No meu caso específico, ter acesso ao dado privado das empresas que eram nossas clientes era muito importante. Como nos primeiros usos normalmente ainda não tínhamos integrações, apenas importávamos dados estáticos, isso queria dizer que toda vez que uma pessoa entrava no produto ela via o mesmo resultado… e ela simplesmente parava de voltar.

Eu trouxe esse assunto aqui para, como falei já no título, você não se iludir com uma eventual taxa de adoção alta, porque se você não conseguir gerar valor recorrente, você obviamente não vai conseguir reter esses usuários. Além disso, mesmo os usuários que começaram a usar o seu produto podem não ser o seu ICP ideal, e sim apenas curiosos! Então cuide com os feedbacks desse último perfil pessoa. Eu sei que esse cenário não é tão novo assim, qualquer novo produto que tenha um modelo freemium vai passar por algo semelhante. Mas o que eu queria reforçar é que se tratando de um produto de IA esse cenário tem agravantes, dado a curiosidade das pessoas nessa tecnologia e o tempo que o seu modelo de IA precisa para de fato amadurecer. 

Do outro lado, tome cuidado para não jogar fora o bebê junto com a água suja! Principalmente em um produto em estágio inicial é difícil entregar valor com recorrência  desde o início, você vai errar, seu produto vai precisar de lapidações, como eu disse, seu modelo de IA vai precisar evoluir e etc. Então é provável que você de fato perca muito dos usuários das suas primeiras cohorts… e tá tudo bem! O que você precisa é aprender com essas falhas e continuar evoluindo! Eu sei que não é fácil, mas entender se você está insistindo em um produto essencialmente falho, ou se você precisa persistir mais nesse produto para evoluí-lo e assim chegar em algo que entregue valor, faz parte do nosso papel como pessoas de produto e empreendedoras.

#13 Usar IA pode ser muito caro a ponto de quebrar a lógica de escalabilidade de uma startup

Nas palavras do Steve Blank “Sua startup é essencialmente uma organização construída para buscar um modelo de negócios repetível e escalável.”, isso quer dizer que, entre outras coisas, a lógica básica de uma startup se sustenta no fato de que você vai conseguir escalar o seu negócio, sem escalar os custos na mesma proporção. Quando a gente fala de custos de infraestrutura de software, em sua grande maioria, os custos associados a ela não escalam na mesma proporção que a sua base de clientes cresce. O principal ofensor para a escalabilidade costuma ser pessoas, e esse é um dos motivos que métricas como receita por funcionário (revenue per employee) têm sido cada vez mais utilizadas hoje em dia.   

Eu trago esse assunto aqui porque, dependendo de como você for utilizar Inteligência Artificial no seu produto, a escalabilidade pode ser um problema. Em um cenário onde você apenas habilita uma interface conversacional via Chat, para que as pessoas que usam o seu produto possam fazer perguntas para a IA, pra que ela faça análises, resumos e etc a escalabilidade dificilmente vai ser um problema, dado que o gasto com esse tipo de uso de IA não vai ser significativo perto da sua receita.

Agora, se no outro extremo, por qualquer motivo você precise passar todo e qualquer dado que entra no seu produto pela IA, para ela resumir, classificar ou analisar esse dados por exemplo, isso vai fazer com que o seus custos com os modelos de IA sejam muito mais altos e que vai existir uma correlação grande entre o crescimento da sua base de clientes e dos custos com infraestrutura. Se você estiver utilizando um modelo freemium isso pode ser um grande problema! E mesmo que você não esteja, isso significa que você vai ter que ter um pricing point mais alto, pra conseguir ter uma boa margem de lucro. E esse pricing point mais alto pode ser proibitivo, tanto por dificultar o processo de aquisição do seu produto, quanto por fazer o seu cliente questionar se o produto de fato da ROI. 

Em resumo, olhe com carinho para o seu modelo de negócio e veja se ele para de pé. Fazer um produto de Inteligência Artificial requer tempo para ajustar corretamente os modelos e para conseguir ingerir uma quantidade mínima de dados que possa alimentar esses modelos de IA. Todo esse processo não é tão barato quanto parece, e dependendo do uso que você der para a Inteligência Artificial no seu produto o custo pode ser proibitivo, entrando em um deadlock onde o seus custos são altos porque o seu modelo de IA é ineficiente, mas você não consegue melhorar os modelos porque tem poucos dados/clientes para usar de insumo para treinar eles. É claro que temos que levar em consideração que os custos com os modelos de AI as a service, como a OpenAI, vão diminuir com o tempo, a exemplo do que vimos acontecer com os serviços de computação em nuvem. Mas, ao mesmo tempo, novos e melhores modelos vão ser lançados e se você sempre quiser ficar usando essas últimas versões, com certeza você vai ter que pagar por isso!

Esse é só o começo!

Selecionei aqui alguns dos aprendizados mais relevantes que tive nesses quase 3 anos trabalhando com Inteligência Artificial e espero que de alguma forma esse conhecimento seja útil pra você. Mas certamente o principal aprendizado que eu tive nesse período, principalmente do final de 2022 para cá, é que IA é um caminho sem volta. Em maior ou menor nível tudo que temos hoje em termos de produtos de digitais vão ser impactados com o uso dessas novas tecnologias de Inteligência Artificial. A IA Generativa tem evoluído absurdamente nesses últimos meses, as LLMs estão cada vez mais capazes, novos modelos multimodais estão nascendo e a todo instante vemos novas possibilidades surgindo que vão habilitar casos de uso inimagináveis até o momento.

Se você ainda não começou a estudar sobre IA e/ou pensar em como aplicar essas tecnologias ao seu produto, está certamente perdendo tempo e possivelmente excelentes oportunidades. Estamos vivendo nos últimos anos um momento ímpar, onde tudo tem chance de ficar obsoleto da noite pro dia. E tanto nós como profissionais, quanto as empresas que temos ou trabalhos não escapam dessa lógica.

Caso esse assunto tenha te interessado e você queira se aprofundar mais em como usar Inteligência Artificial, LLMs, GenAI e etc, para criar produtos e como adaptar o seu dia-a-dia como Product Manager para essa nova realidade, fica aqui o convite de participar do meu novo curso sobre como criar produtos com GenAI! O curso será lançado em breve, mas a lista de espera para ter acesso ao lote promocional já está aberta, é só se cadastrar aqui!

Eu acho interessante como existem algumas dúvidas que por mais que o tempo passe, vira e mexe, elas acabam retornando. Seja porque, dado os meus aprendizados mais recentes, eu mesmo me questiono se o que acredito estar correto realmente está correto. Porque o contexto muda ou porque me vejo discutindo as mesmas dúvidas mas com pessoas diferentes, que eventualmente trazem novas perspectivas para a mesa. Uma dessas dúvidas é sobre a autonomia que Product Managers têm para tomar decisões. 

Anos atrás (parece que foi ontem, mas foi em 2016!) eu escrevi um artigo onde procurei definir o que é e o que faz uma boa pessoa de Gestão de Produtos (recomendo fortemente a leitura antes de seguir adiante neste post), inevitavelmente uma das definições que eu apresentei é a famosa comparação do Ben Horowitz entre PMs e CEOs. Além de outras coisas, também falei da importância do papel de gerentes de produto na definição da visão e estratégia de um produto e no momento de priorizar o que será feito. Trazendo as informações dessa forma não é difícil chegar na conclusão de que sim, Product Managers deveriam ter autonomia para tomar decisões de produto. Mas será mesmo?

Disciplina vs. Posição

A primeira coisa que eu gostaria de trazer pra mesa para alimentar essa discussão é um conceito que tenho tentando aplicar pra muita coisa na minha vida do último ano pra cá. Parece algo simples mas faz bastante diferença na hora de entender uma disfunção organizacional, que é separar a disciplina de uma determinada posição, da posição em si. Por exemplo, se a sua empresa está tendo problemas na hora de lançar um produto isso é um problema da disciplina de Product Marketing, que pode ser responsabilidade de Product Marketing Managers ou de qualquer outra pessoa que execute esta disciplina. 

Entender essa divisão de disciplina vs. posição é importante porque Product Management é uma disciplina muito recente na maioria das organizações. Muitas delas ainda não sabem ao certo como executar esta disciplina e tão pouco tem dentro de casa pessoas com experiência no assunto. O resultado disso é que a disciplina de Gestão de Produtos acaba sendo executada por uma série de pessoas e não necessariamente por uma pessoa de Gestão de Produtos em si. Por exemplo, eu posso ter a disciplina de PM sendo executada por Product Owners em parceria com Tech Leads e com a influência direta de um/uma CEO. Nesse cenário, de quem é a responsabilidade da tomada de decisão? Possivelmente ela é dividida entre todas essas pessoas… e inevitavelmente a opinião do/da CEO vai ter um peso diferente no caso de um impasse.

Minha provocação aqui é que ter a posição de Product Manager não garante que essa pessoa é a única responsável pela disciplina de Gestão de Produtos. Essa responsabilidade pode ser compartilhada entre várias posições diferentes, seja por uma escolha consciente ou inconsciente. Dessa forma, em caso de responsabilidade distribuída, é bem natural que o processo de tomada de decisão também seja distribuído, muitas vezes representado por um comitê.

Decisões por Comitê

Pelo contexto que eu trouxe no item anterior, no caso de não se ter claro quem é a pessoa que lidera a Disciplina de Gestão de Produtos e/ou da empresa ainda não ter confiança suficiente nessa pessoa, é bem comum existir algo como um Comitê de Produto, seja formal ou informalmente. Esse Comitê pode ter várias formas, mas normalmente é formado por representantes dos times de Engenharia, Gestão de Produtos, Design e dos times de Negócio (Vendas, Marketing, etc, muitas vezes incluindo o/a CEO). 

Comitês, neste formato que descrevi, são muito valiosos, no sentido de trazer muitas perspectivas diferentes pra mesa. Um trabalho que, por sinal, é da disciplina de Gestão de Produtos. O problema desse tipo de estrutura, na minha opinião, reside no objetivo desse Comitê. 

É importante a gente diferenciar Opinião de Decisão. Quando um Comitê é formado para dar opinião sobre determinado assunto, trazer visões diferentes pra discussão, questionar o direcionamento atual e etc, isso tende a ter muito valor. Mas quando o Comitê é formado para tomar decisões, isso normalmente gera inúmeros problemas.

Na minha visão, tudo e qualquer coisa dentro de uma organização deveria ter uma pessoa que é claramente dona dessa “coisa”, seja um projeto, uma área ou uma decisão. Quando essa dona não é claramente definida, pelo menos três coisas acontecem: 1) O processo de decisão se torna lento, dado que é preciso alinhar muita gente para uma decisão ser tomada; 2) Existe uma tendência de ninguém se sentir realmente responsável por essa decisão, o que dificulta a geração de aprendizado em caso de uma decisão ruim ser tomada e dificulta também a mudança dessa própria decisão caso necessário; 3) Se cria uma sensação de que consenso ou democracia (voto da maioria) é a melhor forma de tomada de decisão, e normalmente isso é uma forma bem pouco eficiente e eficaz de se fazer esse processo.  

Experiência e Liderança

Nesse momento, depois de entender os dois tópicos anteriores, acredito que já tenha ficado claro a importância de se ter uma organização forte de Gestão de Produtos, principalmente de garantir que a liderança e gestão desse time, e dessa disciplina, seja feita por uma pessoa capacitada e com experiência no assunto. Para se aprofundar nesse tema eu recomendo o meu Curso de Product Leadership, onde compartilho muito dos meus aprendizados nesse tópico de liderança e gestão de times de produtos.

Por mais óbvio que seja, eu acho que é importante dizer que Gestão de Produtos é uma posição de bastante responsabilidade. Diferente de outras posições dentro de uma organização, a posição de PM, por mais júnior que seja, já é uma posição de liderança. Como PM você precisa ser capaz de definir uma visão para o seu produto (ou parte dele), uma estratégia para esse produto, escutar e trazer pra mesa várias perspectivas diferentes, inspirar as pessoas, incentivar a colaboração, ter habilidade para negociar decisões, resolver conflitos e por aí vai.

Quando você cria um time de Gestão de Produtos onde muitas pessoas, incluindo muitas vezes a própria liderança, não conseguem executar o papel de PM com excelência, inevitavelmente muitas disfunções na disciplina de Gestão de Produtos vão acontecer. Normalmente, disfunções associadas a ver a posição de PM como algo mais operacional, na linha de um PO ou Gerente de Projeto, por exemplo. Eventualmente algumas dessas disfunções vão se tornar parte da cultura da empresa, e vai ser difícil modificar isso no curto prazo. Como reflexo desse fato, possivelmente vai existir um desafio extra na hora de contratar e reter boas pessoas de Produto.

Apesar desse desafio, ou para evitar ele, é importante entender que ter um time forte de Gestão de Produtos é fundamental para que toda a máquina de produto funcione de uma forma ideal e com isso alcance os resultados que certamente são esperados pelo time executivo dessa empresa. Por um time forte de gestão de produtos eu me refiro a um time que mescle pessoas com experiência na disciplina de PM, experiência no mercado e talentos para serem desenvolvidos. Faço questão de reforçar isso porque é comum algumas pessoas interpretarem “time forte” como “time experiente”, e apesar de experiência ser importante, não é só disso que estou falando. 

Liderando pelo Contexto

Um outro reflexo da maturidade de um time de produto é quando as pessoas entendem que quando estamos falando de liderança no contexto de Gestão de Produtos não estamos falando de uma liderança autoritária. PM não deveria dar “carteirada” na hora de liderar um time porque, por definição, PM não gerencia pessoas, gerencia o produto. O problema é que o produto é feito por pessoas, então como garantir que esse produto está indo na direção adequada? A melhor forma de fazer isso é influenciar as pessoas, dentro e fora do time, através do contexto.

A partir do momento que você, como PM, tem claro o objetivo no qual você está focando, entende os problemas e oportunidades que estão contidas nesse objetivo (árvore de oportunidade é uma ótima ferramenta para isso) e explora o seu cenário da perspectiva de negócio e do seu cliente, você é capaz de interpretar essas informações e comunicar a sua visão desse contexto para o seu time. Dependendo da forma como você comunica este contexto (o “filtro” da realidade que você faz de acordo com a sua perspectiva) você vai influenciar diretamente o seu time, por exemplo, dando mais relevância para um problema em detrimento do outro. 

Sim, a linha entre influência e manipulação é tênue (haja vista toda a polêmica em cima da mídia e das redes sociais), mas é através desse filtro da realidade, da comunicação do contexto, que você consegue influenciar as pessoas e direcionar os esforços e atenção de todos para o lugar onde você acredita que o seu produto deveria caminhar. Esse é um dos motivos pelos quais se fala tanto da importância de técnicas de Storytelling para PMs, se quiser saber mais sobre esse assunto você pode escutar o Episódio 17 do Product Backstage que gravei com o Raphael Farinazzo.

Vale reforçar aqui que é justamente essa capacidade de “filtrar” a realidade, ou seja, como interpretar o contexto, compreender e quebrar problemas, encontrar oportunidades, definir o que é mais ou menos relevante e etc, que é um dos grandes valores que Product Managers podem trazer para um time de produto. É por esse motivo que quando eu estou selecionando alguém para trabalhar comigo eu não me importo muito com as técnicas que essa pessoa conhece, os lugares pelos quais ela já passou, anos de experiência e etc. Mas me importo bastante com a forma como essa pessoa pensa, como ela se comunica e que experiências (no sentido mais amplo) e olhar de mundo ela vai poder trazer de diferente para o time.

Incentivando a Colaboração

Uma vez que você tenha conseguido contextualizar o time sobre o objetivo que vocês precisam alcançar e tudo que cerca isso, é importante que você incentive todas as pessoas do time a colaborarem com o processo de produto de ponta a ponta, da concepção ao lançamento. Essa é hora em que eu gosto de usar a analogia que escutei pela primeira vez do Andrew Chen, de que você deveria ser menos um Product Manager e mais um Product Editor. 

Editar ou curar um produto nesse contexto significa tirar a responsabilidade de você, como Product Manager, de sempre precisar ter as melhores ideias, ou que você é a pessoa que precisa identificar todos problemas, todos os riscos, todos os detalhes da solução que vocês estão criando. Para quem está liderando Produto é libertador poder dividir toda essa responsabilidade com todo o time. E para o time é normalmente muito mais motivante poder participar do processo de priorização, entendimento e concepção do que será feito. Se você quiser saber mais sobre isso vale ouvir o Episódio 14 do Product Backstage onde eu entrevistei o Rafael Dahis.

Na prática a ótica que eu gostaria que você tivesse sobre esse é assunto é que quando a gente fala de fazer produto a gente não deveria pensar em indivíduos e sim em um time. O time é a unidade básica de uma organização de produto e não as pessoas. Individualmente ninguém constrói nada em Produto, para qualquer coisa realmente importante que você queira construir você vai precisar de um time. É justamente esse conceito que permite que mesmo sem nenhuma pessoa tecnicamente espetacular em um time, você consiga alcançar grandes resultados, ou como o Marty Cagan definiu como subtítulo do último livro dele “Ordinary People, Extraordinary Products”.

Logo, a nossa responsabilidade como PM não é ser A pessoa que lidera produto, e sim ser a pessoa que lidera a disciplina de gestão de produtos e que influencia o time para que esse time tenha capacidade de gerir o produto de fato. Se tudo depender do/da PM para ser decidido você provavelmente está falhando na sua missão de empoderar o time. E possivelmente como reflexo disso você vai ter que trabalhar 16h por dia, sempre vai ter trabalho no final de semana, não vai conseguir tirar férias e vai passar por inúmeras discussões de quem é a pessoa responsável por tomar a decisão X ou Y, dado que fatalmente vamos estar falando de pessoas, não de times.

A Tríade

Antes de partir para a conclusão, um último assunto que eu acredito que vale a pena a gente conversar sobre é com relação ao formato e papel das lideranças dentro de cada estrutura de uma organização de produto (seja ela um Squad, uma Tribo ou a própria área). Eu considero esse assunto importante porque quando a gente fala de empoderamento, liderança por contexto, colaboração e etc uma coisa que pode prejudicar isso é polarizar a liderança de uma estrutura de produto em uma única pessoa.

Quando eu tenho um Squad Lead por exemplo, invariavelmente o time vai pender para a disciplina que essa pessoa domina, seja ela Gestão de Produtos, Design, Engenharia ou qualquer outra. Você queira ou não, a lente que essa pessoa vai aplicar para julgar e tomar decisões vai ser da disciplina de origem que essa pessoa tiver, seja isso feito de forma consciente ou inconsciente… é muito difícil fugir desse karma. Assumindo que essa afirmação é uma verdade, para preservar tudo isso que a gente falou até aqui sobre colaboração e unidade de time eu vejo como importante a liderança desse time ser um conjunto de pessoas que representem pelo menos as disciplinas básicas de Engenharia, Gestão de Produtos e Design.

Sobre esse tema eu gosto muito desse post do Alex Schleifer, VP de Design do Airbnb, onde ele faz uma analogia entre as três disciplinas básicas de um time de produto e um banco de três pernas. Se você tiver um banco de três pernas com uma perna menor do que as outras duas, ou até sem uma dessas pernas, esse banco certamente vai pender para um dos lados e, no limite, vai ser inútil. Trazendo para a nossa realidade, isso quer dizer que a gente deveria zelar muito para ter as três disciplinas de Gestão de Produtos, Design e Engenharia o mais equalizadas possíveis em termos de maturidade e poder de influência. 

Toda essa mágica de colaboração dentro de um time de produto depende da capacidade de todas as pessoas, independente das suas disciplinas, poderem trazer pra mesa as suas perspectivas sobre determinado assunto e terem a tal da segurança psicológica para poderem fazer isso sem medo. Novamente, vou reforçar o conceito de que a unidade básica de um organização de produto não são as pessoas, são os times. E esses times, em todas as instâncias, precisam ser multidisciplinares e autônomos para tomarem as suas decisões.

Conclusão

Depois de ler tudo isso você deve estar pensando “Beleza Spengler, você falou um monte de coisas aqui mas ainda não respondeu a pergunta do título desse post, afinal PM é ou não responsável por tomar decisões de produto?”. Eu sei, me desculpe pelo suspense, mas eu prometo que esse post não é clickbait! =)

Eu quis falar tudo isso antes de responder a pergunta central porque eu acredito muito no poder e importância do contexto. Além disso, eu sempre me preocupo com esse tipo de definição porque nesse cenário a gente geralmente vira radical demais, vamos no extremo da definição. Mas indo para a resposta, sim, uma pessoa de Gestão de Produtos deveria ser a responsável, ou seja, ter autonomia para tomar uma decisão de Produto, independente do time concordar com essa decisão ou não. Novamente, buscar por consenso ou democracia na hora de tomar decisões normalmente não nos leva para o melhor caminho, muito menos é a coisa mais rápida a ser feita… e muitas vezes agilidade é um fator extremamente relevante, falei mais sobre isso nesse post.

Agora, por tudo isso que eu falei aqui, esse “super-trunfo” que uma pessoa de Gestão de Produto tem de poder bancar uma decisão, na minha visão, deveria ser usado muito raramente. Eu sinceramente lembro de pouquíssimas vezes ao longo da minha carreira onde eu tive que fazer isso. Mas no outro extremo, quando o/a PM sente que não tem autonomia para tomar decisões ou não tem a confiança necessária para isso, normalmente vão ser criadas inúmeras disfunções nesse time de produto e isso sem dúvida nenhuma vai gerar vários problemas e ineficiências. Então, em resumo, autonomia na tomada de decisão é uma coisa que todo PM deveria ter, mas poucos deveriam precisar usar.

A melhor forma de se tomar decisões de uma maneira saudável é, como falamos aqui, prezar por um time colaborativo, liderar pelo contexto e, sempre que possível, trazer dados (quantitativos ou qualitativos) e não meramente opiniões para a mesa. Bons PMs vão tomar uma porcentagem muito pequena das decisões, a grande maioria dessas decisões vão ser tomadas pelo próprio time, baseadas no contexto e na visão de mundo que essa pessoa de Gestão de Produtos apresentar.

Para escutar esse episódio no Spotify clique aqui
Para escutar esse episódio no Apple Podcasts clique aqui
Para escutar esse episódio no Google Podcasts clique aqui

Livros:
Inspired
Inteligência Visual
Os Primeiros 90 Dias

Outros:
Brian Balfour
How WeChat faded into the silence in India
Behind the scenes of working in a Regional team at Wise

Minha carreira praticamente inteira, desde quando eu era desenvolvedor, foi criando produtos para outras empresas. Gosto bastante desse mercado, especialmente de produtos SaaS. Ao longo desses anos aprendi muita coisa sobre o mercado de B2B e também entendi a diferença de se fazer produto em cada etapa do ciclo de vida deste produto, ou mesmo de uma empresa, desde pré-PMF até produtos/empresas mais maduras. Parte desse conhecimento eu condensei no meu curso de Product Leadership caso você queira saber mais.

Apesar de todo esse aprendizado acumulado em quase 15 anos de carreira trabalhando com produtos B2B, recentemente, na minha passagem pela Stilingue eu me deparei com um cenário novo e que me desafiou bastante: Produtos Enterprise. Até então eu nunca tinha trabalhando no segmento de Enterprise, basicamente minha experiência com B2B era com SMBs (Pequenas e Médias Empresas), na passagem pela RD por exemplo, ou até com empresas ainda menores, como no Nubank onde trabalhei com empreendedores individuais. 

Quando comecei a gerenciar um produto Enterprise, muitas dúvidas surgiram na minha cabeça. Eu comecei a questionar várias das “verdades” que eu tinha sobre como fazer gestão de produtos e passei por alguns momentos de crise existencial até conseguir colocar as coisas no seu devido lugar. Basicamente o grande desafio de se fazer produtos Enterprise reside no fato de que seu TAM é geralmente muito limitado. É comum você ver empresas de muito sucesso nesse segmento (com direito a IPO e etc), com uma base de 1000-1500 clientes por exemplo. Com esse tamanho de base e com um ticket médio altíssimo, tomar algumas decisões de produto pensando na escala se tornam muito difíceis e daí partem basicamente todos os problemas.

Pra piorar esse cenário existe uma escassez muito grande de conteúdos de qualidade (mesmo em inglês) sobre como criar produtos Enterprises. Até benchmarks nesse segmento são complicados, dado que a grande maioria das empresas que operam com esse tipo de produto são empresas bem tradicionais, como a Salesforce, Adobe, Microsoft e etc. O que naturalmente nos leva para um playbook também bem tradicional e que se apóia naquela verdade de que ninguém nunca foi demitido por contratar a IBM, ou seja, a marca que essas empresas construíram é um grande asset em termos de confiabilidade.

Depois de muito revirar a internet em busca de bons conteúdos sobre Enterprise eu cheguei neste post do Blair Reeves, que me levou para o livro que ele escreveu junto com o Benjamin Gaines, e também neste outro post do David Sacks que faz uma comparação interessante entre SMBs e Enterprise, o que me ajudou bastante dado o meu conhecimento anterior neste mercado. Mas, nenhum desses conteúdos realmente me fizeram evoluir significativamente o meu conhecimento. Por esses motivos eu resolvi escrever esse post para sintetizar os meus aprendizados e talvez colaborar com alguém que possa passar por esse tipo de desafio no futuro. Várias das coisas que vou falar aqui se aplicam para o segmento B2B de uma forma geral, mas meu foco neste post é em produtos Enterprise, só pra deixar claro se por um caso isso não estava até aqui.

O que muda na estratégia em um produto Enterprise?

Como já falei neste post, uma característica muito comum no segmento de Enterprise é que o seu TAM é muito limitado. Isso nos leva a uma estratégia bastante utilizada por empresas com um produto deste tipo que é a que chamamos de Land and Expand. Em um super resumo isso significa que o seu objetivo como organização é conseguir conquistar uma conta (cliente) e depois trabalhar incansavelmente para expandir a receita deste mesmo cliente. Isso acontece porque o CAC no segmento de Enterprise tende a ser muito alto, assim como o ciclo de venda. Dessa forma, para dar ROI, o seu produto precisa estar otimizado para fazer tanto Cross Sell de novos produtos, como Upsell do produto existente, e assim aumentar a receita. É como se cada cliente fosse, na verdade, um canal de aquisição e não um cliente simplesmente, por isso “relacionamento” é um palavra bem chave nesse tipo de modelo de negócio. Esse conjunto de táticas é a principal estratégia para conseguir ter um negócio minimamente escalável, com um TAM tão limitado quanto o de um produto Enterprise. 

Quem define a estratégia do meu produto?

Eu sei que essa pergunta pode parecer óbvia, afinal a estratégia do seu produto deveria ser definida por você, certo? Pois é, deveria! Mas nem sempre é. Pela minha experiência tanto pessoal quanto através das mentorias e consultorias que eu faço, é muito comum você delegar a sua estratégia para o seu cliente. Falei disso em mais detalhes no podcast que gravei sobre Estratégia de Produto para o Mentes de Produto. O pior de tudo é que você faz isso sem perceber. Como normalmente as empresas não têm boas estratégias de produto (e é bem comum não ter estratégia nenhuma na verdade), você acaba permitindo que o seu cliente tome a decisão de para onde a sua empresa deveria ir. Obviamente o seu cliente não está preocupado com o crescimento da sua empresa, essa preocupação é sua, como líder de produto. Então pense duas vezes antes de priorizar aquela integração sem sentido ou em traduzir o seu produto para suéco, se você não tem a mínima intenção de entrar no mercado da Suécia ou sequer internacionalizar o seu produto agora. Quem define o que faz ou não sentido para o seu produto é você, não o seu cliente. Cliente nenhum vale o esforço de construir um produto que não está aderente a sua visão e estratégia.

Customização vale a pena?

Customização nunca vale a pena, seja em B2C, SMB ou Enterprise… até o McDonald ‘s sabe que isso é um problema. Dizer não para esse tipo de demanda talvez seja uma das coisas mais difíceis no segmento de Enterprise. Um cliente em uma empresa nesse segmento é muito caro de se conquistar, ter um churn alto em uma empresa que está focada em Enterprise é basicamente assinar a sentença de morte. Então como dizer “não” para um cliente? Aqui tem várias saídas possíveis e nem todas elas passam por dizer “não” necessariamente. Mas se você precisar dizer, diga sem medo! O mais importante é criar uma relação de confiança com o seu  cliente e para isso você precisa ser sincero e não fazer falsas promessas ou prolongar muito essa resposta.

No entanto, às vezes a demanda de um cliente que vem em um tom de customização pode fazer sentido para vários outros clientes, ou potenciais clientes. Se você descobre que uma necessidade de um cliente em específico é, na verdade, a necessidade de um setor inteiro (como Farmacêutico, Agronegócio, etc) fazer essa alteração no produto pode ser bem interessante, por exemplo.

Outra opção muito utilizada em empresas Enterprise é a possibilidade do seu cliente estender o seu produto através de APIs, integrações, parceiros de serviço externos ou até mesmo de uma área interna de Professional Services. O cuidado aqui vale para a palavra “estender”, não estou falando que o seu produto deveria ser alterado, mas sim estendido, através de plugins ou APIs por exemplo. Por fim, uma outra opção muito utilizada é a de criar um produto altamente customizável através de parametrizações, como a Salesforce faz. O ponto negativo é que a implantação do seu produto neste modelo tende a ser muito custosa, mas isso tende a gerar uma maior retenção também.

Como gerenciar as demandas do time de Vendas e CS?

Times customer facing, como Vendas, CS, Suporte e etc, costumam procurar o time de produto com bastante frequência para solicitar alterações no produto, seja para fechar uma venda ou para reter um cliente existente. Isso quer dizer que essas informações, sobre o que é necessário fazer para aumentar a receita do seu produto, são super importantes para direcionar a sua estratégia e a priorização do que será feito. Mas isso não quer dizer que necessariamente você deveria fazer tudo que chega na sua mesa.

É importante entender que existe uma diferença gigante entre sugerir alguma coisa e demandar/solicitar alguma coisa. Time de produto nenhum deveria receber demandas, isso é anos 2000, fábrica de software. A relação que você precisa construir com os times de Vendas, CS e etc é uma relação de parceria onde um time ajuda o outro, entendendo que by design as pessoas dos times customer facing vão estar otimizando o seu processo para cuidar de um cliente específico (a comissão de um vendedor é pela venda da carteira dele, por exemplo, não por todas as vendas da empresa), enquanto o time de produto precisa pensar no todo para garantir a escalabilidade do negócio, então é natural que isso gere conflitos de interesse. Mais uma vez, não tenha medo de dizer “não” e de explicar quantas vezes for necessário qual a estratégia do seu produto.

Como engajar os times internos para colaborarem com a evolução do Produto?

Como eu falei na pergunta anterior, por diversas vezes você vai precisar dizer “não” para uma sugestão que uma pessoa de Vendas, CS, Suporte, Marketing e etc trouxer pra você. Com o tempo esse monte de “nãos” vão gerando insatisfações, que variam entre “o time de produto não me escuta” e “o time de produto não sabe o que está fazendo” (by the way, essa última é campeã em gerar leads internos para virarem PMs, com a motivação de finalmente fazer produto “direito”).

Para resolver esse problema normalmente a primeira ideia que todo mundo tem é criar algum tipo de ferramenta para coletar e gerenciar feedbacks, seja interno ou até externo. Isso é legal, acho que ajuda bastante, mas vou te contar um segredo: não vai resolver o seu problema. Pra resolver o problema de fato, independente de ferramenta, você precisa primeiro deixar muito claro qual é a estratégia do seu produto e quais problemas e oportunidades você está priorizando. A partir do momento que isso estiver claro para todo mundo você pode explicitamente setar a expectativa de que se alguém tiver sugestões/idéias que ataquem esses problemas e oportunidades, elas vão fazer muito sentido para o seu momento. Mas se as sugestões não fizerem sentido nesse cenário, provavelmente não serão levadas pra frente (mas podem servir de inputs para o próximo ciclo de planejamento). 

Fazendo esses alinhamentos de objetivo você vai canalizar a colaboração dos times internos para os problemas e oportunidades mais pertinentes para a sua estratégia. Assim é muito provável que várias das sugestões recebidas sejam de fato implementadas, por mais que a origem dessa ideia tenha sido uma entrevista com cliente, um benchmark ou qualquer outra coisa. Mas o fato é que seu time interno vai se sentir muito mais motivado em colaborar com o produto por ver as sugestões “deles” entrando em produção.

Vale a pena usar um cliente como guia para construir o meu produto?

A resposta curta é sim, vale a pena. Mas é importante que você garanta duas coisas: 1) Esse cliente precisa fazer parte do seu ICP (Ideal Customer Profile) e 2) Você precisa tomar cuidado para não especializar demais o seu produto, incorporando a regra de negócio do seu cliente no seu produto. Se essas duas coisas forem feitas, eu acredito que é sim uma boa estratégia utilizar um cliente que tenha uma necessidade X, que esteja na sua estratégia, como um guia para lhe ajudar a construir o seu produto. Mas é fundamental que você não fale apenas com esse cliente (caso você tenha um CAB – Customer Advisory Board – esse é o tipo de discussão interessante de se ter nesse fórum) e que entenda a necessidade global do mercado aplicando boas práticas de entrevista qualitativa, fazendo bons benchmarks, etc. Se você usar esse cliente “guia” como um early adopter do seu produto, eu acredito que você terá sucesso. Mas se você usar esse cliente como o Product Manager do seu produto, deixando ele guiar como esse produto será, eu temo que você terá problemas. 

Concluindo

No final das contas a conclusão que eu cheguei é que as boas práticas de como se fazer produto são regras quase que universais, pelo menos nos cenários onde eu já trabalhei (B2C, B2B, B2C2C, B2B2C) eu não consegui encontrar exceções que valem a pena citar aqui. Mas, Enterprise, sem dúvida nenhuma, foi um dos cenários mais desafiantes no sentido de se manter fiel às boas práticas de gestão de produtos, é muito fácil se deixar levar pela aquisição ou retenção de um cliente com um ticket muito alto, principalmente se a sua empresa está um momento de vida ou morte e/ou ainda não sabe quem é o seu ICP.

Vale citar aqui também a importância de você manter o foco o máximo possível, em um produto Enterprise é muito fácil você ser distraído por uma grande oportunidade de venda ou por um cliente importante que está ameaçando dar churn. Eu falei mais sobre foco nesse post, mas o mais pertinente aqui é que você tenha consciência de que a última grande oportunidade ou o último grande problema não é necessariamente a coisa mais importante pra você fazer, ter ciência desse viés de recenticidade é fundamental para a saúde do seu produto, do seu time e a sua própria saúde mental. Boa sorte!

Eu acredito que Gestão de Produtos, como disciplina, realmente pode fazer toda a diferença entre uma empresa ter sucesso ou não ter. Não por acaso, o mercado está sedento por boas pessoas de Produto. Dentre tantas coisas que nós, como PMs, podemos colaborar com as empresas que atuamos, tem uma em particular que eu vejo que é cada vez mais fundamental: foco.

Depois de alguns anos criando produtos diretamente e dezenas de consultorias e mentorias, um padrão que vejo de deficiência entre pessoas de produto é a capacidade dessas pessoas em manterem o foco da organização. PMs são tentados o tempo todo a mudarem de rota. Por mais que você tenha uma grande aposta na mão, com potencial de impactar significativamente o negócio, toda hora chegam aos nossos ouvidos novas oportunidades e necessidades “urgentes”.

Apesar desse cenário, é fundamental que nós, como PMs, sejamos capazes de manter o foco no que realmente importa e separar todo resto, todo o ruído que está à nossa frente. Perder o foco gera desperdício de tempo e dinheiro e no médio prazo desmotiva tanto o próprio time de produto quanto as lideranças, porque nós vivemos de resultado e não só de esforço. E, sim, ganhar contexto de um determinado problema, fazer um bom processo de Discovery e etc, apesar de às vezes não ser tão palpável para boa parte dos stakeholders, demanda muito esforço do time de produto.

Já há um bom tempo eu aprendi que se você realmente quer entregar um resultado significativo você precisa fazer escolhas e focar a sua energia em uma única métrica/objetivo. Se você diluir os seus esforços você dilui também a sua capacidade de causar impacto, é física básica. Claro, quanto maior o seu time maior a sua capacidade de atacar várias coisas simultaneamente, mas a regra básica ainda é válida, quanto mais foco, mais potencial de impacto.

Tipicamente tem duas coisas que potencializam a perda de foco: 1) Falta de uma estratégia de produto definida e alinhada com a organização e 2) Lideranças primariamente reativas. Sobre estratégia eu falei bastante deste assunto no episódio do Product Backstage que gravei com o Joca Torres e neste episódio do Mentes de Produto que fui convidado. Mas em resumo, é fundamental que você tenha uma estratégia de produto em mãos que deixe claro os objetivos do seu produto e que ajude o time a resolver os tradeoffs do dia-a-dia, e que você foque nas oportunidades que realmente vão entregar sucesso para essa estratégia. Esse post do Gibson Biddle pode ser um bom cookbook caso você esteja muito perdido em como criar uma boa estratégia de produto.

Já sobre Lideranças reativas, é preciso ter muita cautela. Existem pessoas que por perfil tem naturalmente um viés de recenticidade, ou seja, tudo aquilo que chega por último parece ser mais importante. Isso não é necessariamente ruim, porque de fato se o seu contexto muda você precisa reavaliar as suas decisões. Permanecer de cabeça baixa e não responder às mudanças que acontecem também é ruim. No entanto, se você tem uma estratégia bem definida, mudanças de rota deveriam ser a exceção. Por mais difícil que seja, você precisa conseguir mostrar a importância do foco e reiterar a importância dos objetivos que você está perseguindo.

Manter o foco é extremamente desafiador, mas é fundamental para que você e o seu time alcancem bons resultados. Foco nos permite ter certeza que estamos trabalhando na coisa certa, nos permite terminar o que nos propomos, aprender com os nossos erros e acertos e ganhar confiança para focar na próxima grande coisa

.

Para escutar esse episódio no Spotify clique aqui
Para escutar esse episódio no Apple Podcasts clique aqui
Para escutar esse episódio no Google Podcasts clique aqui

Livros:
Inspired
Empowered
The Power of Moments
No Filter
Platform Revolution

Outros:
Episódio 10 – Dan Printes

Para escutar esse episódio no Spotify clique aqui
Para escutar esse episódio no Apple Podcasts clique aqui
Para escutar esse episódio no Google Podcasts clique aqui

Livros:
Peopleware
The Hard Thing About Hard Things
Principles
Escaping the Build Trap

Para escutar esse episódio no Spotify clique aqui
Para escutar esse episódio no iTunes clique aqui
Para escutar esse episódio no Google Podcasts clique aqui

Livros:
High Output Management
The Hard Thing About Hard Things
Radical Candor
Empowered
Trillion Dollar Coach
No Rules Rules
Inspired
The Lean Startup
Blue Ocean Strategy
Rework

Blogs:
Marty Cagan
Ken Norton
Gibson Biddle
Adam Nash

Para escutar esse episódio no Spotify clique aqui
Para escutar esse episódio no iTunes clique aqui
Para escutar esse episódio no Google Podcasts clique aqui

Livros:
Crossing the Chasm
Obviously Awesome
A Promised Land

Blogs:
Profitwell
The Product Marketing Alliance
Open View Partners

Outros:
Lança Produto
Tour of Duty

Para escutar esse episódio no Spotify clique aqui
Para escutar esse episódio no iTunes clique aqui
Para escutar esse episódio no Google Podcasts clique aqui

Livros:
The Innovator’s Dilemma
Breath
Empowered
Jobs to be Done: Theory to Practice
Running Lean
Inspired
Measure What Matters
Business Model Generation
Sprint

Outros:
Episódio 1 – Marcell Almeida

Para escutar esse episódio no Spotify clique aqui
Para escutar esse episódio no iTunes clique aqui
Para escutar esse episódio no Google Podcasts clique aqui

Livros:
An Elegant Puzzle
High Output Management
Inspired
The Three Laws of Performance

Blogs:
Amplitude
Intercom

Outros:
Episódio 4 – Thiago Belluf
Navigator

Para escutar esse episódio no Spotify clique aqui
Para escutar esse episódio no iTunes clique aqui
Para escutar esse episódio no Google Podcasts clique aqui

Livros:
Domain-Driven Design
Empowered
Essencialismo
Platform Revolution
The Lean Startup

Podcasts:
Masters of Scale
Playbook

Blogs:
Brandon Chu
Intercom

Para escutar esse episódio no Spotify clique aqui
Para escutar esse episódio no iTunes clique aqui
Para escutar esse episódio no Google Podcasts clique aqui

Livros:
How Google Works
Radical Candor
Product Analytics Playbook
Intercom on Product Management

Ferramentas:
Clockwise
Amplitude
Mixpanel

Outros:
Growth Masters

Para escutar esse episódio no Spotify clique aqui
Para escutar esse episódio no iTunes clique aqui
Para escutar esse episódio no Google Podcasts clique aqui

Livros:
Inspired
The Hard Thing About Hard Things
About Face
Arriscando a Própria Pele
The Power of Moments
Thinking, Fast and Slow
Faça Acontecer

Blogs:
SVPG
Product Talk
PM3

Outros:
Curso de Product Discovery – PM3
TED Talk – Teach Girls Bravery not Perfection
Newsletter – Bloco de Notas
Video – Linkin Park Forró