O roadmap é uma ferramenta muito útil para gestores de produtos. Com ele, é possível planejar e comunicar a visão de futuro que você tem para o seu produto. Veja a seguir alguns exemplos de roadmap:

Os dois primeiros exemplos são roadmaps de curto prazo, ou seja, exibem alguns meses e as funcionalidades que estarão em cada versão do software. Por outro lado, no roadmap do Windows Server, vemos uma visão mais abrangente, sem grandes detalhes, mas sendo um roadmap de longo prazo, com quase uma década.

Ao preparar o roadmap de seu produto, você deve adequá-lo à sua audiência. Isto é, você deve colocar mais ou menos detalhes, dependendo de para quem você apresentará esse roadmap.

De quanto em quanto tempo tenho de atualizar o roadmap?

Se você está em um time que utiliza boas práticas de engenharia de software, vocês estarão fazendo entregas frequentes e, ao fazer entregas frequentes, você terá bastante feedback de seus usuários sobre o software e as funcionalidades que vocês estão entregando. Isso provavelmente vai mudar seu roadmap, pois quando seus usuários começam a usar uma nova funcionalidade, eles terão novas sugestões para o seu software. Mas, mesmo que você não receba nenhuma sugestão, ao vê-los utilizando, você provavelmente terá novas ideias para seu produto.

Se você for um gestor de um produto de hardware – como um servidor, um notebook, um smartphone, um tablet, ou mesmo um sistema operacional para rodar nesses aparelhos –, seu roadmap será bem menos flexível. Muitas decisões deverão ser tomadas meses antes de o produto estar na frente do usuário.

Felizmente, as entregas contínuas em produtos web permitem muito mais flexibilidade. É interessante ter um roadmap de um produto web de pelo menos 12 meses. Entretanto, não se esqueça de que esse roadmap mudará frequentemente, de acordo com o que você e seu time aprenderem com os usuários do seu produto web e com a forma como o mercado reage às suas novidades. Por isso, a cada mudança de rumo, atualize seu roadmap e comunique todas as pessoas interessadas.

Roadmaps contínuos de 12 meses

Durante meu período na Conta Azul e agora no Gympass, minhas equipes e eu usamos uma estrutura de roadmap que nos ajudou muito a alcançar os dois principais objetivos dos roadmaps de produtos, planejando quais seriam as próximas etapas do produto, e alinhando a visão do futuro do produto com toda a organização.

Chamamos essa estrutura de roadmap contínuo de 12 meses. Eu sei que algumas pessoas comentaram que o fato de ter um roadmap de 12 meses nos impedirá de ser ágeis, que não devemos ter mais de três meses planejados, na verdade não devemos ter um roadmap e devemos usar apenas OKRs. Costumo concordar com todos esses comentários. No entanto, minha experiência me mostrou que a necessidade de roadmaps depende muito da maturidade da cultura de desenvolvimento de produtos da empresa. Provavelmente, empresas como Google e Facebook têm uma maturidade tão grande na cultura de desenvolvimento de produtos que os roadmaps não são necessários e o produto é desenvolvido apenas com base em OKRs. Esse também é o caso quando gerimos produtos consolidados.

No entanto, se você estiver trabalhando em um produto em sua fase de inovação ou crescimento, e sua empresa ainda não possui uma cultura madura de desenvolvimento de produtos, os roadmaps em geral e o roadmap contínuo de 12 meses que apresentarei aqui podem ser muito úteis.

A motivação

Quando um gestor de produto apresenta às partes interessadas um roadmap de três meses, não é incomum que ele receba perguntas como “E o recurso X?” ou “Quando colocaremos mais energia no objetivo Y?”. A resposta é normalmente algo como “Está planejado para os trimestres seguintes, mas acredito que o que planejamos para o próximo trimestre são as coisas mais importantes para se trabalhar, concorda?”. E provavelmente provocará uma certa frustração.

Se um gestor de produto decidir não usar roadmaps e usar apenas OKRs para apresentar seus planos para o produto às partes interessadas, as perguntas que ele receberá serão em torno de “Como você pretende alcançar o objetivo Z?” ou “Por que você não faz W para alcançar seu objetivo mais rapidamente?”

