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.

Gerindo gestores de produto

Da mesma forma que nem todo bom desenvolvedor pode virar um bom gestor de desenvolvedores, o mesmo acontece com gestores de produto. Assim como as habilidades que uma pessoa tem que ter para gerir desenvolvedores de software é diferente das habilidades que um desenvolvedor precisa ter para ser um bom desenvolvedor de software, as habilidades que um gestor de gestores de produto precisa ter para gerir gestores de produtos é diferente das habilidades que um gestor de produtos produto precisa ter para gerir seu produto.

gestor_de_gestores

Então o que faz um gestor de gestores de produtos?

Um gestor de gestores de produtos tem basicamente duas preocupações, uma tática e outra estratégica:

  • Ajudar os gestores de produto a performarem melhor. Essa é a preocupação tática do gestor de gestores de produto. Ele deve ser capaz de ajudar o gestor de produto a desenvolver as principais características de um bom gestor de produto, empatia, comunicação, gestão do tempo, conhecimento de novas tecnologias, business skills, curiosidade aguçada e conhecimento sobre o tema do produto. Todas essas características são fundamentais para o sucesso do gestor de produtos e nem sempre o gestor de produtos consegue perceber o que precisa ser melhorado ou, se percebe, não sabe bem como melhorar. Aí entra o gestor de gestores de produto, que deve ajudar o gestor de produtos a ver quais características tem espaço para melhoria e como melhorar cada uma delas. Muitas vezes há mais de uma característica que precisa ser melhorada e aqui o gestor de gestores de produto pode mais uma vez ajudar a perceber prioridades, ou seja, qual característica deve ser trabalhada primeiro.
     
  • Ajudar os gestores de produto a criar a visão e a estratégia dos produtos. Essa é a preocupação estratégica do gestor de gestores de produto. Ele deve ser capaz de ajudar os gestores de produto a criar a visão e a estratégia dos produtos da empresa. Aqui é importante fazer uma distinção entre as duas opções de estratégia de portfólio de produtos que uma empresa pode escolher, foco ou diversificação. Em uma empresa que optou pelo foco, cabe ao gestor de gestores de produto coordenar o processo de criação de visão e estratégia do produto da empresa. Ele deve, em conjunto com seus gestores de produto, designers de UX, pessoal de engenharia e gestores de mkt de produto, criar a visão do produto da empresa e desenhar a estratégia para chegar nessa visão. Já em uma empresa que optou pela estratégia de diversificação de portfólio de produto, a responsabilidade do gestor de gestores de produto é ajudar cada gestor de produto a coordenar o processo de criação da visão e do desenho da estratégia de seu produto específico. Além disso em uma empresa que optou pela diversificação, cabe ao gestor de gestores de produtos fazer a gestão do portfólio de produtos, ou seja, garantir que o portfólio de produtos está alinhado com os objetivos estratégicos da empresa e garantir que cada produto tenha o devido investimento de desenvolvimento e de mkt de produtos.

Para ser um bom gestor de gestores de produto é importante que a pessoa já tenha sido gestora de produtos, ou seja, que ela já tenha colocado a “mão na massa” e tenha cuidado diretamente das questões táticas e estratégicas de um produto. Isso irá ajudá-la quando estiver gerindo o trabalho de outros gestores de produto. Contudo, é preciso tomar muito cuidado para não fazer o trabalho no lugar do gestor de produtos ao invés de ajudá-lo a se desenvolver e a fazer seu trabalho. Note que em ambas as preocupações que descrevi acima eu usei “ajudar os gestores de produto”. Por já ter sido um gestor de produtos, é tentador para o gestor de gestores de produtos, no momento em que algum gestor de produto sob sua gestão estiver com dificuldades, fazer o seu trabalho. Mas a função do gestor de gestores de produto não é fazer o trabalho de gestor de produto, mas sim ensinar e ajudar os gestores de produto a fazerem seu trabalho.

Caso vc não tenha experiência como gestor de produtos, mas se veja na situação de coordenar o trabalho de gestores de produtos, como pode ser o caso de um CTO ou um gestor de time de engenharia, valem as recomendações acima, ou seja, ajudar os gestores de produtos a performarem melhor e a criar a visã e a estratégia de seus produtos.

O que é e como criar a visão e a estratégia do produto?

Esse tema tem aparecido com alguma frequência não só na Locaweb mas também em outras empresas de software com quem eu tenho conversado. Por isso acredito que seja um bom momento para escrever um artigo sobre o tema.

O que é e pra que serve visão do produto?

