Software está devorando o mundo

“Software está devorando o mundo.” A frase foi dita por Marc Andreessen, co-autor do primeiro navegador de internet do mundo, o Mosaic.
 
O que Andreessen quer dizer com isso é que o mercado de produtos está se afastando do hardware e voltando-se para o software como foco de geração de valor para o consumidor.
 
Um bom exemplo dessa tendência é o automóvel. Há hoje uma corrida para o desenvolvimento de carros auto-dirigíveis. Nesse cenário cada vez mais real, o que mais importa para vender carros é o software que permitirá que isso aconteça, e não mais o chassi, motor e transmissão em si.
 
Em pouco tempo veremos software como diferencial de quase tudo o que compramos, desde escovas de dentes que avisam quando os dentes estiverem limpos a geladeiras que elaborem listas de compras automaticamente e roupas e acessórios que medem ritmo cardíaco ou que sinalizam quando o usuário estiver a ponto de ter um ataque epilético.
 
Isso é importante para a disciplina de marketing por três razões:
  • O trabalho de marketing envolve cada mais o uso de software
  • Os canais de marketing e produtos a serem vendidos são cada vez mais baseados em software
  • Os sistemas gerenciamento de software é o mais adequado para o ambiente volátil em que vivemos
Razão Um (1): em uma semana normal o profissional de marketing utiliza quase uma dúzia de softwares diferentes para executar seu trabalho. Não há nada de novo nisso, ou particularmente único da profissão de marketing. Mas existe aqui uma oportunidade para o growth hacker adicionar valor, e a chave dessa proposta de valor está no termo “hacker”.
 
Por isso é importante (embora não obrigatório) que você, como growth hacker, aprenda programação, já que se software é o nosso instrumento de trabalho. Imagine o que você poderá atingir ao entender como a sua ferramenta de trabalho realmente funciona.
 
Imagine um piloto de motovelocidade que não sabe como funciona uma motocicleta. Agora compare-o àquele que é um exímio conhecedor do funcionamento e manutenção da moto. Ele terá vantagens tanto na preparação para a corrida (quando poderá conversar inteligentemente com os engenheiros sobre como melhor preparar a moto para as condições da corrida) quanto na corrida em si (quando saberá interpretar as reações da motocicleta à pista e tirar o máximo dela para correr).
 
Isso não significa que o piloto tenha que saber mais do que o engenheiro sobre mecânica. A especialidade do piloto ainda é pilotar e é nesse aspecto que ele deve se concentrar. Mas entender do funcionamento lhe dá uma vantagem competitiva em relação a quem não conhece motocicletas.
 
Na verdade, se você sabe um pouco sobre motovelocidade, saberá que saber de mecânica não é lá mais grandes vantagens, já que todos os melhores pilotos do mundo já são profundos conhecedores de motos. Mas em marketing, conhecer software é sim uma vantagem imensa. São poucos os profissionais de marketing que entendem de programação.
 
Como no caso dos pilotos e mecânicos em um circuito de motovelocidade, um profissional de marketing não precisa necessariamente conhecer mais de programação do que programadores profissionais, que passam 100% do tempo trabalhando nisso. Mas conhecer elementos de programação lhe abrirá um leque imenso de possibilidades que provavelmente não iria passar pela sua cabeça caso não soubesse como software funciona.
 
A Razão Dois (2) é que o consumidor de hoje passa a maior parte do seu tempo em frente a telas digitais, gerenciadas por múltiplos sistemas de software. Isso sem falar na Internet das Coisas, que foi demonstrada acima com os exemplos do carro, pasta de dentes e até roupas. Em breve praticamente tudo o que usamos terá um componente de software. E todos esses softwares se apresentarão, direta ou indiretamente, como canais de aquisição e retenção de clientes.
 
Hoje, praticamente toda a navegação na internet dos consumidores é rastreada por Google e Facebook. Mesmo quando você não está visitando diretamente esses sites ou usando seus aplicativos. Google e Facebook usam esses dados para desenvolver sistemas de propaganda e marketing cada vez mais sofisticados. Ao rastrear o seu comportamento online, essas empresas possibilitam aos seus anunciantes que desenvolvam peças publicitárias cada vez mais relevantes.
 
Você, como anunciante, tem acesso a muito mais informações sobre a performance das suas campanhas. Enquanto no passado, empresas de propaganda se baseavam em pesquisas para avaliar a efetividade de uma campanha publicitária, hoje qualquer anunciante, pequeno ou grande, tem acesso instantâneo a toda visualização, clique e atividade de seus clientes. Esse acesso a informação faz com que anunciantes online possam ser muito mais eficientes na elaboração, análise e melhoria de suas campanhas.
 
