Como usar o Dual track agile no processo de Discovery

No início de uma ideia que queremos construir, temos muita incerteza sobre o problema, o escopo, o que estamos construindo, por que, como… trazendo diversos riscos para o sucesso no nosso produto ou feature. Precisamos então, reduzir nossas incertezas para criar produtos que funcionam e que pessoas utilizem.

Lidar com os riscos durante o estágio de desenvolvimento ou depois de pronto custa muito caro. Portanto, para reduzir a incerteza, devemos enfrentar os riscos antecipadamente, e não no estágio de desenvolvimento. Por isso, precisamos ter uma etapa anterior ao desenvolvimento para reduzir as incertezas, e essa etapa é conhecida por discovery.

O objetivo do discovery é atacar riscos importantes o mais cedo possível. Reduzindo a incerteza, tornando mais fácil e certo de que a equipe terá sucesso.

É importante notar que, quando começamos a desenvolver as coisas, não significa que toda a incerteza se foi. Nós definitivamente encontraremos problemas e aprender à medida que desenvolvemos. No entanto, o objetivo do discovery é ter os principais riscos fora do caminho.

Como fazer discovery sem voltarmos ao antigo modelo de Waterfall?

A ideia do discovery não é ser um processo em que o Product Manager (PM) cria uma especificação, passa para o Product Designer (PD) prototipar e testar e depois para os engenheiros construirem.

“Se a primeira vez que seus desenvolvedores veem uma ideia é no planejamento de sprint, você falhou.”

— Marty Cagan

Para evitar cair nessa armadilha, existe um modelo de trabalho chamado de Dual-track. Um modelo em que o time de produto percorre dois caminhos (tracks) paralelos e simultâneos, o caminho de discovery e outro de delivery.

No Dual-track, enquanto o time de engenharia desenvolve uma solução, outra parte do time foca em validar e especificar as soluções que serão construídas mais para frente. Sendo o discovery de responsabilidade* do PM, Product Designer e Tech Lead, e o propósito garantir que tenhamos evidências suficientes de que, quando pedirmos aos engenheiros para construir o produto, não será esforço e tempo perdido.

*Responsabilidade não significa que são os únicos que participam.

O que acontece na track de desenvolvimento já é muito bem conhecido por todos: existe uma lista de tarefas priorizadas (backlog), os engenheiros desenvolvem as tarefas, testam e colocam no ar. Porém, muitas vezes o que acontece antes dessas tarefas chegarem ao backlog ainda não está claro para todos.

As tarefas que chegam ao backlog nada mais são que oportunidades, ideias ou problemas a serem resolvidos. Como não temos tempo nem pessoas suficientes para todos os itens, precisamos ter certeza de que o time de engenharia não perderá tempo trabalhando em algo que não vai para o ar ou que ninguém vai usar.

Logo, segundo Marty Cagan, devemos considerar 5 principais riscos durante nosso discovery:

• O cliente vai comprar ou usar? (Valor)
• Essa solução funciona para o nosso negócio? (Viabilidade de Negócios)
• Devemos construir isso? (Ética)
• O usuário consegue entender como usar? (Usabilidade)
• Conseguimos construir isso? (Viabilidade técnica)

Riscos

A seção a seguir é um simples resumo do livro Inspired e Empowered do Marty Cagan.

Valor

Sempre temos mais ideias do que braço para construir, logo devemos procurar ter boas evidências de que esta é a decisão certa a se fazer. Para avaliar o valor, podemos fazer testes de demanda quantitativo e qualitativo.

Viabilidade de negócio

• Podemos pagar essa solução? (Financeiro)
• Essa solução funciona para nossos parceiros? (Negócio)
• Esta solução é compatível com a nossa marca? (Marketing)
• Essa solução é algo que nossa equipe de vendas pode vender? (Vendas)
• Isso é algo que podemos fazer do ponto de vista legal ou de conformidade? (Jurídico)

Dica: Entenda o contexto do seu negócio, nem sempre você precisará se dedicar extensivamente a todas essas áreas. Exemplo: empresas como FinTechs são altamente reguladas, logo exigem mais do PM para avaliar riscos regulatórios e de Compliance. Além disso, não apenas consulte, tente trazê-las mais perto da construção.