Por esse motivo, criamos o roadmap contínuo de 12 meses. Auxilia os gestores de produto a comunicar a visão do futuro de seu produto e, consequentemente, isso elevará a discussão a um nível mais estratégico. Veja um exemplo de um roadmap contínuo de 12 meses para uma equipe que cuida da emissão de faturas em um produto de ERP para pequenas e médias empresas.

Elementos e como usar o roadmap contínuo de 12 meses

Os elementos básicos que devem constar em um roadmap contínuo de 12 meses são:

• Objetivos e métricas: são colocados na parte superior do slide, porque essa é a coisa mais importante do roadmap, o que você planeja alcançar fazendo as coisas que planeja fazer, e como mensurar o que alcançou. A partir disso, você cria seus OKRs.
• Entregas: aqui temos o que está planejado para ser entregue por cada equipe para que os objetivos sejam atingidos. É importante registrar quando uma nova equipe será contratada e integrada. Normalmente, leva algum tempo para contratar pessoas e incorporá-las com conhecimento suficiente para fornecer algo. As entregas são caixas de um ou mais meses. Isso não significa que a entrega acontecerá apenas uma vez por mês; as equipes devem estar implantando a produção toda semana, todos os dias, a cada hora, se possível. Isso significa que essas entregas são de alto nível, compostas por muitas entregas menores, com um nível abaixo dos detalhes do que é mostrado nos roadmaps contínuos de 12 meses. Para aqueles familiarizados com metodologias ágeis, pensem em termos de temas, épicos e histórias. No roteiro de 12 meses, estamos no nível de temas e épicos, e não vamos ao nível de detalhe das histórias. As entregas para o próximo trimestre estão em verde mais escuro, enquanto as outras estão em verde mais claro. Isso ocorre por projeto, para mostrar que estamos mais convictos das coisas que estão mais próximas. O trabalho do gestor de produto que apresenta este roadmap contínuo é manter o próximo trimestre no foco da discussão. Se as partes interessadas quiserem discutir as entregas posteriormente no roadmap contínuo, a única discussão importante é se essa entrega deve ocorrer no trimestre seguinte e, se houver, o que deve ser adiado.
• Descobertas: da mesma maneira que você apresenta suas entregas em uma linha do tempo, pode também apresentar as descobertas necessárias que precisa fazer antes das entregas. Novamente, o resultado da descoberta não deve ser apresentado somente após um ou mais meses. A equipe de descoberta (gestor de produto, designer de produto e alguém de engenharia) fará descobertas e as compartilhará com os participantes semanalmente ou até mesmo diariamente, mas uma imagem mais completa da descoberta pode levar mais tempo para ser elaborada. Este elemento é opcional.
• Restrições: se você tiver alguma restrição relevante, é importante que seja colocada aqui. Neste exemplo, o governo estava lançando um novo formato de fatura que deveria ser usado a partir de abril de 2018. Por esse motivo, nosso sistema de faturamento deveria estar preparado para emitir faturas neste novo formato até então. Este elemento também é opcional.

Você pode adicionar outros elementos, se fizer sentido para você, sua equipe e as partes interessadas. Na Gympass, estamos construindo uma camada de integração que nos permite integrar facilmente nossos sistemas aos sistemas de reserva de academias e ERP, bem como aos sistemas de folha de pagamento. À medida que construímos os blocos de construção dessas camadas de integração, estamos nos preparando para oferecer tipos específicos de serviços profissionais. Por esse motivo, criamos em nosso roadmap contínuo de 12 meses um elemento chamado Prontidão para Serviços Profissionais, para mostrar às partes interessadas quando poderemos fazer certos tipos de integrações com nossa equipe de serviços profissionais.

Observe que, com o roadmap contínuo de 12 meses, quando você recebe perguntas como “E o recurso X?” ou “Quando colocaremos mais energia no objetivo Y?” ou “Como você pretende alcançar o objetivo Z?” ou “Por que você não faz W para alcançar seu objetivo mais rapidamente?”, é mais fácil responder porque você tem uma visão geral do que está por vir.

