Quando falamos em priorizar um roadmap, uma coisa que acaba acontecendo é que acabamos atendendo absolutamente todos os pedidos, de todo mundo. Ou seja, tudo é importante, pois tudo entra no roadmap, só que o que é menos importante fica pra depois. A pessoa que pediu tem o alento de que “está no roadmap” apesar de ter ficado lá pra frente e ter boas chances de ser empurrado ainda mais pra frente se aparecer algum item mais importante.

Por que isso acontece?

O gestor de produtos acabando dizendo “sim” para pedidos que recebe por vários motivos:

• Precisa agradar a todos: esse é um problema bastante comum do gestor de produtos, a necessidade de agradar a todos. Quando o gestor de produtos vê que a resposta “vou colocar no backlog” acalma as pessoas que estão lhe pedindo algo, ele começa a usar essa resposta de forma indiscriminada. Como isso o roadmap ficará enorme e bastante complexo de gerenciar. Além disso, quando a pessoa que te pediu algo ver que “estar no backlog” não é garantia de que será feito logo, ele não ficará feliz… :-/
   
• Os dados mostram que temos que fazer: cada vez mais vejo empresas focadas em tomar decisões exclusivamente baseadas em dados. Com isso, em breve poderemos todos nós sermos substituídos por algoritmos que tomarão as decisões, já que basta tomar as decisões baseadas nos dados. Acontece que os dados nem sempre estão certos. Pode haver dados insuficientes, ou mesmo dados errados. Outro problema de decisões baseadas em dados é o risco de se cair em um ótimo local. A sugestão é usar dados como um dos inputs para a tomada de decisão, mas não esquecer tb dados qualitativos, sua intuição e sua capacidade de julgamento.
   
• Mas é uma feature tão pequena: toda feature, por menor que seja, implicará em mais código e mais interação. Mais código significa complexidade de código. Quanto mais complexo o código, mais difícil de manter. Mais interação significa mais complexidade para seu usuário lidar, ou seja, chances de oferecer um experiência ruim para seu usuário. Nenhuma feature é tão pequena que não traga complexidade de código e de interação, por isso, pondere bem se essa complexidade adicional trará benefícios para seu usuário e para o dono do software.
   
• O cliente pediu e se não fizermos ele vai embora: esse é o momento de tomar decisões difíceis. Se vc quiser agradar todos os clientes, vai acabar agradando nenhum. Vc precisa escolher, quem é o ciente para quem vc está fazendo seu produto. Um produto não pode ter mais do que duas ou três personas primárias. Aliás, o recomendado é ter apenas uma persona primária. Ter duas ou três já te dará um trabalho razoável para conseguir gerenciar. Se o que esse cliente pediu não atende sua persona primária, vc terá que ter coragem de dizer NÃO.
   
• A gente sempre pode fazer dessa nova feature mais uma opção nas configurações: mais uma vez estamos criando complexidade sem necessidade. Como dito acima, toda feature implicada em complexidade de código e complexidade de interação. Colocando todas as novas features como opcionais a serem configurados numa tela de configuração fará dessa tela algo bem difícil para seu usuário.
  

• Nossos competidores já tem: esse é um erro bem comum, se basear nos competidores e não no seu cliente / usuário. Lembre-se, um gestor de produtos tem que se preocupar em fazer o software atender os objetivos da empresa dona do software ao mesmo tempo que resolve um problema ou atende uma necessidade de seus clientes. É importante saber o que o competidor está fazendo, mas se o que ele estiver fazendo não tem a ver com o objetivo de sua empresa, nem com os problemas ou necessidades de seus clientes, então vc não precisa fazer igual.
   
• O chefe quer: existem chefes e chefes. Se o seu chefe for extremamente antenado em relação aos clientes, é importante ouvi-lo. Ele será sempre um grande aliado. Agora, se seu chefe quer uma determinada feature simplesmente porque viu em algum competidor, ou alguém falou para ele que deveria fazer assim, vc deve lembrá-lo dos objetivos da empresa e dos problemas e necessidades de seus clientes que vc está tentando atender com o seu produto de software.

Aprendendo a dizer NÃO!

Apesar das razões acima para dizer sim a todo pedido de feature que um gestor de produtos recebe, ele tem que aprender a dizer NÃO.

Dizer NÃO pode parecer difícil, mas se vc tiver muito claro os objetivos de seu produto, ou seja, quais objetivos da empresa o seu produto deve alcançar, quem é seu cliente principal e qual problema desse cliente vc está procurando atender vc terá os argumentos necessários para dizer NÃO a certas demandas. Seja gentil com a pessoa que está trazendo a demanda e diga algo como:

Sua sugestão é interessante e consigo entender porque vc a está pedindo. Contudo, deixe-me te mostrar o que já temos planejado em nosso roadmap e quais são os objetivos de cada item que está nesse roadmap. Por este motivo não conseguiremos dar a devida atenção ao seu pedido nesse momento. Vc me lembra de conversarmos novamente sobre isso no futuro?

Deixe para quem está te pedindo a nova feature a responsabilidade de te lembrar de ter essa conversa novamente no futuro. Se ele não se lembrar, é porque o pedido dele não era tão importante. Se ele se lembrar, reavalie novamente o pedido e, se necessário, diga NÃO novamente.

Série completa de artigos sobre roadmap

Esse artigo faz parte de uma série de artigos que escrevi sobre o tema roadmaps. Confira a série completa:

• O que é um roadmap?
• Como fazer um roadmap?
• Como priorizar um roadmap? Parte 1 e parte 2
• Roadmap = motivação + métrica.
• OKRs, o futuro dos romadmaps