A difícil tarefa de definir um RoadMap de produto
Muitos times têm uma enorme lista de ideias, solicitações de clientes e hipóteses que são revisitadas cada vez que vai se montar um RoadMap de produto. E todos nós sabemos o quanto é árdua a tarefa de definir o que vai entrar para o próximo ciclo de desenvolvimento. A única coisa que sabemos, e isto olhando para tudo o que já foi desenvolvido em Software, é que grande parte do que é desenvolvido não irá vingar. E os motivos são vários:
· Falta de alinhamento com a necessidade do cliente;
· Falta de usabilidade ou dificuldade para colocar aquela funcionalidade em produção;
· Limitações técnicas ou de negócio que fazem com que, durante o desenvolvimento, a gente descubra que precisa gastar muito mais tempo do que o previsto e, com isso, acabamos entregando um produto não totalmente pronto.
· Etc,…
Sem contar que, na grande maioria das vezes, a definição de RoadMap de produto é focar apenas em uma lista de funcionalidades priorizadas pelos Stakeholders ou pelo gerente do produto, não envolvendo o próprio time e também não deixando espaços para trabalhar em correções de bugs, atuação em débitos técnicos e refatorações. E esta lista já vem com datas pré-estabelecidas mesmo antes do time de produto conseguir avaliar com mais detalhes o esforço para o seu desenvolvimento ou até mesmo chegar na fase de prototipagem.
Em seu livro “Inspirado — Como criar produtos de tecnologia que os clientes amam”, que recomendo a todos a leitura, Marty Cagan aproveita toda a sua experiência para tocar neste assunto tão delicado. Segundo ele, “típicos roadmaps são a causa raiz de muito desperdício e esforços fracassados em empresas de produto”. E ele traz uma abordagem que direciona para que as equipes de produto precisam ter o contexto e os objetivos específicos de negócio necessários e passarem a priorizar o resultado de negócio ao invés de simplesmente a entrega de funcionalidades.
E para conseguir este tipo de comprometimento do time de produto, o mesmo tem que se sentir empoderado e conseguir, junto com os stakeholders e o gerente de produto, definir os resultados palpáveis do que se espera com cada funcionalidade que está se desenvolvendo. Isto tudo pode ser traduzido no que chamamos de entregar valor e não somente uma lista de funcionalidades a mais no sistema. E esta entrega de valor tem que ser mensurável, e ser o ponto chave para um cliente comprar o seu produto ou atualizar para a versão mais nova que contém as funcionalidades. Alguns exemplos de valor:
· Funcionalidade gera alguma vantagem competitiva para o cliente;
· Reduz o seu custo operacional;
· Entrega resultados para a gerência tomar decisões;
· Facilita o dia a dia do usuário e da empresa…
Para quem já trabalha com o conceito de Upstream, sabe o quanto é importante para conseguir atingir os resultados acima, mas isto será assunto para um outro post.
Um outro ponto importante, principalmente quando se trata de melhorias em software já implantado, é que estas novas funcionalidades sejam de fácil implantação e adoção pelos clientes. E isso deve fazer parte da entrega e pode ser um dos pontos de resultados esperados ao definir a nova funcionalidade. Além do time de produto se preocupar com a implementação de uma funcionalidade ele tem que ter em mente que a mesma precisa ser facilmente implantada pelo cliente, pois assim a chance de sucesso é bem maior. Nem vou me apegar aqui a falar sobre procurar entregar em fases, começando pelo MVP, para apoiar na validação das entregas por ser um tema já bastante debatido.
Uma forma eficiente de trabalhar para entregar valor ao cliente é aproximá-lo do time de produto, fazendo com que ele consiga validar o que está sendo desenvolvido através de loops de feedback que retro alimentam o desenvolvimento do produto ajudando-o a ser mais ajustado ao propósito. Esta proximidade faz com que alguns gaps funcionais e não conformidades, que antes eram vistos apenas após a liberação do produto, já sejam antecipados e tratados, fazendo com que a funcionalidade já seja liberada com certo grau de maturidade no lançamento.
O produto não está totalmente pronto quando terminamos o desenvolvimento. Ele ainda é uma hipótese. Precisamos validá-lo no mercado, avaliar sua tração, pontos onde não está aderente a necessidade dos clientes e ajustá-lo continuamente, ou cancelar a iniciativa, caso a hipótese se mostre totalmente falha. E lembre-se, o valor de uma entrega não está relacionado com seu tamanho, por isso não se esqueça também de deixar espaço para que o time tenha a liberdade de trabalhar em pequenas melhorias e otimizações no produto que também irão gerar valor para o cliente. Um exemplo claro é otimizar um processo que é muito usado pelo cliente fazendo com que ele seja executado em bem menos tempo.
E você, sabe o propósito do seu produto e foca nos resultados do que você desenvolve?
Seu Roadmap é focado apenas em novas funcionalidades ou tem espaço para melhorias no legado?
Como medir se o seu cliente realmente usa e está satisfeito com o que você desenvolveu?
Deixe aqui os seus comentários.
Referências:
CAGAN, Marty. Inspirado: 2ª edição. Alta Books Editora
Colaboração:
Alaim Porto Alvarenga