Nós o denominamos “roadmap contínuo” por um motivo. Tem que ser revisto regularmente. Se nada mudar, deve ser revisado pelo menos trimestralmente, para garantir que esteja alinhado à visão e estratégia do produto. Se houver mudanças no ambiente externo (nova regulamentação, novos concorrentes etc.) ou no ambiente interno (pessoas saindo da equipe, mudança na estratégia da empresa etc.) e essas mudanças precisarem ser tratadas imediatamente, o roadmap contínuo de 12 meses é a ferramenta perfeita para ajudar todos a entender o impacto das mudanças nos objetivos e nas entregas da equipe.

Devo guardar segredo sobre meu roadmap?

Muitas empresas publicam seus roadmaps para os usuários e para o mercado, enquanto outras preferem guardá-los a sete chaves, temendo que concorrentes copiem seus passos. Acredito que o roadmap de curto prazo (1 a 3 meses) deve ser conhecido pelos seus usuários, até para que eles possam dar feedback sobre ele.

Já o mercado, você pode responder de forma reativa. Quando perguntado, você pode responder se está ou não no seu roadmap de curto prazo. Já o de médio e longo prazo (3 ou mais meses), não faz sentido ser divulgado, nem tanto para guardar segredo de seus concorrentes, mas porque há grandes chances de ele mudar e, se ele for público, essas mudanças acabarão frustrando seus usuários.

Cone da incerteza

O cone da incerteza é um conceito usado em gestão de projetos que descreve a quantidade de incerteza ao longo da vida de um projeto.

No começo, pouco se sabe e a incerteza é grande. À medida que progredimos no projeto, aprendemos mais e a incerteza diminui. Pesquisadores da indústria de software chegaram a concluir que, antes do início de um projeto de desenvolvimento de software, a incerteza pode variar de 4 vezes a até 1/4 do inicialmente estimado quanto ao tempo e ao custo de desenvolver esse software.

Como fazer um roadmap?

Após aprender o que é um roadmap, a pergunta que fica é: como fazer um roadmap? Como definir que itens vão nele e em qual ordem? A resposta é composta de três elementos: a empresa, os usuários e o que dá para fazer.

Quais os objetivos da empresa? O primeiro elemento que um gestor de produtos deve conhecer para fazer o roadmap são os objetivos da empresa. O principal objetivo de uma empresa não é receita ou margem. Receita e margem são indicadores da sua saúde, que podem até mostrar se seus objetivos estão sendo atingidos.

Contudo, algumas vezes receita e margem não estão necessariamente atreladas aos objetivos. Aliás, esses objetivos costumam mudar com o tempo. Por exemplo, no começo de qualquer rede social, o objetivo não é receita, mas sim obter a maior quantidade de usuários e garantir que estes retornem. Somente depois de ter uma base considerável de usuários ativos é que faz sentido pensar em como obter receita, quer seja dos usuários, quer seja de empresas interessadas em falar com eles. Por isso, é importante o gestor de produtos saber qual o objetivo da mpresa e, periodicamente, validar se ele continua o mesmo.

O que os usuários querem? Sabendo quais os objetivos da empresa, o gestor de produtos precisa pensar em novos produtos ou em evoluir produtos existentes para atender a esses objetivos. Para fazer isso, ele precisa conhecer:

• Seus usuários: é preciso conhecer os usuários ou possíveis usuários de seu produto, e quais problemas ou necessidades eles têm que seu produto pode resolver. Existem inúmeras ferramentas e métodos para conhecer o cliente. Alguns exemplos são pesquisa, entrevistas, análise de dados de acesso, teste A/B, protótipos, teste de usabilidade etc.
• Contexto: o contexto em que seus usuários estão inseridos no dia a dia e, especificamente, quando usam o produto. O contexto é o conjunto de condições físicas e de eventos que circundam seu usuário. Por exemplo, seu usuário acessar seu produto de um desktop ou de um smartphone faz parte do contexto.
• Mercado e concorrentes: tanto concorrentes diretos como indiretos. Os concorrentes diretos são aqueles que entregam o mesmo produto ou um produto similar. Já os indiretos são aqueles que de alguma forma substituem o seu produto. Por exemplo, suponha que você fez uma ferramenta de gestão de ordens de serviço para pequenos prestadores de serviços. Um dos principais concorrentes é o e-mail, pois esses pequenos prestadores podem usá-lo em vez de usar sua ferramenta. Ou ainda, podem usar telefone, papel e caneta!

