Cultura de dono intrínseca

Tenho ouvido com alguma frequência os termos “cultura de dono”, “mentalidade de dono”, “atitude de dono”. Acredito que seja uma tentativa de quebrar a barreira entre os donos de uma empresa e seus funcionários. Uma tentativa de alinhar propósitos para que todos “remem na mesma direção” como se costuma dizer. Essa relação entre donos de empresa e seus funcionários tem uma longa história. Vem da pré-história, da evolução do conceito de trabalho, quando o homem inventou instrumentos como a pedra lascada e o machado para sobreviver e, posteriormente, no desenvolvimento de atividades de caça, pesca, coleta e agricultura.

pedra_lascada

Durante boa parte de nossa história o trabalho foi considerado uma atividade depreciável pois por muito tempo foi associado à atividade de escravo ou de pessoas consideradas inferiores na sociedade. Os gregos, no período clássico, pensavam que só o ócio criativo era digno do homem livre e desprezavam o trabalho manual. O filósofo Aristóteles afirmava que ninguém poderia ser livre e ao mesmo tempo obrigado a ganhar o próprio pão. Na Idade Média, o trabalho também era considerado uma atividade desprezível. A sociedade feudal era dividida entre os senhores, donos das terras, e os servos, camponeses que trabalhavam em troca de moradia e proteção.

Desde então existe essa separação entre os donos dos recursos e as pessoas que trabalham na transformação desses recursos para gerar outros recursos. Com essa separação vêm a separação de propósitos e os conflitos. De um lado, os donos pensam que os funcionários não sabem o sacrifício que é construir uma empresa, as preocupações, as dívidas. Do outro lado, os funcionários acham que os donos estão com a vida ganha, que pagam baixos salários e ficam com todo o lucro para si.

Soluções para aproximar funcionários e donos

As relações de trabalho e de emprego têm evoluído muito ao longo dos anos. Várias ferramentas têm sido usadas para alinhar os interesses dos donos das empresas e seus funcionários. Alguns exemplos:

  • gestão participativa: é o envolvimento regular e significativo dos colaboradores nas tomadas de decisão que impactam a empresa. Por meio da gestão participativa os funcionários de uma empresa têm acesso às informações e opinam nas decisões da empresa, que podem ser desde decisões simples como decoração do escritório e definição de roupas adequadas para o ambiente de trabalho até decisões bem complexas como demissões, contratações e promoções, podendo chegar até mesmo a decisões estratégicas do tipo qual o tipo de cliente atender, que tipo de produto fazer e qual mercado atuar. Para que a gestão participativa funcione é importante educar os funcionários para que eles entendam quais informações são necessárias para as tomadas de decisão, como receber e interpretar essas informações e qual o impacto dessas decisões.
     
  • gestão de livro aberto: do inglês open-book management é bastante parecido com a gestão participativa e parte do pressuposto que os livros da empresa precisam estar abertos para todos os funcionários, ou seja, todos os funcionários têm acesso a todos os números da empresa. Há alguns livros sobre o tema sendo um dos mais conhecidos o livro chamado The Great Game of Business que conta sobre a implementação da gestão de livro aberto em algumas empresas. Nesse livro o autor comenta que durante a implementação da gestão de livro aberto é interessante perguntar para os funcionários, antes de mostrar os números da empresa, quanto eles acham que é o lucro da empresa. As respostas costumam vir sempre em valores acima de 50% e o espanto é considerável quando são informados que o lucro é bem menor que isso, podendo ser às vezes quase próximo de zero. Isso mostra como existe uma percepção diferente da realidade que pode dificultar a busca por resultados comuns que beneficiem donos e funcionários.
     
  • participação em resultados: é a distribuição do lucro da empresa para os funcionários. Quanto mais lucro tiver, mais os funcionários ganham, assim eles podem se sentir um pouco mais donos da empresa pois serão remunerados da mesma forma que o dono da empresa. Essa ferramenta é inócua caso os funcionários não entendam como seu trabalho pode impactar no resultado. Por isso cabe novamente reforçar a importância do treinamento para ajudar os funcionários a entenderem como a empresa consegue obter lucro e quais são as possíveis alavancas para mexer no resultado.
     
  • plano de compra de ações: esse costuma ser o ponto mais alto de possibilidade de ser dono da empresa. É a possibilidade de, dadas algumas condições específicas, o funcionário poder comprar ações da empresa, normalmente a preços com desconto, e se tornar sócio da empresa e, consequentemente, sócio do(s) dono(s) da empresa. Nesse caso o funcionário vira, literalmente, dono da empresa. Contudo, assim como nas ferramentas acima, o funcionário precisa entender o que é ser dono da empresa, qual o impacto que isso traz para si e para a empresa e como ele pode influenciar a empresa para que aquilo que ele seja dono não só continue existindo como também venha a ser mais valioso ao longo do tempo.<

Todas essas ferramentas são muito úteis e, se bem aplicadas, têm potencial de trazer a mentalidade de dono para o funcionário, ou seja, de quebrar essa distinção que existe entre donos e funcionários e alinhar os objetivos.

Extrínseco vs intrínseco

Contudo, essas ferramentas são externas ao funcionário, ou seja, trazem uma sensação de dono extrínseca ao funcionário. É um pouco como o conceito de motivação extrínseca. A motivação extrínseca está relacionada ao ambiente, às situações e aos fatores externos. Um exemplo claro de motivação extrínseca são as premiações de campanhas para a equipe comercial ou bônus oferecidos para vendedores que alcançarem determinado nível de vendas.

Além da motivação extrínseca existe a motivação intrínseca, ou seja, a motivação relacionada aos interesses individuais e que podem ser alterados apenas por escolha da pessoa. Geralmente, a motivação intrínseca está associada a metas, objetivos e projetos pessoais que estimulam a pessoa a acordar todos os dias, enfrentar dificuldades e se dedicar a horas intensas de trabalho.

Cultura de dono intrínseca

Da mesma forma que a motivação intrínseca, será que existe como a pessoa ter uma sensação de dono intrínseca? Parece bastante contraditório, como uma pessoa pode se sentir dono de algo que não é dela?

Acredito que aí esteja o “pulo do gato”. Apesar do funcionário não ser dono da empresa, ele é dono de algo relacionado à empresa. Ele é dono do que faz, ele é dono do seu trabalho e dos resultados gerados pelo seu trabalho. Aonde ele for ele pode falar sobre o que fez e sobre os resultados que gerou como sendo suas conquistas. Ele é dono disso. Então por que não usar essa perspectiva, essa nova forma de encarar seu trabalho, para encontrar o senso de dono intrínseco?

Mesmo que você não esteja numa empresa com gestão participativa, com gestão de livro aberto, com participação em resultados e plano de compra de ações, mesmo assim você pode trabalhar tendo “cultura de dono”, afinal, você é dono do trabalho que você faz. Você poderá contar para outras pessoas sobre o trabalho que você fez e sobre os resultados que o seu trabalho gerou. Em qualquer situação você pode usar o conceito de cultura de dono intrínseca para sempre produzir o melhor trabalho e gerar os melhores resultados! Certamente você sairá ganhando com isso e trabalhará mais feliz!

Churn negativo, o santo graal das empresas de produtos de software por assinatura

Santo Graal é uma expressão medieval que designa normalmente o cálice usado por Jesus Cristo na Última Ceia, e onde, na literatura, José de Arimateia colheu o sangue de Jesus durante a crucificação. O Santo Graal também está presente na história do Rei Arthur. É o objetivo da busca dos Cavaleiros da Távola Redonda. Há quem atribua a esse cálice poderes como prover felicidade e juventude eterna em abundância infinita. Por esse motivo chamo o churn negativo de o Santo Graal das empresas de produtos de software por assinatura. É algo buscado arduamente por essas empresas para alavancar seu crescimento, mas bastante difícil de atingir.

santo-graal

Contudo, antes de falar sobre churn negativo, vale relembrar o conceito de churn. Escrevi uma definição de churn em um artigo antigo meu intitulado “Seja uma data geek“, quando falei sobre um pedaço do funil de conversão que normalmente é pouco comentado:

Quantidade de usuários e clientes que deixaram de ser usuário ou cliente: eventualmente alguns usuários e clientes deixaram de ser seu usuário ou cliente. É importante saber quantos são, e os motivos por que isso acontece, pois aqui você descobrirá muito informação para melhorar seu produto web.

Pronto, está aí em cima a definição de churn, é a quantidade de clientes que deixam de ser seu cliente. Simples assim.

Esse número é muito importante em qualquer empresa que tem por modelo de negócio o uso contínuo, principalmente aqueles baseados em assinatura. Ele costuma ser medido como um percentual da seguinte forma:

churn mensal = quantidade de clientes que cancelou no mês / total de clientes do último dia do mês anterior

Existe também o churn anual que se calcula da mesma forma, só que dividindo a quantidade de clientes que cancelaram em um determinado ano pelo total de clientes do último dia do ano anterior.

É um número que contém muita informação mas, por ser somente um único número, ele deixa várias perguntas em aberto. Já vi discussões do tipo “se o churn está em 20%, em cinco meses não teremos mais clientes, então não vale a pena investir em divulgar esse produto”. Uma frase como essa não tem muito sentido pois mesmo que o churn se mantenha a 20% durante vários meses, até mesmo mais de 5 meses, a quantidade total de clientes pode continuar crescendo. Como? Basta ter uma quantidade maior de ativações do que de cancelamentos. Veja o exemplo abaixo:

exemplo_churn

Apesar de todos os meses o churn ser maior do que 20%, o crescimento no ano foi de 73 novos clientes.

Note que a quantidade de novos usuários (coluna “ativaram”) cresce ao longo dos meses. Por isso a quantidade de usuários ativos cresce apesar do churn de 20%.

Um exemplo real, os dados de novos assinantes e cancelamentos do ContaCal, experimento de startup que iniciei em julho de 2011 com o objetivo de avaliar se era possível criar do zero, sem nenhuma marca forte por trás, um produto web que desse algum retorno.

