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!