Sou nova aqui na Product Oversee e também no mundo de produtos, longuíssimos 5 meses para ser mais exata. Venho do mundo da educação e se eu pudesse me definir em uma palavra, essa palavra seria educadora. Por isso vi a oportunidade de compartilhar experiências e aprendizados através desse canal que já me ajudou bastante.

Esse é um relato do primeiro roadmap da squad e meu.

Como todo bom início de jornada eu precisava ter e dar clareza pro time de quais seriam os nossos passos. Entre muitos primeiros passos na formação dessa nova squad, sim, além de um PM novata, a squad que estou está nascendo, veio o desafio do roadmap.

O primeiro erro:

Começamos pelo básico, definindo o desafio do quarter, e após algumas aulas e alguns artigos lidos eu já estava bem segura de fazer um roadmap pro time! Afinal, existem inúmeras ferramentas prontas de roadmap. Após algumas histórias definidas e OKRs, não deveria ser um desafio muito grande, né? E esse foi meu primeiro erro, subestimei o valor do roadmap para squad.

Fiz ali o que eu tinha visto, repliquei um roadmap que era comum na empresa em que estou, quebrei ele em sprints, sim tudo isso com um time que estava entendendo a sua capacidade, mas de alguma forma aquilo fazia sentido pra mim.

Eis que vamos mostrar para o time o que foi pensado, e não consigo pensar em outra expressão: me senti dando um banho de água gelada em um gato. A ferramenta que deveria servir para tangenciar e dar para o time um norte se tornou ponto de ansiedade e angústia.

“Como a gente vai conseguir alcançar isso?” “Não conhecemos todos os pormenores dos códigos e se tiverem regras que teremos que gastar mais tempo do que o imaginado?” Vi todos insatisfeitos e com aquele ar de “não vamos entregar”. Paramos a reunião e em comum acordo decidimos que não faria sentido pra gente aquele modelo.

Foi nesse momento que eu aprendi uma das primeiras coisas sobre roadmaps: cada persona precisa de uma interpretação diferente do roadmap e nesse caso eu precisava fazer um roadmap para o time e não um roadmap do time. O que isso significa na prática? Não existe uma ferramenta pronta e generalista para ser usada ou uma receita de bolo, a função do roadmap é comunicar o planejamento e gerenciar as expectativas, nesse caso do time, o ponto é gerar entendimento mútuo e alinhamento e é isso que ele deve entregar!

O segundo erro:

Após internalizar o primeiro erro e focar em errar rápido para aprender rápido, aprofundei os estudos sobre roadmap e percebi que a ansiedade dos stakeholders de que o time começasse a entregar rápido estava me deixando ansiosa e eu passei isso para o time.

Quando se monta um time cheio de gente boa a expectativa para que as entregas comecem rápido nasce na cabeça da empresa. No fim, pouco importa as estrelas que você contratou para o seu time, é preciso um tempo para se adaptar e conseguir se entender como time. Sem esse tempo todos ficam inseguros e esse provavelmente não será um ambiente possível para se desenvolver um time ágil ou ter espaço para as estrelas brilharem.

Quando comecei a me concentrar nisso e focar no roadmap para a squad e não um roadmap da squad, ou seja, um roadmap geral, entendi que eu precisava deixar claro qual era o nosso plano para o time e que quando precisasse deixar claro o plano para os stakeholders precisaria de um outro modelo.

Aproveitei que estava engajada nos estudos e consultei algumas ferramentas prontas mas não me detive a elas e coloquei o que achava que traria clareza para o time, onde escolhi o modelo ‘’now, next, later’’. Nos blogs de produto que visitei, a ferramenta escolhida era indicada para stakeholders, no entanto estávamos entendendo nosso capacity e não conseguiríamos alinhar por sprints, fazia sentido naquele momento.

A comunicação ficou clara, todos entenderam o porquê da priorização e ficaram confortáveis com o plano. Na empresa que estou somos norteados por OKRs e sinalizei quais KRs iríamos bater ao terminar a história “chave” para motivar o time, uma das coisas que personalizei no modelo pronto. A princípio pareceu que todos estavam satisfeitos e fiquei feliz por ter conseguido tangibilizar os passos para o time sem autoritarismo.

O terceiro erro:

Parecia que tinha dado tudo certo, mas algumas horinhas depois chega uma mensagem do techlead da squad, algo como,  “Esse roadmap ficou muito melhor e vou ler ele com mais atenção, parece fazer muito sentido, mas senti falta de não ter feito junto com você, gostaria de ter participado”.

Ops! Lição número 3 aprendida: Apesar de ser papel do PM fazer um roadmap, o que é mais importante é que todos se sintam donos daquele produto, porque são. E por querer aplicar as coisas que eu estava lendo e aprendendo, não envolvi todos no processo criativo. Lembra quando eu disse que o roadmap deveria ser para o time e não do time? Nesse terceiro erro entendi que deve se com o time.

O próximo passo:

Nesse momento estamos organizando dinâmicas possíveis para o nosso cenário e dividindo a ideia com a agilista da squad para que esse momento aconteça de forma eficaz e que possamos construir juntos o nosso norteador. Talvez seja o quarto erro para dividir aqui com vocês, mas errar e entender o erro é evoluir, por isso acredito que estamos no caminho certo.

Quando o 3º roadmap estiver pronto espero compartilhar com vocês a experiência dessa dinâmica!

O que aprendi até agora:

• O roadmap perfeito existe? Talvez! Mas não estará em um modelo pré feito de roadmap e não atenderá todas as necessidades do seu time. É necessário personalizar as ferramentas prontas e construir com o time de acordo com a necessidade e maturidade da squad que você está!
• Entender o propósito da ferramenta para aplicar na realidade do time com clareza e empatia;
• Tempo de amadurecimento é fundamental;
• Envolver todo o time é essencial;
• Adaptação de ferramentas prontas para a realidade do seu time é bem importante.