Visão do produto é a razão de existir do produto. É o que deve nortear todas as decisões em relação a esse produto. O que o que dá o contexto para o time de desenvolvimento do produto tomar decisões sobre o que priorizar em relação ao produto. Vale lembrar que quando falo “produto” estou me referindo a qualquer software que tenha usuários.

Lembrando da definição de gestão de produtos, um produto deve ao mesmo tempo atender aos objetivos estratégicos que o dono do produto tem para esse produto enquanto ele resolve problemas e necessidades de seus usuários. Pronto, esses dois elementos são o que você precisa para fazer a sua visão do produto.

Criando a visão do produto

A visão do produto será criada juntando esses dois elementos, o entendimento dos objetivos do dono do produto e os problemas e necessidades do usuário do produto.

Sendo assim, o primeiro passo para criar a sua visão do produto é ter bem claro quais os objetivos que o dono do produto tem para o produto. Por exemplo, um banco pode querer, com um sistema de Internet Banking, reduzir a necessidade de atendimento em agências. Um laboratório de análises clínicas e de imagem, com um sistema de consulta de resultados, pode querer diminuir os custos operacionais de manuseio e envio de resultados.

Em seguida é preciso entender dos usuários do produto quais são os problemas e necessidades que esse produto vai resolver, qual o contexto onde esses problemas e necessidades acontecem e qual a motivação que esses usuários têm para querer ter esse problema ou necessidade resolvido.

Uma ferramenta bacana para entender o usuário é o mapa de empatia.

empathy-map

Esse mapa ajuda a dar foco nas diferentes percepções que o usuário pode ter:

  • Vê? O que seu usuário vê? Como é o ambiente onde ele usa o produto? O que o mercado oferece?
  • Ouve? O que o seu usuário ouve? O que seus amigos dizem para ele sobre o seu produto? O que o chefe dele diz? O que os influenciadores dizem?
  • Diz e faz? O que o seu usuário diz e faz em relação ao seu produto? O que ele comenta com amigos e em redes sociais? O que ele consegue fazer graças ao seu produto?
  • Pensa e sente? O que seu usuário pensa e sente quando usa o seus produto?
  • Dores? Quais são as principais dores, medos, frustrações e obstáculos que o seu usuário encontra?
  • Ganhos? Quais os principais ganhos, desejos e necessidades resolvidas que seu usuário espera ter ao usar seu produto?

Outra ferramenta muito útil é a persona, que representa um grupo de usuários com padrões de comportamento, atitudes e motivações similares em termos de decisão de compra, de uso de tecnologias ou produtos, de estilo de vida etc.

As personas são usadas para:

  • Conhecer e entender clientes e usuários de produtos e serviços;
  • Trazer o usuário para o foco do projeto;
  • Tornar as decisões de design mais humanas e menos abstratas.

A figura a seguir mostra como construir uma persona:

persona-1

O primeiro passo é definir um nome e algumas características dessa persona. Isso ajuda nas conversas sobre o produto. No nome, é bacana já dar uma dica da característica principal. Por exemplo, Maria, a descolada ou Michelle, a ocupada.

Se você estiver fazendo um produto para Michelle, a ocupada e quiser inserir uma nova funcionalidade, vale a pergunta: “Será que Michelle, a ocupada vai conseguir usar essa funcionalidade? Ela a achará útil o suficiente para achar tempo para aprender a usá-la?”. Além do nome e características básicas, é importante também descrever seus comportamentos e seus problemas. Os exemplos a seguir deixarão mais claro o conceito de persona.

persona-2
Maria, a descolada

persona-3
Michelle, a ocupada

Maria, a descolada é uma das personas que usamos na Locaweb. Dados os diferentes produtos que temos em nosso portfólio, acabamos construindo oito personas. Contudo, para cada produto de nosso portfólio, temos uns 3 ou, no máximo, 4 personas, sendo que uma destas é a persona primária do produto, ou seja, para quem todas as suas decisões de seu produto de software são tomadas.

Como parte do entendimento do problema ou necessidade que seu usuário espera ver resolvido pelo seu produto é muito importante você mapear quais as alternativas que existem hoje para ele ter esse problema ou necessidade resolvido. No caso de produtos comerciais, são os concorrentes. No caso de produtos que são sistemas sem objetivos diretos de receita, como o internet banking ou o sistema de consulta de resultado de exames, são as alternativas existentes como ir ao banco ou ao laboratório, acesso ao banco por telefone, envio de resultados por correio, etc. Esse mapeamento de alternativas é muito importante para você entender como seu usuário se vira sem o seu produto e no que essas alternativas são melhores e no que elas são piores do que o produto que você cuida.

Tanto o mapa de empatia quanto a persona quanto o mapeamento de alternativas podem e devem ser criados em conjunto com pessoas de UX, de engenharia e de marketing de produtos.

Pronto, você já tem todos os elementos para criar a visão do seu produto:

  • Os objetivos do dono do produto.
  • Quem são os usuários e quais os problemas e necessidades esses usuários esperam resolver com seu produto. Ferramentas úteis para isso são o mapa de empatia, a persona e o mapa de alternativas.

Vale lembrar que para obter esses elementos o gestor de produtos terá que usar muita empatia para conversar com os donos do produto e entender seus objetivos e para conversar e entender o seu cliente.

Com esses elementos em mãos você está pronto para criar a sua visão que nada mais é do que deixar claro esses elementos. Simples, né? Seria algo mais ou menos assim:

O (nome do dono do software) decidiu ter esse software para (objetivos do dono do software em ter esse software). Esse software é usado por (descrição das pessoas que usarão o software) que, ao usar esse software, espera resolver (problema ou necessidade que o usuário espera resolver) de uma forma melhor do que (alternativas existentes). (Incluir mais informações sobre o problema ou necessidade, incluindo contexto e motivação para ver resolvido).

Por favor, não dê copiar + colar no texto acima! Crie sua própria visão do produto, que não precisa ser um texto. Pode ser uma apresentação ou um vídeo. Lembrando que a visão do produto é a razão de existir do produto. É o que deve nortear todas as decisões em relação a esse produto.

Estratégia do produto

Uma vez que você tem em mãos a visão do produto, provavelmente vem um pensamento a mente, algo na linha de “hum, acho que meu produto ainda está distante da visão” e a pergunta subsequente é “como fazer com que meu produto chegue mais perto da visão?”. É aí que entra a estratégia do produto, ou seja, que passos serão dados para aproximar o produto da visão.

Uma boa ferramenta para ajudar a construir a estratégia do produto é a análise SWOT, sigla em inglês para Strengths, Weaknesses, Opportunities and Threats, ou pontos fortos, pontos fracos, oportunidades e ameaças.

swot

Os pontos fortes e os pontos fracos são itens internos, ou seja, do seu time de desenvolvimento de produto, ou da sua empresa, sobre as quais você, seu time ou sua empresa têm algum controle, que ajudam ou atrapalham o seu produto atingir a sua visão. As oportunidades e ameaças são os elementos externos a organização, ou seja, sobre os quais a organização não tem controle, e que podem influenciar positiva ou negativamente o atingimento da visão do produto.

Preencher o SWOT deve ser também um trabalho de equipe, ou seja, o gestor de produto deve ter uma ou mais sessões junto com pessoas de UX, engenharia e marketing para construir o SWOT do seu produto. É provável que sua organização também tenha feito uma análise SWOT para a organização como um todo. É um ótimo input para o SWOT do seu produto.

Tendo em mãos o SWOT preenchido, é hora de desenhar a estratégia do seu produto. A estratégia do produto nada mais é do que um roadmap de curto, médio e longo prazo. Longo prazo? Você certamente está pensando que, como vcs adotaram metodologias ágeis na time de desenvolvimento de produto, não faz mais sentido ter um roadmap de longo prazo, nem de médio prazo. Na verdade, faz sim, mas não no sentido clássico de roadmap como lista de funcionalidades, mas sim usando o roadmap como lista de prioridades, lista de pontos de foco que devem ser vistos para fazer com que o produto se aproxime da visão.

Com o SWOT preenchido você deve, junto com o time (UX, engenharia, mkt de produto) olhar para cada um dos itens em cada um dos quadrantes e avaliar qual o impacto dele na visão de produto que vocês criaram. Existem pontos fortes devem ser reforçados? Se sim, quais devem ser reforçados primeiro? Existem pontos fracos a serem combatidos? Se sim, quais devem ser combatidos primeiro? Existem oportunidades a serem aproveitadas? Se sim, quais devem ser aproveitadas primeiro? Existem ameaças a serem combatidas? Se sim, quais devem ser combatidas primeiro? Essa análise irá te ajudar a definir as motivações, os objetivos, ou seja, os macro-temas do seu roadmap, lembrando que roadmap = motivação + métrica, o que agora está sendo popularizado com a sigla OKR (Objectives and Key Results), tema de um futuro artigo. Essa análise te ajudará a definir no que se focar agora e o que deixar para depois, sempre tendo por objetivo final chegar mais próximo da sua visão de produto. E isso é a estratégia do produto, o caminho que você e o time de desenvolvimento de produto irá percorrer para chegar na visão do produto.

