Essa é uma pergunta frequente de todo gestor de produtos. Quer seja um produto novo que está sendo criado agora, quer seja um produto já em pleno funcionamento, cheio de sugestões de clientes e usuários, como fazer para priorizar, ou seja, para decidir o que fazer primeiro?

Existe uma quantidade grande de técnicas. Falarei sobre algumas delas aqui e, no final da lista, vou dizer qual é a melhor. Só lhe peço que não vá agora até o final da lista para não estragar a surpresa… 😛

Valor versus custo

Uma das formas mais simples de priorizar um roadmap é fazendo uma análise de todos os itens, procurando estimar: o valor (benefício) de cada um para o negócio e para os usuários, e o custo de implementar cada item. Com esses dados em mãos, é possível até fazer um gráfico com dois eixos e colocar cada um dos itens, baseado no valor e no custo. A ideia é priorizar sempre o que tiver maior valor e menor custo, pois o benefício será obtido mais rapidamente.

Análise Kano

A análise Kano foi criada pelo Professor Noriaki Kano, da Universidade de Tokyo, para classificar os itens de um produto com base também em duas dimensões, na necessidade de um item e na satisfação que este causa no cliente.

Com isso, é possível classificar os itens em três tipos: mandatórios, satisfatórios e encantadores.

Por exemplo, em um carro, roda é um item mandatório, pois não há carro sem roda. Teto-solar é um item satisfatório, se seu cliente não o valoriza muito. Já ser muito silencioso é um item que encanta um cliente que aprecia essa característica. A recomendação é ter todos os mandatórios, alguns satisfatórios, mas não deixar de fora alguns encantadores para poder impressionar positivamente o cliente.

RICE

Quando cheguei na Conta Azul, deparei-me com outro método de priorização adotado pelo time de produtos, o RICE. RICE é a sigla em inglês para Reach (Alcance), Impact (Impacto), Confidence (Confiança) e Effort (Esforço). Os três primeiros itens da matriz são pontuados e, ao final, divididos pelo último.

Alcance se refere a quantas pessoas aquela tarefa vai alcançar em um determinado período de tempo, que deve ser igual para todas as features que estão sendo comparadas. Impacto estima a quantidade de pessoas que serão impactadas (use o valor 3 para um impacto massivo, 2 para um grande impacto, 1 para médio, 0.5 para pequeno e 0.25 para um impacto mínimo). Confiança aborda o quão confiante você está sobre suas estimativas (escolha entre 100% para uma alta confiança, 80% para média e 50% para baixa). Em Esforço, coloque quantas pessoas-mês a tarefa levará para ser concluída sendo o mínimo o valor 0,5, ou seja, uma pessoa por meio mês.

O cálculo matemático é bem simples:

RICE = (Alcance x Impacto x Confiança) / Esforço

Sequenciador de features

O Sequenciador de features foi criado por Paulo Caroli, da ThoughtWorks, para auxiliar no planejamento de um produto a partir de suas funcionalidades. As regras desse método, como o limite de 3 cards por linha, auxilia na conversa sobre priorização.

De acordo com seu livro Lean Inception: Como alinhar pessoas e construir o produto certo, o Sequenciador de features ajuda a organizar e visualizar as funcionalidades e sua relação com os entregáveis. O sequenciador organiza as releases do produto além do primeiro entregável. Tipicamente, times utilizando o Sequenciador de features vão vislumbrar a evolução do produto por meio de um entendimento claro das funcionalidades de cada entregável bem como a ordem dos releases.

A imagem anterior possui um exemplo de sequenciador de features; cada funcionalidade é representada por um cartão de índice. Os post-its no lado direito representam os produtos a serem entregues.

Árvore de produto

A ideia é mais ou menos parecida com a análise de Kano: classificar os itens do roadmap de acordo com as partes de uma árvore. Raízes são a infraestrutura; caule é o que dá o suporte; galhos são os diferentes caminhos que você pode colocar no seu produto; as folhas são as funcionalidades propriamente ditas; e as flores e os frutos são as funcionalidades que realmente vão encantar o cliente.

Todo produto tem de ter raízes, caule e alguns galhos com suas respectivas folhas, mas é importante sempre incluir algumas flores e frutos para deixar seu produto encantador.

Compre suas funcionalidades

Nessa técnica, você põe o seu cliente para trabalhar. Você mostra todos os itens que estão em seu roadmap e dá um valor para cada um deles baseado no quanto vai lhe custar fazer cada um. Em seguida, convide alguns clientes e diga para eles que eles têm X para gastar. Esse X tem de ser consideravelmente menor que a soma do valor de todos os seus itens.