Dá para fazer? Muito bem, você já conhece os objetivos da empresa, entendeu o seu usuário e agora definiu como vai ser seu produto ou aquela nova funcionalidade que vai, ao mesmo tempo, atender os objetivos da empresa e ser útil para o seu usuário. Agora, você precisa saber se dá para fazer e qual seria o custo. Pode até ser que seja possível fazer, mas se demorar muitos meses e custar muito, pode ser que não valha a pena. Aí entra a conversa com o time que vai produzir o novo produto ou a nova funcionalidade; é o pessoal de UX e de desenvolvimento. São eles que dirão o custo, tanto em tempo quanto em dinheiro e, se ele não for aceitável, vocês terão de conversar para buscar alternativas.

Traduzindo tudo isso em uma imagem

Após ler o que é preciso levar em conta ao fazer um roadmap, dá para traduzir gestão de produtos em uma imagem, que já vimos no capítulo O que é gestão de produtos de software?:

Para fazer seu roadmap, você precisa conhecer os objetivos da empresa, os usuários, suas necessidades e problemas, e o que dá para fazer. Com isso em mãos, você consegue construir seu roadmap. Mas não se esqueça de que os objetivos da empresa podem mudar, como também os problemas e necessidades de seus usuários, e o que é possível fazer. Por isso, é fundamental fazer revisões periódicas de seu roadmap para mantê-lo sempre em linha com esses 3 elementos.

Roadmap = motivação + métrica

É comum ver roadmaps como uma lista de funcionalidades, conforme ilustrado nos exemplos anteriores. Esse tipo de roadmap funciona bem quando você estiver apresentando-o para uma audiência externa à sua empresa, ou seja, para os usuários e para o mercado em geral.

Ter o roadmap como uma simples lista de funcionalidades está incompleto. A seguir, dois elementos muito importantes para explicar por que essas funcionalidades estão no roadmap nessa ordem de prioridade.

Qual a motivação?

Como dito anteriormente, devemos levar em conta 3 aspectos ao fazer um roadmap:

• Objetivos estratégicos da empresa;
• Problemas e necessidades do cliente;
• Tecnologia disponível.

Esses são os insumos que o gestor de produtos tem de levar em conta ao construir um roadmap, para definir quais funcionalidades colocar nele e em que ordem. Por esse motivo, para o roadmap que será usado para comunicação interna, além da funcionalidade propriamente dita, é importante constar a motivação que levou o gestor de produtos a colocá-la lá. Mais clientes? Mais receita? Menos contatos de cliente pedindo suporte? Aumentar o engajamento? Etc.

Ter a motivação da funcionalidade no roadmap vai ajudar o gestor de produtos a setar o contexto para o time que trabalhará no desenvolvimento dessa funcionalidade.

Como medir o resultado?

Além da motivação, o roadmap deve também ter alguma indicação de como medir se o que motivou a funcionalidade está sendo atingido. Se a motivação for aumentar o número de clientes, como será medido esse aumento de clientes? Se for obter mais receita, como será medido esse aumento de receita? Se for menos contato de suporte, como será medida essa diminuição? Se for aumentar o engajamento, como isso será medido?

É importante definir como medir se uma determinada funcionalidade cumpriu a sua motivação, e efetivamente fazer essa medição. É muito provável que a forma de fazer essa medição deva ser considerada no desenvolvimento da funcionalidade, pois pode haver a necessidade de incluir código de programação específico para permitir essa medida.

Exemplificando

Para ilustrar o uso de motivação mais métrica na construção de um roadmap, usarei um exemplo da Locaweb. Temos um produto de e-mail marketing que serve para fazer envio de e-mails.

Quem usa e-mail marketing sabe que é preciso seguir algumas boas práticas para conseguir uma boa taxa de entrega de e-mails disparados. Primeiro, é preciso ter o consentimento do destinatário para poder enviar e-mails para ele. Em seguida, é fundamental ter uma frequência de envio. Se enviar uma mensagem uma única vez e nunca mais mandar, você não está criando um relacionamento com o destinatário. Além disso, é importante manter sua lista de destinatários limpa. Sempre que receber mensagens de erro ou reclamação de spam de alguém, esse endereço deve ser removido de sua lista.