Seu produto evolui, sua visão e estratégia também!

Um ponto importante é que seu produto evolui à medida que o time trabalha nele. Muito se aprende sobre os usuários do produto, seus problemas e necessidades. Novas alternativas podem aparecer para ajudar seu usuário a resolver seus problemas e necessidades. O dono do software também pode revisitar seus objetivos estratégicos e, consequentemente, revisitar os objetivos definidos para o software. Além disso, pontos fortes e pontos fracos podem mudar com o tempo, e oportunidades e ameaças podem aparecer ou sumir. Por isso é importante entender que nem a visão nem a estratégia do produto estão escritas em pedra. Elas podem e devem ser revisitadas periodicamente. Minha sugestão é que elas sejam revisitadas anualmente, ou quando algum evento relevante acontecer como, por exemplo, quando houver uma mudança nos objetivos estratégicos da empresa ou quando aparecer uma alternativa que resolve o problema ou necessidade do usuário de uma forma diferente da do seu produto.

The book is on the table

English version below…

A bem da verdade, não está em cima da mesa, mas está no LeanPub. O Paulo Caroli está trabalhando na tradução para o inglês do meu livro sobre gestão de produtos.

title_page

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.

Ainda estamos nos primeiros capítulos, mas se vc quiser acompanhar a tradução e a publicação, basta visitar a página do livro lá no LeanPub.

Se vc tem amigos de outros países que não falam Português, mas que se interessam pelo tema Gestão de Produtos de Software, fique à vontade para indicar o livro Product Management: Delight your customers with your software. Ainda em Beta, mas já com conteúdo interessante. Feedbacks são muito bem vindos!

English version

“The book is on the table” is a phrase that every Brazilian who learns English is faced with when learning about use of preposition in English language. Hence the title of this article. :-)

However, the book is not on the table. The is at LeanPub. Paulo Caroli is translating my book on Software Product Management that I wrote in Portuguese and launched in Brazil last year.

Our main objective with this translation is to increase the number of books on Software Product Management available for readers all over the world. The are not many books on the topic, even in English, and we believe the content of this book is useful for people in the software industry not only in Brazil but anywhere in the world.

We are working on the first chapters but as we progress we are already releasing the content. If you want to see the work in progress, please visit the book page at LeanPub.

And if you have friends who don’t read in Portuguese but are interested in Software Product Management topic, please feel free to point them to Product Management: Delight your customers with your software. Still in beta but already with valuable content. Feedback is always welcome!

Sobre QA (e Front-end e BA)

No artigo anterior, sobre organização de times de desenvolvimento de produtos e sistemas, prometi que o próximo artigo seria sobre o papel de gestor de gestores de produto. Contudo, recebi alguns comentários sobre a falta do time e do papel de QA (Quality Assurance) na organização dos times, por isso resolvi mudar um pouco a sequência de temas e vou falar nesse artigo sobre QA (e Font-end e BA).

Disclaimer

Antes de mais nada, gostaria de citar uma frase muito bacana que ouvi certa vez e que deve ser lembrada sempre que conversas sobre pontos de vista distintos acontecem:

O fato de discordamos não significa necessariamente que um dos dois está errado.

Qual é o objetivo?

Na minha visão, processos, metodologias e formas de se organizar um time não são o objetivo em si, mas sim os meios, as ferramentas para se atingir um objetivo. No caso de um software, o objetivo normalmente é atender aos objetivos estratégicos do dono desse software e, ao mesmo tempo, resolver problemas e necessidades dos usuários desse software.

QA (e Front-end e BA) na Locaweb

Até meados do segundo semestre de 2015 tínhamos na Locaweb os times de engenharia de produtos, um time para cada um ou dois produtos, e tínhamos dois times funcionais separados desses times de engenharia de produtos, os times de Front-end e de QA. O artigo anterior foi extraído do meu livro e no livro o texto ainda contempla Front-end e QA separados da engenharia. No final do ano decidimos por não ter mais time de Front-end nem de QA.