Com esse X, cada cliente tem de “comprar” as funcionalidades que são mais importantes para ele e, como o dinheiro é limitado, ele é forçado a fazer escolhas do tipo “Será que pego essas duas funcionalidades, ou as troco por essa outra mais cara?”. É um exercício muito interessante e dá ao gestor de produtos um bom conhecimento sobre o comportamento do cliente.

Na Conta Azul, utilizávamos essa técnica com os contadores para priorizar o que fazer no nosso sistema para contadores e foi muito interessante ver esses contadores passando pelo dificuldade de priorizar o que fazer no produto.

UserVoice

UserVoice é um sistema de sugestões que você pode colocar dentro do seu produto. Com isso, seus usuários poderão fazer sugestões sobre ele, e poderão também votar em sugestões feitas por outros usuários. Você ainda pode limitar a quantidade de votos, forçando-os a fazer escolhas como no método anterior. Você pode usar outros sistemas de gerenciamento de sugestões.

A que você lembrar primeiro

Jason Fried, fundador da 37signals, que agora se chama Basecamp, disse no seu livro Getting Real que, na sua empresa, a opção foi por priorizar baseado na lembrança. Eles recebem várias sugestões todos os dias, e decidiram simplesmente não anotar para não ter de depois gastar tempo contando e classificando-as.

Como sugestões aparecem todos os dias, eles as ouvem todos os dias. De tempos em tempos, eles se reúnem e discutem sobre as sugestões que se lembram, e essas são as que são tratadas e eventualmente priorizadas no roadmap dos produtos.

A melhor técnica de priorização

Como deu para perceber, existem várias maneiras de se priorizar um roadmap, todas elas bastante úteis. O que dá para concluir é que, se há tantas maneiras de se priorizar um roadmap e se todas as maneiras de se priorizar podem ser úteis, isso significa que a priorização de um roadmap não é uma ciência exata.

Temos um anseio de querer achar um método de priorização para justificar nossas escolhas. Entretanto, sempre que esse método falhar em um determinado item, que temos certeza de que seria melhor fazer antes (ou depois) do que o método diz, acabamos tentados a seguir essa nossa certeza, pondo abaixo o método.

Por isso, por mais que existam várias técnicas e métodos de priorização de roadmap, o melhor método é o bom senso. Ou seja, a capacidade do gestor de produtos de analisar as opções disponíveis e, usando-se de sua empatia, priorizar essas opções levando em conta os objetivos da empresa e as necessidades dos usuários.

O que fazer com pedidos especiais?

Ao longo da vida de seu produto, você certamente encontrará pedidos de novas funcionalidades vindas de clientes (ou da equipe comercial) que vêm acompanhados, de forma explícita ou não, de uma ameaça de que, se não fizermos essa funcionalidade, vamos perdê-los. Por outro lado, se você atender a essa demanda, em detrimento de todo o planejamento de roadmap feito, corre o risco de atrasar a entrega de funcionalidades importantes para o resto dos clientes e para os objetivos estratégicos do dono do produto de software.

O que fazer?

A resposta a essa pergunta depende muito do seu produto e de sua base de clientes. Vou explicar melhor essa resposta com um exemplo.

Na Locaweb, tínhamos dois produtos de e-mail marketing. Um deles se chama E-mail Marketing Locaweb (nome bem original, né?), e o outro é o All In Mail. Para dar um pouco da dimensão de cada produto e do tipo de cliente que cada um deles atende, aqui vão alguns números.

Na tabela, podemos ver que, apesar de o e-mail Marketing da Locaweb ter 75 vezes mais clientes que o All In Mail, ele dispara somente 16,7% do total de mensagens disparadas no All In Mail. O E-mail Marketing tem uma quantidade muito maior de clientes que o All In Mail, mas são clientes bem pequenos, que usam pouco o produto se comparado aos da All In Mail.

Por esse motivo, a gestão de produtos do E-mail Marketing Locaweb não pode se dar ao luxo de atender pedidos especiais. Não pode favorecer o pedido de um único cliente em detrimento dos outros 29.999. A gestão de produtos nesse caso deve se preocupar em implementar funcionalidades que atendam a maior quantidade possível de clientes. Já a gestão de produtos do All In Mail não só pode como deve prestar total atenção aos pedidos especiais. São poucos clientes, mas são todos clientes especiais que demandam atenção personalizada.

O problema de falar sim para tudo

Quando falamos em priorizar um roadmap, uma coisa que acaba acontecendo é que acabamos atendendo absolutamente todos os pedidos, de todo mundo. Tudo é importante, pois tudo entra no roadmap, só que o que é menos importante fica para depois. A pessoa que pediu tem o alento de que “está no roadmap”, apesar de ter ficado lá para a frente, e ter boas chances de ser empurrado ainda mais para a frente se aparecer algum item mais importante.

Por que isso acontece?

O gestor de produtos acabando dizendo “sim” para pedidos que recebe por vários motivos:

• Precisa agradar a todos: esse é um problema bastante comum do gestor de produtos, a necessidade de agradar a todos. Quando o gestor de produtos vê que a resposta “vou colocar no backlog” acalma as pessoas que estão pedindo algo, ele começa a usar essa resposta de forma indiscriminada. Com isso, o roadmap ficará enorme e bastante complexo de gerenciar. Além disso, quando a pessoa que lhe pediu algo vir que “estar no backlog” não é garantia de que será feito logo, ele não ficará feliz… :-/

• Os dados mostram que temos de fazer: cada vez mais vejo empresas focadas em tomar decisões exclusivamente baseadas em dados. Com isso, em breve poderemos todos nós ser substituídos por algoritmos que tomarão as decisões, já que basta basear-se nos dados. Acontece que os dados nem sempre estão certos. Pode haver dados insuficientes, ou mesmo errados. Outro problema de decisões baseadas em dados é o risco de se cair em um ótimo local. A sugestão é usar dados como um dos inputs para a tomada de decisão, mas não esquecer também dos dados qualitativos, sua intuição e sua capacidade de julgamento.

• Mas é uma funcionalidade tão pequena: toda funcionalidade, por menor que seja, implicará em mais código e mais interação. Mais código significa complexidade de código, e quanto mais complexo o código, mais difícil de manter. Mais interação significa mais complexidade para seu usuário lidar, ou seja, chances de oferecer uma experiência ruim para ele. Nenhuma funcionalidade é tão pequena que não traga complexidade de código e de interação, por isso, pondere bem se essa complexidade adicional trará benefícios para seu usuário e para o dono do software.

• O cliente pediu e, se não fizermos, ele vai embora: esse é o momento de tomar decisões difíceis. Se você quiser agradar todos os clientes, acabará agradando nenhum. Você precisa escolher quem é o cliente para quem você está fazendo seu produto. Um produto não pode ter mais do que duas ou três personas primárias. Aliás, o recomendado é ter apenas uma persona primária; ter duas ou três já dará um trabalho razoável para conseguir gerenciar. Se o que esse cliente pediu não atende sua persona primária, você terá de ter coragem de dizer NÃO.

• Nós sempre podemos fazer dessa nova funcionalidade mais uma opção nas configurações: mais uma vez, estamos criando complexidade sem necessidade. Como já dito, toda funcionalidade implica em complexidade de código e de interação. Colocar todas as novas funcionalidades como opcionais a serem configuradas em uma tela de configuração fará dessa tela algo bem difícil para seu usuário.

• Nossos competidores já têm: esse é um erro bem comum, basear-se nos competidores e não no seu cliente/usuário. Lembre-se: um gestor de produtos tem de se preocupar em fazer o software atender os objetivos da empresa dona do software, ao mesmo tempo que resolve um problema ou atende uma necessidade de seus clientes. É importante saber o que o competidor está fazendo, mas se o que ele estiver fazendo não tem a ver com o objetivo de sua empresa, nem com os problemas ou necessidades de seus clientes, então você não precisa fazer igual.

• O chefe quer: existem chefes e chefes. Se o seu chefe for extremamente antenado em relação aos clientes, é importante ouvi-lo. Ele será sempre um grande aliado. Agora, se seu chefe quer uma determinada funcionalidade simplesmente porque viu em algum competidor, ou alguém falou para ele que deveria fazer assim, você deve lembrá-lo dos objetivos da empresa e dos problemas e necessidades de seus clientes que você está tentando atender com o seu produto de software.

Apesar das razões vistas, para dizer sim a todo pedido de funcionalidade que um gestor de produtos recebe, ele tem de aprender a dizer NÃO.

Dizer NÃO pode parecer difícil, mas se você tiver muito claro os objetivos de seu produto, ou seja, quais objetivos da empresa o seu produto deve alcançar, quem é seu cliente principal e qual problema desse cliente você está procurando atender, você terá os argumentos necessários para dizer NÃO a certas demandas.

Seja gentil com a pessoa que está trazendo a demanda e diga algo como:

Como dizer não

Sua sugestão é interessante e consigo entender por que você a está pedindo. Contudo, deixe-me lhe mostrar o que já temos planejado em nosso roadmap, e quais são os objetivos de cada item que está nele. Por este motivo, não conseguiremos dar a devida atenção ao seu pedido nesse momento. Você me lembra de conversarmos novamente sobre isso no futuro?

Deixe para quem está pedindo a nova funcionalidade a responsabilidade de lembrar-se de ter essa conversa novamente no futuro. Se ele não se lembrar, é porque o pedido dele não era tão importante assim. Se ele lembrar, avalie novamente o pedido e, se necessário, diga NÃO novamente.

Lidando com pedidos especiais de clientes B2B

Mencionei anteriormente que, se você tem um produto B2B focado em clientes maiores, o gestor de produto “deve prestar total atenção a solicitações especiais. Existem poucos clientes, mas todos são especiais e exigem atenção personalizada. O gestor de produto deve ter cuidado e não implementar recursos que serão usados por apenas um cliente. No entanto, solicitações de um cliente, especialmente os maiores, sempre serão uma prioridade neste cenário”.

Como gerir esses pedidos especiais

Então isso significa que o gestor de produto deve fazer tudo o que os grandes clientes exigem? A resposta curta é NÃO! Você ainda está gerindo um produto, portanto, dois aspectos importantes da gestão de produto ainda se aplicam:
A demanda normalmente vem na forma de soluções, e os grandes clientes podem ser bastante incisivos ao descrever a solução que desejam. O trabalho do gestor de produto é entender qual é o problema subjacente que levou o cliente a solicitar essa solução específica. Dica rápida: pergunte por que o cliente precisa dessa solução e o que fará assim que obtê-la. Isso fornecerá muitas informações sobre o problema do cliente.

Você está gerindo um produto, não um software personalizado. Se você implementar cada solicitação de funcionalidade dos clientes, estará criando um software personalizado para cada cliente ou, o que é ainda pior, um produto de “software frankenstein”.

A resposta mais longa é não, mas você ainda precisará gerir as solicitações especiais. Existem algumas técnicas que podem ajudá- lo a lidar com esses pedidos especiais:

• Modularização: se você for capaz de criar seu produto como módulos que trabalham juntos em diferentes combinações para fornecer diferentes tipos de soluções, isso permitirá que sua equipe de vendas selecione e combine os módulos para atender às necessidades de seus clientes. E sempre que uma nova solicitação de funcionalidade chegar, e você descobrir o problema subjacente e decidir criar uma solução para esse problema, poderá construí-la como um módulo separado. Você pode até cobrar desse cliente pelo desenvolvimento deste novo módulo. Cobrar um cliente pelo desenvolvimento de uma nova solução, mesmo considerando que essa nova solução possa ser oferecida a outros clientes, é uma boa maneira de testar a real necessidade desse cliente. Se ele estiver disposto a pagar a você para que forneça essa solução, ele realmente precisa dela e confia em você para construí-la. SAP é um bom exemplo de soluções modulares.

• Configuração avançada: outra maneira de personalizar seu produto sem parecer um produto “software frankenstein” é através da configuração avançada. Por exemplo, para um determinado cliente, o recurso X pode ser entregue como a sequência da etapa A, etapa B e etapa C. Para outro cliente que não deseja o recurso X, mas precisa do recurso Y, ele pode ser entregue pela sequência da etapa C, depois a etapa E, e você desativa o recurso X para este cliente. Dependendo da complexidade, também é possível fornecer essa configuração avançada por meio de linguagens de programação. Alguns exemplos são, novamente o SAP, com ABAP (Advanced Business Application Programming) e o Salesforce com Apex, que permitem que os desenvolvedores adicionem lógica de negócios à maioria dos eventos do sistema Salesforce, incluindo cliques em botões, atualizações de registros relacionados, e páginas do Visualforce.

• Integração: outra necessidade comum das grandes empresas é ter seu produto integrado a outros produtos que elas já usam. Por exemplo, vamos imaginar que sua empresa fornece soluções de comércio eletrônico. Seu cliente contratou seu produto de comércio eletrônico e ele incluirá todo o catálogo de produtos, além de dados sobre clientes e compras em seu produto. Esse grande cliente certamente solicitará que você integre sua solução de comércio eletrônico ao ERP deles, para que eles possam faturar clientes e gerenciar seu inventário. Essa integração pode ser feita de várias maneiras: completamente manual através da redigitação de dados, troca de arquivos ou uso de uma integração via API. A melhor solução é através da API, pois fornece uma solução sem erros e em tempo real para a integração de dados entre sistemas. Por esse motivo, é muito importante que seu produto tenha APIs com as extremidades necessárias para conectar-se a outros sistemas.

Tech Sales (ou Engenharia de Vendas ou Pré-vendas)