churn_exemplo_real

Como dá para ver acima, mesmo tendo churn superior a 20% e, em alguns meses, a 30%, há um crescimento da quantidade total de assinantes. Houve queda do total de assinantes em 3 meses, julho, agosto e dezembro. Em janeiro, mesmo tendo um churn de quase 36%, foi o mês em que o ContaCal mais cresceu.

Churn é um limitador do crescimento

Suponha que você tenha um churn mensal de 20% e que a quantidade de novos usuários por mês é 40. Com esses números, seu limite de crescimento será 200 usuários. Por quê? Simples, 20% de 200 é igual a 40. Você consegue 40 novos clientes todos os meses mas. Como seu churn é de 20% ao mês e você tem 200 usuários, você perde 40 usuários por mês. Ou seja, entram 40 novos clientes todos os meses, mas você perde 40 cliente todos os meses. Para voltar a crescer, você tem duas opções, diminuir o churn e aumentar a quantidade de novos usuários. O mais adequado é se focar nas duas opções, para aumentar sua chances de crescimento, pois só uma pode não ser suficiente. E há uma terceira opção, que comentarei mais abaixo.

Churn e o tempo de vida dos usuários

O churn varia de acordo com o tempo de vida do usuário, ou seja, varia de acordo com quanto tempo ele já é seu usuário. É comum ter casos onde o churn é alto no primeiro mês, pois o cliente não gostou do serviço e decidiu cancelar logo de cara. Ou no terceiro ou sexto mês, se sua cobrança for trimestral ou semestral. Algumas pessoas chamam esse churn de churn prematuro.

O churn prematuro, apesar de ser comum, é algo que pode ser diminuído. você faz isso:

  • alinhando a expectativa que o cliente tem alinhando a sua divulgação do produto com o que ele vai encontrar quando passar a usar seu produto.
     
  • garantindo que as primeiras experiências de uso de seu produto sejam muito boas e que seu cliente consiga atingir seus objetivos nesses primeiras experiências. Isso é conhecido como processo de onboarding do seu cliente.
     
  • mantendo seu produto útil para o seu cliente ao longo dos meses e dos anos, investindo em entender seu cliente e seus problemas e em atualizar seu produto para que ele continue resolvendo os problemas de seu cliente.

Veja o gráfico abaixo de idade do churn do ContaCal:

Idade do churn

Idade do churn

Separei o churn em 3 curvas, o churn total, o churn de boleto e o churn de cartão. Veja como o churn de cartão é uma curva suave, com números altos nos 3 primeiros meses, mas caindo para menos de 5% a partir do 5º mês. Isso me dá a impressão que o ContaCal é um pouco parecido com matrícula em academia. É algo que a gente sabe que precisa fazer, mas que nem sempre temos vontade e disposição de fazer.

A curva do boleto já tem mais picos pois durante algum tempo fiz o período mínimo de assinatura com boleto ser 3 meses e em outro período ser 6 meses, daí os picos de cancelamentos nos 3 e nos 6 meses de idade.

No ContaCal tenho apenas um plano e um preço. Você pode criar diferentes planos em seu produto e com isso terá que entender o churn de cada um desses planos separadamente.

Churn de receita

Além do churn de quantidade de clientes, existe também o churn de receita que é a quantidade de receita que você deixa de receber quando um cliente “churneia”, ou seja, quando deixa de ser seu cliente.

Ele também é um percentual e seu cálculo é feito da seguinte forma:

churn de receita mensal = receita mensal dos clientes que cancelaram no mês / total de receita do mês anterior

E aqui está a terceira opção para crescer apesar do churn, buscando formas de aumentar a quantidade de receita gerada por cliente. Como isso é possível? Há duas formas:

  • Cross-sell: é quando você oferece para seu cliente mais um produto que ele tem interesse em comprar.
     
  • Upsell: é quando seu cliente decide comprar um plano maior, ou quando decide comprar add-ons, funcionalidades extra de seu produto que você decidiu vender separadamente.

Por exemplo, suponha que você vende um produto para fazer lojas de ecommerce. Você criou seus planos baseados na quantidade de produtos vendidos na lojaQuerent:

  • 50 produtos: R$ 50,00 por mês
  • 500 produtos: R$ 200,00 por mês
  • 1000 produtos: R$ 300,00 por mês

Além disso, você criou add-ons e produtos para oferecer para seus clientes:

  • funcionalidade de multi-idioma e multi-moeda: R$ 200,00 or mês
  • 50 produtos adicionais: R$ 15,00 por mês
  • Email marketing: R$ 100,00 por mês para 5000 mensagens enviadas.

Você faz upsell quando um cliente está no plano de 50 produtos e decide ir para o plano de 500 produtos. Ou quando ele compra o aumento de limite de 50 produtos adicionais por R$ 15,00 por mês. Ou ainda, quando ele decide fazer a loja dele ser multi-idioma e multi-moeda, para que ele possa vender em outros países.

Você faz cross-sell quando vende o produto de email marketing para seus clientes de loja.

Com o churn de receita é possível ter o Santo Graal das empresas de produto de software por assinatura, o churn negativo. Churn negativo nada mais é do que quando a receita dos clientes que ficam na sua base aumenta, devido a upsell e cross-sell, mais do que a quantidade de receita dos clientes que “churnearam”.

Concluindo

Para ter um produto de software com um crescimento saudável e sustentável é preciso se focar em três fatores muito importantes:

aumentar a quantidade de novos clientes por mês;
diminuir a quantidade de clientes que “churneiam”, ou seja, que deixam de ser clientes, e;
aumentar a receita paga pelos clientes da sua base de clientes.

Como quadruplicar a produtividade de desenvolvimento de software sem aumentar o time e sem queda de qualidade

Escrevi há algum tempo atrás um artigo sobre como organizar times de desenvolvimento de produto e algumas mudanças que fizemos nos times de desenvolvimento de software da Locaweb.

Temos nos focado bastante, desde o ano passado, em produtividade, ou seja, em como os times de desenvolvimento de produto e de software da Locaweb podem produzir mais, sem precisarmos colocar mais gente nos times, e sem que a qualidade das entregas caísse.

O gráfico abaixo mostra nossos números. Contabilizamos quantidades de entregas por semana e, como dá para ver no gráfico, em algumas semanas mais do que quadruplicamos a quantidade de entregas por semana.

produtividade_800

Esse aumento de produtividade aconteceu quando o time cresceu apenas 10% em quantidade de pessoas, ou seja, não dá para creditar esse aumento de produtividade ao aumento de pessoas nos times.

Quando há um aumento desses, além do natural questionamento sobre se o aumento de produtividade se deve ao aumento de pessoas nos times, outro questionamento que existe é se houve queda da qualidade das entregas. Uma das medições de qualidade que fazemos é a quantidade rollbacks. Como dá para ver abaixo, mesmo com o aumento de produtividade, a quantidade rollbacks foi reduzido em 40%!

rollbacks_por_semana_800

Como conseguimos isso?

Não há bala de prata, foram várias ações que tomamos e temos certeza de que ainda há mais ações que poderão ser tomadas para aumentar ainda mais. Aqui vai uma lista do que fizemos.

  • Medir: antes de mais nada, para melhorar qualquer coisa é preciso medir, para poder saber se essa coisa está melhorando! Fizemos uns cálculos estimados de entregas por semana no período de setembro de 2015 a fevereiro de 2016. O cálculo foi bem simples, total de deploys feitos no período dividido pelo número de semanas. Passamos então a comunicar toda a empresa sobre as entregas da semana. Cada gestor de produtos me manda na sexta-feira as entregas da semana, eu compilo os dados e anoto a quantidade de cada semana, gerando esse gráfico mais acima. A partir do momento que começamos a medir, ficou mais claro o nível em que estávamos e as ações que passamos a fazer começaram a mostrar resultado no gráfico. Além disso, os times passaram a usar uma única ferramenta de medição, o Jira, o que deu a eles uma visão melhor de progresso de cada time e permitiu comparações com troca de experiência, ou seja, algo na linha de “olha que interessante no seu gráfico, como vcs conseguiram aumentar esse indicador?”
     
  • Kanban vs sprint: outro ponto que mexemos foi a mudança de Kanban para sprint. Antes, todos os times rodavam com Kanban. Só que no Kanban, quando um item tem um impedimento, ele não pode ser mexido, e o time não pode fazer mais nada, o time fica travado. Contudo, às vezes acontecia de o time, por estar impedido mover um item de “doing” para “to be done” e pegar outro item para fazer o que não deveria ser feito. Uma vez em “doing” a tarefa só pode ir para “done”, não pode voltar pra “to be done” pois perde-se o controle da produtividade. Com sprint, o time organiza as próximas duas semanas de trabalho, colocando vários itens para serem trabalhados. Assim, se algum item tiver impedimento, o time pode começar a mexer em outro item e, com isso, consegue entregar mais no mesmo intervalo de tempo.
     
  • Discovery e delivery: o que o designer de UX e o gestor de produtos fazem pode ser chamado de discovery, ou seja, descobrir o que é preciso ser feito. Já o que engenharia faz pode ser chamado de delivery, ou seja, fazer e entregar o que tem que ser feito. Essa separação de papéis parece óbvio, mas não deixar isso explícito nos times pode atrapalhar o processo de desenvolvimento de software. Por quê? Por alguns motivos. O primeiro é que se o discovery não é visto de forma explícita, não é claro o que é feito nessa fase e nem o que motiva certas decisões sobre o que deve ser implementado no software. É díficil fazer alguma coisa sem saber porque se estáfazendo aquilo. O segundo motivo é que quando essa separação não é explícita, itens podem ir e voltar de delivery para discovery e vice-versa sem critério. Não raro a gente via nos times algo sendo implementado pelos engenheiros e UX e gestor de produtos, ao verem sua especificação implementada, desejarem mudar algo, no meio do desenvolvimento. Com a separação clara entre discovery e delivery, definimos que, uma vez indo para delivery, não se mexe mais. Se quiser mexer de novo, deve passar por novo discovery para só então ir para delivery.
     
  • Tamanho das entregas: uma discussão que temos já há alguns meses é sobre o tamanho das entregas. Em alguns casos nossas entregas eram bem grandes, trabalho de várias semanas ou até alguns meses. Como já amplamente discutido em metodologias ágeis, a entrega frequente de software funcionando é um dos princípios de agilidade, reforçado pela técnica de entrega contínua. É só procurar no Google para encontrar inúmeros exemplos de empresas de primeira linha que fazem múltiplos deploys por dia, com algumas fazendo centenas de deploys por dia! :-O Para fazer isso, é preciso os deploys sejam de entregas pequenas, bem pequenas. É preciso dividir toda história grande em hostórias menores. Isso é trabalho deo gestor de produtos em conjunto com o designer de UX. Já me perguntaram se isso não é trapacear, afinal, ao invés de entregar uma história grande estaremos entregando a mesma coisa só que dividido em pequenas histórias. Parece ser a mesma coisa, mas ao invés de entregar algo grande depois de semanas ou até mesmo meses, a gente acaba entregando valor todo dia, e assim nosso usuário já pode usufruir dos benefícios logo, ao invés de esperar semanas ou meses. Além disso, ao colocar em produtção todos os dias, já podemos aprender com o feedback e ajustar entregas futuras. E ainda há um benefício adicional, o fato de colocar em produção todo dia algum código faz desse processo de colocar código em produção algo mais simples, exatamente pelo fato de ser feito diariamente. Então, entregar uma história grande num período de semanas ou meses não é a mesma coisa que quebrar essa história em pequenos pedaços e entregar um pedacinho todos os dias. Há ganhos claros de produtividade em se entregar pequenos pedaços com frequência.

Além desses pontos acima, estamos começando a experimentar mais alguns pontos que certamente têm impacto na produtividade:

  • Primeira solução vs solução mais simples: é da natureza humana querer resolver problemas. Assim que um problema aparece, a primeira reação é pensar em uma solução e sair implementando essa solução para resolver o problema. Só que nem sempre a primeira solução é a melhor solução, tanto do ponto de vista do cliente, quanto do ponto de vista de quem implementa a solução. Por esse motivo temos preferido não começar a resolver imediatamente cada novo problema que aparece. Buscamos antes verificar se há mais soluções possíveis, analisamos todas as soluções e só aí escolhemos uma solução e partimos para a solução. Investir mais tempo pensando em outras possíveis soluções, sempre tendo claro qual a questão a ser resolvida e porque precisamos resolver essa questão. Saber o porquê ajuda a encontrar soluções simples. Uma solução simples (1 semana de implementação) que resolve 70% a 80% do problema é melhor do que uma complicada (1 mês de implementação) que resolve 100% e, na maioria das vezes, resolver 70% a 80% do problemaé mais do que suficiente. Às vezes a solução mais simples é não fazer nada!
     

    Exemplificando, na Locaweb o serviço de hospedagem e de email pode deixar de funcionar por um motivo externo ao serviço. O domínio ao qual a hospedagem e o email estão ligados, que é pago anualmente para o Registro.br, pode não ter sido renovado e, quando ele não é renovado, os serviços associados a esse domínio deixam de funcionar, mesmo que tudo esteja operando perfeito na Locaweb. Recentemente a Registro.br disponibilizou uma forma de a Locaweb cobrar o domínio do cliente em nome da Registro.br. A princípio a ideia parece boa, com a gente cobrando a gente garante que o cliente sabe que tem pagar esse domínio para manter os serviços no ar. Só que, analisando um pouco melhor, vimos que essa solução pode gerar mais problemas. O cliente vai receber duas cobranças pela mesma coisa, o registro de domínio, pois o Registro.br iria continuar cobrando o domínio. O que acontece se ele pagar as duas cobranças? E se ele pagar só a da Registro.br? E se ele pagar só a da Locaweb? Além disso, implementar um novo tipo de cobrança, onde iremos cobrar pelo serviços de terceiro, seria algo novo para o time e para a Locaweb. Novos processos teriam que ser desenhados. Começamos então a pensar se não existiriam formas mais simples de resolver o problema de ajudar nosso cliente a não esquecer que ele tem que pagar por seu registro de domínio na Registro.br. Como para poder cobrar pela Registro.br é necessário acessar a informação de que o domínio está para expirar, pensamos na seguinte solução, vamos implementar uma régua de comunicação com esse cliente avisando-o da importância de pagar o Registro.br, para garantir que o serviço continue funcionando, solução essa bem mais simples que duplicar o processo de cobrança. Se a Registro.br fornecer tb link direto para a cobran;ca do domínio, podemos mandar esse link na comunicação e as chances de resolver o problema aumentam ainda mais. E uma régua de comunicação é bem mais simples de implementar do que uma cobrança duplicada.

  • Escolha da ferramenta mais apropriada: aqui o tema são ferramentas para implementação da solução, ou seja, linguagem de programação, frameworks e bancos de dados. Cada ferramenta tem suas características e essas características as fazem mais apropriadas para resolver certos tipos problemas. Escolher a ferramenta certa para cada problema vai impactar a produtividade. Esse é um tema que estamos começando a estudar agora. Hoje usamos Rails para quase tudo, mas tem alguns problemas para os quais a implementação de solução usando outro framework ou outra linguagem pode ser mais simples e rápido. Usar uma única linguagem de programação para todos os problemas é como usar uma única ferramenta para todos os consertos que tem que ser feitos. Será que o martelo é a melhor ferramenta para apertar um parafuso? Será que Rails é a melhor ferramenta para gerenciar filas?

Temos confiança de que com os dois pontos acima, que estamos começando a mexer agora, conseguiremos aumentar a produtividade por 10x ou mais! \o/

E com certeza há ainda pontos que sequer percebemos ainda e que, quando percebemos e tratarmos, podem impactar ainda mais.

Conclusão

Como disse acima que não há uma bala de prata, mas tem uma ação específica que fizemos que tem impacto crucial nesses resultados: transformamos produtividade em tema importante em nossas conversas. Todos passaram a conversar sobre produtividade, o que pode impactar e como endereçar esses pontos. Esse movimento nos fez iniciar várias mudanças e experimentos que nos ajudaram a aumentar consideravelmente nossa produtividade. Se você também quer aumentar a produtividade de seu time de desenvolvimento, coloque essa tema como tema central de suas conversas e experimente bastante. Vc verá como há espaço para melhorar bastante a produtividade dos seus times de desenvolvimento de software.

Entrevista: Eventials

Falei sobre a Eventials como caso prático no artigo sobre Mudança de rumo (pivot) e no artigo 5 anos depois, como está o ContaCal?, a Eventials aparece de novo como exemplo de empresa que conseguiu chegar à 4ª fase do ciclo de vida de uma statup, a fase da escala, que é a fase em que, se tudo tiver corrido bem nas fases anteriores (descoberta, validação e eficiência), é o momento de pisar no acelerador para fazer a startup crescer.

Logo_Eventials

Thiago-Lima

Para ajudar a conhecer um pouco melhor a Eventials, fiz uma entrevista com o Thiago Lima, fundador e CEO. Confira abaixo a entrevista completa:

Guia da Startup: Você poderia nos contar como surgiu a ideia da Eventials?

Thiago Lima: A idéia da Eventials surgiu em 2007, 4 anos antes do lançamento do primeiro MVP da Eventials. Naquele ano, eu estava cursando minha pós-graduação em Blumenau-SC e por estar fora do eixo Rio-SP, não conseguia acompanhar os melhores eventos de tecnologia e internet, área em que eu atuava profissionalmente, justamente por conta da distância.

Além de ser caro estar em SP todos os meses, o Brasil passava pelo “caos aéreo”, havia uma imensa dificuldade de locomoção. Isso me frustava bastante.

Mas em junho de 2007, quando eu ainda estava em Blumenau, a Apple fez o lançamento do primeiro iPhone em um evento chamado MacWorld, evento este que foi transmitido ao vivo para o mundo inteiro. Eu assisti esse evento ao vivo pela internet e a experiência foi fantástica. Mesmo vivendo em uma cidade do interior do Brasil, pude ter acesso a mesma informação que as pessoas presentes na MacWorld. Eu tinha uma dor (não poder participar de eventos que aconteciam no eixo Rio-SP), e com observação encontrei a solução: criar uma plataforma para transmissão de eventos online.

No mesmo dia comecei a desenhar a idéia.

GS: Como você validou que sua ideia poderia virar uma empresa?

TL: Após ter a idéia e fazer os primeiros sketchs, eu procurei a incubadora tecnológica de Blumenau em busca de apoio para desenvolver o produto (uma sala, telefone, mentoria, computadores, etc).

Uma incubadora é formada por um conselho de pessoas envolvidas diretamente com criação de novos negócios então o aceite deles para incubar esse projeto já serviu como uma validação inicial. Não é qualquer idéia que é aceita e naquele momento eu já tive pessoas experientes acreditando no negócio.

Mas logo ao entrar na incubadora eu não consegui me focar 100% no projeto que viria a ser a Eventials. Para poder desenvolver o projeto e contratar programadores, comecei a oferecer para o mercado de Blumenau algo que eu já sabia fazer, que era desenvolvimento de sites. Pensei que fazendo 3, 4 sites eu conseguiria juntar dinheiro para tocar o projeto mas o que aconteceu foi que fiquei por 4 anos desenvolvendo sites, e minha idéia inicial foi engolida pela criação de uma outra empresa, uma agência de desenvolvimento web.

Mas o sonho sempre permaneceu, eu tentava desenvolver qualquer coisa e na primeira oportunidade que tive de reservar um recurso financeiro com a lucratividade da agência eu consegui alocar parte do time de desenvolvedores da agência para desenvolver o primeiro MVP da Eventials.

Com o lançamento do primeiro MVP da Eventials no ar, nós oferecemos a solução gratuitamente para alguns eventos, que adoraram a idéia, e também para a faculdade de Blumenau e a Fundação CERTI, que contrataram e pagaram pela solução. Mesmo com um atraso de 4 anos, da idéia ao MVP, a primeira versão da Eventials era bastante inovadora para a época, ninguém transmitia eventos com a qualidade que fazíamos.

Nesses dois casos em que conseguimos “vender” a solução, a margem de lucro foi brutal, acima de 1000% e eles ainda acharam barato. Ficou evidente que aquele projeto tinha aderência com o mercado.

Curiosidade: a primeiro MVP da Eventials utilizou o Windows Streaming da Locaweb. Eu pagava R$ 199,00 reais pelo servidor e vendemos a transmissão de eventos por mais de R$ 6.000.

GS: Você teve sócios desde o início? Como você encontrou seus sócios?

TL: Quando eu apresentei a idéia da Eventials para a incubadora eu tive um sócio que cursava MBA comigo em Blumenau. Mas a sociedade durou pouco mais de 6 meses, rompemos quando percebemos que tínhamos criado uma agência.

Quando lancei a primeira versão da Eventials em 2011 eu não tinha sócios.

Mas em 2012 eu convidei o Luiz Fernando, que trabalhava na área comercial de uma agência concorrente, para ser meu sócio na agência de desenvolvimento web e na Eventials.

GS: O que te motivou a buscar um investidor como a Locaweb?

TL: O MVP da Eventials teve bastante aceitação, muitos elogios e também críticas. O mais importante contudo, foi que validou o aceite do mercado, ou seja, tinha valor e havia clientes dispostos a pagar.

Apesar disso, ele ainda não gerava receita suficiente para sua evolução. Ficou claro para nós que precisávamos de um investidor para acelerar isso e não perdermos o time to market. Nosso foco era a evolução do produto, ainda com modelo de negócio que precisava provar sua escalabilidade.

Chegamos a conversar com alguns fundos que se interessaram pelo negócio, mas em uma de nossas reuniões internas nós pensamos que antes de um fundo, a gente precisava de um investidor anjo, com muita experiência no mercado.
Como o fundo tem um prazo para saída, essa união teria objetivos diferentes, fundadores e investidores estariam pensando em coisas opostas. Nosso pensamento é de longo prazo, queremos permanecer na empresa por muitos anos ainda.

Decidimos então conversar com o Gilberto Mautner, fundador e presidente da Locaweb na época, por uma série de motivos: primeiro a admiração pela trajetória do Gilberto e da Locaweb, uma startup que deu certo no Brasil em um case único. Segundo porque a Locaweb era uma cliente da Eventials, e pagava pelo produto. Terceiro pela ética. E por fim, pelo conhecimento de mercado e na criação de produtos escaláveis.

Naquele momento, nós não sabíamos de nenhum investimento venture capital feito pela Locaweb. Não sabíamos nem se ela faria isso. Então a idéia inicial foi buscar o Gilberto para ser investidor anjo, que também não sabíamos se toparia, mas era algo mais factível para nós.

Consegui um almoço com ele em um evento e nesse almoço ele demonstrou interesse e marcou uma reunião de apresentação, para ele e o CFO da Locaweb.

Fizemos o pitch pensando em conseguir um investidor anjo, e nesse pitch mostramos que futuramente buscaríamos um investimento de venture capital. A Locaweb então propôs fazer todo o investimento de venture capital e se isso interessava para nós. Dei o aceite na hora.

Para nós estava muito claro a vantagem de ter um investidor como a Locaweb ao invés de um fundo. Nosso pensamento sempre foi de longo prazo, nós não queríamos nos preocupar em pensar em saída, vender empresa, fazer uma série de novos rounds. Como fundadores, a nossa visão com a Locaweb estava muito alinhada em construir um negócio sustentável, que mesmo que demorasse um pouco mais para escalar, pudesse ser algo sólido.

Além disso a Locaweb oferecia tudo que um fundo pode oferecer e mais um pouco. Além do dinheiro, temos acesso a toda estrutura do grupo, mentoring, gestão, governança. Nós literalmente pudemos nos concentrar em produto, marketing e comercial. A parte burocrática a gente conta com eles.

Aqui eu acho que tem uma coisa que vale comentar, que só percebemos depois do negócio fechado. O pitch que foi feito para Locaweb naquele dia teve uma importância muito pequena na conclusão do negócio.

O fato é que a Locaweb já conhecia nosso produto, usava, pagava por ele e estava satisfeita. As perguntas a serem respondidas para que ela pudesse fazer o investimento, ou não, eram muito simples:

  • Existem outras empresas como a Locaweb dispostas a pagar pelo que a Eventials está ofertando?
  • Esse modelo de negócio é replicável e escalável?
  • Estou pagando X para a Eventials e não vejo problema no preço. A margem é boa?

Com respostas positivas, o blá blá blá do pitch ficou em segundo plano.

No final de 2012 a Locaweb decidiu fazer o investimento na Eventials.

GS: Hoje podemos dizer que a Eventials atingiu a fase de “Escala”. Quais são, na sua opinião, os principais fatores que ajudaram vocês a chegar nessa fase?

TL: Muita observação e persistência. Nosso modelo de negócio mudou e isso foi crucial para a escala. No começo acreditávamos que os organizadores de eventos seriam nossos principais clientes. Mas esse público não nos trazia receita recorrente. Analisando a todo momento o perfil de nossos clientes, percebemos que quem realmente gerava receita recorrente eram pessoas e empresas que usavam nossa solução para fazer webinars.

Então mudamos, sem medo, o conceito e o foco da plataforma. Ao invés de transmissão de eventos, direcionamos para transmissão de webinars. E adequamos o modelo de negócio para quem usa com essa finalidade.

Um fator muito importante para escalar é manter seus custos o mais baixo possível até você descobrir o modelo de negócio escalável. Nosso investimento em marketing nos primeiros 3 anos foi zero, pois não estávamos certos de que o modelo escalava.

Nota: você pode conhecer mais sobre a mudança de modelo de negócio citada pelo Thiago no artigo Mudança de rumo (pivot).

GS: Como a Locaweb te ajudou a chegar até aqui?

TL: Desde de 2012, quando a Locaweb fez o investimento, eles têm nos ajudado bastante. Como expliquei acima, além do dinheiro, temos acesso a toda estrutura do grupo, mentoring, gestão, governança. Nós literalmente podemos nos concentrar em produto, marketing e comercial. A parte burocrática a gente conta com eles. Além disso, eles nos dão muito apoio em mentoring para tocarmos a Eventials. Desde o início de 2013 eu tenho reuniões quinzenais com o Joaquim Torres (Joca), diretor de produtos da Locaweb para conversarmos sobre gestão de produto, estratégia, execução, desenvolvimento, UX, etc. A cada 3 ou 4 meses temos reunião de Conselho onde podemos contar com o Gilberto, o Joca e outros executivos da Locaweb. E sempre que preciso, tenho acesso para falar com qualquer pessoa da Locaweb sobre os mais variados assuntos, RH, financeiro, marketing, vendas, UX, etc.

GS: Que conselhos você daria para quem está com uma ideia de montar uma startup?

TL: Siga em frente, vale a pena.

Mas esteja preparado pois não existe sucesso rápido, você vai precisar provar que é capaz antes do mercado te dar algo em troca. Construa um MVP, valide sua idéia, venda para alguém que não seja sua família. Não acredite nessas histórias de startups que já nascem com milhões em investimentos pois elas são raras e quando isso ocorre é porque o fundador já é muito rico e bem relacionado (o que não é caso da maioria de nós).

Mais lições aprendidas sobre OKRs

Já contei sobre como substituímos os roadmaps por OKRs na Locaweb. Nesse artigo também falei sobre algumas lições aprendidas. Acabamos de fazer a retrospectiva do último trimestre e adivinha só o que aconteceu? Aprendemos mais algumas coisas interessantes, que vou compartilhar aqui! :-)

Réguas claras para os KRs

Um dos pontos que chamou a atenção na última retrospectiva foram a falta de clareza da definição sucesso ou insucesso de cada KR. Na tentativa de criar um padrão de análise igual para todos os KRs, nós os definíamos sempre com um valor alvo e o critério de sucesso era definido como sendo o atingimento de 80% ou mais do valor alvo e o de insucesso era o atingimento de 40% ou menos do valor alvo.

okr_1

O problema é cada KR tem seu próprio contexto e sua própria mecânica. Enquanto para um determinado KR o atingimento de 80% de seu valor alvo pudesse ser considerado bom, para outro, esse mesmo atingimento de 80% poderia ser considerado ruim e, para ser considerado bom, seria necessário o atingimento de 98% do valor alvo.

Em função disso, cada KR terá agora 3 valores, o valor alvo, o valor acima (ou abaixo) do qual o KR será considerado OK e o valor abaixo (ou acima) do qual o KR será considerado como não OK.

okr_2

KRs semanais

Ao definir KRs, é comum nos depararmos com métricas de mensuração mensal como, por exemplo, churn, novas vendas, receita, margem, contatos de suporte e assim por diante. Como essas métricas são mensais, durante um trimestre teremos apenas duas oportunidades de avaliar se o que estamos fazendo está surtindo efeito em mover o ponteiro. Duas oportunidades é muito pouco, se você erra a primeira, só tem mais uma.

Por esse motivo nós decidimos nos esforçar em dividir métricas mensais em semanais. A ideia é fazer isso de forma bem simples, dividindo o valor mensal por 4. Por exemplo, se o objetivo for 2000 novas vendas por mês, deveremos ter pelo menos 500 novas vendas por semana. Assim, se numa determinada semana tivermos 380 vendas, saberemos que estamos atrás que teremos que compensar de alguma forma na semana seguinte. Um outro exemplo pode ser um KR de atingir um churn de 2% ao mês ou menor. Esse churn de 2% ao mês equivale aproximadamente a 0,5% de churn por semana. Assim, se numa determinada semana tivermos 0,3% de churn estaremos bem, mas se tivermos 0,6% de churn estaremos mal.

Com KRs semanais é possível acompanhar de forma fácil e frequente se estamos bem em relação a um determinado KR e fazer ações apropriadas para manter ou melhorar o KR sem ter que esperar o fechamento do mês para ver como estamos.

