Mais sobre priorização de roadmaps

Como comentei em meu artigo anterior, priorização é uma das principais tarefas de um PO e de um PM, e é o diferencia um PO de um BA. Escrevi um artigo sobre as várias formas de priorização e sobre como dizer não aos inúmeros pedidos que recebemos tanto dos clientes quanto das pessoas de dentro da empresa.

priorizacao

Como o passar do tempo aprendi mais maneiras de se priorizar um roadmap e queria compartilhá-las aqui.

Sequenciador de Funcionalidades

O Sequenciador de Funcionalidades foi criado por Paulo Caroli, da ThoughtWorks, para auxiliar no planejamento de um produto a partir de suas funcionalidades. As regras desse método, como o limite de 3 cards por linha, auxilia na conversa sobre priorização.

O Sequenciador de Funcionalidades ajuda a organizar e visualizar as funcionalidades e sua relação com os entregáveis. O sequenciador organiza as releases do produto além do primeiro entregável. Tipicamente, times utilizando o sequenciador de funcionalidades irão vislumbrar a evolução do produto por meio de um entendimento claro das funcionalidades de cada entregável bem como a ordem dos releases.

secuenciador-2

De acordo com Paulo Caroli, em seu livro Direto ao Ponto, Criando produtos de forma enxuta, o Sequenciador de Funcionalidades funciona da seguinte forma:

Feature é a descrição de uma ação ou interação de um usuário com o produto. Por exemplo: imprimir nota fiscal, consultar extrato detalhado, e convidar amigos do facebook. A descrição de uma feature deve ser o mais simples possível. O usuário está tentando fazer uma coisa. O produto deve ter uma feature para isso. Que feature é essa?

Cada cartão de feature possui uma cor representado o nível de incerteza, e marcações para o nível de esforço e o valor de negócio. Por exemplo, a figura acima mostra features em index cards, nas quais foram adicionadas marcações de $, $$ ou $$$, respectivamente, para valor de negócio alto, muito alto e altíssimo, bem como E, EE, ou EEE, respectivamente, para nível de esforço baixo, médio e alto. O nível de incerteza é representado pela cor do cartão de índice, os quais são verde, amarelo ou rosa, indicando níveis baixo, médio ou alto de incerteza, respectivamente.

O nível de incerteza da Feature refere-se ao grau em que a Feature é incerta, a partir do ponto de vista do entendimento de negócio e do entendimento técnico. Isso é indicado pela cor do cartão de índice, os quais são verde, amarelo ou rosa, indicando níveis baixo, médio ou alto de incerteza, respectivamente. O entendimento da Feature de acordo com os desafios técnicos, e os requisitos de infraestrutura. Você já fez isso antes? Você sabe como fazê-lo? Um sim bem firme indica elevado nível de entendimento técnico. A clareza do objetivo da Feature, o benefício para o negócio e o que deve ser feito. O que fazer? Uma resposta direta e clara indica um alto nível de concordância.

Esforço da Feature

O nível do trabalho que precisa ser feito para a Feature. O entendimento da equipe de acordo com a dificuldade e o trabalho que vai ser necessário para completar a Feature.

Valor do Negócio da Feature

O valor de negócio, o ROI (Return On Investment) associado a Feature, uma medida do negócio sobre o valor previsto para tal feature. Qual é o retorno no investimento ou a economia que a Feature vai trazer?

As regras do sequenciador de features

Features serão adicionadas a cada onda. A seguir, as seis regras para adicionar features às ondas. Tais regras foram definidas depois de aplicar esta forma de planejamento e priorização inúmeras vezes.

  • Regra 1: Uma onda pode conter no máximo 3 features.
     
  • Regra 2: Uma onda não pode conter mais de uma feature em cartão vermelho.
     
  • Regra 3: Uma onda não pode conter três features, somente em cartões amarelos e vermelho.
     
  • Regra 4: A soma de esforço das features não pode ultrapassar 5 Es.
     
  • Regra 5: A soma de valor das features não pode ser menos de 4 $s.
     
  • Regra 6: Uma onda tem de conter no mínimo 2 features.

