Essa diferença de foco em resultado é o que sempre me fez preferir ter times de desenvolvimento de produto internos a contratar empresas terceirizadas para desenvolver produtos. As empresas terceirizadas têm por principal objetivo vender mais horas de desenvolvimento de software. Consequentemente, elas vão sempre buscar oportunidades para nos vender mais horas de desenvolvimento de software. O próprio relatório de prestação de contas ao final do mês, que vem junto com a nota fiscal que devemos pagar, vem com um detalhamento de quantidade de horas trabalhadas por cada profissional alocado e uma lista de funcionalidades entregues. Já vi em relatórios de empresas de terceirização de desenvolvimento de software alguma demonstração de entrega de resultado para a empresa ou para o cliente, mas isso é bastante raro.
Certa vez, tive a oportunidade de ajudar um cliente a tomar a decisão de trocar o time terceirizado por um time interno. Uma vez que o custo mensal médio por pessoa do time de desenvolvimento de produto tende a ser próximo, a troca se justificaria pelo simples fato de ter as pessoas do time interno bastante alinhadas com os objetivos de negócio. Nesse cliente, uma das métricas de negócio que acompanhávamos era a quantidade de vendas geradas por esse time de desenvolvimento de produto.
É interessante notar que, enquanto o time é parcialmente terceirizado, a quantidade de novas vendas não aumentava, por mais que estivesse claro que esse era um dos principais objetivos do time. Somente após alguns meses com o time sendo majoritariamente formado de pessoas internas é que a métrica de novas vendas começou a crescer.
Acredito que, a essa altura, já deva estar bem claro qual o principal objetivo de qualquer time de desenvolvimento de produto, mas vou repetir, para deixar ainda mais explícito:
A prioridade número um de qualquer time de desenvolvimento de produto é GERAR RESULTADOS O MAIS RÁPIDO POSSÍVEL.
Gerar resultados para a empresa que possui o produto e investe na construção desse produto, e resultados para o cliente, resolvendo seus problemas e atendendo suas necessidades. Precisa ser o mais rápido possível, pois gerar resultados custa dinheiro, e quanto mais tempo gastarmos na geração de resultados, mais dinheiro gastaremos.
Já citei algumas boas ferramentas para obter resultados, e a terceira parte desse livro será focada nesse tema, mas não devemos esquecer que elas são ferramentas para nos ajudar a gerar resultados o mais rápido possível. Visão, estratégia, estrutura de time, OKR, roadmap, prova de conceito, MVP, discovery, protótipo, site, app, funcionalidade, bot, algoritmo, e assim por diante. A lista é bem extensa, mas não podemos nunca nos esquecer que tudo isso são ferramentas para que possamos gerar resultados para o negócio e para o cliente. Até o produto, a palavra que vai no título da função de gestão de produtos, é uma ferramenta para gerar resultados.
Para vender imóveis de um novo prédio, a Lopes e a construtora criam uma relação de parceria na qual a construtora compartilha informações sobre preços, disponibilidade de unidades e leads, e a Lopes trabalha na venda dessas unidades com base em sua larga experiência na comercialização de lançamentos imobiliários.
Para cumprir suas atribuições nesta parceria, precisamos saber da construtora os preços de cada unidade, preços esses que mudam frequentemente de acordo com a evolução das vendas. Precisamos também saber quais unidades estão disponíveis, e precisamos receber leads da construtora. Essas informações eram enviadas através de arquivos para serem importados manualmente em nosso sistema. Todas as entradas manuais de informações tendem a ser lentas e sujeitas a erros, por isso fica claro que essa integração manual não é o ideal.
A integração da Lopes com as construtoras não é diferente. Por ser uma operação manual, era feita uma ou duas vezes por semana, o que gerava informações desatualizadas sobre preços e unidades disponíveis em nossos sistemas para uso pelos nossos corretores. Além disso, quanto mais antiga a informação do lead, mais frio esse lead se torna e, provavelmente, o cliente em potencial descobre outras maneiras de receber as informações de que precisa e, eventualmente, fecha um negócio com outro vendedor que não é da Lopes.
Resolvemos esse problema mantendo sempre o foco em gerar resultados o mais rápido possível:
Optamos pela solução 3 porque era a que nos traria resultados mais rapidamente. Levamos apenas algumas semanas para ter o primeiro RPA funcionando e trazendo resultados. Após um ano usando essa solução, nenhuma API ainda tinha sido fornecida pelos provedores do sistema de gerenciamento e também não tivemos a necessidade de construir nossos próprios RPAs. O provedor de RPA funcionava bem com um custo razoável e podíamos focar nossa equipe para gerar resultados a partir de outras oportunidades.
Uma nova pessoa que se juntou ao time do Lopes Labs e que veio de um site de comércio eletrônico mencionou que as notificações push do aplicativo de onde ela trabalhava geravam mais leads e tinham maiores taxas de conversão do que SMS e e-mail marketing. Ficamos interessados em testar essa hipótese de geração de resultado, mas não tínhamos app para os clientes poderem buscar imóveis e, no curto prazo, não tínhamos planos de desenvolver um.
Como poderíamos testar essa hipótese o mais rápido e barato possível? Construir um aplicativo nativo com todos os recursos do nosso site existente levaria meses. Mesmo que reduzíssemos muito o escopo, com o mínimo para entregar algum valor ao usuário, ainda levaria muitas semanas.
Como nosso site é responsivo, criamos uma solução simples para testar a hipótese. Decidimos criar um aplicativo webview, uma solução mais simples do que construir um aplicativo nativo, mesmo que o limitássemos ao escopo ao mínimo.
Aliás, foi assim que o Facebook e o LinkedIn também lançaram seus primeiros aplicativos móveis. Somente quando perceberam os resultados gerados pelos seus apps e comprovaram que uma versão nativa traria ainda mais resultados, decidiram investir na construção de seus aplicativos nativos. Com este aplicativo móvel, pudemos confirmar que a notificação push gerava mais leads e tinha maiores taxas de conversão do que SMS e e-mail marketing. Lançamos este aplicativo no início de 2021.
Aproveito para ressaltar que esses exemplos, do app para corretores, do RPA e do app para busca de imóveis, servem para ilustrar não só o princípio de “entrega de resultado”, como também os dois princípios anteriores de “entregas rápidas e frequentes” e de “foco no problema”.
No final de 2020, mesmo com o time do Lopes Labs focado em “entrega de resultado”, “entregas rápidas e frequentes” e “foco no problema”, ele ainda era muito cobrado por entregas de funcionalidades. Apesar de ser um pouco frustrante, encarei essa cobrança como algo esperado, afinal a diretoria da Lopes estava investindo muito dinheiro no Lopes Labs, com o custo mensal crescendo mês a mês, custo esse com pessoas e infraestrutura para desenvolvimento e hospedagem das aplicações feitas.
Qualquer empresa ou pessoa que faz algum tipo de investimento tem uma expectativa de retorno desse investimento. Na Lopes não era diferente. A diretoria, o conselho e os acionistas da Lopes esperavam o retorno do investimento que estavam fazendo no Lopes Labs. Esse time era composto de pessoas de produto, de design, de engenharia e de dados. O que esse pessoal todo faz? A resposta mais óbvia para essa pergunta é que o que esse time faz é desenvolver e entregar funcionalidades, sites, apps, telas, algoritmos, relatórios etc. Então, o que devemos esperar e cobrar desse time como retorno do investimento que fizemos e continuamos fazendo? Funcionalidades, sites, apps, telas, algoritmos, relatórios etc. Nada mais natural.
Acontece que, como vimos anteriormente, nada disso é o objetivo final, mas um meio para o atingimento de objetivos e resultados. Em função disso, o time do Lopes Labs propôs fazer o orçamento de 2021 baseado em três premissas:
1. Estabilizar custos: como comentei, o custo estava crescendo mês a mês. Propusemos que o custo não crescesse mais ao longo de 2021, o que significaria que qualquer novo custo só entraria com a saída ou redução de algum custo existente.
2. Medir receita: um dos resultados esperados de todo esse investimento de desenvolvimento de produtos digitais é que esses produtos gerassem mais vendas de imóveis. Deveríamos, então, medir essa quantidade de receita gerada a partir da venda de imóveis originadas em produtos digitais.
3. Receita > custo: por fim, ao longo de 2021, deveríamos ter como objetivo a receita gerada pelos produtos digitais ser maior do que o custo do Lopes Labs. E obviamente, quanto antes, melhor!
Esse orçamento foi aprovado e foi assim que operamos ao longo de 2021. Ao final do ano, conseguimos manter os custos dentro do orçado e a receita acima do orçado, eventualmente registrando receita maior do que o custo do mês, o que comprovou nossa capacidade de entrega de resultado.
Esse artigo é mais um trecho do meu mais novo livro “Transformação digital e cultura de produto: Como colocar a tecnologia no centro da estratégia da sua empresa“, que vou também disponibilizar aqui no blog. Até o momento, já publiquei aqui:
Ajudo líderes de produto (CPOs, heads de produtos, CTOs, CEOs, tech founders, heads de transformação digital) a enfrentarem seus desafios e oportunidades de produtos digitais por meio de treinamentos e consultoria em gestão de produtos e transformação digital.
Você trabalha com produtos digitais? Quer saber mais sobre como gerenciar um produto digital para aumentar suas chances de sucesso, resolver os problemas do usuário e atingir os objetivos da empresa? Confira meu pacote de gerenciamento de produto digital com meus 4 livros, onde compartilho o que aprendi durante meus mais de 30 anos de experiência na criação e gerenciamento de produtos digitais. Se preferir, pode comprar os livros individualmente: