Pensando produto e evitando armadilhas

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:

How To Create Products Customers Love - Marty Cagan apresenta a Causa Raiz das falhas

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.

Pensando produto e evitando armadilhas

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.

Pensando produto e evitando armadilhas - Product Manager

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.)

Pensando produto e evitando armadilhas - OKR

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?

Pensando produto e evitando armadilhas - Escalando

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:

Por |2018-09-16T17:48:49+00:0026 de junho, 2018|Negócio, Product Owner|

Sobre o Autor:

Agile Coach na K21, trabalha com produtos digitais há 10 anos, liderando produtos em TI para web e mobile. Certificada como CSP, PMP, CSM, PSMI, CSPO, Lean-Kanban. Contribui com iniciativas de inclusão como a Code Like A Girl. Formada em cinema (!), canta e desenha nas horas vagas, além de contar histórias como forma de contribuir para um mundo melhor.

3 Comments

  1. Thiago Torricelly 27/06/2018 em 10:25 - Responder

    Oi Andressa, obrigado por compartilhar os insights do workshop do Marty, sou fã do trabalho dele, parabéns!

    Fiquei com uma dúvida sobre um ponto de vista do Marty, gostaria de saber sua opinião sobre.
    O modelo do Marty parece ter um foco especial em produtos digitais, onde tb é o nome do workshop, porém existem outros contextos de construção de software que não se encaixam no contexto de produtos digitais, como um ERP interno de folha de pagamento onde não existe muita incerteza sobre o problema e soluções.
    O Marty crítica uso de roadmaps e SAFe de forma genérica, mas nesses contextos que não são produtos digitais como o da folha de pagamento interna, será que uso de roadmaps ou SAFe possa ser útil?

    O que acha? Está não é uma pergunta retorica, realmente ainda tenho dúvidas sobre esse assunto, ainda não formei uma opinião concreta sobre 🙂

    • Andressa Chiara 28/06/2018 em 23:51 - Responder

      Olá Thiago!

      Excelentes pontos, vou tentar contribuir de forma sucinta:

      – Sobre tipos de produto, o Cagan separa produtos customer-facing (o produto que o cliente usa diretamente), customer-enabling (os produtos que são internos, mas que sem eles o cliente ficaria sem poder usar nosso produto/serviço) e True IT (produtos que são exclusivamente voltados para a tecnologia, e não afetam o cliente mesmo indiretamente). Marty fala que os dois primeiros são o que te torna fantástico. Quando falamos de um ERP interno de folha de pagamento, por exemplo, sabemos que este é um customer-enabling product, mas ainda estamos falando de um sistema que tem seus próprios usuários/clientes. As pessoas que trabalham no RH, por exemplo, são clientes deste produto. As pessoas do Financeiro também. O funcionário que recebe o salário? Também. É não apenas factível como fundamental mapearmos suas dores e testarmos hipóteses de solução para seus problemas. E talvez o maior desafio, incerteza e risco não seja a usabilidade, e sim a viabilidade técnica e performance das integrações que geram pagamentos neste caso. Talvez sejam essas hipóteses que precisamos (in)validar primeiro. Build > Measure > Learn continua sendo tão válido quanto em qualquer outra situação.

      – Sobre a crítica que o Marty faz sobre SAFe, não vejo como relacionada apenas a contextos de produtos digitais. O incômodo que o SAFe gera nestes grandes nomes da agilidade gira em torno de ser uma ferramenta prescritiva e hierarquizada. Com isso, o valor de adaptabilidade fica facilmente afetado. Marty falou muito sobre evitar a todo custo usar qualquer modelo “one size fits all”, e o SAFe tem uma tendência a oferecer uma solução de organograma para transformação sem que antes analisemos o contexto e deixemos uma nova estrutura emergir a partir da vivência da organização. Com estruturas hierarquizadas e pouco adaptáveis, a autonomia dos times tende a ser baixa, e isso pode matar a agilidade.

      Fez sentido?

  2. […] Anterior Próximo Transformação Ágil com OKRs […]

Deixar Um Comentário