Sobre o time de Front-end:

  • O time tinha 5 desenvolvedores, enquanto a Locaweb tinha 12 times de desenvolvimento de produtos e sistemas. Como desenvolvedores de back-end não mexiam com front-end, o time de front-end acabava virando gargalo.
  • O time havia desenvolvido, junto com UX, o Locaweb Style um framework front-end de comportamento e estilo que usamos em nossos produtos e disponibilizamos para que qualquer pessoa tb possa utilizar em seus projetos. O objetivo do Locaweb Style é facilitar o programação front-end das interfaces de nossos produtos. Com o Locaweb Style ficou mais fácil desenvolvedores de back-end fazerem front-end e diminuir o gargalo.
  • Com isso decidimos não ter mais o time de Front-end e os desenvolvedores de front-end foram para os times de produtos onde front-end é mais relevante. Os desenvolvedores de front-end passaram a tb mexer em back-end, assim como os desenvolvedores back-end passaram a mexer em fron-end. Sempre respeitando o Locaweb Style.
  • Diego Eis, que era coordenador desse time de Front-end, contou em um artigo como foi a mudança. Ele passou de coordenador de time funcional a coordenador de time de engenharia de um produto. Isso deu a ele a aos membros do time de front-end, que agora são desenvolvedores alocados em um time de produto, um senso maior de propósito, pois entregam um produto completo e não só a programação da interface.

Sobre o time de QA:

  • Quando existe a função de QA separada da função de desenvolvimento de software, é comum ouvir frases do tipo “a funcionalidade está pronta, agora está em QA”, o que denota uma cultura waterfall, o que pode aumentar consideravelmente o tempo de desenvolvimento e impactar negativamente a qualidade do software.
  • Quando existe a função de QA separada da função de desenvolvimento de software, também é comum ouvir frases do tipo “por que o QA não pegou esse bug?”, o que denota uma cultura de busca de culpados, que pode ser bem prejudicial para o clima do time e, consequentemente, impactar negativamente a qualidade do software.
  • Qualidade não deve ser a preocupação de uma pessoa ou de um time, deve ser uma preocupação de todas as pessoas que estão trabalhando no software.
  • Qualidade é um requisito não-funcional, ou seja, um requisito que especifica um critério para julgar a operação de um software, o que é diferente do requisito funcional, que especifica um comportamento do software. Performance, escalabilidade, “operabilidade”, “monitorabilidade” são alguns exemplos de requisitos não-funcionais de software que são tão importantes quanto a qualidade. Mesmo assim, não existem o papéis de perfomance assurance, scalability assurance, operability assurance e monitorability assurance. Por que qualidade é o único requisito não-funcional que tem uma função específica para assegurá-lo?
  • QA tem por foco garantir a qualidade do processo de desenvolvimento de software. Se é necessário um papel separado para garantir essa qualidade, por que não existe a necessidade de um papel separado para garantir a qualidade do processo de gestão de produtos, do processo de design de UX, do processo de marketing de produtos, do processo de vendas, do processo financeiro?
  • Na Locaweb tínhamos em torno de 12 QAs, alguns com perfil mais de desenvolvedor e outros com perfil mais de SysAdmin. Ao propormos a extinção do papel de QA, alguns dos QAs viraram devs de um produto enquanto outros assumiram o papel de sysadmins.
  • Existia entre os devs a preocupação de que, se o próprio dev agora vai ter que testar, as entregas vão demorar mais para ficar prontas. Essa preocupação existia pois os devs consideravam que seu trabalho terminava quando passavam a história para o QA testar. Contudo, essa visão de pronto do dev é incorreta, pois ele só passou a história para a próxima fase, o teste. Do ponto de vista do usuário do software, a história só está pronta quando o usuário pode utilizar a nova funcionalidade. E o que acontece quando a história não passa por QA e tem que voltar pro desenvolvimento?

Sobre BA:

Outro questionamento que recebi quando publiquei o artigo anterior foi sobre a ausência de BA (Business Analyst). Não coloquei explicitamente o BA pois 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. Em algumas organizações pode acontecer de o BA estar focado exclusivamente no business, ou seja, em entender apenas quais são os objetivos de negócio, deixando de lado os problemas e as necessidades dos usuários. Nesse caso, é importante o BA passar a levar tb em consideração os problemas e as necessidades dos usuários do software, balanceado-os com os objetivos de negócio.

Concluindo

Com esse artigo espero ter esclarecido as perguntas sobre a ausência de QA e BA que ficaram do artigo anterior, sobre organização de times de desenvolvimento de produtos e sistemas. Vale lembrar que processos, metodologias e formas de se organizar um time não são o objetivo em si, mas sim os meios, as ferramentas para se atingir um objetivo. No caso de um software, o objetivo normalmente é atender aos objetivos estratégicos do dono desse software e, ao mesmo tempo, resolver problemas e necessidades dos usuários desse software.

No próximo artigo meu plano é falar um pouco sobre o papel de gestor de gestores de produto. Stay tuned!