Eu lembro que era uma sexta-feira. Passei o dia todo em ligações e “entrevistas” sobre a possibilidade de assumir o papel de Product Owner em um novo projeto que estava iniciando no Rio.
Por volta das 17:00 eu recebi a ligação final: “Thiago, pode comprar a sua passagem. Segunda já começamos o Product Discovery”. E assim foi: comprei minha passagem, reservei meu hotel e dediquei meu fim de semana para rever algumas coisas. Foi quando eu li o “Direto ao Ponto”, do Caroli, e também estudei todo o processo que iríamos adotar para essa semana inteira de discovery.
Chegou a segunda-feira e justo nesse dia aconteceu algo que até é bem comum para quem vai sempre pro Rio. Meu vôo atrasou e foi desviado para o Galeão (o escritório era do lado do Santos Dumont). Resultado: além de toda a correria, cheguei com a sessão já iniciada. Estavam na sala todos os envolvidos no produto (Um CDC Online): marketing, operações, TI, backoffice, financeiro, cobrança, atendimento. Da parte técnica também tínhamos especialistas em fraude, segurança, arquitetura.
Todos os envolvidos em algum nível estavam lá. Fui brevemente apresentado e seguimos com as dinâmicas.
Um detalhe aqui: nesse ponto, já tinham sido feitas pesquisas de mercado, estudos financeiros e alguns direcionamentos prévios da inciativa. Estávamos reunidos para aprimorar o entendimento e conseguirmos uma proposta de MVP e Roadmap.
E começamos nossa semana com a Visão do Produto: “Estabelecer uma visão compartilhada do que é o produto junto a todo o time”. Como algum trabalho já havia sido feito, essa etapa foi rápida, pois já havia um bom entendimento do que seria o produto.
Em seguida, fizemos um Painel CSD: “Entrar em consenso com o time todo sobre quais são nossas certezas, nossas suposições e nossas dúvidas”. Essa foi uma atividade bem proveitosa, que gerou insumos e discussões que se mostraram úteis ao longo de toda a execução da iniciativa nos meses seguintes. Dinâmica simples, mas muito poderosa!
Depois rolou um tradicional É / Não É / Faz / Não Faz – “Alinhar o time sobre tudo aquilo que é o produto e também o que não é, e definir o que ele faz e o que ele não faz”.
Aqui merece uma observação. Como era um grupo relativamente grande, eles foram todos divididos em sub-grupos. Cada grupo menor executava a dinâmica, e depois fazíamos um compilado com a contribuição de todos, assim garantindo que todos eram considerados nos estudos.
Essa atividade também norteou muito toda a execução. Em muitos encontros no futuro nós voltamos a itens que foram discutidos nesse momento. Extremamente útil.
Nesse momento nós já tínhamos uma relação preliminar de features que deveriam estar presentes no produto, e então fizemos uma dinâmica comparativa de Valor X Complexidade de features – “Panorama comparando o valor das features do produto e quão complexa elas são para desenvolver”. Estávamos nos aprofundando no produto e já entendo sobre como poderíamos priorizar as coisas.
Tudo isso rolou no primeiro dia. Já o segundo dia foi destinado ao mapeamento de personas – “Qual é o perfil dos usuários do produto?”. Os grupos fizeram o mapeamento de 9 personas que representavam os principais afetados pela solução dentro do nosso público alvo. Mas isso gerou um pequeno problema: como trabalhar com 9 personas diferentes?
Nesse momento, fizemos uma priorização das personas levando em consideração dois fatores: quão digital e quão planjada seria cada persona. Dessa forma, conseguimos reduzir em 4 personas que se mostraram mais representativas para trabalharmos. Essa etapa foi totalmente não planejada, mas necessária. Aqui entrou nosso toque de adaptação do processo, não ficar preso ao script inicial.
No terceiro dia foi a vez de mapear a jornada do usuário – “Como o usuário interage com o produto” – e entender pontos de dor e possíveis GAPs. E foi mais um momento muito rico. Conseguimos mapear uma enormidade de situações e possibilidades que não tínhamos pensado antes. E acabou saindo um novo resultado inesperado: nosso backlog de coisas a serem consideradas além do desenvolvimento do produto, mas relativa a todo o processo.
Como esse era um projeto de transformação digital, essa foi uma etapa importantíssima para orientar toda a companhia sobre as mudanças que começariam a partir daquele momento. Como tínhamos todos os envolvidos na sala, o nível de alinhamento foi sensacional, e foi mais uma atividade que acabou balisando toda a execução do projeto nos meses seguintes.
No dia 4 foi a hora de montar nosso backlog de features e épicos – “Quais são os itens que compõem o produto” – e fazer a priorização, entendendo o que poderia (ou na verdade, deveria) entrar no MVP.
Vale ressaltar aqui o trabalho “por fora” do PO (no caso eu). Todos os dias fazíamos um fechamento dos aprendizados e discutíamos os ajustes necessários. Eu ia sempre evoluindo as informações e artefatos, já montando o backlog e listando features e desenhando épicos. Quando chegamos no quarto dia, uma boa parte do trabalho já estava bem adiantada, o que facilitou muito as dinâmicas.
Na priorização, utilizamos o RUT – Relevância, Urgência, Tendência – “Qual a prioridade dos itens do produto”. É uma dinâmica ótima para grandes grupos, onde todos votavam com as mãos, e discutíamos as discrepâncias, atingindo o consenso. De mais de 50 features mapeadas, precisamos priorizar efetivamente em torno de 30, já que as demais já estariam claramente fora do MVP.
A sim, e o MVP? Para sairmos com uma definição do que seria o MVP, eu utilizei o próprio RUT. Tudo aquilo que recebeu uma nota 5 em Relevância – “Não há produto sem este ítem” – certamente deveria estar no MVP. E foi esse critério que utilizamos.
E o resultado é que muita coisa importante ficou de fora, mas houve consenso sobre o que era realmente necessário para a primeira entrega, e para podermos validar a hipótese do nosso produto. Isso foi crucial para o sucesso de toda a inciativa.
Uma das coisas que eu mais fiz dali pra frente foi relembrar do escopo do MVP e defender de todas as formas que não desviássemos disso, garantindo que entragaríamos o que era necessário para validar o produto dentro de um prazo razoável para o negócio.
No final nós aproveitamos o último dia para mapear e direcionar todos os cenários de exceção da Jornada, para que pudéssemos tratar ao longo do projeto nos momentos oportunos, até porque muita coisa envolveria processos e trabalhos manuais das áreas, e não estavam diretamente atrelados ao backlog do produto.
Após essa semana intensa, eu tinha a missão de apresentar o roadmap do produto, responder a famosa pergunta: “vai dar tempo?”, e ainda direcionar todo o time de desenvolvimento (iríamos iniciar o desenvolvimento em apenas duas semanas). Mas as emoçöes da execução eu posso contar em um novo artigo. Só me diga nos comentários se você quer saber como que eu:
- Fiz workshops técnicos para entender todo o negócio em uma semana.
- Trabalhei com o time para estimar e desenhar o Roadmap.
- Mantive o foco no MVP e trabalhei todas as mudanças de escopo e prioridade.
- Reportei a iniciativa para o comitê executivo, mantendo todos alinhados semanalmente evitando surpresas.
- Gerimos as diversas frentes envolvendo times distribuídos para UI, UX, UX Writing, Meios de pagamento, etc.
- Rodei testes de usabilidade com o usuário final.
Olha que time maravilhoso:
Ah, você deve se perguntar: “Thiago, mas não eram dois produtos digitais?”. Pois é, todo esse relato foi sobre como iniciamos o CDC Online, mas pouco depois disso também começamos o EP Online, e isso eu também conto nos próximos artigos (teve muito benchmarking, e muito mais emoção).
Atualização! Recentemente fizemos um Almoce e Aprenda com esse case! Confira em nosso canal do Youtube.
Referências
Muito dessa dinâmica foi inspirada no livro: “Lean Inception: Como alinhar pessoas e construir o produto certo” – https://amzn.to/3PLlnST