Ética

“No passado, as empresas tinham uma única parte interessada – o acionista. Faça o que é bom para os resultados financeiros. Essa é uma abordagem que levou muitas empresas a pensar em tudo no curto prazo, atingindo o número trimestral. E também incentiva muitos comportamentos que estão cada vez mais sendo reconhecidos como antiéticos e fazendo com que mais e mais pessoas percam a fé nas empresas. Acerte o número e não se preocupe se o que você está construindo é realmente bom para seus clientes, ou para o meio ambiente, ou para seus parceiros, ou para o mundo em geral. ”

— Rob Chesnut

Não existe fórmula para avaliar algo eticamente, mas Rob Chesnut sugere as seguintes perguntas para te ajudar na avaliação:

• A solução do produto será boa para o cliente final?
• Tem impacto negativo no meio ambiente de alguma forma ou em terceiros na comunidade?
• É algo que, se todos os e-mails, documentos e discussões sobre o produto fossem publicados online, você ficaria envergonhado?
• Como os reguladores do governo reagiriam se soubessem de tudo?
• O produto será algo de que você se orgulhará como parte de sua marca pessoal?

Usabilidade

O objetivo é obter uma compreensão mais profunda de seus usuários e clientes e, é claro, identificar os pontos de atrito no protótipo para que você possa corrigi-los. Pode ser nomenclatura, fluxo, problemas de design visual ou problemas de modelo mental, mas assim que você achar que identificou um problema, basta corrigi-lo no protótipo.

“O design não é apenas a aparência e a sensação. Design é como funciona ”

— Steve Jobs

Viabilidade técnica

Precisamos garantir a viabilidade técnica antes de decidirmos construir, não depois. Isso não só acaba economizando muito tempo perdido, mas verifica-se que obter a perspectiva do engenheiro mais cedo também tende a melhorar a própria solução e é fundamental para o aprendizado compartilhado.

Quando falamos sobre validação de viabilidade, os engenheiros estão realmente tentando responder a várias perguntas relacionadas:

• Nós sabemos como construir isso?
• Temos as habilidades na equipe para construir isso?
• Temos tempo suficiente para construir isso?
• Precisamos de alguma mudança arquitetônica para construir isso?
• Temos em mãos todos os componentes de que precisamos para construir isso?
• Nós entendemos as dependências envolvidas na construção disso?
• O desempenho será aceitável?
• Será que vai escalar para os níveis de que precisamos?
• Temos a infraestrutura necessária para testar e executar isso?
• Podemos pagar o custo para fornecer isso?

Nesta etapa, devemos examinar pontos como:

• Questões de algoritmo
• Preocupações de desempenho
• Questões de escalabilidade
• Questões de tolerância a falhas
• Uso de uma tecnologia que a equipe nunca usou antes
• Uso de um componente ou serviço de terceiros que a equipe não usou antes
• Uso de um sistema legado que a equipe não usou antes
• Dependência de mudanças novas ou relacionadas por outras equipes

Não se assuste com a grande lista, ela serve apenas para ajudar, não é como se você tivesse que criar um grande relatório sobre cada item.

Como aplicar no dia a dia?

Beleza, muitos de vocês já leram Inspired (Marty Cagan), sabem a teoria, porém enfrentam problemas para fazer para esse trabalho fluir melhor. Para fazer com que isso aconteça é um trabalho extenso e leva bastante tempo e esforço da liderança, porém deixo aqui algumas dicas que funcionaram para mim.

• Tenha o time comprado na mudança de forma de trabalho.

Muitas vezes os engenheiros, tech-lead e até designers não conhecem a fundo os conceitos e práticas de Discovery. Além disso, muitas vezes o time possui diversas dores que um bom discovery resolveria.

Logo, entenda as dores que o time possui e mostre como o processo de discovery pode melhorar o trabalho de todos. Marque uma apresentação para o time, explique o que é Discovery, quais as etapas, quais os riscos e por que é importante.