Da mesma forma o seu site ou aplicativo também é capaz de rastrear cada visualização, tempo de visualização, clique, saída, etc. de seus visitantes em tempo real. A velocidade de acesso a informação se traduz na velocidade de reação a essas informações. Em questão de horas, você poderá aprender que a sua nova homepage não está tendo uma boa performance, e poderá trabalhar para ajustá-la de acordo.
 
Até mesmo empresas “offline” vêm utilizando software para oferecer a seus clientes produtos mais relevantes em suas peças de marketing. Um exemplo disso é a Target, uma grande empresa de varejo americana que emprega “cientistas de dados” em seu departamento de marketing. O papel desses cientistas é analisar o comportamento de cada cliente, baseados nas compras feitas pelos seus clientes em suas lojas físicas, que são salvas em cartões de fidelidade.
 
Ao oferecer incentivos como descontos para clientes frequentes, através do cartão de fidelidade, a Target não está apenas trabalhando na retenção deles pela simples tática (embora em muitas vezes, bastante efetiva) de oferecer descontos. O motivo principal desses cartões de fidelidade existirem é ter acesso a todo o histórico de compras de seus consumidores durante todo o tempo em que eles são seus clientes.
 
Há alguns anos, no entanto, um dos clientes da Target nos Estados Unidos, entrou na loja, enfurecido, procurando pelo gerente. “A sua loja” disse ele “está querendo corromper a minha filha.” Retirando do bolso uma mala direta que havia sido enviada à sua casa, com o destinatário de sua filha adolescente de apenas 16 anos, haviam dezenas de ofertas de produtos para gravidez e cuidados com recém-nascidos.
 
O gerente da loja pediu desculpas em nome da empresa e disse que iria averiguar o que havia acontecido. Alguns dias depois, o gerente enviou um email para o cliente, pedindo novamente desculpas e afirmando que mudanças estavam sendo feitas no departamento de marketing para que isso não ocorresse novamente. Para a sua surpresa, no entanto, a resposta veio na forma de desculpas do outro lado. “Houveram certas atividades na minha casa” disse o cliente em um email de resposta “de que eu não estava ciente. A minha filha está grávida de 3 meses.”
 
A partir desse episódio, a Target passou a “disfarçar” seus sofisticados conhecimentos sobre seus clientes, adicionando algumas ofertas aleatórias em suas malas diretas e anúncios para não ficar tão óbvio que eles sabem muito mais sobre você do que você imagina (ou gostaria). Isso é possível através de um algoritmo que compara uma sequência de compras de determinado cliente com outros milhares de clientes e, a partir disso, poderá “adivinhar” o que esse ela vai comprar depois. Esse tipo de informação vale ouro para qualquer profissional de marketing.
 
Mas a maior razão porque software é extremamente importante para profissionais de marketing e growth hackers vai além disso tudo, e é a parte mais importante para nós Growth Hackers. A Razão Três (3) entra no cerne de como uma metodologia de trabalho revolucionou a maneira com que profissionais do novo milênio trabalham: o método ágil de desenvolvimento.

O Método Ágil de Desenvolvimento

Nos anos 1990, com a proliferação de computadores sendo usados no dia-a-dia das empresas, desenvolvedores de software enfrentavam uma crise. Naquele momento (e isso não mudou até hoje), a maior parte do desenvolvimento de software era feita para o público empresarial e não para o consumidor final.
 
Empresas dos anos 1990, no entanto, evoluíam muito mais rapidamente do que as empresas de 25 anos antes. No espaço de três anos (tempo médio de desenvolvimento de um sistema de software complexo), demandas, requerimentos, sistemas e até empresas inteiras frequentemente sofriam grandes mudanças estruturais.
 
Isso resultava em muitos projetos sendo cancelados em meio ao seu desenvolvimento. E os projetos que seguiam chegavam ao seu final eram apresentados ao cliente com funcionalidades ultrapassadas, já que o cenário havia mudado muito nesse meio tempo. O que havia sido determinado há três anos atrás já não servia para as atuais necessidades da empresa e seus objetivos.
 
Jon Kern, um engenheiro aeroespacial nos anos 1990, era um entre tantos engenheiros extremamente frustrado com a maneira “dilbertesca” de trabalho da época. Programadores trabalhavam com o método de desenvolvimento “em cascata”, vigente até então. Esse método exigia que todos os mínimos detalhes de um projeto fossem descritos em um documento. Esse documento então era entregue aos engenheiros, que passavam anos trabalhando em seu desenvolvimento.
 
O resultado é o cenário que vimos acima. Ao final de três anos, as especificações determinadas por esse documento já estavam totalmente ultrapassadas e anos de trabalho eram jogados no lixo. Frustrados com essa situação, em 2001 Jon e outros 16 engenheiros se reuniram em uma cabana de esqui em Oregon, nos Estados Unidos com o objetivo de propor uma solução para o problema.
 