Quem não seguir essas regras simples acabará tendo uma taxa baixa de entrega de e-mails, vai se decepcionar com o produto e, eventualmente, deixará de usar o e-mail marketing por achá-lo ineficaz.

Pensando nisso, decidimos na Locaweb criar o conceito de “reputação” na forma de um percentual que tem por objetivo dizer ao cliente quão bem ele está seguindo essas boas práticas. Com isso, conseguimos educá-los sobre as boas práticas de envio de e- mail marketing.

Sendo assim, a funcionalidade “reputação” do e-mail marketing da Locaweb teve:

• Motivação: educar os clientes sobre boas práticas de envio de e-mail marketing para que eles obtivessem maior taxa de êxito em suas campanhas e, consequentemente, não cancelassem o serviço.
• Métrica: o resultado dessa funcionalidade está sendo medido de duas formas: quantidade de entregas (entregas no inbox, taxa de abertura de e-mails, taxa de reclamação de envio de spam) e diminuição de cancelamentos.

OKRs, o futuro dos roadmaps

Desde 2012, tínhamos na Locaweb uma mecânica de revisar o roadmap a cada trimestre. No início de cada trimestre, fazíamos uma retrospectiva sobre o que foi feito no trimestre anterior, quais itens foram entregues, quais não foram e quais as razões de sucesso ou insucesso. Em seguida, planejamos o que fazer no trimestre seguinte.

Em meados de 2014, escrevi um artigo sobre como escrever roadmaps, incluindo a motivação por trás de cada item no roadmap e métricas que mostravam que a motivação estava sendo cumprida. Foi o resultado de várias conversas que tivemos na Locaweb sobre ter o roadmap como uma lista de itens a fazer a cada trimestre, mas não estar sempre clara a razão de estarmos fazendo cada um daqueles itens planejados. Desde aquela época, começamos a experimentar fazer nossos roadmaps onde cada item deveria ser composto de 3 subitens: o que fazer, por que aquilo tinha de ser feito e qual a métrica que esperávamos mexer ao fazermos aquele item. Contudo, apesar de tentarmos deixar claro a motivação e a métrica de cada item do roadmap, as discussões acabavam girando mais em torno de “o que fazer”.

No primeiro semestre de 2015, ouvimos falar de um framework chamado OKR, que significa Objectives and Key Results. Esse framework é usado no Google desde seu início e foi trazido para lá por John Doerr, um funcionário da Intel, empresa na qual esse framework foi criado. John Doerr, após sair da Intel, se tornou investidor em negócios de tecnologia tais como Google, Amazon, Intuit e Zynga, e acabou levando esse framework para essas empresas. Várias empresas de tecnologia hoje usam OKRs. Mais alguns exemplos são LinkedIn, GoPro, Flipboard, Yahoo!, Amazon, Adobe, Baidu, Dropbox, Facebook, Netflix e Spotify.

OKR é um framework derivado de uma técnica de gestão chamada de Administração por Objetivos, termo criado por Peter Drucker em seu livro The Practice of Management, de 1954. A Administração por Objetivos consiste em um processo que requer a identificação e descrição precisas de objetivos a atingir e prazos para conclusão e monitorização. Tal processo exige que as pessoas envolvidas concordem com o que se pretende atingir no futuro e que todos desempenharão as suas funções em função dos objetivos.

Como funcionam os OKRs?

Existem vários artigos e vídeos que explicam em detalhes como funcionam os OKRs, por isso farei uma explicação sucinta. Os OKRs são compostos de duas partes: um objetivo e de 2 a 5 resultados-chaves (key results) que indicam que o objetivo foi atingido. Por exemplo:

• Objetivo: ter clientes satisfeitos ao ponto de recomendar nossos serviços aos seus amigos.
• Key Result 1: manter 80% das notas de pesquisa de satisfação acima de 8, em uma escala de 0 a 10.
• Key Result 2: pelo menos 50% das novas vendas devem vir de recomendações de clientes existentes.

