Embora muitos PMs achem que o Roadmap é uma ferramenta exclusiva para gestão de projetos, o formato de Roadmap é uma das melhores formas de trazer visibilidade do momento atual e futuro do Produto para qualquer pessoa da empresa. O Roadmap mostra com clareza o que estamos fazendo agora e o que está priorizado para o futuro.

Para ter uma visão mais organizada e coerente, é mais fácil pensar em quebras, partindo do maior pedaço para o menor pedaço. É basicamente um exercício de drilldown, onde você quebra a visão anual em semestres, que por sua vez é quebrado em trimestres e que por sua vez pode ser quebrado em meses.

Perceba, que se estamos usando a estrutura de Opportunity Tree já vista nos capítulos anteriores, podemos fazer uma divisão desse tempo com a hierarquia de outcomes do produto e da empresa.

Se quisermos forçar um pouco, podemos tentar fazer um comparativo com a organização das tarefas em épicos, user stories e tasks. Eu acho que aqui já começamos a forçar muito a barra que no nível da semana não iremos necessariamente fazer experimentos e o nível de experimento não é necessariamente task técnica, pelo contrário, nesse nível, nós já podemos ter certeza do que vamos fazer e não é necessário haver mais experimentos.

Essas visões servem apenas para você ter um pensamento linear e mais coerente de organização. Não é uma simetria exata, mas pode servir mostrar para stakeholders e times uma visão mais didática do plano.

- Ano + Goal: Qual o Goal principal que a empresa inteira ou pelo menos a sua precisa buscar para o ano?
- **Semestre + Outcome**: Quais os resultados que precisamos alcançar em 6 meses que irão resultar no atendimento do Goal do ano? Podemos ter vários outcomes trabalhados em seis meses;
- Trimestre + Oportunidade: Uma oportunidade que será explorada durante o trimestre que contribuirá para o alcançamento do outcome. É quase que inevitável trabalhar em várias oportunidades ao mesmo tempo, referentes a vários Outcomes diferentes;
- Mês + Solução/Feature: Durante o mês vamos trabalhar em várias soluções que podem ser features ou até mesmo melhorias pontuais no produto, que exploram as oportunidades que estamos trabalhando no trimestre;

Quando explico essa visão no livro que vou lançar em breve, explico previamente que o Roadmap serve para que você dê e tenha visibilidade do presente e futuro do produto. O Roadmap não deve servir para ser uma especificação do produto, porque ele muda sempre toda hora e se torna antigo muito rápido. O passado, geralmente, pouco importa no Roadmap.

Nossos links e redes

Pode nos dar seu feedback? Você responde em menos de 15 segundos.

Compartilhe nossa Letter: https://pmletter.email/

Diego Eis é Head de Produtos Digitais na Sympla.

@diegoeis
https://gestaomodernaprodutosdigitais.com/
https://diegoeis.com/
https://pmtoolkit.work/
https://medium.com/gestao-produtos
https://tableless.com.br/

• Diego Eis: Autor do livro Gestão Moderna de Produtos Digitais. Um dos idealizadores do Product Oversee e metido a besta. Já passou pela Sympla, Neon, Jüssi, NuInvest e Locaweb.