O objetivo dos participantes dessa reunião era encontrar maneiras de se produzir software rapidamente e colocá-lo o mais cedo possível nas mãos do usuário final. A rápida entrega de software para o usuário traz alguns benefícios importantes. O primeiro e óbvio benefício é o de que uma entrega rápida significa que o cliente receberia o programa mais cedo. O segundo benefício, no entanto, é o mais importante. Quanto mais cedo dentro do processo de desenvolvimento de software o usuário tiver acesso ao produto, mais rapidamente ele poderá dar feedback sobre o produto à equipe de desenvolvimento.
 
Desenvolvedores, em posse de dados importantes vindos de feedback do usuário final sobre o que estavam desenvolvendo, usariam esses dados para melhorá-lo. Aqui você já deve ter encontrado semelhanças entre o método ágil e o método científico. Um cientista “quebra” seu problema em hipóteses e as testa antes de prosseguir com sua teoria, moldando-a de acordo com os resultados dos experimentos. De maneira semelhante, um programador “quebra” seu produto em pequenos aplicativos funcionais para que o usuário teste-os. A partir dos dados coletados pelo uso do aplicativo, desenvolvedores decidem se devem trabalhar mais no que entregaram até agora e melhorá-lo ou seguir em frente para desenvolver novas funcionalidades.
 
O resultado daquela reunião em Oregon foram os doze princípios do desenvolvimento ágil:
  1. Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado.
  2. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente.
  3. Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo.
  4. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.
  5. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho.
  6. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face.
  7. Software funcionando é a medida primária de progresso.
  8. Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.
  9. Contínua atenção à excelência técnica e bom design aumenta a agilidade.
  10. Simplicidade–a arte de maximizar a quantidade de trabalho não realizado–é essencial.
  11. As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.
  12. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.
Da mesma forma em que growth hackers trabalham com uma versão do método científico, o método de Growth se apropria também dos princípios do método ágil como rotina de trabalho.
Se fossemos traduzir os princípios acima para uma linguagem de growth hacking, teríamos os seguintes princípios:
  1. Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de melhorias em todo o funil de marketing.
  2. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento de experimentos. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para a empresa.
  3. Colocar frequentemente funcionalidades e campanhas no ar, de poucos dias a poucas semanas, com preferência à menor escala de tempo.
  4. Growth Hackers e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.
  5. Construa uma equipe com indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho.
  6. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de growth é através de conversa face a face.
  7. O número de testes lançados por semana é a medida primária de progresso.
  8. O processo de Growth promove crescimento sustentável. A equipe de growth deve ser capaz de manter um ritmo constante (e crescente) indefinidamente.
  9. Contínua atenção à excelência técnica e bom design aumenta o crescimento.
  10. Simplicidade–a arte de maximizar a quantidade de trabalho não realizado–é essencial.
  11. Os melhores experimentos, campanhas e designs emergem de equipes auto-organizáveis.
  12. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.
Enquanto alguns desses princípios são auto-explicativos (e aplicáveis ao nível de senso comum) outros parecem contra-intuitivos à primeira vista. Então é interessante analisarmos alguns deles mais à fundo.
 
O Princípio Dois (2), por exemplo, considera que sejam bem-vindas mudanças e sugestões ao trabalho, mesmo que tardiamente no seu desenvolvimento. Isso quer dizer que, embora a velocidade de entrega seja um dos princípios mais importantes, profissionais de growth devem ser ágeis e flexíveis para fazer mudanças em seus experimentos, caso entendam que elas sejam cruciais para a qualidade dos mesmos.
 
Muitas vezes, quando se trabalha com inovação (que é o cerne do processo de growth), fica impossível prever todos os obstáculos e demandas de uma determinada funcionalidade ou campanha. Podem acontecer imprevistos que, por definição, não foram previstos anteriormente. Ao invés do desenvolvimento em cascata que tenta, em vão, prever toda e qualquer funcionalidade e cenário de uso, growth hackers confiam nas pessoas encarregadas de desenvolver seu trabalho e tomar decisões em prol sempre da qualidade do experimento.
 
Do Princípio Três (3) nós falamos acima, quando discutimos a necessidade de se buscar feedback o mais cedo possível no processo de desenvolvimento. O desenvolvimento ágil enfatiza “software funcionando, ” o que significa que, para se buscar feedback adequado, um programa precisa oferecer pelo menos as suas funcionalidades básicas. Dessa maneira, o usuário poderá ter uma melhor noção sobre o programa e irá gerar dados úteis para análise. Vamos ver mais sobre esse conceito no capítulo sobre MVPs (Minimum Viable Products).
 
