No artigo passado eu expliquei como mapear e separar em níveis de interação as equipes e pessoas que são impactadas pelo desenvolvimento do seu produto.

Se você não leu, você pode conferir aqui.

Compreender quem são os seus stakeholders é somente um pequeno passo, você tem que entender como tirar vantagem de seus cargos.

Quando eu digo tirar vantagem não é no sentido ruim da coisa; tipo dar uma rasteira corporativa.

Falo no sentido de utilizar das competências e habilidades inerentes aos seus respectivos cargos, para alavancar o seu trabalho de produto, confiando responsabilidades para atingir um resultado em conjunto.

Vamos fazer um exercício de imaginação.

Imagine que você é uma jovem produteira louca para lançar o seu primeiro desenvolvimento.

No refinamento, a sua tech lead não pode participar pois estava em uma reunião estratégica, já que ela também era Head de Engenharia da tribo.

Para não perder tempo você se juntou com as suas duas engenheiras de software Júnior, refinaram a entrega e definiram um escopo de tempo que você obrigatoriamente comunicou para a sua gerência e áreas interessadas.

No final da sprint de duas semanas, você perguntou para as suas engenheiras:

“E aí, tudo certo para o deploy?”

”Então, tenho uma péssima notícia. Vamos precisar de mais uma semana.”

No fim, semanas foram perdidas devido a estimação de esforço errada e você sabe que isso poderia ser resolvido com apenas um papinho com a sua Tech Lead em outro horário.

Ok. O exemplo é um pouco simplista, mas define bem o que a compreensão profunda dos papéis pode causar. Principalmente quando há mais de um papel para a mesma pessoa (muito comum em startups).

Quando você falha em confiar o trabalho para ganhar em outros aspectos, você perde a oportunidade de alavancar o seu trabalho em produto.

Assim, assumindo riscos que geralmente se conectam com um resultado que não atende as expectativas e por consequência desperdiça tempo (e dinheiro).

Afinal, alguém poderia ter feito o trabalho com mais qualidade e mais rapidamente.

Para que isso não ocorra, eu vou passar para você quatro passos para dar aquele impulso na sua execução.

Compreenda em qual calo você está pisando

Antecipe-se e saiba quem são as equipes multifuncionais das quais o seu lançamento vai impactar.

PMs são responsáveis por mapear as multi dependências das suas ações e comunicá-las de antemão ao início do desenvolvimento.

Esse tipo de atividade pode incluir coisas simples como alinhamento da data de lançamento com o time de Product Marketing, escrever as respostas do FAQ, garantir a política de riscos e por aí vai.

Quer algo para jogar água no champanhe do seu lançamento? Pega um time de atendimento que não foi preparado antecipadamente para atender os clientes e agora está desesperado em busca de respostas das perguntas que a sua funcionalidade criou.

Me dá arrepios em pensar nisso. O Caos!

Escreva as especificações de produto

Papo reto.

Não tem sabor mais gostoso que enviar um link com todas as hipóteses, dados, regras de negócio, discussões, definições e conclusões para explicar o que é e o porquê você está construindo algo.

Aqui eu posso estar sendo um pouco enviesado, afinal eu adoro escrever.

Porém, desde que eu comecei a documentar as decisões de produto, meu trabalho de comunicação síncrona caiu uns 80%.

“Anselmo, você escreve um PRD (Product Requirement Document) para tudo que a equipe faz?”.

Eu gosto de escrever, mas não sou maluco.

A especificação de produto é um documento conciso e fácil de ler que descreve uma aposta de produto proposta. O one-pager comunica claramente sobre o que é a aposta do produto, quais resultados são esperados e como eles serão medidos.

A não ser que o projeto não seja substancial o bastante para merecer uma documentação, escrever é essencial porque força as equipes de produto a pensar, avaliar e revisitar suas apostas de produto.

Porém, eu não vou escrever uma bíblia para mudar a cor de um botão que estava fora do design system. Ou até mesmo quando há a necessidade de resolução de um bug muito urgente.

Para cada caso há uma maneira de se comunicar e documentar.

Compreender qual é o tamanho do esforço empregado para cada caso é o que faz você evoluir e ganhar agilidade.

Estime seu esforço. Ele é importante, SIM!

Estimar é o processo de “custo” que o seu projeto vai ter em contrapartida ao resultado que ele vai entregar.

Trago um exemplo que pode elucidar um pouco melhor essa necessidade.

Já imaginou você chegar na sua equipe de Product Marketing e dizer que não tem a menor ideia quando uma funcionalidade vai ser lançada?

Meu amigo, as outras áreas precisam se preparar. Ou você acha que a sua equipe de produto é a única da empresa que está lançando algo?

Utilize da sua equipe de desenvolvimento e tech lead para que você consiga a melhor estimativa possível, dado a capacidade e habilidade dos mesmos.

Gerencie os riscos de desenvolvimento

Shit happens!

Mas o que você faz quando elas acontecem é a sua responsabilidade.

Quem nunca foi pego de surpresa com um código “legadão”, alguém ficando doente (Alô, COVID) ou mudanças estratégicas.

Com isso, você pode ter que lidar com algumas mudanças nas especificações iniciais do produto que vão forçá-lo a tomar decisões.

É o trabalho do PM transformar as incertezas em hipóteses de solução.

No fim do dia, gerenciamento de produto é envolto por ambiguidades. Você deve estar disposto a trabalhar com essas barreiras e comunicar o impacto no resultado final com muita transparência e trabalho em equipe.

Conclusão

A aplicação efetiva das responsabilidades e papéis de outras áreas vai permitir que você execute de maneira mais rápida.

Execução importa.

Isso te liberta, inclusive, para passar mais tempo nos aspectos mais estratégicos do produto como identificação de oportunidades e validações.

Ter esse espaço para apertar os parafusos vai te ajudar ainda mais a se desenvolver, o que é muito bom para a sua carreira ao longo prazo.