Roadmap de produto em cinco etapas simples
Por Scott Colfer (publicado originalmente aqui, em inglês)
…então meu investidor disse que eu preciso de um product manager pra fazer o nosso roadmap de produto?”
Quando eu era consultor em product management, os clientes geralmente falavam sobre “precisar de um roadmap de produto urgentemente”. Eu investigava um pouco mais para descobrir o que eles realmente precisavam, e geralmente era voltar aos princípios básicos da proposta de valor e do modelo de negócios. Na verdade, pedir um roadmap de produto era uma forma de dizer “por favor me ajude com a minha estratégia”.
Roadmaps de produto estão sobrecarregados de significados e são uma fonte de incerteza entre product managers. Hoje eu lidero uma equipe de mais de 40 product managers trabalhando em softwares de acesso público e também restritos, tecnologia de base e consultoria em métodos ágeis: assim, roadmaps de produto tem sido o tópico mais recorrente para o suporte e desenvolvimento profissional nos últimos dois anos. Roadmaps geralmente são a parte do nosso trabalho que recebe o maior escrutínio e atenção (para o bem e para o mal).
Os exemplos acima estabelecem duas suposições que eu tenho sobre roadmaps:
Roadmaps são uma abreviação para “gestão de produto” que profissionais de outra área se sentem confiantes em pedir, e nos oferecem uma grande oportunidade de explicar os conceitos centrais da gestão de produto.
Nós (product managers) ficamos ansiosos com a criação de roadmaps porque eles significam muito para nossas equipes, para os nossos colegas de trabalho, e para nossa autoestima. Precisamos de um lugar onde nos sentimos seguros para admitir isso, para compartilhar nossos problemas e para aprendermos uns com os outros.
Eu criei um diagrama para ajudar a explicar, simplesmente, o que faz um bom roadmap mas eu acho que ajuda em qualquer outro contexto. Isso também pode ser um ponto de partida para falar sobre conceitos básicos de product management com nossos colegas.
Vamos pegar do início e olhar para os cinco pontos que contribuem para um bom roadmap.
1. Contexto
É importante determinar o contexto para o nosso produto, considerando coisas como os estágios do ciclo de vida do produto, necessidades organizacionais e qual é o público alvo. Eu geralmente aplico contextos diferentes em meus roadmaps:
Estratégico: um roadmap é útil quando você entende o valor atual do seu produto e o objetivo de valor do seu produto no futuro — seu roadmap conecta os dois, agindo como uma ferramenta estratégica para planejar como você vai do seu atual modelo de negócios para sua visão de um modelo futuro, com cada etapa incremental e priorizada por vez.
Ciclo de vida do produto: durante o desenvolvimento e introdução de um projeto, o foco geralmente fica em priorizar os features principais. Durante o crescimento você precisar considerar as vendas, o marketing, a plataforma e a resiliência enquanto tenta obter um posicionamento de produto/mercado.
Durante a etapa de maturidade, você otimiza seu modelo de negócio para aumentar o retorno sobre o investimento (ROI). E, ao retirar o produto de circulação, acontece o equilíbrio entre o encerramento do produto e as necessidades das pessoas usuárias restantes.
Equipe: Você e sua equipe devem usar o roadmap do produto como uma das ferramentas que vai ajudar a descobrir a sua estratégia de longo prazo. Também é uma ferramenta de comunicação e motivação para você e sua equipe. Certa vez eu operei uma plataforma de infraestrutura que precisou de seis a nove meses para pagar o custo de desenvolvimento técnico, e preciso dizer: ver essas metas serem atingidas e superadas uma a uma foi o que nos manteve firmes nos piores dias.
Organizacional: o roadmap de produto pode ser usado como uma ferramenta de comunicação entre você, colegas de trabalho e/ou clientes. Às vezes você pode precisar de versões que escondam alguns dos aspectos estratégicos do roadmap e “vender” o trabalho da sua equipe, dando às pessoas o que elas querem. E tudo bem. Você pode precisar de uma versão específica do seu roadmap mais focada nas features — contanto que esse não seja seu único roadmap, está tudo certo — pense nisso como relações públicas.
Talvez você queira apresentar melhor o contexto do seu produto acrescentando coisas como a sua visão, metas, nome de produto e logotipo — como um mínimo. Mas o ponto mais geral é: o contexto é importante — e muda muito — então uma medida não serve para todos. Você deve entender o que funciona melhor para o seu próprio contexto.
2. Valor
A gestão de produtos promete solucionar nossos problemas em detrimento de estabelecer um compromisso com soluções específicas. Há uma tendência geral de especificar a forma de fazer algo, em vez de mostrar o resultado desejado. Product managers geralmente são agnósticos sobre as soluções — nós ajudamos as equipes a priorizar os problemas de maior valor e ajuda-las a priorizar a solução que requer o menor esforço para o maior resultado — e ficamos felizes quando aprendemos algo que nos ajuda a refinar e simplificar nossas soluções.
O valor (expressado em termos de objetivos para nossas pessoas usuárias e nossa organização) é o coração de um bom roadmap de produto, e da própria gestão de produto. Seu roadmap deve ser orientado por um conjunto de hipóteses para melhorar o valor do produto:
- Nós acreditamos que [tal ação, para tais pessoas, com tal investimento X]
- vai alcançar [tal objetivo]
- nós saberemos que tivemos sucesso quando observarmos [tal sinal].
3. Entrega
Focar exclusivamente nas features, agenda de custos e prazos é um dos maiores anti-padrões de um roadmap de produto. Um documento que liste soluções pelos seus prazos não é um roadmap de produto, é um plano de projeto ou um cronograma de entrega — eles são úteis em situações de certeza elevada e mudança lenta, mas não para muitas equipes de desenvolvimento de produto. Essa abordagem alimenta a falácia da entrega: entregar features sem criar valor para as usuárias ou para a organização.
No entanto, a entrega é uma parte importante para a estratégia geral de um produto para que haja um bom motivo para que ela esteja no nosso roadmap:
- Se você tem um prazo fixo em um contrato que está para acabar, muita gente da equipe de férias, ou uma janela estreita de oportunidade para atingir um segmento de pessoas e fazer pesquisa, talvez você precise refazer sua estratégia de valor para adaptá-la às features da vida real.
- Enquanto você não quiser que seu roadmap seja um espaço de dedicação apenas a features, talvez haja casos de uso para falar sobre detalhes técnicos. Por exemplo, alguns anos atrás minha equipe usou essa estratégia para descobrir caminhos importantíssimos para analisar opções de ferramentas de infraestrutura, planejando o tempo para fazer análises e usar o roadmap de forma a nos ajudar a entender os diferentes cenários possíveis e o impacto subsequente de cada um deles.
Quando os detalhes de uma entrega aparecem no roadmap, resta ainda outra questão: o roadmap pode ser um espaço estratégico em comum para múltiplas pessoas (não só para product managers). No cenário de infraestrutura citado acima, o roadmap foi compartilhado entre eu (produto/valor), o gerente de entregas (fluxo de trabalho) e o lead de operações online (opções técnicas). O roadmap foi um espaço estratégico em comum para dar várias perspectivas sob uma estratégia geral.
4. Confiança
Medidas de confiança são uma ferramenta poderosa para debater opções enquanto se administra expectativas. Qualquer roadmap e qualquer equipe devem ter maturidade o suficiente para reconhecer e discutir as timeboxes, as condições financeiras e os resultados — e qualquer equipe de gestão deve ter maturidade para reconhecer e discutir a confiança nos planos e a necessidade de mudar conforme aprendemos.
A confiança também ajuda a responder à questão de “com quanta antecedência eu devo projetar meu roadmap”? Se o seu limite de confiança não alcança os seus planos iniciais, então você sabe que um roadmap vai ter pouco valor.
O nível de confiança vai sofrer influência de uma ampla gama de fatores e é extremamente específica de cada contexto, mas pode ser representada de forma simples— no diagrama apresentado acima, é mostrado como uma figura simples na base do roadmap, mas recentemente eu vi colegas de trabalho usando o padrão de avaliação vermelho/amarelo/verde para ajudar a gerenciar as expectativas.
5. Idade
Um dos aditivos mais úteis e simples que eu fiz em meus roadmaps depois de ler Product Roadmaps Relaunched é a seção “últimas atualizações” (e portanto nosso roadmap). Se o seu roadmap mostra 20% de confiança em um informação depois de três meses quando ela não foi nem revisada nem atualizada, então provavelmente ela é inútil. Pessoalmente, eu procuro revisar meus roadmaps todos os meses (mesmo se for apenas para verificar que está tudo bem), e oferecer uma revisão mais relevante a cada trimestre.
Leituras recomendadas
- Product Roadmaps Relaunched
- Se você quer exemplos de como estabelecer e medir os objetivos: Google re:Work Guide: Set Goals with Objectives and Key Results
- Se você considera que seu roadmap como conector de proposta de valor e modelo de negócios, para sua visão de futuro, leia: Estratégias de value proposition canvas, Estratégias de business model canvas & lean canvas de Ash Maurya e o board de visão de produto de Roman Pichler
- Se você quer ler sobre estratégia focada em valor: Lean Enterprise
- Se você esta interessada em fluxo de trabalho: Explicando o Papel de um Gerente de Entregas.