• Construa a cultura e processo com o time.

Não saia criando regras e estabelecendo processos de como fazer as coisas. Discovery não tem uma fórmula ou passo a passo, cada problema e time tem métodos e necessidades diferentes. O mais importante é que o time entenda e pegue gosto pela coisa.

O que costumo fazer é ter uma dinâmica com o time, atacando uma solução hipotética que queremos fazer. Nessa dinâmica, tente passar por todos os 5 riscos, estabelecendo com o time como avalariam os riscos, quais métodos usariam, artefatos criados durante o processo e evidências coletadas. Simule o mundo perfeito, até chegar na etapa em que o time sinta que teriam elementos suficientes para desenvolver e que todos os riscos foram avaliados.

Exemplo:

• Discovery não é só do PM e do Designer.

Por mais que cada risco possua uma pessoa que seja o mais responsável, os 3 (PM, PD e TL) devem participar e estar cientes de todas as etapas. A ideia não é que cada um faça sua parte e passe o bastão para o próximo.

Além disso, é muito importante os inputs do restante do time (engenharia, marketing, ux research…). Logo, crie dinâmicas ou cerimônias para coletar feedback.

• Comunique constantemente o que acontece em Discovery.

Vejo inúmeras dailies de engenharia onde só é apresentado e discutido o board de desenvolvimento. Pessoalmente eu gosto que Designers e PMs estejam presentes nas dailies e que seja, diariamente, mostrado o que está no board de discovery.

Será um excelente momento para o time lembrar o que estar por vir, fazer perguntas, levantar preocupações e dar ideias.

• Tenha um board de discovery.

O board de discovery vai te ajudar como PM a se organizar melhor e também facilita na comunicação com o time e stakeholders. Com os engenheiros vendo o board de discovery todos os dias, as pessoas sabem o que estar por vir, discutem e trazem novas ideias e ajudam a avaliar riscos.

As etapas (colunas) do board vão depender de time para time. Caso não saiba por onde começar, crie uma coluna para cada risco e depois itere em cima disso.

Alerta: O board de discovery cria a impressão que existe um passo a passo, uma ordem correta do que fazer primeiro. Diferente do board de desenvolvimento, é importante lembrar ao time que o board de discovery não precisa seguir a ordem correta. Exemplo: Em alguns casos é muito mais eficiente você avaliar o risco técnico antes do risco de usabilidade.

• Lançar e medir também é discovery.

Nem tudo você tem que ter um extenso processo de discovery, seu objetivo é descobrir que ideias necessitam de mais atenção e quais outras você pode acelerar e testar rapidamente. Os 5 riscos não são uma regra, eles servem somente como um guia.

A solução tem pouco esforço e baixo risco? Você construir rapidamente, lançar e medir é um tipo de discovery.

Conclusão

À primeira vista, parece um processo extenso, mas não deveria ser. Devemos sempre tentar encontrar um equilíbrio entre construir a coisa certa, construir da maneira certa e construir rapidamente.

Fazer isso não é fácil, o truque é descobrir como dividir as entregas em pequenas partes, que agreguem valor e nos permita aprender mais rápido.

Domine Product Discovery!

Fique fera em Product Discovery e eleve a barra em Produto na sua empresa! Ao estudar com a PM3, você participa de uma comunidade exclusiva com milhares de alunos e alunas, para fazer muito networking, ver oportunidades de emprego (muitas vezes postadas por quem está contratando), participar de mentorias com experts do mercado, trocar experiências e muito mais.

Baixe agora mesmo a ementa do mais completo Curso de Product Discovery do mercado brasileiro. Com mais de 30 horas de conteúdo aprofundado, reunimos um time de peso, que traz cases reais de empresas como Booking.com, Porto Seguro, OLX Brasil, Easynvest, Creditas, Nubank e muitas outras.

Conteúdos que você também pode gostar:

• O que é e como fazer uma jornada de compra?
• Como mapear uma jornada de monetização em Produto?
• Como funciona o desenvolvimento de novos produtos em grandes empresas
• Tudo o que um Product Manager precisa saber sobre Marketplace