Lembrando que o HDD é um processo orientado a hipótese com foco principal em validação das ideias sob a perspectiva de geração de ROI e satisfação dos usuários. Para isso, um processo maduro de CI (Continuous Integration) e CD (Continuous Deployment) habilita a esteira de validação de ideias e suporte imediato.

Ao formular as hipóteses, utiliza-se os conceitos da experimentação, e por isso a user story é insuficiente para verificar se a hipótese está correta. Na HDD criada, existe uma validação de hipótese referente a uma campanha promocional que pode aumentar a taxa de conversão.

Iniciando a implementação do HDD em um time cross functional – Desenvolvedores, UX, SM (Scrum Master), PO (Product Owner) e QA, precisando validar uma ideia de plataforma de inscrição online para um evento. Algumas discussões surgiram durante a fase de inception para criação do produto:

• E se uma campanha promocional estiver disponível durante 2 semanas? Talvez melhore a taxa de conversão? Os usuários que não aproveitarem a promoção podem repercutir negativamente?
• E quanto isso custa? Você consegue estimar?
• E se ao invés de estimar, checarmos se vale a pena implementar? Acredito que realizando testes A/B podemos verificar a aceitação do público. E se aumentarmos a conversão em 10% já valeria a pena implementar.

E como ficaria tudo isso criando histórias de hipóteses (ao invés de histórias de usuários):

We believe that uma campanha promocional de 2 semanas
Will result in melhoria na conversão da inscrição
We will know we have succeeded when evoluirmos a taxa de conversão em 10% do início ao final da campanha promocional.

E assim, o Product Owner prioriza este desenvolvimento com o time e a implementação deve ocorrer em breve para confirmar se a hipótese irá gerar o valor idealizado. O time começa então a execução do backlog em gestão ágil com práticas CI/CD e apoio total do time de UI/UX para criação dos layouts e experiência do usuário. O resultado do primeiro protótipo foi aprovado e esta é a versão colocada em produção:

E após as duas semanas, verificando o progresso diariamente da conversão, o objetivo foi alcançado. Nesta jornada, foi muito importante o mindset ágil da empresa, operando com práticas DevOps e arquitetura bem estruturada que possibilitam a inovação de produtos. Ao confirmar a hipótese, podemos adotar um exemplo de aumento em receita de R$ 78.000, justificando assim um desenvolvimento na plataforma de 160 horas para implementação desta funcionalidade.

Cases de sucesso

A empresa Hello Group apresentou o uso do HDD com outras técnicas como Google Design Sprints e os livros Lean UX e The Innovator’s Hypothesis para validar hipóteses no mercado, aplicando quatro etapas: 1- Verbalize as hipóteses de que sua ideia é baseada 2- Definir a hipóteses mais críticas que pode ser testada com o menor esforço 3- Faça um plano de como testar sua hipótese 4- Descarte ou ajuste sua ideia.

Outra case de Desenvolvimento Orientado a Hipóteses é da empresa Lastminute.com, divulgado pelo CEO Tom Klein da Sabre Holdings, em que a taxa de conversão aumentou 400% em uma semana devido ao retorno da hipótese que considerava a aquisição da hospedagem premium por usuários em um hotel, de acordo com o período do dia em que eles efetuavam a reserva. A combinação das práticas HDD e CD (Continuous Delivery) amplificam o conhecimento validado, acelerando a experimentação e inovação.

As métricas são essenciais quando trabalhamos com HDD (Hypothesis-Driven Development), pois direcionam as decisões e proveem visibilidade sobre a aceitação dos produtos ou serviços. Há algumas recomendações na adoção de métricas para não se tornarem irrelevantes ao seu negócio.

Actionable metrics são exemplos de métricas consideradas importantes, pois resultam em ações específicas e repetíveis no apoio a tomada de decisão e cumprimento dos objetivos. A abordagem HDD pode ser utilizada neste contexto para desenvolver e experimentar implementações que adicionem valor ao negócio. Comece com poucas métricas e que façam sentido para o seu time.