Novos pedidos especiais surgem durante o processo de vendas. Cada uma dessas solicitações especiais tomará tempo do gestor de produto bem como da equipe de desenvolvimento do produto. A equipe precisará entender a solicitação especial, o problema subjacente e as opções de projeto de solução que podem ser usadas com outros clientes. Isso tomará tempo do gestor de produto e da equipe.

A certa altura, a equipe usará as técnicas descritas acima para lidar com solicitações especiais de forma escalável. Assim que a equipe começar a usar essas técnicas, a necessidade de interagir com os clientes para cada solicitação provavelmente persistirá ou aumentará. A equipe de vendas solicitará que o gestor de produto faça reuniões com o cliente e ajude-o a mostrar ao cliente quais são as opções técnicas disponíveis para atender à solicitação.

O primeiro passo é treinar a equipe de vendas. No entanto, isso não será suficiente. O gestor de produto continuará sendo solicitado a participar de reuniões para responder a perguntas técnicas. Para ajudar com esse problema, devemos criar uma nova função, a de Tech Sales, também conhecidas como Engenheiro de Vendas ou Consultor de Pré-venda, alguém com formação técnica que participará de discussões técnicas com o cliente durante o processo de vendas.

Às vezes essa função, por conter a palavra vendas, é colocada como liderança de vendas. É uma possibilidade, mas pode levar ao desalinhamento de incentivos. Como liderança de vendas, o incentivo é o número de vendas. Portanto, se um vendedor de tecnologia estiver demorando muito para projetar a solução e outras solicitações forem adiadas, um novo vendedor de tecnologia será contratado, aumentando o número de funcionários e, consequentemente, o custo da venda. Uma alternativa é colocar essa função sob a liderança da gestão de produto, para que o foco esteja na ativação de vendas, ou seja, fornecer à equipe de vendas as ferramentas necessárias para realizar vendas sem a necessidade de um vendedor de tecnologia.

Serviços profissionais

Supondo que tudo corra bem com a negociação e o cliente decida comprar o seu produto, se houver personalizações a serem feitas, será necessário um trabalho adicional, não importa se através de módulos, configuração avançada e/ou integração. Esse trabalho pode acabar caindo no backlog da equipe de desenvolvimento de produtos, o que não é o ideal, pois esse trabalho é específico para atender a uma determinada solicitação do cliente, enquanto que a equipe de desenvolvimento de produtos deve estar trabalhando em itens que possam ser usados pela maioria dos clientes.

Para ajudar com esse problema, devemos criar uma segunda função, chamada de serviços profissionais. Uma pessoa com essa função trabalha nesse tipo de projeto, estabelecendo um novo cliente utilizando as técnicas de personalização do produto (módulos, configuração avançada e/ou integração). Eles devem ser pessoas com habilidades técnicas capazes de executar o trabalho de personalização necessário para estabelecer o produto da nova empresa.

Os serviços profissionais podem ser realizados por uma equipe dentro da empresa que oferece o produto e/ou por terceiros. Por exemplo, para implementar o SAP, Salesforce ou Zendesk, você pode optar por usar serviços profissionais deles ou de terceiros certificados, que tenham conhecimento e experiência na implementação e personalização do software deles em muitos clientes. Este trabalho é normalmente cobrado como taxa de configuração.

Resumindo

Vimos muitas técnicas para priorizar um roadmap. Priorizar um roadmap não é uma ciência exata, e aprendemos que a melhor maneira de priorizar um roadmap é pura e simplesmente bom senso, ou seja, construir um roadmap que alinha as metas e objetivos da empresa enquanto resolve um problema ou atende a uma necessidade de clientes e usuários. Também aprendemos a dizer não às solicitações de priorização e o que é e como lidar com solicitações especiais.

Lidar com pedidos especiais pode ser uma necessidade do seu mercado, especialmente se você estiver no espaço B2B com clientes maiores. É possível criar um produto que atenda a essas solicitações especiais sem criar um produto de “software frankenstein”. Para fazer isso, o gestor de produto e a equipe de desenvolvimento de produto devem utilizar uma ou mais das técnicas conhecidas para lidar com solicitações especiais, modularização, configuração e integração avançadas. Colocar essas técnicas em prática provavelmente não será suficiente, pois a equipe de vendas ainda precisará de ajuda para apresentar as opções ao cliente e, após a venda, implementá-las. Em seguida, surgem duas novas funções, que devem estar próximas da gestão de produtos: vendas técnicas – ou engenheiro de vendas – e serviços profissionais, que podem ser internos, podem ser executados por terceiros ou por ambos.

Próximo tópico: dados!

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.