Lag measure vs lead measure

A maioria das métricas que olhamos podem ser chamadas de lag measures ou métricas históricas. Elas contam o resultado de algo que aconteceu, mas não contam o que foi feito para esse algo acontecer. Para que algo aconteça é importante que a gente saiba quais são as lead measures, ou seja, o que precisa ser feito. Exemplificando, quando uma pessoa emagrece 5 quilos em 3 meses, a lag measure é emagrecer 5 quilos em 3 meses, mas quais foram as lead measures feitas para atingir esse resultado? Provavelmente ela deve ter restringido sua alimentação a um determinado número de calorias por dia, evitado determinado tipo de alimentos e se exercitado por uma certa quantidade de minutos uma certa quantidade de vezes por semana. Essas são as lead measures que levaram à lag measure de emagrecimento descrita. Outro bom exemplo, agora que estamos próximos das Olimpíadas, são os resultados esportivos. Por exemplo, determinado país foi líder no quadro de medalhas dos últimos jogos Olímpicos. Essa é a lag measure. E quais foram as lead measures para obter esse resultado? Investiu em formação de atletas e em patrocínio para o esporte.

KRs normalmente são lag measures. NPS, TMA, novas vendas, receita, custo, churn, quantidade de contatos, etc. Todas essas métricas são lag measures. Mas quais são suas lead measures? O que as faz mudar de valor? O que as influencia? É muito importante conhecer esses influenciadores para saber onde trabalhar para mexer na métrica. Na Locaweb fizemos um trabalho de mapeamento de influenciadores de NPS e de TMA. Esse trabalho consistiu de algumas sessões de brainstorming onde procuramos identificar tudo o que influencia o NPS ou o TMA. Em seguida, para cada item, avaliamos se já o medimos, se o valor medido parece estar OK e qual o seu impacto, usando uma escala simples do tipo P, M eG, na lag measure. Com isso conseguimos um bom guia do que deve ser nosso foco para podermos melhorar o NPS e o TMA.

Dashboard visíveis

Outro ponto importante que pode ajudar bastante é o conceito de controles à vista. Esse conceito é bastante difundido nas metodologias ágeis, com os times tendo um quadro que os permite constante ver como andam as principais métricas e, em alguns casos, sua evolução histórica. O uso de controles à vista tem origem no sistema de produção usado em fábricas japonesas conhecido como kanban. Aliás, a palavra japonesa kanban significa, literalmente, cartaz ou placar.

A ideia aqui é criar um placa à vista que mostre o que são os OKRs e como eles estão progredindo. Com isso fica mais fácil para todo o time acompanhar a evolução de cada uma de suas métricas.

okr_dashboard

Contudo, só ter o dashboard visível não é suficiente. Ele precisa ser constantemente atualizado para ser útil. Daí a quinta lição aprendida.

OKRs weekly standup

Mais uma ideia que também está sendo “emprestada” das metodologias ágeis. Como explicado acima, não basta só o time criar o seu dashboard visível, ele precisa ser atualizado. A sugestão é atualizá-lo semanalmente, afinal definimos KRs para serem acompanhados semanalmente.

okr_weekly_standup_1

okr_weekly_standup_2

Uma reunião em pé de 15 minutos para atualizar os KRs, e cada um contar o que fez na semana passada e o que pretende fazer na semana atual. Algo bem simples, mas que ajuda na comunicação e no comprometimento do time.

Aprendizado contínuo

Temos aprendido muito com o uso dos OKRs. O fato de começarmos a medir mais nos ajuda a visualizar melhor como estão as coisas e a identificar pontos de melhoria. Temos certeza de que iremos continuar aprendendo bastante e vou continuar compartilhando à medida que formos aprendendo.

E vc, já implementou OKRs na sua empresa? Compartilhe vc também suas lições aprendidas!

5 anos depois, como está o ContaCal?

Agora em julho o ContaCal está completando 5 anos! Nesse artigo irei contar com está o ContaCal, experimento de startup que iniciei em julho de 2011 com o objetivo de avaliar se era possível criar do zero, sem nenhuma marca forte por trás, um produto web que desse algum retorno.

Esse experimento acabou virando um livro, o “Guia da Startup: Como startups e empresas estabelecidas podem criar produtos web rentáveis“, meu primeiro livro, lançado em 2012, que acabou sendo também o primeiro livro da editora Casa do Código, startup criada pelo pessoal da Caelum para edição de livros de tecnologia que hoje conta com mais de 380 títulos.

Quanto tempo demora até ter retorno?

Uma pergunta que todo mundo que começa um novo empreendimento se pergunta é quanto tempo leva para começar a ter resultados desse empreendimento. Como dá para ver acima, por mais rápido que se seja, o caminho é longo. As entrevistas que fiz (veja no índice) mostram sempre uma história de anos até ter os primeiros resultados. Mesmo nos produtos da Locaweb, após lançarmos o produto leva meses, e às vezes até mais de um ano, para atingir a rentabilidade no mês. Isso sem contar o tempo de desenvolvimento do produto. Por isso é importante estar preparado financeira e emocionalmente para a jornada.

Em 2012 foi disponibilizado um relatório chamado “Startup Genome Report“. Esse relatório é uma análise feita com dados de mais de 650 startups de produto web, feito por alunos e professores de Berkley e Stanford, com o apoio do Steve Blank, da Sandbox Network e de 10 aceleradoras de startup de todo o mundo. Vale a pena dar uma olhada. Tem muita informação interessante nesse relatório.

Esse relatório divide o ciclo de vida de uma startup em 4 fases:

  • Discovery: o foco é descobrir se o produto web resolve um problema e se há alguém interessado nessa solução. Média de 5 a 7 meses.
     
  • Validation: aqui o foco é validar se existem pessoas interessadas no produto em troca de dinheiro ou de atenção. Costuma demorar entre 3 a 5 meses.
     
  • Efficiency: esse é o momento de refinar o modelo de negócio e melhorar a eficiência da aquisição de clientes. Mais 5 a 6 meses.
     
  • Scale: Se tudo correu bem nas fases anteriores, aqui é o momento de pisar no acelerador para fazer a startup crescer. São mais 7 a 9 meses.
     

Ou seja, até chegar na fase de escalar são de 13 a 18 meses. No final do relatório é apresentado um gráfico que mostra o tempo que leva para chegar na fase de escalar em função do número de sócios-fundadores:

Tempo para chegar a fase de escalar

Esse gráfico mostra que leva pelo menos de 20 a 30 meses até chegar na fase de escalar. Isso se vc não estiver sozinho. Caso você esteja sozinho na sua startup, o que é o caso do ContaCal, pode levar mais de 5 anos.

A evolução do ContaCal

Desde o começo, em julho de 2011, até maio de 2012 foram os meses em que tentei entender se o ContaCal resolvia o problema de alguém e se havia alguém disposto a pagar por essa solução. Essa foi a fase de descoberta, e durou 9 meses.

Em seguida veio a fase de validação. Em agosto de 2012 o ContaCal havia atingido a rentadilidade no mês, ou seja, as receitas do mês foram maiores do que os custos do mês. Nesse momento comecei a investir um pouco mais em marketing para continuar fazendo a validação até maio de 2013.

A partir daí veio a busca pela eficiência.

Abaixo o gráfico de receita mensal do ContaCal que mostra essa evolução.

Evolução do ContaCal até jan/15

Retorno do investimento

Até hoje (julho/2016) investi R$ 136.201,82 no ContaCal e recebi R$ 137.668,52. O retorno do investimento acumulado só aconteceu há 3 meses atrás, 4 anos e 10 meses depois do primeiro mês. Esse prazo bate com o previsto pelo Startup Genome Report. Veja abaixo a curva de resultado acumulado do ContaCal.

contacal-resultado-acumulado

Então o ContaCal deu certo?

A resposta curta é depende!… :-P

Depende do ponto de vista. Como explicado acima, o ContaCal foi um experimento para ver se era possível criar do zero, sem nenhuma marca forte por trás, um produto web que desse algum retorno. Desse ponto de vista, ele deu certo, pois mostrou ser possível.

Do ponto de vista de retorno financeiro, não deu certo. A partir de julho de 2013 começou fase da eficiência, ou seja, de refinar o modelo de negócio e melhorar a eficiência da aquisição de clientes. O correto seria passar alguns poucos meses nessa fase para então entrar na fase de escalar, mas isso não aconteceu, como fica bem claro na imagem abaixo.

evolucao-contacal-2

Por que o ContaCal não escalou?

No artigo entitulado Quanto tempo dedicar? Quem devo chamar? eu falei sobre dois temas que poderiam ter influenciado o resultado e ajudado o ContaCal a escalar:

  • quanto tempo dedicar: no artigo minha recomendação era que “vc continue com seu trabalho atual e use-o para financiar sua startup. Depois que sua startup crescer, veja se ela demanda sua atenção tempo integral. Pode ser até que ela não demande a sua atenção em tempo integral, mas sim a de alguém com um perfil diferente do seu, que vc venha a contratar para tocar o dia-a-dia da sua startup que, a essa altura já não será mais uma startup.” A recomendação continua válida. Contudo, é importante ter clareza sobre qual o momento em que vc vai investir mais tempo na sua startup. Olhando em retrospecto, provavelmente no início de 2014 eu deveria começar a colocar mais energia no ContaCal. Ele estava começando a ficar cada vez mais eficiente e eu já precisaria ter estratégias para escalar. Muito provavelmente para escalar seria necessário mais dinheiro. É nesse momento que se busca investidores, que poderia ser eu mesmo, caso eu decidisse investir minhas economias, ou poderia ser parentes e amigos, outra possível fonte de dinheiro para investir em um novo negócio. Outra opção ainda seria buscar um investidor anjo, o que certamente dá um pouco mais de trabalho. Ou seja, em um determinado momento eu, ou alguém que eu contratasse, teria que se dedicar bastante ao ContaCal, com a missão de fazê-lo passar da fase de eficiência para a fase de escala.
     
  • quem devo chamar: no artigo comento que “essa é uma pergunta e uma decisão muito pessoal. Depende muito de sua personalidade. Ter sócio numa startup significa ter uma pessoa que vai trabalhar com vc nesses primeiros passos de desenvolvimento de seu produto web. Tem pessoas que não conseguem trabalhar sozinhas. Já outras só conseguem trabalhar sozinhas. E ainda há as que às vezes preferem trabalhar sozinhas e às vezes preferem trabalhar em conjunto com outras pessoas.” Sem dúvida é uma decisão bastante pessoal, mas até mesmo o Startup Genome Report deixa claro que a startup anda bem mais rápido de forem duas ou mais pessoas. Isso provavelmente acontece pelo comprometimento que cada pessoas tem com as outras para que a startup dê certo. Olhando em retrospecto, o ContaCal poderia ter se beneficiado se eu não o tocasse sozinho.

