Rich é o CEO da Mironov Consulting. Ele treina executivos de produtos, equipes de gerenciamento de produtos e organizações de desenvolvimento ágil com foco em receita.
Como bons profissionais de produtos, sabemos que os clientes devem reconhecer um problema antes de pensarem em comprar nossa solução. As empresas que não têm problemas de cadeia de abastecimento (ou pensam que não) não estão no mercado de sistemas ERP. Organizações que não pensam que são alvos de hackers não investem em infraestrutura de segurança. Os “viciados em sofá” não se importam com as métricas de tração para tênis de corrida. Famílias sem animais de estimação (a maioria) não compram suéteres bonitos para cães. Não compramos antídotos para doenças não reconhecidas.
Mas muitas vezes vejo gerentes de produto e líderes esquecerem disso quando lidam com executivos e stakeholders internos. Nós pressionamos nossas empresas a adotar práticas e processos do lado do produto sem enquadrar e “vender” claramente os problemas subjacentes. Não descrevemos os melhores resultados em termos não técnicos. Eu penso nisso como uma “filosofia de venda” – lançar palavras-chave fora do contexto e terminologia de tecnologia obscura para executivos do lado do mercado que não entendem (ou se preocupam profundamente) com as distinções complicadas que nós, técnicos, estimamos. Eu ouço líderes de produto dizerem o seguinte aos CEOs:
“Precisamos ser mais ágeis e menos cascatas.”
“Somos orientados para as vendas, não para o produto, por isso os principais negócios continuam tendo prioridade sobre os roteiros.”
“As operações continuam nos dizendo exatamente como querem que consertemos nossos aplicativos operacionais internos, em vez de enquadrar os problemas.”
“Devemos mudar para o Desenvolvimento Orientado a Testes.”
“O produto recebe centenas de solicitações de recursos mensalmente: de cada departamento, usuário e parceiro de canal. Portanto, precisamos que cada remetente conclua um caso de negócios com sua solicitação.”
Carroça antes do cavalo. (Recomendação antes do problema.) Para muitos CEOs e líderes de vendas / marketing, essas são frases sem sentido que parecem choramingar. Eu vi executivos do go-to-market (GTM) ouvirem os primeiros três minutos de um argumento de duas horas ‘Kanban vs. scrum vs. XP vs. SAFe’ e ir embora enojados. (“A razão de não tirarmos muito proveito da Engenharia é porque eles passam o dia todo debatendo quantos arquitetos podem dançar na cabeça de um alfinete.”)
Como líderes de produto, também devemos aplicar nossas habilidades de produto à mudança organizacional interna. Para mim, isso significa evitar filosofia técnica e frases de efeito sobrecarregadas; em vez disso, crie um entendimento compartilhado dos problemas com base em incidentes internos detalhados e específicos. Minha abordagem para essas discussões:
- Devemos concordar com um problema antes de oferecer soluções. Os executivos do GTM não se importam com a filosofia técnica; eles se preocupam com a receita, as metas de negócios e a produtividade.
- Não presuma que os executivos do GTM saibam o que queremos dizer com palavras-chave do lado da tecnologia. ‘Validação’ e ‘orientada para o produto’ e ‘MVP (Mínima Viabilidade do Produto em inglês)’ pode não significar nada para eles: já emburrecido na imprensa de negócios ou sequestrado por grandes empresas de consultoria que vendem óleo de cobra de transformação. Eles normalmente ouvem ‘ágil’ como ‘construir todas as coisas que eu quero mais rápido.’
- Suponha que o lado do GTM não veja os padrões que vemos no lado da tecnologia ou atribua diferentes causas. O que parece causalmente óbvio para nós não é. Devemos encontrar exemplos específicos da empresa suficientes para demonstrar um problema que vale a pena resolver.
- É autodestrutivo adotar uma atitude intelectualmente superior. Vender é difícil; o marketing é difícil; as finanças são difíceis; dirigir uma empresa é difícil. Desprezar colegas de trabalho que não sabem programar é um erro fundamental. Não pedimos aos gerentes de produto ou engenheiros para descobrir “vendas com base na conta” ou “ocultação do mecanismo de pesquisa”. Precisamos deixar nossos egos na porta.
Um Exemplo
Fraca declaração de problema: “estamos permitindo que nossos maiores clientes definam o roadmap, incluindo especificações técnicas detalhadas. O produto precisa fazer uma ampla validação de mercado primeiro.”
Isso vem do ponto de vista do processo de desenvolvimento com muitas suposições internas do produto. Nem sempre é óbvio para quem vai ao mercado que temos um problema. Não é assim que deveria funcionar? Saltamos direto para as palavras-chave enigmáticas (“validação de mercado”) e processamos as alterações sem enquadrar o problema. Eu esperava respostas do meu CEO e VP de vendas/CRO como:
“Claro, nós fazemos isso! Nossos clientes sabem o que desejam e vão além para escrever especificações detalhadas para nós. Você deveria estar agradecendo a eles/nós por fazer o seu trabalho.”
“Nossas equipes de vendas conversam com cem clientes a cada semana. Os gerentes de produto têm algumas conversas por mês. Vendas representam a voz do cliente.
“A validação de mercado é uma perda de tempo. Pesquisamos as equipes de vendas e marketing semanalmente para saber as novidades. E na semana passada eles nos disseram que todos em nosso segmento querem X.”
“Eu adoraria fazer mais, discutir menos. Nossos executivos e equipes de sucesso do cliente são especialistas em logística de frete | resenhas de filmes | aparelhos de ortodontia | leilões de comércio eletrônico | qualquer que seja. Seus desenvolvedores/gerentes de produto não são. Sabemos como esses sistemas devem funcionar”.
A visão de mundo do GTM pode ser bem diferente da visão de mundo de produto/desenvolvimento. Para eles, dizer “sim” a todas as solicitações dos clientes deve ser nosso objetivo. Eles acreditam que os compradores entendem nossos sistemas internos bem o suficiente para escrever histórias de usuários para nós. Especialmente em vendas, eles generalizam rapidamente a partir de 2 demandas semelhantes para necessidades universais do mercado. Onde você está depende de onde você se senta.
Então, vamos reformular nossa declaração de problema e mudar o diálogo:
Produto: “Temos um problema sistemático. Frequentemente, as solicitações recebidas de nossos maiores clientes são menos importantes do que nosso roteiro acordado e tendem a ser tecnicamente incompletas/incorretas. Portanto, estamos desperdiçando esforços que deveriam ir em direção à estratégia e aos compromissos.” Isso soa menos apavorante, menos crítico e convida à discussão.
CEO: “Nós não fazemos isso.”
Produto: “Bem … Três semanas atrás, a equipe executiva aprovou a solicitação da HugeCorp para autenticação de nove fatores. Estamos retirando a equipe da Grande Nova Inovação deste Ano, que vai atrasar um mês. São US$ 25 milhões em ARR (Receita Anual Recorrente em inglês) que estamos atrasando.”
CEO: “Mas todo mundo quer autenticação de nove fatores. Vendas disse que sim.”
Produto: “Não identificamos nenhum outro cliente pelo nome e seu caso de uso é confuso. Não acho que mais do que dois de nossos 800 clientes o usariam.”
CEO: “OK, acho que entendi seu ponto. Mas essa é a única vez que fizemos isso, e a HugeCorp paga o salário de todos.”
Produto: “Eu te escuto. Mas na semana passada, também prometemos construir uma integração de aplicativo personalizado para MassiveCo. Não foi planejado, dimensionado ou no roteiro. Isso vem da mesma equipe que trabalha na grande nova inovação deste ano. Poderia empurrar aquele ARR de US$ 25 milhões para outro mês ou mais.”
CEO: “Hmmm. Então, apenas duas vezes. A engenharia tem muita capacidade e 20 vagas em aberto.”
Produto: “E a Behemoth Inc acaba de enviar sua especificação para sincronização de dados em nuvem híbrida. Não fazia sentido para nossos arquitetos e provavelmente não funcionará. Mas eles estão esperando uma data de entrega confirmada. Dissemos à diretoria que começaremos a migrar clientes locais para nuvens híbridas em dezembro, e isso depende desse grupo. Acho que devemos apontar Behemoth para um de seus integradores de sistema em vez de fazermos isso nós mesmos.”
CEO: “Hmmm. Pode ser. Estou começando a ver o padrão. Conte-me mais sobre como estamos aprovando isso e quem está montando casos de negócios ou dimensionando o trabalho…”
Observe que estruturamos um problema em termos técnicos e comerciais, reunimos uma série de instâncias recentes (evidências) e começamos identificando (‘vendendo’) o problema em vez da solução. Estamos preparados para lidar com objeções ao problema em si: tendência de recência, não reconhecimento de padrão, impacto sutil sobre os clientes ou receita e metas de vendas que estão desalinhadas com as metas da empresa/produto. Adiamos a apresentação de novos fluxos de trabalho ou aprovações ou comitês ou sistemas de tíquetes ou contratações de gerenciamento de produtos adicionais ou modelos de caso de negócios até que o CEO reconheça que temos um problema que vale a pena enfrentar.
Um Outro Exemplo
Fraca declaração do problema: “Não estamos ganhando dinheiro com o desenvolvimento personalizado pelo qual o Leviathan Bank nos paga. O produto precisa de poder de veto em todos os especiais.”
Já vi isso muitas vezes: as empresas procuram projetos de software personalizados de grandes clientes para obter dinheiro imediato. Ele ignora o custo real de um desenvolvimento único e a economia fundamental do negócio de software. Mas obtive respostas melhores ao conversar com CEOs e CFOs (e CROs) sobre isso em termos de avaliações dos investidores.
Produto: “Esses grandes projetos de serviços personalizados para Leviathan podem parecer a receita que queremos, mas acho que a diretoria e nossos investidores ficariam chateados em saber disso.”
CEO: “Não. Eles estão entusiasmados com o fato de o Leviathan ser uma conta de mais de US$ 1 milhão.”
Produto: “Recuando um pouco, os investidores normalmente avaliam a receita recorrente de software de assinatura em 6x ou mais, e os serviços de desenvolvimento de contrato em 1x ou menos*. Eles querem crescimento de software escalonável, onde adicionar mais clientes não nos força a fazer mais trabalho de desenvolvimento. Vendendo exatamente os mesmos bits centenas de vezes.”
CEO: “Mas o Leviathan precisa desse trabalho e está disposto a nos pagar por ele. Um dólar de receita é um dólar de receita.”
Produto. “Hmmm. Acho que estamos gastando a maior parte desse contrato de serviços fazendo o trabalho de engenharia. Tenho certeza de que o projeto Leviathan de U$ 280 mil deste trimestre custará mais de US$ 200 mil em desenvolvimento, o que deixa uma margem de talvez 20% depois de pagarmos à equipe de conta. Inscrever mais um cliente de US $ 75 mil/ano na plataforma principal seria um lucro de US$ 70 mil – o mesmo para aquele projeto único – com mais de 90% margem. Poderíamos adicionar dez clientes de nível intermediário mais rápido do que podemos concluir este trabalho, o que aumentaria a avaliação em 10 vezes em relação ao Leviatã. Fazer este projeto pode realmente reduzir nosso valor de saída.”
CEO: “Não parece certo para mim. Você é o cara do produto, não nosso CFO ou investidor de risco. Deixe-me passar por alguns deles.”
Produto: “Absolutamente. Só quero que tenhamos uma saída melhor para os acionistas. Por favor, deixe-me saber o que o pessoal financeiro pensa.”
Novamente, reconhecemos que nem todos os executivos são fascinados pela mecânica do desenvolvimento de software e podem ter visões de receita de curto prazo. Mas todos estão interessados nas saídas financeiras e em como os investidores avaliam as empresas. E precisamos evocar instâncias específicas, em vez de filosofia. Estamos motivando uma discussão que vai demorar um pouco. (Aliás, útil se você já teve essa mesma discussão com seu CFO – que está preparado para conversar sobre isso com seu CEO. Mas nunca, jamais, converse com o CEO para membros do conselho ou investidores.)
Depois que todos chegarmos a um consenso sobre a mudança de ofertas de serviços pesadas, podemos buscar soluções: mudar o foco de vendas para mercados intermediários; parceria com integradores para trabalhos personalizados; a engenharia evita muito do nosso esforço de integração; não pagar comissão de vendas sobre serviços; criar incentivos para que os clientes migrem para a versão mais recente com suporte; etc.
Como líderes de produto, pensamos em como toda a empresa opera. Trabalhamos para ser uma voz executiva confiável para o valor do cliente final – menos focados no departamento do que outros em torno da mesa de conferência (virtual). Às vezes, os problemas recaem perfeitamente sobre Engenharia/Projeto/Produto, mas geralmente temos recomendações ou sugestões para nossos colegas de nível C. É importante tomar nossas pílulas de humildade todos os dias, estruturar discussões para caber em nosso público, entender os sistemas de recompensa da empresa e focar em onde podemos motivar a mudança.
Frase de Efeito
Os problemas internos da empresa podem ser tão complexos ou mal interpretados quanto os problemas dos clientes externos. Para chegar a um acordo sobre as soluções, geralmente precisamos chegar a um acordo primeiro sobre os problemas subjacentes. Ao definir os principais problemas de produto/desenvolvimento para públicos menos técnicos, precisamos nos concentrar primeiro nas causas básicas e, em seguida, nos resultados de negócios tangíveis.