No ponto de vista do growth hacker, isso significa que uma campanha, por exemplo, precisa ter um certo padrão de qualidade, embora seja apenas um protótipo. Essa contradição entre colocar rapidamente algo no ar e, ao mesmo tempo, se certificar de que exista uma qualidade mínima para que os dados gerados pelo experimentos sejam válidos, é uma constante na vida profissional de um growth.
 
Podemos pensar em um exemplo bem simples para ilustrar esse problema. Digamos que uma hipótese sobre as campanhas de anúncios no Facebook seja a de que anúncios que tenham fotos de pessoas felizes, ao invés de apenas fotos dos produtos, terá um impacto positivo na taxa de cliques desses anúncios. No entanto, se as fotos de pessoas usadas no experimento forem de baixa qualidade, é provável que isso irá impactar no experimento e isso impedirá que se faça uma análise conclusiva sobre o experimento. O resultado negativo se deu porque a nossa hipótese estava errada ou porque a qualidade das fotos era baixa? Por outro lado, se gastarmos uma fortuna com fotógrafos e modelos produzindo fotos para um experimento que tem alta probabilidade de não se confirmar, isso será um grande desperdício de tempo e dinheiro. Faz parte da criatividade do growth hacker (e essa é uma grande parte do trabalho) buscar soluções inteligentes para resolver esse tipo de contradição.
 
Os Princípios 4, 5 e 6 são sobre o correto gerenciamento da equipe. Uma equipe de growth é formada para executar seis funções básicas:
  • Gerenciamento do processo de growth
  • Análise de dados da empresa e experimentos
  • Programação
  • Design
  • Redação
  • Gerenciamento dos canais de aquisição mais importantes
Essas funções não precisam, necessariamente, serem executadas por seis pessoas. Se a sua empresa é pequena, é possível que uma só pessoa possa ser responsável por todas as funções. Existe também a possibilidade (embora esse não seja o cenário ideal) de que profissionais especialistas nessas funções não trabalhem em tempo integral na equipe de growth. Por exemplo, um membro da equipe de desenvolvimento poderá ser um membro honorário da equipe de growth, participando das reuniões e executando tarefas enquanto também trabalha em outras funções dentro da empresa. Ter membros dedicando 100% do seu tempo à equipe de growth é importante porque velocidade de execução é um dos princípios mais importantes do método de growth hacking, como demanda o Princípio Sete.
 
O Princípio Sete (7) pede atenção especial. Growth hackers medem o progresso do seu trabalho, não pelo aumento no número de vendas ou usuários, mas pelo número de testes lançados por semana. Isso pode parecer contra-intuitivo, mas se olharmos para o método de growth como um método que visa potencializar o aprendizado da empresa, isso faz todo o sentido. Inevitavelmente, enquanto você aprende cada vez mais sobre o seu mercado, canais de aquisição, consumidor e produto, os números finais de vendas e cadastros vão crescer aceleradamente.
 
Por isso o Princípio Oito (8) se refere a “ritmo”. Aqui não falamos sobre o ritmo de crescimento (por exemplo, 30% de crescimento por mês). O Princípio Oito se refere ao ritmo de trabalho. E como o trabalho do growth hacker é medido pelo número de experimentos lançados semanalmente, é sobre o ritmo de experimentos que estamos falando aqui. Isso requer que o processo seja gerenciado nos seus mínimos detalhes pelo Gerente de Crescimento (ou o Growth Master – análogo ao Scrum Master). Esse gerente é um gerente de processos (e não de pessoas) cujo trabalho é se certificar de que todos os elementos estejam nos lugares certos.
 
Uma equipe nova de Growth geralmente começa com um objetivo modesto. Podemos começar buscando um ritmo de três novos experimentos lançados por semana, por exemplo. Na maioria dos casos, esse é um objetivo difícil de ser posto em prática por uma equipe que acaba de se conhecer. As ferramentas de trabalho ainda não estarão todas sedimentadas e, principalmente, o ritmo e entrosamento ainda não estará no seu ponto ideal.
 
O Ponto Doze (12), aliás, se refere a resolver justamente esse problema. Em intervalos regulares, a equipe se reúne para avaliar o trabalho da semana anterior. Se a equipe não alcançou o objetivo da semana (por exemplo, o lançamento de três experimentos), avalia-se o porquê disso. Esse processo busca a melhoria do processo e não culpados. O papel do Gerente de Crescimento não é gerenciar pessoas, mas o método. Ele precisa se certificar que os obstáculos que a equipe enfrentou durante essa semana não sejam recorrentes. Normalmente os percauços enfrentados estão relacionados ao processo de trabalho entre os membros da equipe de growth e o resto da empresa.
Os lugares onde growth hackers trabalham para otimizar o seu trabalho em intervalos regulares são as reuniões semanais e mensais de growth, mas esse é o tema do próximo post. 

Share Your Thought