E por que eu decidi não dedicar mais tempo, nem procurei dividir com alguém? Porque o ContaCal era um experimento de startup. Meu objetivo não era fazer uma startup nem que gerasse meu sustento, nem que crescesse rapidamente, dois possíveis objetivos que expliquei no artigo sobre porque ter uma startup. Meu objetivo era ver se era possível criar do zero, sem nenhuma marca forte por trás, um produto web que desse algum retorno. E esse objetivo foi atingido! \o/

Exemplo de startup que escalou

No final de 2012 a Locaweb decidiu investir em uma startup chamada Eventials, uma plataforma para transmissão de palestras online. Nessa época a Eventials vinha crescendo em termos de visitantes e número de palestras online. A equipe da Eventials, na época 3 pessoas, decidiu reescrever toda a aplicação para atender a demanda por novas funcionalidades e evitar gargalos na infra-estrutura. No início do segundo trimestre de 2013 a nova aplicação foi lançada. Também nessa época a equipe da Eventials, que era de Blumenau, decidiu se mudar para São Paulo, para dentro do escritório da Locaweb. Sou membro do Conselho da Eventials e passei a ter reuniões quinzenais com o Thiago Lima, fundador e CEO, para que pudéssemos trocar experiências sobre startups e gestão de produtos. No início de 2014 decidimos mudar o modelo de negócios, de Freemium com “Pay-As-You-Go”, onde o palestrante podia criar palestras gratuitas mas, para poder ter funcionalidades mais avançadas tais como estatísticas, palestras pagas e palestras privadas, o palestrante precisava comprar créditos que eram consumidos quando os visitantes assistiam as palestras, para venda de planos com mensalidade, o que aumentou consideravelmente a previsibilidade da receita mensal da empresa.

A Eventials é um ótimo exemplo de startup que escalou. Ela foi fundada em 2010. Em 2012 o Thiago já tinha um time de pessoas com ele e procurou alguém para investir, além dele mesmo. A Locaweb decidiu fazer essa aposta. Até hoje a Eventials ainda não retornou tudo o que foi investido, isso porque toda a receita é reinvesitda na empresa. Contudo, ela já está num patamar de receita bem interessante, com mais de R$ 100K por mês. Veja abaixo a evolução de receita da Eventials e as fases do ciclo de vida claramente definidos.

evolucao-eventials

Concluindo

Como sua startup irá evoluir depende muito de vc e de seus objetivos. Isso tem a ver com o que escrevi no artigo sobre porque ter uma startup. É importante que vc tenha isso bem claro.

Se vc está construindo sua startup junto com alguém, vcs precisam estar alinhados sobre seus objetivos. Se vocês tiverem objetivos diferentes, isso certamente trará conflitos durante a jornada, conflitos esses que poderão chegar ao ponto de serem irreconciliáveis.

Vale lembrar que seus objetivos em relação à sua startup podem mudar ao longo do tempo, à medida que vc tem novos aprendizados pelo caminho.

No meu caso específico, meus objetivos em relação ao ContaCal se mantiveram os mesmos ao longo de todo o caminho, conduzir um experimento para ver se era possível criar do zero, sem nenhuma marca forte por trás, um produto web que desse algum retorno. Comprovei que é possível e aprendi bastante no caminho, não só com o ContaCal, como também com muitas pessoas das várias startups e empresas estabelecidas com quem conversei ao longo desses anos.

Como você sabe, esse aprendizado todo acabou virando um livro, o Guia da Startup: Como startups e empresas estabelecidas podem criar produtos web rentáveis, lançado em 2012. Agora no segundo semestre de 2016 vou lançar a segunda edição desse livro, revista e ampliada com todas as lições aprendidas desde então.

A falácia do cliente interno

Tenho visto com alguma frequência pessoas usando o conceito de cliente interno ou de usuário interno, quando se referenciam a trabalhos feitos entre áreas. Algo na linha de “eu tenho aqui uma demanda para você(s) e, como sou seu cliente/usuário interno, preciso dessa demanda solucionada por você(s) o mais rápido possível, preferencialmente até o dia X”. Tenho inclusive visto algumas pessoas propondo que avaliemos uns aos outros como clientes-fornecedores internos, ou seja que avaliemos satisfação do cliente/usuário interno com seu fornecedor interno.

O problema de usar esse conceito de cliente interno para a relação entre áreas é que ele tende a colocar as pessoas dessas áreas em lados opostos, ou seja, uma pessoa de uma área pede algo ou, termo que também já vi sendo usado, tem uma demanda, para outra área. Uma área pede e a outra faz. Se a outra área não fizer bem feito, a área que pediu reclama. Se a outra área não entregar no prazo combinado, a área de pediu reclama. Aí a área que atendeu a demanda justifica que o pedido não estava claro e que o pedido tem que ser feito no formato Z, especificando A, B e C pois, sem isso, não dá para atender a demanda direito, nem no prazo. E assim por diante.

Além disso, as empresas normalmente têm mais do que duas áreas. Assim, um área pode ter mais de um cliente interno e, consequentemente, pode receber várias demandas que, na maioria das vezes, são todas “pra ontem” e todas são “a mais importante para a empresa”. Aí começa a disputa de prioridades.

Cliente interno vs trabalho em equipe

Em 2001 um grupo de pessoas que trabalhavam com desenvolvimento de software sob demanda se reuniu para conversar sobre maneiras melhores de se fazer software. Essas conversas deram origem ao Manifesto Ágil contendo a base dos conceitos de agilidade que melhoraram em muito a taxa de sucesso dos projetos de desenvolvimento de software em nossa indústria. Durante essas conversas eles chegaram à conclusão que, dentre outras coisas, era necessário haver mais colaboração com o cliente. Ou seja, para ter mais sucesso nos projetos de desenvolvimento de software é essencial que o cliente seja parte do time que está desenvolvendo software, e não mero demandante espectador.

cliente-interno-x-trabalho-em-equipe

É preciso parar com esse conceito de cliente-fornecedor interno e voltar a usar o bom e velho conceito de trabalho em equipe, inclusive entre áreas diferentes. Trabalho em equipe não serve apenas para pessoas da mesma área, mas também para pessoas de áreas diferentes. Qualquer empresa pode e deve ser vista, em última instância, como uma equipe de equipes.

Para se trabalhar bem em equipe, é preciso ter empatia, ou seja, saber entender e respeitar o ponto de vista do outro, colocar-se em seu lugar, tentar entender como o outro pensa e porque ele pensa dessa forma. Áreas diferentes têm culturas e modos de pensar diferentes. E isso é bom! Equipes funcionam, principalmente, porque pessoas diferentes, colaborando entre si, são capazes de produzir um resultado de maior impacto do que se usassem somente suas habilidades individuais. Se todos pensassem igual, isso não seria possível. Por isso, para que haja um verdadeiro trabalho em equipe, é importante não só tolerar e conviver com as diferenças: é preciso explorá-las. É preciso colaborar, trocar conhecimento. Valorizar o conflito saudável, não ter medo de debater e discordar. Quando duas pessoas trocam ideias, cada uma sai com uma ideia a mais, todos ganham. Opiniões diferentes ajudam a construir, desde que motivadas não por ego ou desconfianças, mas sim pela crença num resultado melhor.

Exemplo prático

Para sair do teórico e citar um exemplo prático, vamos usar a necessidade de contratações de novas funcionários de uma determinada área que vai precisar do RH para efetuar essas contratações. Quando precisamos fazer novas contratações, devemos evitar simplesmente mandar para o RH um descritivo do cargo e aguardar passivamente o prazo que o RH tem para fazer essa tarefa e só aí chegar para o RH e perguntar se conseguiram preencher a vaga. O problema a ser resolvido é preencher a vaga com a melhor pessoa possível dentro da faixa salarial orçada para a vaga e dentro do prazo. Esse não é um problema só do RH. É do RH e da área que pediu. Por isso quem pediu deve trabalhar junto com o RH para preencher esse vaga, não só fazendo as entrevistas, mas também ajudando a divulgar a vaga, conversando sobre cada currículo recebido, cada candidato entrevistado e assim por diante. Uma nova contratação deve ser um trabalho em equipe do RH e da área que precisa fazer essa nova contratação. As chances de fazer uma boa contratação no prazo adequado são muito maiores quando a área que precisa fazer essa contratação e o RH se juntam e trabalham em equipe.

Por isso sugiro pararmos de usar o conceito de cliente interno e voltarmos ao bom e velho trabalho em equipe, inclusive entre áreas. Isso vai aumentar em muito a taxa de sucesso das novas empreitadas, assim como a motivação das pessoas das áreas envolvidas.

OKRs, o futuro dos roadmaps