A regra 1 limita o número de features que estão sendo trabalhados ao mesmo tempo. Isso evita o acúmulo de features parcialmente completas, aumentando o foco para as poucas features priorizadas por onda. As regras 2 , 3 e 4 evitam um período de trabalho desequilibrado com muita incerteza, ou muito esforço. As regras 5 e 6 garantem o foco constante na entrega de alto valor para o negócio.

Os MVPs no sequenciador de features

Além dos cartões de features (sequenciados), o sequenciador de features mostra claramente o agrupamento de features para cada MVP. Isto é representado por post-its no canto direito sobre a linha que delimita uma onda.

As ondas não terão necessariamente uma relação de um para um com os MVPs. O intuito é de organizar features em ondas para entregar valor o mais rápido possível, entretanto respeitando as dependências entre as features

RICE

Quando cheguei na ContaAzul me deparei com outro método de priorização adotado pelo time de produtos, o RICE.

RICE é a sigla em inglês para Reach (Alcance), Impact (Impacto), Confidence (Confiança) e Effort (Esforço). Os três primeiros itens da matriz são pontuados e, ao final, divididos pelo último.

Alcance se refere a quantas pessoas aquela tarefa irá alcançar num determinado período de tempo, que deve ser igual para todas as features que estão sendo comparadas. Impacto estima a quantidade de pessoas que serão impactadas (use o valor 3 para um impacto massivo, 2 para um grande impacto, 1 para médio, 0.5 para pequeno e 0.25 para um impacto mínimo). Confiança aborda o quão confiante você está sobre suas estimativas (escolha entre 100%, para uma alta confiança, 80% para média e 50% para baixa). Em Esforço, coloque quantas pessoas-mês a tarefa levará para ser concluída sendo o mínimo o valor 0,5, ou seja, uma pessoa por meio mês.

O cálculo matemático é bem simples:

RICE = (Alcance x Impacto x Confiança) / Esforço

A melhor ferramenta de priorização

Tanto o índice RICE quanto o sequenciador de funcionalidades são excelentes ferramentas para o gestor de produtos poder ter mais confiança em sua priorização. Contudo, como eu disse no meu primeiro artigo sobre o tema:

…existem várias maneiras de se priorizar um roadmap, todas elas bastante úteis. Ou seja, o que dá para concluir é que, se há tantas maneiras de se priorizar um roadmap e se todas as maneiras de se priorizar podem ser úteis, isso significa que priorização de roadmap não é uma ciência exata.

Temos um anseio de querer achar um método de priorização para justificar nossas escolhas, mas sempre que esse método falhar em um determinado item que temos certeza que seria melhor fazer antes ou depois do que o método diz, acabamos tentados a seguir essa nossa certeza, pondo abaixo o método.

Por isso, por mais que existam várias técnicas e métodos de priorização de roadmap, o melhor método é o bom senso, ou seja, a capacidade do gestor de produtos de analisar as opções disponíveis e, usando-se de sua empatia, priorizar essas opções levando em conta os objetivos da empresa e as necessidades dos usuários.

E por que é preciso incluir o bom senso como mais uma ferramenta de priorização? Porque para priorizar é preciso entender os objetivos dos usuários de seu produto de software e do dono do software. Esse objetivos podem ser conflitantes e, provavelmente, existem mais variáveis do que alcance, impacto, confiança, esforço, retorno, valor, custo, satisfação e necessidade para ajudar a quantificar esses objetivos. Como se não bastasse a grande quantidade de variáveis e os objetivos conflitantes dos usuários do produto de software e do dono de software, há ainda a variável tempo, ou seja, esses objetivos podem mudar ao longo do tempo.

Toda priorização é uma decisão e todo processo decisório é composto de incertezas. As ferramentas acima ajudam a remover um pouco das incertezas. Contudo, com essa grande quantidade de variáveis, é muito difícil, diria até que impossível, remover 100% das incertezas. Por esse motivo, para fazer uma boa priorização, pode ser útil usar uma ou mais dessas ferramentas descritas, mas é importante usar também o instinto, a experiência e o bom senso.

BA, PO e PM

Escrevi em julho de 2014 sobre as diferenças entre gestor de produtos ou product owner, onde comento que gestor de produtos e product owner são dois lados da mesma moeda. Enquanto o papel de gestão de produtos é focada no resultado, ou seja, no software que está sendo feito e nos objetivos desse software, tanto para o dono do software quanto para seu usuário, o papel de product owner é focado no processo pois todas a metodologias ágeis tem seu foco no processo de desenvolvimento de software.

Em um outro artigo, de março de 2016, comento que “BA e PO são papéis muito similares no desenvolvimento de software. Ambos têm o mesmo objetivo: ajudar o time a fazer um software que atenda ao objetivos do dono do software enquanto resolve problemas e necessidades de seus usuários”.

Algum tempo depois…

Esse dois artigos foram escritos baseados em minha experiência na Locaweb, onde tínhamos somente o papel de gestor de produtos, que chamávamos indiscriminadamente de PO ou de PM e em conversas que tive com pessoas de outras empresas onde elas me contavam sobre suas estruturas e divisões de papéis e responsabilidades.

Em agosto de 2016 assumi a gestão da gestão de produtos na ContaAzul e quando aqui cheguei me deparei com business analysts (BAs) e product managers (PMs), um cenário novo para mim. Passei algum tempo conversando com as pessoas para entender papéis e responsabilidades de cada função e as motivações de essa estrutura ter sido criada. Após essas conversas, ficou mais claro para mim a diferença de papéis e responsabilidades de cada uma das funções, diferença essa que tento traduzir na imagem abaixo.

ba-po-pm

Essa imagem mostra alguns pontos importantes:

  • POs fazem o que BAs fazem (especificação) mais a priorização do que precisa ser feito. E os PMs, além de priorização e especificação, são responsáveis pelo desenvolvimento, comunicação e execução da visão e estratégia do produto. Ou seja, existe um aumento de escopo e responsabilidade à medida que se move na carreira de BA para PO e depois para PM.
     
  • Apesar de o PM ter por sua responsabilidade o desenvolvimento, comunicação e execução da visão e estratégia do produto, ele também é responsável pela priorização e pela especificação.
     
  • Pode fazer sentido em algumas empresas ter BAs e PMs, ou POs e PMs, ou mesmo BAs, POs e PMs. Contudo, não pode haver empresas sem alguém fazendo o papel de PM, ou seja, desenvolvendo, comunicando e executando a visão e estratégia do produto.
     
  • Caso haja em uma empresa, além dos PMs, pessoas exercendo função de BA e/ou PO, é possível colocar os PMs como gestores dos BAs e/ou POs. Contudo, isso cria uma carga extra para o PM que, além de gerir o produto, terá que se preocupar com gestão de pessoas.
     
  • Minha preferência é por não ter essa separação de papéis e ter apenas PMs, ou seja, se houver BAs e ou POs numa determinada organização, minha recomendação é por tratar esse papéis como passos intermediários de carreira que vão evoluir para atingir o nível de PM, com aumento de escopo e de responsabilidade. A justificativa para essa minha preferência é que, ao deixar os papéis separados, pode acontecer de o PM fazer pouca ou nenhuma especificação e/ou priorização, delegando essas responsabilidades para BAs e/ou POs. Ao fazer isso, o PM perderá insumo importante para o desenvolvimento da visão e estratégia do seu produto.

Acredito que com essa imagem consegui deixar mais claro as diferenças e similaridades das funções de BAs, POs e PMs.

Retrospectiva 2016

Mantendo a tradição das retrospectivas, como fiz no final de 2015, farei agora uma retrospectiva de 2016.

2016-930x527

Gestão de Produtos

Ao longo desse ano acabei escrevendo alguns artigos que complementam meu livro Gestão de Produtos: Como Aumentar as Chances de Sucesso do seu Software:

Guia da Startup

Também escrevi algumas atualizações para o meu primeiro livro, Guia da Startup, Como startups e empresas estabelecidas podem criar produtos web rentáveis:

Dentre meus planos para 2017 está lançar as segundas edições desses dois livros. Também estou pensando seriamente em transformar esse material em dois cursos online.

Cultura Organizacional

Além da atualização desses dois livros, escrevi bastante em 2017 sobre valores e cultura empresarial:

Alguns dos artigos acima estão em inglês pois o Paulo Caroli está trabalhando na tradução para o inglês do meu livro sobre gestão de produtos. Nosso objetivo com essa tradução é aumentar a literatura disponível sobre o tema Gestão de Produtos. Há poucos livros sobre o tema, mesmo em inglês, e acreditamos que essa tradução pode ser útil para pessoas da indústria de software não só no Brasil, como em todo o mundo.

Artigos mais lidos

Aqui vai a lista dos 5 artigos escritos em 2016 mais lidos ao longo do ano:

E essa aqui é a lista do 5 artigos mais lidos em 2016, não importando quando foram escritos:

Pronto, está aí minha retrospectiva 2016. Estou bastante animado com 2017. Como disse acima, tenho planos de lançar as segundas edições de meus dois livros. Se tudo correr bem, também terei o livro sobre Gestão de Produtos em inglês. Além disso, estou estudando a possibilidade de lançar dois cursos online, um sobre Startup e outro sobre Gestão de Produtos. E tenho certeza que vou aprender muita coisa nova bacana que irei compartilhar por aqui!

Um excelente 2017!!!

Entrevista: ContaAzul

Trabalhei na Locaweb por mais de 11 anos. Quando eu entrei lá, eram pouco mais de 100 funcionários, ou seja, era ainda uma startup. Após esses 11 a empresa cresceu muito e hoje tem mais de 1000 funcionários. Nesse tempo que passei lá conheci várias pessoas e, dentre elas, vários fundadores de startups. Um deles foi o Vinicius Roveda, que conheci em 2012, quando a ContaAzul ainda estava dando os seus primeiros passos. A ideia era Locaweb e ContaAzul terem algum tipo de parceria para oferecer a solução de ERP da ContaAzul para os clientes da Locaweb. Na época a parceria não vingou mas Vini e eu conversamos algumas vezes sobre gestão e desenvolvimento de produtos de software e desde essa época já havia afinidade sobre esses temas.

Ao longo de 2016 voltamos a conversar e começamos a explorar a possibilidade de eu me juntar ao time da ContaAzul. A empresa agora tem 5 anos e está escalando a uma velocidade incrível. Por esse motivo o Vini estava buscando pessoas que tivessem já passado por isso em outras empresas e pudessem ajudar o time da ContaAzul a escalar de forma sustentável mantendo a alta velocidade de crescimento. Resolvi aceitar a proposta e voltar a viver novamente esse clima de startup.

Claro que eu aproveitei a oportunidade para fazer mais um entrevista para o Guia da Startup!

logo_contaazul

vini

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

Vinicius Roveda: A ContaAzul surgiu com o objetivo de proporcionar uma nova experiência para micro e pequenos empreendedores em termos de sistemas de gestão. Sabemos que a principal causa a mortalidade das micro e pequenas empresas é a falta de planejamento e gestão. Por isso criamos algo que permite o pequeno empreendedor, com o mínimo de esforço, ter um alto nível de controle do seu negócio e, por consequência, obter melhores resultados. Nossa ideia era baseada em fazer um sistema online de gestão que pudesse ser acessado de qualquer lugar, sem a necessidade de treinamentos e implantação.

Outra preocupação que tínhamos era a capacidade de investimento do pequeno empreendedor e pensando nisso, criamos uma solução altamente escalável que nos permite oferecer um preço super acessível sem a necessidade de investimentos em infra estrutura própria, basta um computador com acesso a internet para começar a usar.

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

VR: Visualizamos a oportunidade de fazer um sistema de gestão online focado para MPEs em 2007. Desde então, estudamos muito esse mercado. O começo foi muito difícil. Criamos uma primeira versão do produto em 2008, mas acabamos não saindo dos beta users. Foi muito difícil encontrar o modelo de negócio ideal para escalar. Eu acabei gastando todas as minhas economias e diante dessas dificuldades nós acabamos abrindo outra empresa de desenvolvimento de software sob demanda junto com alguns amigos. Em paralelo a essa empresa, continuávamos com a ideia de fazer um negócio baseado em produto de software e com alta escala. Foi aí que relançamos o projeto com o nome ÁgilERP, isso foi entre 2010 e 2011. Nessa fase, fizemos uma tentativa de utilizar revendedores, mas esse modelo voltou a fracassar, pois os revendedores preferiam vender softwares mais caros e não o nosso que era barato e baseado em mensalidade. Em 2011, tivemos a oportunidade de conhecer a 500 Startups. Fomos a primeira empresa brasileira a ser escolhida para o processo de aceleração. Tivemos a oportunidade de viver quatro meses na Califórnia, período em que aprendemos muito sobre como acertar o modelo de negócio que utilizamos hoje.

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

VR: Sim, desde o começo o José Carlos Sardagna, o João Zaratine e eu estamos juntos nessa jornada. Logo trouxemos também o Anderson Borges. Fiz faculdade com o Sardagna, fizemos o primeiro estágio juntos e depois de passar por outras empresas conhecemos e trabalhamos com o João e com o Anderson. Antes da ContaAzul montamos uma empresa de desenvolvimento de software sob demanda, a Informant onde trabalhamos juntos por alguns anos até criarmos o ContaAzul. Estou contando esses passos que demos juntos para mostrar a importância de conhecer bem e ter afinidade com os sócios com quem você vai trilhar esse caminho.

Anderson Borges, José Carlos Sardagna, João Zaratine e Vinicius Roveda

Anderson Borges, José Carlos Sardagna, João Zaratine e Vinicius Roveda

GS: O que motivou vocês a buscarem investimento?

VR: Para que a gente pudesse ajudar o maior número de pequenos empreendedores o mais rápido possível, precisávamos de ajuda. Essa ajuda era não só o dinheiro, que nos permitiu contratar os melhores profissionais para compor o nosso time, mas também a possibilidade de aprender com quem já fez empresas de sucesso e passou por desafios similares aos nossos. Temos a possibilidade de conversar com pessoas muito experientes do Brasil e de todo o mundo para trocar experiências. Isso nos ajuda muito. Os investidores nos apoiaram a estruturar o negócio e nos tornar líderes no segmento de sistema de gestão online com apenas 3 anos de existência.

Além de dois fundos americanos (500 Startups e Ribbit Capital) e dois brasileiros (Napkn Ventures e Monasshees), em 2013 recebemos um aporte da Valar Ventures, fundo do Peter Tiehl, que foi um dos criadores do Pay Pal e um dos primeiros investidores do Facebook. Recentemente recebemos mais um aporte que teve a participação da Tiger Global.

GS: Hoje podemos dizer que a ContaAzul atingiu a fase de “Escala”, ou seja, não é mais uma startup. Quais são, na sua opinião, os principais fatores que ajudaram vocês a chegar nessa fase?

VR: Foi uma combinação de fatores mas eu acho que o mais importante são as pessoas. É essencial ter as pessoas certas. Não basta só ter as melhores pessoas em cada função da empresa. Elas precisam estar alinhadas com o mesmo propósito, no nosso, o propósito de ajudar o pequeno empreendedor a ter sucesso, e com os mesmos valores, ou seja, com a mesma entendimento sobre a maneira correta de endereçar as situações.

Tendo as pessoas certas conseguimos construir um produto simples e fácil de usar mas que, apesar de simples, resolvia problemas reais dos pequenos empreendedores.

Com o time certo criamos um atendimento ao cliente UAU, ou seja, quando o cliente é atendido por nós ele é surpreendido positivamente. Ele fala “UAU”.

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

VR: É um caminho difícil, mas vale a pena. Hoje podemos ver que ajudamos milhares de pequenos empreendedores de todo o Brasil a terem sucesso. Recebemos testemunhos todos os dias que nos enchem de alegria e nos dão a certeza de que estamos no caminho certo.

Ter um ótimo time é fundamental. E quando falo em time, não é só funcionários. A primeira escolha são os sócios, escolha pessoas com quem você tenha afinidade para trabalhar junto e para encarar momentos difíceis. Escolha bons investidores, que aportem mais que dinheiro, que te ajude a atingir os objetivos.

É isso! É um caminho difícil, mas vale muito a pena pela satisfação de poder ajudar pessoas a realizarem seus sonhos.

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.