Como fazer um bom Continuous Discovery?

Hoje falaremos um pouco sobre Continuous Discovery, tema da aula do Marcelo Abreu, instrutor do nosso Curso de Product Discovery.

Para gerar o processo de Continuous Discovery, é necessário desenvolver uma cultura e mudança de mindset na equipe e na empresa.

É um ciclo contínuo de descobertas em paralelo com um ciclo de entregas. É necessário um time colaborativo e integrado para fazer acontecer!

Veja como aplicar o Continuous Discovery na prática!

O que é Continuous Discovery?

Vamos começar passando o conceito desta prática: Continuous Discovery é fazer o processo de Discovery continuamente, abraçando experimentações focadas no resultado gerado, seguindo a visão de produto ou objetivo de negócio em um trabalho colaborativo com foco constante no usuário.

Vem embutido com alguns mindsets específicos, que você precisa ter no radar. Alguns deles fazem parte do mindset de Discovery, mas existem outros muito importantes para que este processo seja contínuo.

Precisamos avaliar a cultura da Certeza e a cultura da Experimentação. É muito comum, para todos que trabalham com produtos, principalmente para quem está entrando na área, algumas hipóteses parecerem meio óbvias. Nos deparamos com problemas que, muitas vezes, parecemos ter certeza de qual é a solução. Nós sabemos que a palavra “certeza” é bem perigosa quando empregada no Discovery de produtos. É muito importante você ter o mindset de que tudo é experimento. Você precisa descobrir (da maneira mais rápida possível), se sua hipótese vai ter o resultado esperado – ou não.

Outro ponto muito importante neste processo é ter os “Outcomes” no lugar dos “Outputs”. Resultados valem muito mais que features entregues.

Uma questão muito importante em Continuous Discovery é o foco que os times têm em muitas ideias geradas, criando um backlog muito longo versus um mindset de objetivos claros, sendo muito menos produtivo.

Handoffs x colaboração. As pessoas acham, muitas vezes, que existem dois times diferentes: um focado em Discovery e outro em Delivery, dividindo o time em muitas etapas, deixando-se de lado, erroneamente, a colaboração.

O Continuous Discovery tem tempos diferentes do processo de Delivery, além de cargas diferentes de descoberta. É importante fazer validações rápidas para colocar o produto em produção o quanto antes.

“Eu encorajo times a fazer um Discovery de produtos contínuo – onde eles estão constantemente identificando, validando e descrevendo novos itens do backlog.” Marty Cagan (Consultor de Product Management, Fundador do Silicon Valley Product Group)

Vale também citar a Opportunity Solution Tree, da Teresa Torres, sobre a qual já falamos aqui no blog!

Metodologia Dual-Track Agile

Bom, e agora? Como colocar o processo, de maneira prática, no ar? Vamos lembrar um pouco sobre os 12 princípios do Manifesto Ágil, criado em 2001 por 17 profissionais da área:

1 – Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado.

2 – Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.

3 – Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo.

4 – Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.

5 – Construir projetos em torno de indivíduos motivados, dando a eles o ambiente e o suporte necessário e confiando neles para fazer o trabalho.

6 – O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é por meio de conversa face a face.

7 – Software funcionando é a medida primária de progresso.

8 – Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.

9 – Contínua atenção a excelência técnica e bom design aumenta a agilidade.

10 – Simplicidade: a arte de maximizar a quantidade de trabalho não realizado é essencial.

11 – As melhores arquiteturas, requisitos e designs emergem de times auto organizáveis.

12 – Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.

Ou seja, o Manifesto Ágil foca muito na forma como o time deve ser construído e o que é realmente uma entrega de valor.

Quando falamos do processo do desenvolvimento ágil, pensamos em receber feedbacks rápidos dos clientes para criar soluções cada vez melhores, sempre gerando valor para os usuários. Mas sabemos que, na prática, não é bem assim. Alguns problemas podem acontecer:

Features entregues não geram o impacto esperado;
Backlog pouco detalhado e muitos riscos não mitigados;
Pouco valor real sendo gerado, de fato, para o usuário;
Processo moroso de priorização com backlog crescente;
Falta de conexão entre visão de produtos e entregas;
Pouca ou nenhuma inovação entregue;
Baixa produtividade do time.

Justamente por entender que, na prática, o processo poderia não funcionar tão bem quanto na teoria, foi desenvolvido o processo de Dual-Track Agile. Este processo consiste em ter um único time trabalhando com dois focos diferentes ao mesmo tempo: Discovery e Delivery.

“O gerente de produto, o designer e o techlead trabalhando juntos, lado a lado, para criar e validar itens de backlog.” Marty Cagan

Temos ideias sendo geradas constantemente, que vão para o backlog, mas a diferença agora, é que vamos ter uma parte do processo para entender se as ideias possuem valor agregado e se são viáveis tecnicamente.

Neste momento, existem focos voltados para o que acontece (por meio de ferramentas de analytics, por exemplo, baseado em dados) e por que acontece (falando com o usuário, fazendo pesquisas). O processo de Problem Research deve utilizar dados quantitativos e qualitativos para termos a validação do “o que” e “por que” o comportamento ocorre.

Para validar as oportunidades a serem focadas, podemos utilizar alguns métodos, como:

Entrevistas com os clientes;
Análise de ferramentas de analytics;
Análises de dados de business;
Pesquisa de mercado;
Análise de tickets do chat;
Conversas com os times de atendimento/vendas.

