#3 Bloco de Notas — Resenha do Livro Product Roadmaps Relaunched
Oi! Eu sou a Erica e este é o Bloco de Notas, uma série sobre livros da área de Produtos.
Aqui, vamos compilar ideias e conceitos das principais publicações da área.
No episódio anterior fizemos a resenha do livro do Martin Cagan: Inspired — Como criar produtos que as pessoas amam! Você pode ouví-lo no nosso canal no Spotify e nos principais agregadores.
E para este episódio, trouxemos um tema central na gestão de Produtos, escolhido pela comunidade: Vamos falar sobre os roadmaps de produto. E o livro selecionado foi Product Rodmaps Relaunched, que traduzo livremente para algo como Uma nova abordagem para rodmaps de produto — Como definir direção em meio à incerteza.
Foi escrito por 4 autores. Um deles que é o C. Todd Lombard que tenho acompanhado as publicações e palestras. Vale a pena seguir o perfil no twitter: @iamctodd.
Também vou deixar na descrição do episódio o link do livro na Amazon para quem tiver interesse em aprofundar os conceitos. Eu recomendo! E depois convido que você dê uma passada nas nossas redes sociais para contar o que achou do episódio e, caso tenha lido o livro, que outros aspectos te chamou a atenção. Vamos compartilhar conhecimento e fortalecer a comunidade de produto!
O livro começa relatando a frustração de Product Managers em relação aos roadmaps. Uma fala que ilustra bem essa desilusão é a declaração de David Cancel, ex-head de produto da HubSpot, onde explica porque não cria mais roadmaps tradicionais. Ele diz: — Ou vou decepcioná-lo, dando-lhe exatamente o que pensamos seis meses, achando que era a melhor solução, quando não é mais, ou mudando o curso e assumimos que mentimos para você.
A verdade é que os roadmaps tradicionais, que traziam uma lista de features e uma data de entregam a ser atingida já foram úteis. Em um cenário em que as mudanças eram lentas e as metas eram bem óbvias, essa abordagem funcionava. Mas em ambientes incertos e que mudam rapidamente, esse modelo não funciona mais. E os rodmaps precisam de uma nova versão para continuarem a setar visão e direção.
Resgatando uma fala do Martin Cagan: — É tudo sobre solucionar problemas e não sobre implementar features. Os roadmaps tradicionais eram sobre entregáveis. Mas bons times de produto sabem que precisam garantir que a solução realmente resolva o problema. É sobre resultados — finaliza.
Uma nova abordagem para roadmaps
Os autores defendem que num lugar de uma imensa lista de funcionalidades e datas de entrega, os roadmaps deveriam ser uma ferramenta para comunicar visão e direcionamento.
Logo, um roadmap de produto deveria:
- Colocar os planos da organização em um contexto estratégico
- Focar em entregar valor para usuários, clientes e empresa
- Abraçar o aprendizado como parte de um processo de desenvolvimento de produto de sucesso
- Reunir a empresa em volta de um conjunto único de prioridades
- Fazer com que os usuários fiquem animados com a direção que o produto está tomando.
Sendo assim, um roadmap de produto não deve:
- fazer promessas que o time de produto não está confiante que poderão entregar
- exigir uma processo dispendioso para desenhar e estimar
- ser confundido com um plano de projeto ou planejamento de entregas
Após fazer essas distinções, os autores começam a elencar problemas recorrentes que envolvem as organizações e o uso de roadmaps, contrapondo com o que deveria acontecer.
- Um roadmap deve colocar e empresa em um contexto estratégico
O diagnóstico é de que as pessoas não sabem porque fazem o que fazem. E como os roadmaps tradicionais estão tão focados em mostrar entregas de funcionalidades, acabam não respondendo o porquê da empresa estar trabalhando nestas questões. Eles defendem que o roadmap é uma grande oportunidade para articular porque estamos trabalhando em uma determinada iniciativa, porque ela é importante e vital para o sucesso da em empresa.
Então, antes de começar a detalhar o que, procure explicar o porquê. E um bom começo para definir a sua visão de produto é conectá-la com o propósito da empresa. Dar esse contexto, é essencial conectar os pontos e conseguir o engajamento de todos.
2. Um roadmap deve focar em entregar valor para usuários e empresa
Outro problema que as empresas enfrentam é que entregam muitas funcionalidades, mas não fazem progresso. Isso porque, para muitas pessoas, um calendário de entregas é sinônimo de roadmap.
Um roadmap é uma série de declarações que comunicam O QUE vamos fazer para ajudar nossos usuários a realizar algo e PORQUE estes objetivos são importantes para o sucesso deles.
Uma alternativa para este cenário é, depois de descrever a visão do produto, em vez de sair escrevendo uma lista de funcionalidades, comece listando os blocos de valor que se pretende entregar e que serão acumulados ao longo do tempo para realizar sua visão.
Frequentemente, esse é um conjunto de necessidades, problemas ou tarefas de cliente de alto nível, que os autores chamam de temas.
3. Um roadmap deve incluir aprendizado
Outro desafio diz respeito ao compromisso assumido pela área de vendas com os clientes. O que fazer quando um cliente diz que não vai assinar um super contrato se não tiver uma data acordada para entrega de uma funcionalidade X ainda este ano? Quem nunca tirou pedido?
Imagine se em vez de termos este tipo de conversa, falássemos valor, sobre metas? Sobre por que os recursos que o cliente pede são importantes e quais problemas estão impulsionando suas prioridades?
Uma melhor abordagem é se comprometer com resultados em vez de entregas.
Então, quando alguém pedir por uma funcionalidade, pergunte: Por quê? Porque essa funcionalidade é importante, que problemas resolve? Essa mudança simples, além de permitir um melhor entendimento das necessidades dos usuários, permite aumentar o nível d as discussões. Permite avaliar outras formas de entregar o resultado desejado. Nem tudo passa por colocar um botão ou desenvolver uma nova funcionalidade. Às vezes é só processo.
4. Um roadmap deve reunir a empresa em volta de um conjunto único de prioridades
Conseguir alinhamento em relação a prioridades não é fácil. A melhor forma para conseguir esse alinhamento é envolvendo as pessoas nas decisões. Compartilhe algum as de suas ideias com antecedência, antes que as partes relevantes roadmap estejam concretas, para obter sua opinião.
Levante:
- Quais são as prioridades de vendas?
- Quais são as prioridades da equipe de operação?
- O que a segurança precisa?
A equipe de produto é responsável por pegar todas as diferentes necessidades e dizer: ‘É isso’. ”
5. Um bom roadmap deve deixar os usuários empolgados sobre a evolução do produto
Compartilhar roadmap com clientes pode ser assustador. As prioridades podem mudar e funcionalidades podem não fazer mais sentido. Imagine o cliente confrontando você sobre promessas não cumpridas?
Mas e se, em vez disso, você usar o roadmap como um validador da direção? Michael Salerno, VP de Produto da Brainshark diz que usa o roadmap como uma via de mão dupla para se comunicar com seus usuários. É um forma de dialogar com eles sobre as dores de negócio e prioridades.
É também uma oportunidade de descobrir onde você pode estar errado. E isso talvez seja ainda mais valioso, porque você ainda tem a oportunidade de mudar de direção.
E como se proteger de promessas não cumpridas, quando o roadmap muda? O melhor é já deixar claro para os usuários que mudanças são inevitáveis e assim como eles podem influenciar o roadmap, outros usuários também podem. Logo o resultado final, pode ser diferente mesmo.
6. Um Roadmap não devem demandar muito esforço para criar e estimar
O roadmap é uma estratégia. Deixe o time determinar a solução e permita que resolvam o problema. Refinamentos e estimativas devem ser realizados em outro momento.
O que nos leva ao próximo ponto:
7. Um roadmap não deve ser confundido com um Plano de Projeto
Roadmap sé um artefato estratégico. Já um plano é um artefato tático que descreve como a estratégia vai ser executada. Se o seu roadmap estiver como um gráfico de gantt com datas muito específicas ou contiver uma lista de features, então não é um roadmap. É um plano de projeto.
Uma forma de contornar este problema é se comprometer com um resultado em vez da entrega.
Resumindo… Para definir uma direção clara, ao mesmo tempo em que se abraça a incerteza do desenvolvimento de produtos, você deve:
- estabelecer os princípios orientadores (incluindo uma visão de produto ligada à visão e objetivos de sua empresa que ajudará a medir seu progresso),
- focar nos resultados em vez de recursos e datas,
- priorizar com base no retorno sobre o investimento e no cumprimento de seus objetivos,
- considerar necessidades de todas as partes interessadas para impulsionar o alinhamento
- e planejar e comunicar as mudanças em andamento.
Principais componentes do Roadmap
Já que entendemos que um roadmap está além de uma lista com features e datas, o que devemos considerar para criar um roadmap que realmente faça sentindo?
Os autores trazem 5 elementos primários:
- Visão de produto: é um princípio orientador que diz como seus usuários vão ser beneficiados quanto o seu produto chegar em seu potencial máximo. Ter essa imagem de chegada é uma forma de não se desconectar do que é relevante.
- Objetivos de negócio: além de ajudar a medir o progresso, ao focar nos objetivos, a solução passa a ser um dos meios possíveis para se alcançá-los e não o fim em si.
- Temas: Expressar as necessidades ou problemas do cliente em temas é muito eficaz para orientar o desenvolvimento de soluções.
- Horizontes de tempo: trocar as datas por marcos traz flexibilidade e dá foco para o que é importante agora. Uma sugestão é trabalhar com 3 horizontes de tempo como: NOW, NEXT, LATER. Em now, damos visibilidade do que estamos fazendo agora. Em next, o será feito em seguida e em later o que está previsto para depois.
- Avisos legais: sempre bom lembrar que roadmaps não estão escritos em pedra e por isso podem sofrer alterações. Particularmente, considero interessante indicar premissas ou restrições que foram considerados no planejamento.
E mais 5 componentes secundários que tentam responder a preocupações das partes interessadas. São opcionais mas podem deixar sua documentação mais completa.
- Funcionalidades e soluções: dependendo da expectativa das partes interessadas, podem ser listadas ou detalhadas.
- Confiança: é uma ótima maneira de indicar quão previsível será a entrega.
- Estágio do desenvolvimento: é importante garantir que as pessoas compreendam o significado de cada etapa para alinhar expectativas. Para isso. Etapa de “descoberta”, “design” ou “prototipagem” indica que se está em um estágio muito inicial. Um rótulo como “pré-produção” ou “beta”, ao contrário, deve indicar que o produto pode ser visto ou demonstrado, e provavelmente, estará disponível em breve.
- Usuários-chave: se você tem diversos tipos de usuários, faz sentido indicar que a solução afetará um público específico.
- Áreas: importante mapear quem pode impactar, ser impactado pela entrega e entender se os objetivos de negócio de cada estão convergindo.
Além disso, você pode adicionar informações complementares que dão contexto ao roadmap como:
- Informação do projeto: cronograma, time, dependências, riscos, status
- Considerações técnicas: requisitos de escalabilidade ou infra-estrutura
- Contexto financeiro: oportunidade de mercado, P&L
- Direcionamentos externos: mudanças regulatórias, concorrência
Mas porque tantas informações?
Como defendem os autores: para reunir pessoas em torno de um plano, o roadmap precisa ser mais do que apenas uma lista de recursos e datas. Ele precisa contar uma história:
- Como será quando você alcançar sua visão?
- O que será necessário para chegar lá
- Como você saberá se está progredindo?
O que são os temas mesmo?
Os temas são uma forma de expressar as necessidades dos usuários.
Um tema é uma necessidade do cliente de alto nível. Um subtema é uma necessidade mais específica. Os temas podem ser independentes, mas também podem representar um agrupamento de subtemas.
Um exemplo de tema para um aplicativo de e-commerce poderia ser: melhorar a visibilidade do status do pedido. Veja como abordar desta forma traz a problemática para o primeiro plano, enquanto o time tem flexibilidade para explorar soluções.
Como Jared Spool diz: “Os temas ajudam as equipes a manter o foco sem se comprometer prematuramente com uma solução que pode não ser a melhor ideia mais tarde”. Ele aponta que é importante concentrar a maior parte do esforço de mapeamento nas necessidades e problemas do cliente porque “a viabilidade de um recurso pode mudar drasticamente, enquanto a natureza de um problema importante do cliente provavelmente permanecerá a mesma.
Os autores trazem diversas formas de explorar os temas. Deixo aqui alguns dos exemplos citados:
- Jornada do Usuário
- Mapas de Experiência
- Necessidades do Produto, do sistema
- Árvore de Oportunidade da Teresa Torres
- Jobs e user stories
O que é importante em usar temas no desenho do roadmap, é que eles são sobre resultado e impacto e não sobre entrega de funcionalidades.
O livro tem bastante conteúdo e aprofunda em diversos outros tópicos. Recomendo demais a leitura. Mas espero que esta resenha já dê um norte de como abordar roadmaps. E para não esperar pelo próximo quarter, já te convido a fazer um exercício: pegue o desafio atual do seu produto e faça um reenquadramento a partir deste modelo. Está dando foco no que realmente é importante? O que você mudaria na sua estratégia?
Olha que tô curiosa e vou querer saber o que você achou da resenha. Escreve pra gente no instagram do MulheresdeProduto compartilhando seu feedback e sugerindo um livro que você quer muito que a gente traga o resumo pra cá!
Vou ficando por aqui e até o próximo episódio do Bloco de Notas!
