Evolução contínua e direcionamento de produtos por outcomes

Um produto digital não tem fim. Ele é o resultado de um trabalho constante de evolução do time de produto, do mercado, do negócio, das mudanças ocasionadas pelo comportamento do usuário e uma série de outros fatores que criam um ciclo contínuo de melhoria e adaptação.

Continuous Improvement: Kaizen

Uma das bases do Kanban é a melhoria contínua. Não que você não possa melhorar usando qualquer outra metodologia, longe disso, mas é que o Kanban incluiu isso como um dos fundamentos de prática. Não existe Kanban se não há melhoria contínua. Para contextualizar essa melhoria contínua, encapsulamos esse significado na palavra japonesa Kaizen, que remete a um significado de melhoria contínua.

É uma palavra que expõe a necessidade e o estado de melhoria profissional e pessoal, de forma incrementada e sucessiva.

O contrário do Kaizen é o Kaikaku, que significa mudança radical. Diferente do Kaizen, que se foca em pequenas mudanças incrementais, o Kaikaku sugere uma quebra de paradigma, fazendo uma mudança drástica e dura, uma revolução.

Pequenas mudanças evolucionárias são mais fáceis de dirigir e consequentemente mudar a empresa como um todo. As características principais dessas pequenas mudanças são:

• Mudanças pequenas, objetivas e focadas;
• Geração de menos resistência;
• Resultados mais constantes e rápidos;
• Mais engajamento de todos os níveis da empresa, já que não causa atrito;
• Geração de confiança de todos os envolvidos, já que os resultados aparecem e são consistentes;

Esses pequenos passos de evolução, geram aprendizados. Quando esses aprendizados são absorvidos, o nível de maturidade de todos aumenta e isso desbloqueia caminhos para a próxima pequena evolução.

Essa abordagem não é diferente na construção de Produtos Digitais. Quando falamos sobre Continuous Discovery e Continuous Delivery (no caso de desenvolvimento), estamos falando de dois ciclos diferentes, mas complementares em suas atividades. A entrega de um complementa a do outro. O avião consegue voar se tiver apenas um dos motores funcionando, mas não terá a mesma potência, não será tão seguro e as pessoas ficarão mais receosas por voar em um avião com um motor só. Contudo, o avião ainda funciona, capenga, mas funciona. Por isso, é recomendado que haja os dois ciclos funcionando juntos. Se por um acaso o time de desenvolvimento não fizer algo como Continuous Delivery ou Deployment, quer dizer que as validações das descobertas do Continuous Discovery demorarão para acontecer e a evolução contínua do produto levará mais tempo para se completar.

Contudo, ambos os ciclos de Discovery e Delivery são ciclos de aprendizado e evolução contínua. Neste caso, quero falar sobre um método de aprendizagem, que na minha opinião, pode ser a bala de prata fundamental teórica para outros métodos. Vamos tentar entender o porquê.

PDSA - A bala de prata. Real e oficial.

Quando você se torna um Product Manager (isso acontece também no mundo dos Agilistas), você se afoga em uma série de métodos e frameworks. Todo mundo quer apresentar aquele framework bala de prata com um nome bonito disjuntivo que saiu no último livro best-seller no The New York Times. Aqui mesmo neste livro mostro uma série de frameworks que eu uso ou usava para me ajudar na gestão do dia a dia de um Produto Digital. Mas, se eu tivesse que elencar um método, que talvez chegue mais perto da bala de prata que todos procuram, certamente esse método seria o PDCA.