O objetivo não precisa necessariamente ter números. Já os key results devem obrigatoriamente ter algum número, ou seja, devem ser alguma métrica e devem dizer onde se está e onde se quer chegar com a métrica. Isto é, qual é a meta que queremos atingir com aquela métrica.

Recomenda-se ter pelo menos 2 key results, pois quando há apenas um key result, pode haver o chamado “efeito perverso”. Por exemplo, suponha que o objetivo seja aumentar a produtividade do time de atendimento telefônico e que seja definido um único key result que seria o TMA (tempo médio de atendimento), que hoje está em 8 minutos e deve cair para 2 minutos. Uma forma de se atingir esse resultado-chave é simplesmente o atendente desligar o telefone quando estiver próximo de dar 2 minutos de ligação. Claro que isso seria péssimo para a qualidade do serviço, mas o key result e o objetivo seriam atingidos. Nesse caso, para balancear o “efeito perverso”, é recomendável ter mais um key result que garanta que a satisfação do cliente que estiver sendo atendido se mantenha.

Implementando OKRs na Locaweb

Após estudarmos OKR por algum tempo, chegamos à conclusão de que ele era muito parecido com o que sempre quisemos fazer: nos focarmos mais nas motivações e métricas do que no “o que fazer” propriamente dito. A grande diferença é que, nos OKRs, o “o que fazer” simplesmente não entra. Ele pode ser discutido quando se define cada objetivo e seus respectivos resultados-chaves, mas o “o que fazer” não é documentado e, por isso, não vira um compromisso e pode ser mudado. O que importa é o objetivo e os resultados-chaves que indicam que o objetivo foi atingido.

Para nos ajudar nessa mudança, chamamos o Felipe Castro, da Lean Performance, consultoria especializada em implementação de OKR. Chamamos em junho de 2015 e começamos a implementação no 3o trimestre de 2015, com uma série de treinamentos internos sobre OKR, definição de objetivos, métricas e metas. Em agosto, fizemos uma sessão de planejamento “café- com-leite” para definir OKRs para o mês de setembro. Foi apenas um teste para podermos entender um pouco melhor a mecânica do processo de definição de OKR. No final de setembro, fizemos nossa primeira sessão de planejamento de um trimestre completo, em que definimos os OKRs do 4o trimestre de 2015 para os times de desenvolvimento e marketing de produtos da Locaweb. Em paralelo, continuamos com o planejamento trimestral de roadmap de produtos baseado em itens a fazer.

Cada time atualizava seus OKRs semanalmente. Além disso, acompanhávamos a evolução do roadmap mensalmente. Vimos ao longo desses acompanhamentos que os itens do roadmap eram as tarefas que habilitavam o atingimento dos objetivos e dos resultados chave, isto é, havia um acompanhamento duplo para o mesmo trabalho. Ao longo desse acompanhamento, surgiu a ideia: que tal abandonarmos o roadmap tradicional, da lista de tarefas a fazer, e focarmos apenas em definir e acompanhar OKRs?

De tarefeiros a gestores de ponteiros

Foi isso o que fizemos no planejamento de 1o trimestre de 2016. O planejamento foi feito totalmente baseado em objetivos e em métricas que queríamos mexer, os ponteiros que queríamos gerir. Deixamos de ser meros tarefeiros, meros executores de tarefas, para nos tornarmos gestores de ponteiros. Dado um objetivo e uma métrica que indica que esse objetivo está sendo atingido, decidimos o que vamos fazer. Na reunião de revisão dos OKRs do 1o trimestre de 2016 e de planejamento dos OKRs do 2o trimestre, ninguém sentiu falta da lista de tarefas a fazer do antigo roadmap. Obviamente, durante a retrospectiva cada time comentou um pouco sobre o que fez para tentar mexer os ponteiros, mas o “o que fazer” passou a ser apenas um meio para se atingir um objetivo, e não mais o objetivo em si. E é claro que, em cada sessão de planejamento de OKRs, os times já têm uma noção de “o que vão fazer” para atingir seus objetivos, mas eles têm autonomia para decidir esse “o que fazer” como quiserem.

OKRs ou roadmaps?