Já escrevi vários artigos sobre roadmap:

  • O que é um roadmap? Nesse artigo explico que o roadmap é uma ferramenta útil para gestores de produto pois com ele é possível planejar e comunicar a visão de futuro que vc tem para o seu produto.
  • Como fazer um roadmap? Nesse artigo conto que para fazer um roadmap é preciso saber bem os objetivos estratégicos da empresa, os problemas e necessidades dos clientes e o que dá para fazer. De posse dessas informações é possível criar um bom roadmap.
  • Como priorizar um roadmap? Parte 1 e parte 2. Esses dois artigos contém várias técnicas que ajudam o gestor de produtos a definir as prioridades de seu roadmap.
  • Roadmap = motivação + métrica. Nesse artigo da série sobre roadmaps, falo sobre o quão importante é ter em seu roadmap não só o que se quer fazer como também a razão pela qual se quer fazer e quais as métricas que mostram que o que se fez está de fato atendendo a razão pela qual se quer fazer esse item.

Desde 2012 temos na Locaweb uma mecânica de revisar o roadmap a cada trimestre. No início de cada trimestre fazemos uma retrospectiva sobre o que foi feito no trimestre anterior, quais itens foram entregues, quais não foram e quais as razões de sucesso ou insucesso.

Esse último artigo sobre motivação + métrica foi escrito em meados de 2014. Ele foi fruto de várias conversas que tivemos na Locaweb sobre ter o roadmap como uma lista de itens a fazer a cada trimestre mas não estar sempre claro a razão de estarmos fazendo cada um daqueles itens planejados. Desde aquela época começamos experimentar fazer nossos roadmaps onde cada item deveria ser composto de 3 sub-itens, o que fazer, por que aquilo tinha que ser feito e qual a métrica que esperávamos mexer ao fazermos aquele item. Contudo, apesar de tentarmos deixar claro a motivação e a métrica de cada item do roadmap, as discusões acabavam girando mais em torno do “o que fazer” do que sobre a motivação e a métrica.

No primeiro semestre de 2015 ouvimos falar de um framework chamado OKR, que significa Objectives and Key Results. Esse framework é usado no Google desde seu início e foi trazido para lá por John Doerr, um funcionário da Intel, empresa onde esse framework foi criado. John Doerr, após sair da Intel, se tornou investidor em negócios de tecnologia tais como Google, Amazon, Intuit e Zynga e acabou levando esse framework para essas empresas. Várias empresas de tecnologia hoje usam OKRs. Mais alguns exemplos são Linkedin, GoPro, Flipboard, Yahoo!, Amazon, Adobe, Baidu, Dropbox, Facebook, Netflix e Spotify.

OKR é um framework derivado de uma ténica de gestão chamada de Administração por Objetivos, termo criado por Peter Drucker em seu livro The Practice of Management, de 1954. A Administração por Objetivos consiste num processo que requer a identificação e descrição precisas de objetivos a atingir e prazos para conclusão e monitorização. Tal processo exige que as pessoas envolvidas concordem com o que se pretende atingir no futuro e que todos desempenharão as suas funções em função dos objetivos.

Como funcionam os OKRs?

Existem vários artigos e vídeos que explicam em detalhes como funcionam os OKRs, por isso farei um explicação sucinta. Os OKRs são compostos de duas partes, um objetivo e de 2 a 5 resultados chave (key results) que indicam que o objetivo foi atingido. Por exemplo:

Objetivo: Ter clientes satisfeitos ao ponto de recomendar nossos serviços aos seus amigos
Key Result 1: Manter 80% das notas de pesquisa de satisfação acima de 8 numa escala de 0 a 10.
Key Result 2: Pelo menos 50% das novas vendas devem vir de recomendações de clientes existentes.

O objetivo não precisa necessariamente ter números. Já os key results devem obrigatoriamente ter algum número, ou seja, devem ser alguma métrica e devem dizer onde se está e onde se quer chegar com a métrica, ou seja, qual é a meta que queremos atingir com aquela métrica.

Recomenda-se ter pelo menos 2 key results pois quando há apenas um key result pode haver o chamado “efeito perverso”. Por exemplo, suponha que o objetivo seja aumentar a produtividade do time de atendimento telefônico e que seja definido um único key result que seria o TMA (tempo médio de atendimento) que hoje está em 8 minutos deve cair para 2 minutos. Uma forma de se atingir esse resultado chave é simplesmente o atendente desligar o telefone quando estiver próximo de dar 2 minutos de ligação. Claro que isso seria péssimo para a qualidade do serviço, mas o key result e o objetivo seriam atingidos. Nesse caso, para balancear o “efeito perverso”, é recomendável ter mais um key result que garanta que a satisfação do cliente que estiver sendo atendido não caia.

Implementando OKRs na Locaweb

Após estudarmos OKR por algum tempo, chegamos à conclusão que ele era muito parecido com o que sempre quisemos fazer, nos focarmos mais nas motivações e métricas do que no “o que fazer” propriamente dito. A grande diferença é que nos OKRs o “o que fazer” simplesmente não entra. Ele pode ser discutido quando se define cada objetivo e seus respectivos resultados chave, mas o “o que fazer” não é documentado e, por isso, não vira um compromisso e pode ser mudado. O que importa é o objetivo e os resultados chave que indicam que o objetivo foi atingido.

Para nos ajudar nessa mudança, chamamos o Felipe Castro, da Lean Performance, consultoria especializada em implementação de OKR. Chamamos ele em junho de 2015 e começamos a implementação no 3º trimestre de 2015, com uma série de treinamentos internos sobre OKR, definicão de objetivos, métricas e metas. Em agosto fizemos uma sessão de planejamento “café-com-leite” para definir OKRs para o mês de setembro. Foi apenas um teste para podermos entender um pouco melhor a mecânica do processo de definição de OKR. No final de setembro fizemos nossa primeira sessão de planejamento de um trimestre completo, onde definimos os OKRs do 4º trimestre de 2015 para os times de desenvolvimento e marketing de produtos da Locaweb. Em paralelo, continuamos com o planejamento trimestral de roadmap de produtos baseado em itens a fazer.

Cada time atualizava seus OKRs semanalmente. Além disso, acompanhávamos a evolução do roadmap mensalmente. Vimos ao longo desses acompanhamentos que os itens do roadmap eram as tarefas que habilitavam o atingimento dos objetivos e dos resultados chave, ou seja, havia um acompanhamento duplo para o mesmo trabalho. Ao longo desse acompanhamento surgiu a ideia: que tal abandonarmos o roadmap tradicional, da lista de tarefas a fazer, e focarmos apenas em definir e acompanhar OKRs?

De tarefeiros a gestores de ponteiros

Foi isso o que fizemos no planejamento de 1º trimestre de 2016. O planejamento foi feito totalmente baseado em objetivos e em métricas que queríamos mexer, ou seja, os ponteiros que queríamos gerir. Deixamos de ser meros tarefeiros, meros executores de tarefas, para nos tornarmos gestores de ponteiros. Dado um objetivo e uma métrica que indica que esse objetivo está sendo atingido, decidimos o que vamos fazer. Na reunião de revisão dos OKRs do 1º trimestre de 2016 e de planejamento dos OKRs do 2º trimestre, ninguém sentiu falta da lista de tarefas a fazer do antigo roadmap. Obviamente que durante a retrospectiva cada time comentou um pouco sobre o que fez para tentar mexer os ponteiros, mas o “o que fazer” passou a ser apenas um meio para se atingir um objetivo, e não mais o objetivo em si. E é claro que em cada sessão de planejamento de OKR os times já têm uma noção de “o que vão fazer” para atingir seus objetivos, mas eles têm autonomia para decidir esse “o que fazer” como quiserem.

Lições aprendidas

Temos aprendido algumas valiosas lições nesse quase um ano em que estamos lidando com OKRs. Essas lições aprendidas são relembradas frequentemente para que possamos constantemente melhorar nossas definiçãoes de OKRs:

  • Entregas e medições mais frequentes ajudam a atingir objetivos. Se houver entregas e medições apenas mensais, o time só terá duas chances no trimestre para testar sua ideia de como mexer a métrica. Se houver entregas e medições semanais, são 12 oportunidades de avaliar e mudar o rumo se necessário.
     
  • Objetivos técnicos podem e devem entrar se necessário. Alguns times de desenvolvimento de produto podem ter optado por colocar em seus roadmaps apenas tarefas que entregam valor para o cliente e preferem não colocar histórias técnicas como “atualizar versão da linguagem de programação” ou “rever arquitetura para torná-la mais escalável”. Esse era o caso da Locaweb. Ao fazermos a transição de roadmap para OKR, surgiu a dúvida se faria sentido definir objetivos técnicos, já que tarefas técnicas não entravam nos roadmaps. Após algumas conversas, todos concordaram que sim, podemos e devemos colocar objetivos mais técnicos em nossos OKRs. Por exemplo, ter infra mais robusta e escalável é um objetivo técnico que pode ter como métricas MTBF, MTTR, SLA, filas, etc.
     
  • Objetivos e KRs podem ser modificados ou mesmo cancelados, desde que isso seja combinado. Algumas vezes, ao começar a trabalhar em alguma métrica nova, que nunca se trabalhou antes, pode-se descobrir que mexer aquela métrica é mais difícil ou mais fácil do que inicialmente imaginado. É possível, nesse caso, mudar a meta daquela resultado chave, desde que todas as pessoas interessadas estejam de acordo. Também pode acontecer de um determinado resultado chave ou mesmo de um determinado objetivo ser menos importante do que algo que surge após o planejamento dos OKRs do trimestre. Também não é problema remover o OKR para colocar um novo, desde que todas as pessoas interessadas estejam de acordo.
     
  • Cuidado com interdependências. Tarefas que podem influenciar os KRs e que dependem de outros times que tenham outras prioridades ou mesmo de fornecedor externo têm grande risco de atrasar. O ideal é que sejam feitas no início do trimestre, ou mesmo no trimestre anterior. Em caso de interdependência onde um time precisa fazer A para que outro time possa começar a fazer B, pode-se colocar A nos OKRs do primeiro time em um trimestre e o outro time inclui B como OKR no trimestre seguinte.
     
  • Cuidado com métricas muito genéricas. Esse é um dos aprendizados mais recentes. Métricas como NPS e TMA (tempo médio de atendimento) são muito genéricas, ou seja, podem ser impactadas por uma quantidade enorme de fatores. Por exemplo, o TMA pode ser influenciado por razões tão distintas quanto o sistema de atendimento é lento, o produto está com uma usabilidade que deixa o cliente confuso, turn-over de funcionários de atendimento muito alto e assim por diante. Nesses casos é recomendável transformar a métrica em objetivo, por exemplo, “queremos baixar o TMA em 3 minutos” e definir KRs específicos como, por exemplo, “diminuir o tempo de carregamento do sistema de 30 segundos para 3 segundos”.
     
  • Cuidado com o excesso de otimismo! Quando se começa a trabalhar com OKRs e se começa a definir metas para as métricas, pode acontecer com muita frequência de as pessoas do time subestimarem o esforço necessário para mover o ponteiro. Existe uma tendência natural a setar metas muito otimistas e, na retrospectiva, perceber que mover o ponteiro é mais difícil do que o imaginado inicialmente. Nesses casos, na próxima sessão de planejamento de OKRs, pode acontecer o contrário, ou seja, após ter exagerado no otimismo, o time pode ficar receoso e acaba colocando metas muito tímidas.
     

