Para quem me conhece, sabe que adoro roteiros de produtos.

Eu sou uma pessoa muito voltada para resultados. Gosto de fazer perguntas e entender por que e como as decisões são tomadas. Suponho que seja por isso que me encaixo no produto muito bem, porque estou sempre perguntando por que as coisas funcionam da maneira que funcionam.

Tendo feito parte do produto por mais de 10 anos e tendo experimentado a enorme evolução e transformação pela qual passou, ainda parece haver uma grande divisão quanto ao que é um roadmap de produto.

Algumas pessoas ainda usam o conceito de cronogramas, enquanto outras passaram a usar roteiros baseados em resultados ou roteiros que se concentram mais em explicar o processo de tomada de decisão.

Mas, com uma transformação digital tão grande acontecendo, por que alguns gerentes de produto estão se agarrando tão fortemente aos cronogramas?

Um pouco de história sobre roteiros

Antes de começarmos, acho que vale a pena dar um passo para trás e olhar primeiro para a história dos roteiros.

Por que as pessoas usaram cronogramas como roteiros?

Porque as equipes não eram Agile. Eles eram em cascata e, para coordenar uma liberação adequada e várias partes móveis, em um ambiente em cascata você precisava de datas de vencimento.

Por que as pessoas não usam cronogramas como roteiros agora?

Porque a maioria das equipes são Agile ou alguma combinação deles (dual track, XP, etc.) Agile é uma metodologia que se concentra em pequenas iterações para o progresso com foco no cliente, ao invés de esperar que tudo seja ‘feito’ para entregar algo . Como há iterações menores, uma linha do tempo se torna um pouco inútil, porque você não está planejando uma “data de término”.

É errado usar uma linha do tempo?

Depende (desculpe pessoal, vocês sabiam que essa seria a minha resposta!) Depende principalmente para o que você está usando. É aceitável usar um cronograma para ampliar o trabalho de Link Dedicado revisado e aceito a ser feito, para que você possa planejar adequadamente a execução de sua estratégia. Isso significa que você não vai precisar de mais do que talvez 6 semanas de trabalho, e isso é em uma equipe Agile Dual Track realmente eficiente que acertou em cheio seu processo de descoberta muito bem.

Então, se a maioria das equipes são Agile, aplicando entrega contínua e trabalhando em iterações – por que diabos os cronogramas são tão proeminentes no setor?

Link Dedicado

A Enquete: O cronograma é um roteiro do produto?

Decidi explorar o conhecimento do setor e fiz uma pequena pesquisa no Linkedin e no Twitter para tentar entender isso.

Dos 258 votos até agora no Linkedin, 92% dos gerentes de produto não veem uma linha do tempo como um roteiro do produto, enquanto 8% disseram que sim (o Twitter apresentou resultados semelhantes).

Mas, como qualquer bom gerente de produto diria, os dados podem contar uma história, mas o feedback qualitativo pode contar outra.

Como os gerentes de produto usam cronogramas?

Enquanto a maioria dos PMs de fato disse que não via uma linha do tempo como um roteiro, as histórias que contaram por trás de como e por que os usam foram realmente interessantes.

Três cenários únicos surgiram:

Gerentes de produto que não usam cronogramas de forma alguma, ou os usam estritamente para comunicar a entrega (lançamentos).

Gerentes de produto que ainda usam cronogramas para se comunicar com as principais partes interessadas, como executivos de nível C, VC ou pessoas fora do produto que não entendem o que é ser “focado no resultado” e insistem em prazos.

Os gerentes de produto que usam cronogramas como roteiros, estão em uma fábrica de recursos sem saída e não têm espaço ou capacidade para trabalho de descoberta.

Das duas pessoas que disseram que ainda usam cronogramas como roteiros, uma delas explicou que comunicam a estratégia com uma tela que descreve como as decisões são tomadas. Este documento estratégico específico é o que eu usaria como um roteiro, então, neste caso específico, acho que é um problema com a terminologia, não com a abordagem.

Por que as pessoas fora do produto ainda estão pedindo cronogramas?

Não tenho certeza se há uma maneira fácil de responder a esta, mas vou tentar.

A necessidade de previsibilidade

Um ambiente em cascata abre caminho para uma previsibilidade muito precisa no processo de entrega. Toda a equipe está trabalhando em direção a um big bang, então definir as datas é crucial.

Quando a transformação de cascata para Agile aconteceu, essa previsibilidade foi embora até certo ponto.

A previsibilidade vem no fato de que você sempre estará lançando algo, mas o que você estará lançando pode mudar drasticamente. Esse é o ponto principal do Agile, estar preparado para feedback e ter um ciclo de aprendizado contínuo com base no que seus clientes e o mercado estão dizendo a você.

