Dez maneiras de ter sucesso na apresentação do roteiro do produto

A apresentação de um roteiro de produto pode ser complicada para desenvolvedores e gerentes de produto. Uma das partes trabalhou muito para chegar a uma visão enquanto a outra parte aguarda para ver algo desconhecido que vai afetar seu trabalho.

Senti essa tensão quando trabalhei como desenvolvedor e me encontrava, com frequência, insatisfeito com os roteiros que o gerenciamento de produtos reunia. Eu não concordava totalmente com as decisões e, com frequência, saia de reuniões de planejamento com o sentimento de "bem, isso não faz sentido para mim, mas se eles pensam assim...", ou, até pior, um "teremos que descobrir nós mesmos e fazer parecer que nos adequamos a esse roteiro".

Você pode argumentar que o problema devia ser eu sofrendo da síndrome do "não inventado aqui" e você pode estar certo. Como desenvolvedor, eu tinha uma opinião muito forte sobre o que era o certo a fazer. Mas agora, como gerente de produto, vejo o que causou esta desconexão e quais aprendizados gerais os gerentes de produtos podem tirar desse caso para emplacarem uma apresentação de roteiro. Afinal, se a equipe técnica entende e concorda com a visão global, as decisões de implementação e de design do dia a dia vão ser feitas com o contexto certo e você vai ter o produto que imaginou.

Estas são, para mim, as dez principais maneiras de conquistar as equipes com uma apresentação de roteiro.

Chavões como "análise de big data", "aprendizagem de máquina" ou "uma iniciativa de Internet das Coisas (IoT)" podem soar, para os parceiros de negócios, como pontos de ancoragem de alto nível, mas não são itens úteis e práticos para as equipes técnicas. A equipe de engenharia precisa saber exatamente o que está criando, como se relaciona com os produtos atuais, como deve ser entregue, qual é o público-alvo e qual é a finalidade.

Definir temas de alto nível é ótimo para estruturar o roteiro e o contexto, mas se certifique de não parar por ai e tenha ótimas respostas para o que está por trás de cada item de alto nível. Por exemplo, se você chama um tema de "serviços inteligentes", certifique-se de detalhar isso em epics e iniciativas principais que são necessários para fornecer esse tema.

As equipes técnicas precisam saber por que você está criando algo de acordo com um roteiro. Nenhuma equipe técnica dirá: "Diga-me o que quer e farei para você". Pelo contrário, os engenheiros precisam de evidências que mostrem por que você precisa de uma função. Deixe os dados falarem, mas conte também uma ótima história do ponto de vista de seus usuários. Use personagens e fale sobre algumas alternativas que você já excluiu e o motivo. Para ajudar toda a equipe entender o roteiro, o motivo importa tanto quanto a necessidade.

Se uma função não parecer bem pensado ou realista, mas estiver no roteiro, ele deverá ser analisado com cuidado. Você não quer que a equipe técnica tenha a impressão de que devem criar itens só porque você prometeu isso a alguém. Isso pode ser um compromisso com um cliente ou apenas porque "a gerência quer". Então, pense bem antes de fazer compromissos. Mesmo que alguém com um cargo mais alto deseje uma determinada alteração, certifique-se de entender e passar a base racional para a equipe e continue dando suporte.

Uma ideia pode ser boa, mas será ainda melhor se todo mundo tiver confiança de que ela poderá ser alcançada. O plano não necessita ser preciso, mas se a primeira coisa que seu gerente de desenvolvimento vir ao olhar para um roteiro for um grande obstáculo – por exemplo, se o roteiro parecer complicado e centralizado em front-end, mas a equipe tem apenas um designer e está enfrentando problemas com tópicos de frontend nos últimos meses – então o gerente terá dificuldades com o roteiro durante toda sua apresentação.

Verifique a realidade antecipadamente com a equipe e teste cenários hipotéticos. Você precisa ter respostas, um plano de ação e uma consideração concisa sobre "como isso pode ser feito" antes de pedir o comprometimento de todos.

