Nos dias 16 e 17 de junho de 2018, Marty Cagan, autor de Inspired, um dos livros mais importantes no mundo da criação de produtos, veio ao Brasil e ministrou o curso How to create products customers love, em São Paulo. Durante o curso, ficamos bastante felizes em ver que o conteúdo que oferecemos nos cursos da K21 está perfeitamente alinhado com o que as grandes mentes de produto pensam, mas incomodados com o que há de gap entre o mindset de produto e o dia a dia das empresas no Brasil.
Com isso, resolvemos compartilhar algumas dicas de Cagan aqui para tornar a vida de todos mais feliz e produtiva!
Se você não está fazendo ágil…
“… precisamos conversar”. Foi assim que Cagan abriu seu treinamento, surpreso por haver algumas pessoas na sala que não levantaram a mão quando ele perguntou quem usava alguma forma de ágil no trabalho. Além disso, como Jeff Sutherland ano passado e Ken Schwaber em 2013, ele fez questão de se colocar contra a utilização do SAFe nas empresas, afirmando categoricamente que “SAFe é veneno!”.
Um modelo scrumlhambado
É bastante comum encontrarmos o cenário de empresas que começaram a adotar o ágil, mas estão fazendo entregas assim:
Quando Cagan projetou este slide, eu soube que teria um fim de semana divertido. No topo se lê “As Causas Raiz do Fracasso”, e em seguida vemos algo muito comum: primeiro uma cúpula tem as ideias, depois surge um plano de negócios, um roadmap, depois os requisitos, fazemos o design, construímos, testamos e subimos para produção. Basta colocar sprints na parte da construção e pronto, é tudo ágil.
Esta é a garantia que perdemos toda a adaptabilidade necessária para encontrar o market fit (como seu produto se encaixa no mercado). É um modelo de execução que não dá abertura alguma para qualquer aprendizado, não prevê testes de hipóteses e (in)validação das suposições que tivemos ao longo do processo. Como cereja no sundae, não estamos fazendo entregas frequentes ou orientando nada a valor. É um desastre.
A partir deste momento, Cagan passou a dedicar seu esforço a quebrar cada um dos paradigmas que criamos ao nos acostumarmos com o status quo do dia a dia em uma empresa cujo mindset ágil ainda não está amadurecido.
Planos de negócios não funcionam
O motivo pelo qual planos de negócio são atraentes é que eles dão uma falsa noção de segurança. Você coloca as informações de quanto o seu produto vai custar, quanto você pretende vender e qual é o retorno esperado, e você usa isso para aprovar o financiamento do produto.
O problema é que todas essas informações são fictícias. Não sabemos quanto tempo vai levar para desenvolver um produto porque, para começar, não temos garantia de que o mercado irá recebê-lo bem. Não temos certeza de como este produto que idealizamos será construído, ou sequer se resolve um problema doloroso o suficiente para que as pessoas paguem por ele. E, justamente por isso, não temos como garantir quanto vamos vender e qual é o retorno esperado. Na verdade, estamos pedindo financiamento em primeiro lugar justamente para poder descobrir todas essas informações que colocamos como certezas no plano de negócios.
E, no entanto, seremos cobrados pelo que escrevemos no plano como se ele fosse uma bola de cristal USB.
Roadmap como causa do fracasso
Sem melindres, Cagan afirmou que você vai se arrepender de pelo menos metade das ideias que colocou em seu Roadmap. Só que, quando apresentamos um Roadmap, estamos simplificando o caminho até um produto de sucesso, e vendendo uma ideia de linearidade que não reflete a realidade. Ao ver um Roadmap, os patrocinadores acreditam que estamos lidando com a mera execução de uma lista de features, quando a realidade parece mais com um ninho de mafagafos bêbados que ninguém quer desenrolar. As cobranças passam a acontecer em cima de execução e não de aprendizado, e parabéns! Temos mais um produto que ninguém usa no mercado.
Nesta mesma toada, Cagan reforçou que a coisa mais arriscada que podemos fazer é não assumir riscos, pois sabemos que as coisas vão mudar e que há muito que não podemos afirmar. Se isso é um fato, precisamos começar a (in)validar hipóteses e mitigar esses riscos, em vez de evitá-los, o mais cedo possível.
Tipos de risco
Uma vez que você começou a (in)validar hipóteses, é importante ter em mente que há diferentes tipos de risco que precisamos tratar ao gerir um produto:
- riscos de valor: será que estamos resolvendo um problema real? Será que esta forma de resolver o problema agrega valor para meu cliente? Será que as pessoas vão pagar por isso?
- riscos de usabilidade: será que meu cliente consegue usar meu produto?
- riscos de viabilidade técnica: é possível construir este produto?
- riscos de viabilidade de negócios: será que conseguimos assumir os riscos deste produto?
E uma boa forma de explorar mais estes riscos é através de um MVP.
MVP é produto?
Mais um belo tapa na cara: Cagan colocou, de forma muito correta, que é frequente ver empresas construindo MVPs de 4 meses. Um MVP de 4 meses não é um MVP, porque MVP é um protótipo, não um produto. As empresas têm usado o termo MVP para criar produtos mal feitos e não testados, o que está longe do objetivo desta técnica.
Toda a razão de existir do MVP está em (in)validar hipóteses e, segundo Cagan, é comum que uma startup tenha que fazer ao menos 100 iterações no seu produto antes de encontrar o market fit. Agora considere que uma startup geralmente tem dinheiro para sobreviver por 1-2 anos, e imagine que você leva 4 meses para colocar seu produto na mão do primeiro cliente, para só então coletar feedback e fazer a primeira iteração (de 100). É provável que levaria 20 anos até que essa startup encontrasse o market fit, e quase ninguém tem dinheiro para sustentar isso.
Com este problema em mente, um time deve fazer de 15 a 30 iterações em um protótipo ao longo de uma semana, sempre (in)validando hipóteses e aprendendo rápido. Da mesma forma, um erro comum dos times é esperar até a Review para mostrar o produto pela primeira vez aos stakeholders. A proposta é fazer essa validação mais cedo, mostrando o protótipo e coletando feedback o tempo todo.
Sou um monstrinho visual, então minhas anotações seguem este padrão
Dual-track Scrum
Cagan abordou também um pouco do termo cunhado por Jeff Patton, explicando que você pode trabalhar em duas faixas: uma de descoberta e outra de entrega. A faixa de descoberta é onde você “finge” e a de entrega é onde você “faz”. Esta é uma referência à expressão fake it till you make it, que significa “finja até conseguir fazer”. Na faixa de descoberta o time está focado em prototipar e (in)validar hipóteses. Em paralelo, o time está construindo aquilo que já teve suas hipóteses validadas. Não deve existir um momento onde o time só valida ou só constrói, pois precisamos aprender sempre e entregar sempre produto funcionando ao cliente. No entanto, para um problema particularmente difícil, é viável fazer uma design sprint, onde o time fica focado em testar e iterar possíveis soluções para aquele problema.
O papel do time de desenvolvimento
“Se você está usando seus desenvolvedores para escrever código, você está recebendo apenas metade do valor deles.” Resolver um problema difícil requer várias cabeças pensando juntas. Se excluímos os desenvolvedores do intenso ciclo de prototipação e testes, estamos privando nosso produto de testes de viabilidade, além de termos diferentes pontos de vista com base nas tendências tecnológicas. Às vezes estamos pensando em algo super complexo, como uma caneta que consiga escrever em gravidade 0, vem o desenvolvedor e pergunta “por que não usamos um lápis?”
Já que estamos falando da participação dos times, Cagan ressalta que os melhores times não são feitos de estrelas. Eles são pequenos, duráveis, multidisciplinares, olham o escopo completo, são preferencialmente co-alocados e trabalham orientados a resultado. Sobretudo, mesmo que cada membro do time tenha um conhecimento mais profundo em uma disciplina, um bom sinal de times fantásticos é você não ser capaz de distinguir facilmente quem é o gerente de produto, o designer, ou o desenvolvedor. Todos trabalham em uma colaboração tão intensa que estes papéis são apenas conhecimento agregado ao todo.
OKRs
Para dar visibilidade à organização e garantir que todos os times estão remando para o mesmo lado, Cagan propôs substituirmos o famigerado Roadmap por OKRs. Desta forma, os times e a organização passam a estar menos orientados a volume de entrega e mais orientados a resultado de negócio. Ainda, os OKRs são uma forma ótima de ajudar o time a manter o foco em (in)validar e construir o que realmente traz valor, e dizer não para todas as outras demandas que recebe da organização. (Veja mais sobre OKR clicando neste link.)
Escalando
Sobre trabalhar com ágil em escala, Cagan fez referência ao Airbnb e à lógica de que, para escalar, você precisa primeiro fazer coisas que não escalam. Não adianta buscar um modelo que sirva para todos os cenários, todas as organizações. Como disse Peter Drucker, a cultura come a estratégia no café da manhã, então se aplicarmos qualquer tipo de definição organizacional sem que ela emerja da interação entre as pessoas, a adesão é baixa, e a estrutura se torna um problema em vez da solução.
Com isso, Cagan sugere que sejam desenvolvidas fortes lideranças dentro dos seguintes papéis:
- Líderes de Produto: cuidando da visão, estratégia e da estrutura dos times
- Líderes de Design: cuidando da linguagem de design e padrões
- Líderes em Engenharia: cuidando da arquitetura e da estrutura dos times
- Líderes em Dados: cuidando das ferramentas de análise de dados e da linguagem dos KPIs (indicadores chave de performance)
- Líderes em Entrega: cuidando das datas de entrega e das dependências
Em última análise, estes líderes servirão como evangelizadores das melhores práticas. E não é isso que estamos todos fazendo?
Foram dois dias intensos com muito conteúdo, mas o objetivo deste post é apenas dar uma visão de como podemos pensar melhor em produto e evitar as armadilhas mais comuns. Se você quiser saber mais, acompanhe nosso blog!
Quer saber mais sobre esse assunto?
Quer aprender a criar produtos de sucesso? Faça o nosso treinamento de Certified Scrum Product Owner (CSPO)
Veja também outros posts relacionados a esse tema clicando nos links abaixo:
- Transformação Ágil com OKRs
- Métricas de eficácia do produto em Métricas – Como medir a agilidade do seu time.
- 10 Livros para se aperfeiçoar como Product Owner