Concluindo

Como eu disse acima, em nossas reuniões de retrospectiva e planejamento de OKRs na Locaweb, ninguém sentiu falta da lista de tarefas a fazer do antigo roadmap. Durante a retrospectiva cada time comenta um pouco sobre o que fez para tentar mexer os ponteiros, mas o “o que fazer” passou a ser apenas um meio para se atingir um objetivo, e não mais o objetivo em si. E é claro que em cada sessão de planejamento de OKR os times já têm uma noção de “o que vão fazer” para atingir seus objetivos, mas eles têm autonomia para decidir e mudar o “o que fazer” como quiserem, desde que atinjam seus objetivos.

Por esse motivo, está cada vez mais claro para mim que os OKRs são o futuro dos roadmaps. É uma ferramenta que coloca os objetivos e as métricas no centro da discussão, deixando a decisão do que fazer mais fluída e flexível, dando aos times mais autonomia na decisão sobre o que fazer.

Agile Trends 2016

Sexta-feira, dia 29/04, estarei no Agile Trends falando às 10:15 na Sala ContaAzul sobre “Diversificação ou foco, qual a melhor estratégia para sua empresa?“. Espero você lá!

logo-agiletrends-350x218

Aqui está a descrição da trend talk: “Google, Microsoft e várias outras empresas adotaram a estratégia de diversificação do portfólio de produtos. Já Facebook, Twitter, airbnb, Uber e vários outras empresas optaram pelo foco em único produto. Qual a melhor estratégia? Quando aplicar uma ou outra? Nessa trend talk serão apresentados pontos positivos e negativos das duas estratégias e técnicas para gestão de portfólios de produtos.”

Principais características de um gestor de produtos

O que uma pessoa precisa ter para ser um bom gestor de produtos? Existem algumas características bem importantes e falarei sobre elas aqui, mas a mais importante de todas é, sem dúvida alguma, a empatia.

empatia

Empatia é a capacidade que uma pessoa tem de se colocar no lugar de outra para compreender os seus anseios, motivações, necessidades e problemas. Essa característica é importante para entender os clientes e usuários do produto, saber como estes se relacionam com ele, e que problema esperam resolver ou que necessidade querem ver atendidas. Isso ajudará o gestor de produtos a entender melhor seu usuário para poder, junto com o UX e a engenharia, desenhar o melhor produto.

Contudo, a empatia não deve ser usada apenas com o cliente ou usuário. O gestor de produtos deve usá-la também no seu relacionamento com todas as áreas da empresa, e deve entender o impacto que seu produto tem no trabalho delas. Será que aumentaram os problemas jurídicos devido a alguma funcionalidade nova no produto? Qual o impacto para a equipe de vendas, suporte, operações, financeiro e marketing? Até mesmo em relação ao time do produto, engenheiros e analistas de UX, como o produto interfere no trabalho desses profissionais?

A segunda característica mais importante é a comunicação.

comunicacao

Para poder ter empatia, é necessário que o gestor de produtos se comunique com as pessoas nos mais diferentes cenários: em conversas um a um e em pequenos grupos, ou fazendo apresentações para grupos pequenos e grandes de pessoas, estes que podem ser internos (dentro da empresa) ou externos (em conferências, grupos de usuários etc.).

Deve também ser bom de comunicação escrita (e-mail, blog, documentação, chat, redes sociais etc.), e ser capaz de discernir sobre qual a forma de comunicação mais apropriada para cada momento, público e meio de comunicação; e de se comunicar de forma a ser entendido pelos diferentes públicos: técnico e não técnico.

Como se isso tudo não bastasse, ele também precisa ser capaz de se comunicar passando segurança e confiança no que está comunicando; afinal, o gestor de produto é o porta-voz do produto.

Porém, não é só de falar que vive o gestor de produtos. Comunicação é uma via de mão dupla, ou seja, o gestor de produto tem de ser muito bom em saber ouvir e compreender o que os outros estão dizendo, e entender os anseios e as necessidades deles; o que tem a ver com a primeira característica, a empatia.

A terceira característica mais importante é a gestão do tempo.

O dia a dia de um gestor de produtos pode se encher rapidamente de tarefas, e ele precisa ser capaz de perceber e diferenciar o que é urgente do que é importante, para garantir que terá sempre tempo para conhecer mais sobre o cliente e o usuário de seu produto. É muito fácil um gestor de produtos ver sua agenda repleta de reuniões, com pessoas de diferentes áreas para tratar dos mais diversos assuntos: backlog do produto, atendimento, comunicação de marketing, problemas operacionais, revisão de previsão de crescimento, questões jurídicas, cobrança, régua de comunicação etc.

Isso acontece pois o gestor de produto deve cuidar de seu produto por inteiro. Para o usuário, não existe engenharia, operações, financeiro, jurídico, atendimento e cobrança. Ele enxerga tudo isso como parte do produto que você cuida; e você tem sim de se importar com tudo isso. Contudo, importar-se não significa que você deva ir a todas essas reuniões. Se você fizer isso, poderá tirar o foco do que é mais importante para o seu produto.

Você, como gestor de produtos, precisa focar seu tempo em:

  • Com quantos clientes e usuários você falou essa semana?
  • Você tem uma estratégia e uma visão de longo prazo para o seu produto?
  • Como está e quais as últimas mudanças no cenário competitivo de seu produto?
  • Que insights você teve sobre o seu produto essa semana?
  • Você sabe qual a motivação e a métrica de cada item de seu roadmap?
  • Que novas tecnologias você vê aparecendo que podem influenciar, ou mesmo competir, com o seu produto?
  • Que novas habilidades você está procurando aprender?

As reuniões que mencionei anteriormente são importantes, e aconselho você participar delas quando puder. Apesar disso, você terá muito pouco a contribuir para essas reuniões se você não se focar nos 7 itens que acabei de listar. Procure bloquear um tempo em sua agenda para focar nisso, e você verá como sua participação nas reuniões será muito mais útil e produtiva.

Além dessas três características (empatia, comunicação e gestão do tempo), existem mais quatro que vão ajudar o gestor de produtos a fazer seu trabalho melhor:

  • Novas tecnologias: o gestor de produtos deve estar antenado sobre as novas tecnologias para saber como ela pode impactar o seu produto. Acesso via smartphone, como isso impacta o produto? O usuário quer acessar via smartphone? Para fazer o quê? Redes sociais, como o produto pode tirar proveito delas? Bancos de dados não relacionais, quais os benefícios e as deficiências? Go, a nova linguagem de programação do Google, no que ela é melhor do que a linguagem usada no produto? E no que ela é pior? Smartwatches, smartglasses, como isso impacta o produto? Como o usuário espera interagir com o produto nessas novas interfaces?
     
  • Business skills: o gestor de produtos deve se preocupar se o seu produto está atingindo os objetivos de negócio. Se o objetivo for margem, receita menos custos estão sob controle? Se o objetivo for só receita, como está o crescimento de receita? Se o objetivo for número de usuários, como está evoluindo essa métrica? Além disso, o gestor de produtos deve entender como cada área da empresa funciona e como o produto afeta essas áreas. Como o jurídico funciona? Como o produto impacta o departamento jurídico? E como o departamento jurídico impacta o produto? Essas perguntas podem ser repetidas para todas as áreas da empresa: suporte, operações, financeiro, RH, marketing, vendas, engenharia e UX.
     
  • Curiosidade aguçada: o gestor de produto precisa ter a capacidade de aprender rápido para poder ter insights e fazer julgamentos sobre o produto. Deve ser capaz de aprender tanto o lado soft do produto (qual é a motivação de negócio, qual problema do cliente o produto resolve etc.) como o lado mais técnico (qual tecnologia usamos, qual o impacto dessa tecnologia, que métricas podemos obter etc.).
     
  • Tema do produto: por fim, mas não menos importante, o gestor de produtos precisa conhecer sobre o tema do produto. Se for um produto médico, o gestor de produto deverá entender um pouco sobre medicina. Se for um produto financeiro, deverá conhecer um pouco de finanças. Por exemplo, na Locaweb, temos produtos mais técnicos (como o Cloud Server) e menos técnicos (como a Loja Virtual). A necessidade de conhecimento técnico é bem diferente nesses dois produtos. O gestor de produto do Cloud Server deverá conhecer bem a fundo questões técnicas, enquanto o gestor de produto da Loja Virtual não precisa ter tanto conhecimento técnico, mas deverá saber bastante sobre questões de venda online.

Dá para perceber que essa lista é um conjunto de características que nem todas as pessoas têm. É comum casos de pessoas de outras áreas que resolvem experimentar a carreira de gestor de produtos, mas que, após algum tempo, percebem que não têm todas as características necessárias.

Se você é um gestor de produtos, ou deseja ser um, faça uma autoanálise para ver como você está em cada uma das características e, se alguma estiver aquém do desejado, foque em desenvolvê-la. Se você é responsável por identificar e contratar gestores de produto, use essa lista como guia para saber se o candidato tem as características necessárias para ter sucesso como gestor de produto.