Em agosto de 2016, depois de 11 anos liderando o desenvolvimento e gestão de produtos na Locaweb, decidi me mudar para a Conta Azul, uma startup de ERP SaaS em Joinville, cidade no sul do Brasil, para ajudá-los a escalar sua equipe de desenvolvimento de produtos. Quando cheguei na Conta Azul, notei que eles também usavam OKRs para toda a empresa, incluindo a equipe de desenvolvimento de produtos. No entanto, além de usar o OKR, eles também usavam roadmaps e não parecia possível parar de usá-los e gerir todos os esforços de desenvolvimento de produtos usando apenas OKRs. Isso me fez refletir se o OKR pode realmente substituir roadmaps ou se existem circunstâncias em que ambas as ferramentas podem ser usadas juntas. E se isto for verdadeiro, quais são essas circunstâncias.

Ao discutir esse tópico com pessoas da indústria de software, ficou claro para mim que o uso do roadmap ou do OKR depende do estágio do produto em seu ciclo de vida. Eu discuti sobre os quatro estágios de um ciclo de vida do produto no capítulo Ciclo de vida de um produto de software.

Conforme descrito nesse artigo, o ciclo de vida do produto de software possui 4 estágios:

• Inovação: das quatro etapas do ciclo de vida de um produto de software, a inovação é a que detém a maior quantidade de dúvidas. É também a etapa sobre a qual possui o maior número de livros. Qualquer livro sobre inovação e startups é útil quando o seu produto está nesta fase. O objetivo principal é criar um produto que atenda aos problemas e necessidades de um grupo de clientes. Por esse motivo, durante esta fase, há apenas um objetivo, encontrar a adequação do produto ao mercado, e para medir esse objetivo, podemos usar vários key results que demonstram o envolvimento e a satisfação do cliente. Na etapa da Inovação, não devemos usar OKR nem roadmaps. Devemos usar a estrutura MVP (Minimum Viable Product) do construir-medir-aprender para atingir o objetivo de encontrar a adequação do produto ao mercado.
• Crescimento: na fase de crescimento, quando o produto foi desenvolvido e lançado, devemos nos preocupar em como gerir o produto durante o seu crescimento. Uma vez que na etapa de inovação construímos um MVP para atingir nosso objetivo de encontrar a adequação do produto ao mercado, nosso produto está bastante incompleto; portanto, devemos ter um roadmap descrevendo quais funcionalidades criaremos, mais a motivação para criar cada funcionalidade e as métricas que serão adotadas para nos mostrar que estamos cumprindo a motivação de criar cada funcionalidade, como descrevi no meu artigo sobre o roadmap. Motivação é outra palavra para Objetivo, e Métrica é o mesmo que key results. Na etapa de crescimento, devemos usar os roadmaps juntamente com o OKR, pois na fase de inovação lançamos um MVP sem muitas funcionalidades que tornariam o produto mais completo, e agora precisamos implementá-las.
• Maturidade: após o crescimento, vem a maturidade. Nesta etapa, nosso produto atingiu seu mercado potencial e, consequentemente, não cresce tão rápido quanto na etapa Crescimento. Quando um produto chega a esse estágio, possui todos os recursos necessários e não há mais necessidade de um roadmap. Na etapa Maturidade, devemos usar apenas OKRs para gerir o desenvolvimento do produto, pois nesta fase otimizaremos o produto para cumprir seus Objetivos.
• Fim da vida útil: após a maturidade, ou quando o produto é desenvolvido mas não se encaixa no mercado, chega a etapa conhecida como fim da vida útil ou pôr do sol de um produto de software. Nesta etapa, como na etapa Maturidade, não é necessário um roadmap, pois não faz sentido criar funcionalidades adicionais. Se o seu produto atingiu a etapa Fim da vida útil após a etapa Maturidade, ele já possui todas as funcionalidades necessárias. Se o seu produto atingiu essa etapa logo após a etapa Inovação, porque não encontrou o mercado adequado, você não deve investir nenhum esforço na construção de funcionalidades adicionais. Na etapa Fim da vida útil, devemos usar apenas OKRs para gerir o desenvolvimento do produto, pois nesta fase nosso único objetivo é parar de servir o produto.