Você precisa estar ciente sobre como são o produto e as habilidades da equipe em relação a o que você deseja. É ótimo avançar em novos campos, o que podem exigir novas habilidades na equipe ou o afastamento de uma tecnologia existente, mas não estabeleça apenas sonhos sobre o que deseja obter em um ano. Em vez disso, pense em como obter o que deseja realisticamente. Aquisição de talentos e adoção de novas tecnologias levam tempo, e abandonar os produtos existentes requer compromissos claros e um plano de transição.

Caso de negócios? Sim. Equipes técnicas se preocupam com casos de negócios. Talvez não na mesma medida que a gerência sênior, mas toda a equipe de desenvolvimento se preocupa com o motivo pelo qual algo é relevante para o negócio, se produz resultados reais e como será mensurado. Explore o conhecimento de negócios de sua equipe técnica. Todo mundo tem grande interesse no sucesso de negócios, e isso pode ser uma grande fonte de feedbacks ou ideias adicionais.

Além disso, clareza total sobre o impacto nos negócios e ver tudo acontecer pode ser um grande motivador. Ter resultados é melhor do que apenas criar e fornecer uma função.

Os engenheiros querem criar produtos exclusivos e inovadores dos quais possam se orgulhar. Se for algo que já foi feito antes, eles podem ficar desmotivados. Certifique-se de pesquisar para confirmar se sua história é tão inovadora quanto você pensa. Além de desenvolvedores desmotivados, o impacto nos negócios da falta de inovação é ainda pior.

Dito isto, até os roteiros serão sempre um ato de equilíbrio entre novas funções incríveis e outros, tecnicamente, não muito interessantes que devem ser feitos. Tente certificar-se de que até mesmo o monótono seja motivador no seu roteiro.

Criar um produto mínimo viável e, em seguida, uma versão 1 é uma coisa, mas também há tudo o que acontece após a liberação: operações, manutenção, solicitação de funções pelos usuários, melhorias contínuas e novas versões de outros produtos e/ou plataformas que são integrados. Pensar rapidamente nos desafios e obstáculos que podem surgir após a liberação mostrará esses pontos sem muito esforço, e os engenheiros serão gratos por você não ter ignorado estas realidades. Estimativas aproximadas sugerem que o esforço inicial da criação de uma nova função é muitas vezes apenas de um terço à metade do esforço total gasto em relação a todo o ciclo de vida do função. Ou seja: a pós-liberação é mais custosa que a criação inicial e algumas "coisas pequenas e rápidas" tornam-se muito caras a longo prazo.

Estimativas são algo bom de se fazer. Elas dão orientação e são criadas de acordo com o melhor do conhecimento do gerente de produtos de acordo com as circunstâncias. No entanto, muitas suposições feitas de acordo com estimativas podem se mostrar incorretas após a implementação ou a melhoria de um design. Certifique-se de preparar e apresentar o roteiro para que ele seja flexível às mudanças.

Um roteiro existe para fornecer orientação. Não é um plano detalhado para execução e todos em uma equipe de software sabem disso. Não há necessidade de vendê-lo como algo diferente do que é. Então, se você ainda não tem todos os detalhes sobre um tema, seja honesto sobre isso. Compartilhe o que tem, qual é a intenção, quais são as questões em aberto e os riscos mais altos que ainda precisam ser abordados. Destaque áreas que requerem testes e mais pesquisa para entender o cenário. Lembre-se de executar o teste de acordo com o planejamento.

Sua equipe merece um roteiro que claramente mostre todo o cenário, mas não negligencie as realidades. Sua equipe também merece um roteiro motivador, emocionante e que tenha detalhes suficientes para que toda a equipe de software saiba o que fazer nos próximos 1-2 sprints com um sentimento de confiança de que obterão grandes resultados com impacto material para o negócio.

Precisa de mais ajuda? Consulte as funções de roteiros do Jira Software e o template de roteiro do produto no Jira. Ou teste o Jira Product Discovery, feito para PMs, é grátis.