O Terror do dia a dia de Produtos
Nesse artigo quero trazer algumas situações que são um verdadeiro terror no dia a dia das personas de produtos. Situações que são mais comuns que imaginamos e afetam diretamente a qualidade, métricas, objetivos a serem alcançados e a saúde do produto como um todo. Além de trazer confusão para o time de desenvolvimento, desperdícios e desmotivação.
O primeiro terror e pesadelo é a estratégia de negócio mal desenhada e não clara. Costumo sempre dizer a seguinte frase: Se eu sei quem eu sou e sei para onde vou, outros me seguirão. O segredo para o sucesso de um produto passa pela estratégia de negócio. Ela deve ser bem desenhada, com objetivos claros, um roadmap desenhado com entregas de valor. Com uma estratégia de negócio bem definida, com um alvo a ser atingido, se torna mais fácil a construção do produto, visto que todo o time de negócio e tecnologia compreenderão de forma clara o que deve ser feito e assim poderão seguir o planejamento idealizado. Quando essa prática não acontece, temos o que chamo de síndrome de “Alice” que é regida pela seguinte máxima: “Se você não sabe para onde ir, qualquer caminho serve”. (Alice no País das Maravilhas — Lewis Carroll). Dessa forma como consequência podemos observar que mudanças constantes no roadmap e MVP ocorrerão, entregas sendo postergadas, aumento constante de escopo e insatisfação do time pela falta de clareza e definições.
Como consequência do primeiro terror, observamos no dia a dia priorizações que não agregam valor, as temidas priorizações Frankenstein. Essas priorizações geralmente ocorrem no meio de uma interação (sprint), chegam na maioria das vezes sem ter havido uma discovery, refinamento, com ideias abstratas. Podem até soarem como uma ideia interessante, porém antes de ser priorizada deve-se realizar uma análise prévia que pode ocorrer através das respostas a esses questionamentos: Qual dor ou problema essa priorização irá resolver? Qual impacto e ou valor será entregue e o que será agregado de valor ao produto? A dor ou problema que será resolvido é algo de grande impacto com um resultado duradouro ou apenas resolve uma circunstância temporária? Quanto essa priorização irá custar (tempo e investimento)? Faz sentido despriorizar o MVP que está sendo priorizado para absorver essa nova demanda (analisar o tempo que será postergado o MVP acordado). Por fim, deve-se ter claro que havendo aumento de escopo, haverá uma mudança de rota e como consequência o que foi acordado no início sofrerá alterações.
Um último terror que é consequência dos dois primeiros que destaco, é a criação de features eternas, onde por não ter uma ideia clara do ciclo de vida do produto, planejamento mal estruturado e priorizações sem valor acaba-se confundindo o que deveria ser um MVP com evolução de produto. Em um cenário ágil, é razoável que ocorram mudanças, no entanto o que não pode ocorrer é a falta de visibilidade no processo de construção de uma funcionalidade. Ela dever ter seu começo, meio e fim bem estabelecidos. O que for sendo identificado como plus se encaixa como estratégia de evolução do produto que passa pelo ciclo de melhorias. Dessa forma não havendo uma clareza desses processos as features sempre serão intermináveis, visto que sempre haverá pontos de evolução, daí deve ser observado qual é a estratégia de negócio que foi definida para cada fase de evolução do produto.
Por fim, coloco algumas dicas de ouro para tentar escapar desses pesadelos do dia a dia de uma pessoa que atua na área de produtos: Monte uma boa estratégia de negócio, realize uma discovery de valor e não queime etapas. Construa um Roadmap e um MVP que agregue valor, sempre visando a entender qual é a dor/problema que irá ser resolvido. Proteja o escopo/MVP. Caso seja necessário adicionar escopo ao MVP, procure deixar tudo claro não traga nenhuma demanda sem uma discovery e refinamento, tudo deve estar bem definido para que assim problemas futuros sejam mitigados.