Na camada de Delivery, a aplicação é desenvolvida e o valor é entregue para o usuário. Lembrando que esta parte do processo não é apenas de responsabilidade dos desenvolvedores, não é simplesmente uma passagem de bastão. Não existe um processo de Continuous Discovery sem um Continuous Delivery.

Uma dica para o acompanhamento do processo, é criar boards separados para o Discovery e para o Delivery. Cada um dos processos tem características diferentes e, para que as informações de cada passo fiquem claras para toda a equipe, recomendamos utilizar o Kanban com tarefas separadas por Discovery e Delivery.

Vale salientar que este tipo de acompanhamento pede mais alinhamento, afinal, não queremos que o time se separe, mas sim, que trabalhe com o mesmo objetivo. Então, a sincronização das tracks se torna muito mais importante. Devemos considerar que o processo de Discovery é 2 vezes mais rápido que o de Delivery e as validações, muitas vezes, são refutadas, gerando muitas iterações no Discovery.

Desenvolvimento voltado a hipóteses

As hipóteses são premissas baseadas em dados, para as quais precisamos usar métodos científicos para validá-las ou refutá-las. Existe até uma frase de hipótese para acompanhamento:

“Acreditamos que a [oportunidade] acontece por conta de [hipótese]. Para verificar isso, iremos [experimento] e mediremos a métrica [métrica]. Saberemos se estávamos certos se a [métrica] chegar em [meta] em [período de tempo].”

É uma técnica simples. Lendo essa frase, conseguimos entender se o que estamos propondo tem sentido; se o experimento tem conexão com a hipótese que estamos gerando.

Tente sempre validar a hipótese antes de desenvolver a feature. Encontre maneiras diferentes de confirma-las sem precisar envolver desenvolvimento. Isso vai ajudar muito a mitigar riscos, mesmo não tendo a garantia 100% de que esta hipótese irá gerar valor.

Agora, você passa a olhar os objetivos de negócio. Para ser mais eficiente na geração e validação de hipóteses, é necessário ter um foco. Não cometa o erro de não acompanhar as hipóteses após o Delivery.

Uma forma muito prática de acompanhar o andamento das hipóteses é utilizando o Product Kata, da Melissa Perri. Este método tem como foco a melhoria contínua pensando nos aprendizados obtidos através de 6 perguntas no início de cada ciclo:

Qual é o nosso objetivo?
Qual é nossa condição atual?
Qual é nossa condição alvo?
Quais obstáculos (oportunidades) estão nos evitando de chegar ao alvo?
Qual será nosso plano de ação para isso e qual a expectativa? (Hipótese)
O que aprendemos com tudo isso?

“Nós precisamos quebrar a métrica de sucesso em algo que podemos mensurar e medir em uma escala de tempo menor. Nós chamamos isso de o objetivo do time, é assim que mensuramos o sucesso da alternativa.” Melissa Perri (Consultora de Product Management, UX, Agile e Lean, Autora do Livro “Escaping the Build Trap”)

Você pode acompanhar suas hipóteses utilizando vários softwares e em vários formatos diferentes, mas o mais importante (e o mais difícil) disso tudo é criar a cultura de acompanha-las sempre para que o processo seja contínuo.

Continuous Discovery na Prática

Começando com uma frase da nossa guru, Teresa Torres:

“É muito comum nós termos um mindset de projeto, em que começamos fazendo um pouco de Discovery, fazemos muito delivery, entregando feature e passamos para o próximo projeto” Teresa Torres (Product Discovery Coach)

Para mudar este mindset de “projuto” (projeto + produto) e colocar o Continuous Discovery em prática, temos algumas dicas valiosas:

Negocie! Negocie para terem objetivos e metas bem definidas nos projetos e não apenas entregáveis.
Dê visibilidade aos resultados positivos. Os benefícios reais gerados são sempre o melhor argumento para convencer qualquer board de empresa.
Não existe Continuous Discovery sem Continuous Delivery. Em um processo não sincronizado (gargalos), não é possível fazer o ciclo girar de maneira contínua.
Limite seu Work In Progress (WIP). Ter muitas tarefas em paralelo, abre concorrência entre os esforços da equipe, fazendo com que o processo se torne pesado e mais difícil.
Não existe um time de Discovery e um time de Delivery. É todo mundo uma equipe! Tome cuidado para não transformar o seu Dual-Track em Waterfall.
Não priorize tarefa, atinja objetivos! Não gaste energia priorizando ideias desconexas do backlog para fazer, descubra as oportunidades que resolverão seu objetivo de negócio foco.
Hipótese reversa: não tente criar uma hipótese quando já tem a solução escolhida, a não ser que isso te ajude a ter uma visão mais clara do problema.

O processo de Continuous Discovery é uma cultura. É uma evolução contínua. Prepare seu time e trabalhe esses mindsets regularmente. Desta forma o trabalho vai se tornar mais produtivo, colaborativo e as entregas terão mais valor para o usuário.

Gostou do conteúdo? Tem muito mais esperando por você!

Além do Marcelo Abreu, temos um time de peso de instrutores esperando por você no curso de Product Discovery da PM3.

Para ter acesso completo às aulas, cases reais e 14 profissionais renomados de empresas como OLX, Nubank, Revelo, Booking.com, PicPay e muitas outras, garanta seu acesso!