Você tem que ser adaptável e não pode se prender a datas definidas, caso contrário, você ficará para trás muito, muito rapidamente.

A necessidade de comercializar

Algumas equipes ainda trabalham supondo que, no momento em que algo atinge seu ambiente de produção, você precisa começar a comercializá-lo.

Eu costumo desaconselhar isso.

Fazer um lançamento suave primeiro e entender como seus clientes atuais reagem às mudanças lhe dará a oportunidade de aprender e fazer ajustes antes de fazer um anúncio maior. Também é provável que os clientes atuais sejam mais receptivos à mudança (e à mudança tendo algumas torções e parafusos soltos, se é que você me entende!)

Depois de entender a recepção e o posicionamento desses novos itens, você pode fazer um lançamento pesado e coordenar com sua equipe de marketing.

Isso também dará a eles a vantagem de acessar análises, comentários e até mesmo ter depoimentos prontos para enviar ao empacotar o anúncio. (Lembre-se de que a validação social e a prova são uma forma de gamificação, então use-as a seu favor!)

Falta de educação

O maior motivo pelo qual os gerentes de produto ficam presos a cronogramas é a falta de educação fora da equipe de produto.

Esta é provavelmente a noz mais difícil de quebrar.

Embora os gerentes de produto possam influenciar a mudança, a menos que os executivos de nível C estejam abertos para a mudança, será uma batalha difícil que você deve aceitar que perderá.

No final do dia, liderança e influência começam de cima para baixo, então, se você for capaz de convencer os executivos de nível C a abandonar o roteiro do cronograma e avançar em direção aos resultados (enquanto ainda usa os cronogramas para olhar para lançamentos de curto prazo), você já está no caminho da transformação digital e do desenvolvimento contínuo.

Link Dedicado

Agile = / Agilidade

Isso pode ser uma extensão do ponto anterior, mas algumas organizações trabalham sob a premissa de que Agile (a metodologia) é o mesmo que agilidade.

Para reiterar, Agile é sobre aprendizado e desenvolvimento contínuos.

Agilidade tem a ver com velocidade.

Essa suposição é o que também leva tantas equipes a tentarem usar estruturas de priorização para decidir no que devem trabalhar a seguir, em vez de usar essas estruturas para estruturar conversas sobre como e por que essas decisões foram tomadas em primeiro lugar.

Como posso ajudar minha equipe a sair dos roteiros da linha do tempo?

Tudo começa com educação e comunicação.

Às vezes, pode valer a pena trazer um consultor de fora para conversar com sua equipe sobre como focar em objetivos, resultados e entrega contínua o ajudará a alcançar mais (e até mesmo trabalhar mais rápido) do que tentar você mesmo.

Nesse ínterim, você pode começar a apresentar alguns argumentos que podem facilitar e abrir a conversa.

Melhor Alinhamento

Em vez de ter prioridades conflitantes, propor um melhor alinhamento por meio de objetivos pode ajudar a facilitar essa transição, apontando que você estará realizando mais fazendo menos.

Mudança no idioma

Acho que uma mudança na linguagem realmente ajuda. As palavras são importantes, e a maneira como nos referimos às coisas geralmente dá o tom de como as coisas são percebidas.

Por exemplo:

Altere “solicitação de recurso” para “feedback” para definir o tom que você está disposto a ter conversas, não se prendendo a uma solicitação.

‘Opportunity backlog’ em vez de ‘backlog’, para diferenciar que o que está no produto está aberto para descoberta, enquanto o que está em desenvolvimento já foi examinado e aprovado.

“Lançamento” em vez de “cronograma” para indicar que um lançamento é sobre um trabalho aprovado que está em andamento, em vez de focar em uma data de término definida.

Alguns gerentes de produto também indicaram que abandonaram totalmente a palavra “roteiro” e se concentram em definir o tom em que o documento em questão se concentra na direção, nas oportunidades e na visão.

Reduzindo o risco de fracasso empresarial

Como vimos, um dos maiores argumentos para usar uma linha do tempo como um roteiro é a necessidade de previsibilidade. Mas a previsibilidade em uma data de lançamento não significa que você está construindo as coisas certas.

Mostre como os resultados e o processo de descoberta realmente ajudam a evitar possíveis falhas de negócios e ajudam a reduzir o débito tecnológico.

Mostre seus objetivos, resultados principais, ROI e custo de atraso.

Essas são as coisas que realmente afetam os negócios muito mais do que uma data de entrega.