Por esse motivo, fica claro que os OKRs substituem os roadmaps em todas as etapas do ciclo de vida do produto, exceto na etapa Crescimento, onde os roadmaps são muito úteis para entender para onde o produto está indo, o futuro do seu produto. Na etapa Crescimento, devemos usar roadmaps e OKRs em conjunto para gerir o desenvolvimento do produto.

Detalhamento vs. audiência

Como dito no início deste capítulo, o roadmap do seu produto de software é a sua ferramenta para comunicar a visão de futuro que você tem para o seu produto. Só que sabemos que existem diferentes públicos que precisarão de diferentes níveis de detalhamento do seu roadmap. Em qual nível de detalhamento devemos entrar para cada público?

A figura dá uma sugestão de nível de detalhamento de acordo com cada audiência. O primeiro aspecto em que você tem de pensar é se o público é interno ou externo. Como disse anteriormente, para públicos externos, você normalmente falará de funcionalidades. Já com públicos internos, seu foco deverá ser mais em funcionalidade e métrica do que na funcionalidade em si.

O segundo aspecto a se preocupar é com o nível de detalhamento que você precisa dar.

• Público em geral: para eles, o detalhamento não precisa ser grande. O ideal é falar em termos de funcionalidades e você pode só comentar as funcionalidades de destaque que estão mais próximas de serem entregues.
• Clientes próximos: para os clientes mais próximos, já é possível dar um pouco mais de detalhes, dando uma visão de médio prazo. Com esses clientes, é importante criar uma boa relação para que eles lhe ajudem a direcionar a visão de seu produto baseado nos problemas que eles têm e que seu produto se propõe a resolver.
• Parceiros: com eles, vale a pena entrar em mais detalhes, principalmente aqueles que ajudam o produto a chegar ao cliente. Por exemplo, o produto de hospedagem de sites da Locaweb tem as empresas que hospedam seus sites na Locaweb como clientes finais, mas tem também os parceiros que são os desenvolvedores e agências que desenvolvem esses sites. Aqui devemos continuar falando em roadmap como lista de funcionalidades.
• CEOs, vice-presidentes e diretores: nesse ponto, movemos para o público interno. Para esse público, tão ou mais importante do que saber quais funcionalidades vêm pela frente é saber a motivação de essas funcionalidades estarem no roadmap. Para eles, essa visão pode ser bem macro.
• Vendas e marketing: já para os times de marketing e vendas, é preciso entrar em um pouco mais de detalhes. Para vendas, os detalhes são importantes pois eles podem já ter identificado a demanda no mercado e, para marketing, a necessidade de mais detalhes vem do trabalho de divulgação que farão.
• Marketing de produtos: esse grupo é praticamente o quarto elemento daquele core team que comentei no capítulo O que é gestão de produtos de software?. Eles devem participar muito próximo do desenvolvimento do produto, e devem conhecer toda a motivação e as métricas das funcionalidades que estão no roadmap.
• SAC: esse grupo talvez não precise saber tanto sobre a motivação das funcionalidades quanto os outros grupos internos, mas ele, sem dúvida, é o que precisa conhecer mais detalhes dessas funcionalidades futuras, pois eles falaram diariamente com os seus clientes.
• Engenharia e UX: fazem parte do core team do produto. Precisam de todos os detalhes, motivações e métrica para poderem fazer seu trabalho.

Roadmap ou backlog?

Por fim, uma pergunta que ouço com frequência é: qual a diferença entre roadmap e backlog? Roadmap é o seu “mapa da estrada”, as coisas que você tem de fazer; já backlog é o termo usado em metodologias ágeis para o seu “registro de coisa a fazer”. Esses termos são equivalentes e podem ser usados como sinônimos.

Gestão de produtos digitais

Este artigo é mais um capítulo do meu livro Gestão de produtos: Como aumentar as chances de sucesso do seu software, onde falo sobre o que é gestão de produtos digitais, seu ciclo de vida, que ferramentas utilizar para aumentar suas chances de sucesso. Você também pode se interessar pelos meus outros dois livros:

• Liderança de produtos digitais: A ciência e a arte da gestão de times de produto
• Guia da Startup: Como startups e empresas estabelecidas podem criar produtos de software rentáveis

Mentoria e aconselhamento em desenvolvimento de produtos digitais

Tenha ajudado várias empresas a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.