O metrics that matter, definido por Dave McClure como AARRR Pirate Funnel Metrics, possui as seguintes métricas para acompanhamento:

• Acquisition: número de usuários que visitam o serviço ou produto. Esta métrica precisa garantir o acompanhamento correto da fase de aquisição e quantidade de conversão de clientes. Por exemplo, qual o maior volume nos canais de venda? Qual a melhor performance entre os canais?
• Activation: mensura como está a resposta inicial dos usuários em relação a ativação do serviço. Como foi a experiência do usuário na sua primeira visita? Tempo de permanência, page views, cliques, entre outros são boas métricas. Os testes A/B podem apoiar com landing pages e conteúdo para obter melhor experiência.
• Retention: a retenção dos clientes, mantendo por perto as pessoas que se inscreveram e utilizam um dos serviços. A automação de e-mails, por exemplo, baseada em eventos ou atividades podem apoiar de forma simples.
• Revenue: número de pessoas engajadas com a geração de receita.
• Referral: referências de usuários que encorajam outros a utilizarem seus produtos e serviços. Os testes qualitativos são aplicáveis a um número menor de usuários para depois disseminar o produto a um número maior de usuários.

Figura: AARRR Pirate Funnel Metrics

Com o uso do AARRR, um dashboard de acompanhamento para cada categoria é importante para dar visibilidade as áreas: quantitativa (análise de tráfego e engajamento), qualitativa (teste de usabilidade e monitoramento da sessão), comparativa (testes A/B) e competitiva (monitoramento e rastreamento do mercado). Veja no dashboard abaixo algumas métricas desde a etapa de acquisition até a revenue.

Figura: AARRR Pirate Funnel Metrics

Um outro exemplo de utilização do AARRR pela Apptentive, que demonstra o funil aplicado a um produto de Mobile App. Na fase de Acquisition, mensura-se a quantidade de downloads, instalações e visitas na página. Em Activation, mais direcionado ao uso – tempo de permanência e telas visualizadas. A Retention verifica a permanência, considerando usuários ativos por mês e frequência do uso. Em Referral, além das referências, as avaliações e revisões dos usuários sobre o produto. Por fim, Revenue considera a monetização como a receita média por usuário e compras do App.

Figura: The Mobile App Customer Purchase Funnel Cheat Sheet

Em uma visão adicional do AARRR, também de Dave McClure, fica bem claro o exemplo da aplicabilidade para cada métrica. Começando com a conversão de tráfego, seguida da análise pós inscrição e assinatura. A retenção verifica os usuários que interromperam o uso, e a referência avalia métricas como NPS de satisfação e lealdade dos clientes. Por fim, a receita direciona a dados monetários como o custo de aquisição do cliente e o valor do tempo de vida do cliente.

Figura: Conversion Metrics Example

Em um post anterior, demonstramos a criação das HDDs e como gerenciar o desenvolvimento no Azure DevOps. Para representar as métricas de acompanhamento das HDDs, crie inicialmente uma query em Boards > Query. No exemplo abaixo, criamos três gráficos:

• Status: visualiza as HDDs por status; o intuito é verificar o WIP e possíveis gargalos
• Owner: incluído story points e o proprietário da tarefa, afim de acompanhar a capacidade dos recursos
• Validadas*: sim ou não. O experiment framework sugere marcar como “validated” ou “falsified” quando a tarefa passa para a coluna Completed Experiments, afim de determinar se aquela hipótese foi válida ou não.

This slideshow requires JavaScript.

* para possibilitar isso, precisamos incluir um novo campo na User Story (ou HDD), acessando “Organization Settings > Boards | Process >  Processo utilizado >  Work item type”. No exemplo abaixo, criamos um novo campo do tipo Picklist. 

E o resultado final com os gráficos e as métricas de acompanhamento das HDDs: