Dual Track Discovery/Delivery é uma prática super moderna e extremamente útil nas equipes de Produto. Depois de implementado, é possível promover um ciclo de inovação contínua dentro da empresa, levando mais valor e mais novidades aos clientes e usuários.
Este tema é pertinente porque ele pode ser considerado como a inovação do Ágil, digamos assim. As empresas mudaram a sua forma de encarar os problemas, também evoluíram seus frameworks, passando a trabalhar com o Continuous Innovation Discovery/Delivery no desenvolvimento de produtos.
Esse texto conta um pouco dos conhecimentos compartilhados pelo César S. Cesar, CPO da Xerpa, em uma das lives da PM3, que você pode conferir clicando aqui.
Problemas no desenvolvimento de Produtos
Dependendo da maturidade da empresa, podemos ver alguns problemas relacionados aos desenvolvimento de produtos. É possível que tenha uma combinação de duas ou mais questões como:
- Features não correspondem às expectativas: são funcionalidades que são lançadas, mas elas não são nem utilizadas pelos usuários. Ou até usam, mas não da melhor forma;
- Histórias incompletas ou pouco detalhadas: a equipe está sempre reclamando que as histórias não estão detalhadas o suficiente, gerando problemas no entendimento da equipe sobre o que deve ser feito, o que estamos precisando resolver;
- Backlog raso. PO sempre correndo atrás: algumas vezes, o time está terminando a Sprint, o PO nem sempre tem todas as histórias prontas e precisa buscar informações para completá-las. Isso acontece quando a equipe não tem o ciclo de Discovery e Delivery sincronizado;
- Pouca ou nenhuma inovação entregue: bastante comum, ainda mais em produtos mais maduros que não seguem uma metodologia desde o início;
- Baixa produtividade dos times: quando as entregas feitas pelo time não estão, de fato, entregando valor e, no final da Sprint, o produto desenvolvido não representa valor para o usuário;
- Gestão não confia nos times / não dá autonomia: talvez o problema mais grave que a equipe pode enfrentar. Quando a equipe tem mais de um problema como os citados acima, ela pode perder a confiança da gestão e isso acaba desmotivando o time.
Vamos ver como a metodologia Inovação Contínua com Dual-Track Discovery/Delivery pode ajudar a resolver muitos destes problemas ou até todos eles!
Evolução do Ágil ao Dual Track Discovery/Delivery
Se estudarmos as etapas de evolução do Ágil ao Dual Track Discovery/Delivery, vamos ver que estes problemas foram sendo resolvidos conforme foram aparecendo. Vamos entender como que esta metodologia funciona na prática e como sua evolução foi acontecendo para tornar as equipes mais engajadas, ajudando muito com que as dificuldades desapareçam aos poucos.
Ágil e o feedback loop
Atuar desta forma significa atuar de maneira iterativa. Ou seja, a cada Sprint, a cada ciclo que a equipe for realizando, ela também recebe feedbacks, novas ideias, solicitações de novas features e faz os ajustes necessários.
- Equipe de Delivery resolve agilmente problemas do cliente;
- Entrega incrementos de valor por meio de nova feature/melhoria;
- Feedback na forma de ideias: relatórios de erros e solicitações de features. Esse ciclo de feedback é o cerne da entrega ágil de software útil (que os clientes usarão);
- Quanto mais rápido entregamos valor, mais rápido obteremos feedback. Aumentando o valor do software para o cliente.
Realidade do feedback loop
Seguir um framework, na prática, geralmente é uma experiência bem diferente do que está escrito no papel. Quando entendemos que a realidade não é tão simples como citado acima, fazemos algumas adaptações. Quando temos muitas ideias surgindo do que tempo de implementação, acabamos acumulando um backlog com uma grande variedade de ideias e podemos perder o controle disso.
Muitas dessas ideias também podem não ser tecnicamente viáveis e podem gerar um problema de produtividade. Principalmente quando o time de Delivery começa a desenvolver e descobre que não vai ser possível dar andamento.
O time de Delivery, muitas vezes, por não ter contato muito próximo com o cliente, pode ficar perdido em relação ao que é realmente valioso ou qual é a prioridade do que deve ser feito.
Portanto, em resumo:
- A realidade da criação do software e do atendimento de clientes é mais complicada que na teoria;
- Sempre haverá mais ideias surgindo do que tempo da equipe para implementar e isso acaba gerando um acúmulo de ideias no backlog;
- É impossível implementar algumas ideias (que não são tecnicamente viáveis), então a equipe as descarta;
- Com o tempo, o backlog fica cada vez maior, até que a equipe fique completamente sobrecarregada e incapaz de responder rapidamente aos clientes.
Garantindo o controle e o valor da entrega
Aqui, a figura do Product Owner (PO) é muito importante. Como PO é um papel do framework Scrum, algumas empresas usam a nomenclatura de Product Manager ou mesmo atuam com um PM e um PO numa mesma equipe.
Ele se torna responsável por fazer um processo, mesmo que mais simples, de Discovery. A cada ideia/história que entra no backlog, ele precisa estudar e entender qual é o seu valor e sua prioridade.
Sempre que o time estiver pronto para receber mais demandas, é papel do PO checar o Product Backlog e entender quais histórias geram mais valor para passar para a etapa de Delivery. Infelizmente, isso não evita o problema de viabilidade técnica da história.
De projeto reativo para a visão de produto
Nesta parte da evolução do processo, a empresa sai de um projeto reativo e entra na visão de produto, com visão e objetivos. Ou seja, até este momento, estávamos atuando na solução de problemas e, agora, passamos a ter metas, trabalhando diretamente no atingimento dos outcomes (resultados).
Todas as ideias precisam estar alinhadas com a visão e objetivos propostos. Passamos, pró-ativamente, a buscar informações que não vêm do cliente diretamente.
Para que consigamos ter um controle melhor, surge um outro backlog: o de ideias ou oportunidades ou outcomes. Neste momento, começamos a trabalhar retirando uma ideia do backlog; o PO continua avaliando se a história é valiosa e está alinhada à visão e aos objetivos e, se estiver, ela entra para o Product Backlog e é desenvolvida de acordo com a prioridade.
Lembrando que, aqui, ainda não acabamos com o problema de viabilidade técnica das histórias (calma que vamos chegar lá! :D).
Garantindo a viabilidade e os insights técnicos (e o comprometimento dos engenheiros)
Finalmente chegamos na etapa em que vamos fechar os gaps de viabilidade técnica. Além disso, também receber insights.
Nesta etapa, um Tech Lead (TL) passa a trabalhar junto com o PO e faz parte do processo de Discovery. Com a adição deste TL, passamos a ter um feedback técnico mais rápido sobre as ideias que podem entrar para o backlog de produto. Além disso, também podem surgir insights técnicos fabulosos sobre como tornar aquela ideia ainda melhor!
Assim como PO faz sempre a pergunta “isso gera valor para o cliente?”, o Tech Lead pergunta “isso é possível de ser feito?”. Gerando um duplo filtro para as ideias que, de fato, vão chegar até o Product Backlog e irem para a etapa de Delivery.
Para que se tenha o engajamento da equipe de desenvolvimento, é bacana ter uma rotatividade entre o TL e os engenheiros. Desta forma,eles podem ter mais contato com a etapa de Delivery e conhecimento mais profundo do cliente, junto ao PO.
Garantindo a usabilidade deliciando usuários ☺
Quando desenvolvemos uma feature ou um produto novo, passamos por 4 riscos que são:
- Risco de valor:
- Risco de visibilidade;
- Risco de usabilidade;
- Risco de viabilidade para o negócio.
Nesta etapa, passamos a ter todos estes riscos endereçados no momento do Discovery. A primeira grande mudança a ser vista é a integração do papel de um Product Designer. Passamos a ter alguém que não vai apenas criar protótipos, mais vai nos ajudar a entender a melhor usabilidade daquela feature ou produto. Começamos a ter um pensamento de design (Design Thinking), adicionando processos de pesquisa (User Centered Design), desenvolvendo protótipos para tangibilizar soluções.
Antes de codificar, conseguimos levar uma solução para o usuário e fazer as perguntas: “você usaria isso?”, “você quer usar isso?” Assim, fazemos um processo de Discovery mais completo e passamos para etapa de Delivery com mais informações, transformando e melhorando a experiência de todos os envolvidos no produto.
Além disso, economizamos o tempo da equipe de engenharia (que costuma ser a equipe mais cara dentro de um time de produtos) e tempo no ciclo de feedback sobre o produto, devido à apresentação de protótipos.
Sabemos que sempre temos que verificar se o produto é possível de construir, se é utilizável e se ele é valioso para o usuário e para o negócio. Na imagem abaixo, podemos ver claramente quais são os responsáveis por cada um destes pontos:
Os PMs são os responsáveis pela inovação e têm o papel de coordenar estes 3 papéis (Product Designer, Tech Lead e engenheiros e o PO).
Vale lembrar:
- Não é só porque algo é viável, possível e utilizável que é desejável.
- É responsabilidade do time de Discovery validar se muitos clientes verdadeiramente têm um problema latente e desejam resolvê-lo com aquela solução;
- Para obter confiança estatística, protótipos navegáveis e dados reais gerados por um sample de usuários representativo são indicados. Sempre que possível, devemos ir além do protótipo navegável. Faça um live data;
- A inovação real acontece quando usamos tecnologia instalada para criar uma forma mais eficiente e/ou mais barata de solucionar um problema real que seja desejado por muitas pessoas, e que possa escalar de forma viável para o negócio.
Sincronizando os tracks de Discovery e Delivery
Geralmente, o ciclo de Discovery é duas vezes mais rápido que o de Delivery. E, em alguns casos, pode ser que seja até mais. Em média, descartamos uma ou mais ideias antes de seguir para o Delivery. Vale salientar que, aqui, estamos falando de um Discovery com features mais simples e não um Job to be Done complexo, que exige mais tempo de aprendizado.
Tendo isso em mente, podemos sincronizar o Discovery e o Delivery para, por exemplo, que o Discovery aconteça entre duas a quatro sprints antes de ser passado para a etapa de Delivery.
Exemplo prático: vamos dizer que estamos iniciando um ciclo de OKR agora, em junho. Se tivermos alguma ideia do que vamos entregar em junho, o ideal é que tivéssemos iniciado o Discovery entre abril e maio para que, em junho, já tivéssemos estabelecido o que será entregue. Desta forma, no início do Delivery já teremos um backlog pronto, validado, detalhado, com todas as informações necessárias para que o produto final seja entregue gerando o maior valor possível para o usuário e produtividade máxima do time, resolvendo ainda um outro problema: melhorar a confiança da gestão na equipe, que nos leva a uma próxima conquista: autonomia.
Continuous Innovation Framework
Continuous Innovation nada mais é do que ter os dois tracks funcionando de maneira contínua, sem interrupções e de maneira sincronizada.
Podemos observar que começamos pelo Job to be Done, geramos os OKRs que irão orientar o Discovery Backlog (com todos os outcomes a serem alcançados). Se observarmos a etapa de Discovery, podemos perceber que ela é composta de práticas de Design Thinking e pesquisa. Se for viável, vamos para a próxima etapa: Delivery. Na segunda parte, a prática é a de Ágil comum: começa por uma história planejada e priorizada, ela é desenvolvida, testada, validada e, se estiver tudo certo, vai para o mercado.
Primeiros Passos
Para dar os primeiros passos do Dual Track Discovery/Delivery na sua empresa, em resumo:
- Comece reunindo todas as ideias que flutuam em torno do produto e crie um backlog de ideias/oportunidades ou mesmo crie épicos para problemas;
- Depois disso, envolva o Tech Lead na avaliação das histórias com o Product Owner antes que elas acabem na frente de toda a equipe de Delivery. Faça um filtro destas ideias validando o que é possível ser desenvolvido;
- Em seguida, envolva o Product Designer e comece a criar protótipos para os casos mais óbvios, validando-os com os clientes antes de alimentar o backlog de Delivery. Isso ajuda muito no processo de design e começamos a trabalhar com uma visão ainda mais centrada no usuário;
- Depois que sua equipe estiver acostumada com a ideia e o processo, encontre maneiras de investigar problemas dos clientes e criar um protótipo para cada incremento significativo de valor que mostre-se viável.
Não é um processo fácil e pode levar meses para sua equipe se adaptar, mas, sem dúvidas, após implementado e rodando corretamente, muitos problemas serão resolvidos. É importante envolver toda a liderança da empresa para que todos entendam, engajem e façam parte da mudança.
Confira a live completa do César, clicando aqui!
Que tal um pouco de Product Discovery na prática?
Assista a live da Iris Sayuri, Product Manager da Easynvest sobre como começar a aplicar o Discovery na prática para saber mais sobre isso. Ela mostra como eles desenvolvem um Product Discovery com qualidade na Easynvest, uma das maiores corretoras do país e a primeira que se lançou na corrida online no segmento. Assista agora.
Quer aprender mais sobre Product Discovery?
Para alavancar seus conhecimentos em frameworks, métricas, ferramentas e saber tudo o que há de novo nessa área, garanta sua vaga em nosso Curso de Product Discovery! São mais de 30 horas de conteúdo em vídeo-aulas, artigos cuidadosamente selecionados, um time de peso de 14 instrutores de empresas como Nubank, Booking.com, PicPay, Itaú, Revelo, OLX e muitas outras. Baixe a ementa do curso e dê um upgrade no seu currículo!
