About Joca

I've been helping companies succeed in the digital era by guiding them on how to create and manage successful digital products that connect their strategic objectives with the problems and needs of their customers.

Why business people hate discovery

There are basically two reasons, one of them has to do with mindset and the other one has to do with the discovery process.

The one that has to do with mindset is clear when we hear phrases like “Why do you want to do a discovery? I’m the business person so I’m the person that understands the most about our business problems/needs and how to solve them. You just have to implement what I say”.

Sometimes this aversion is rooted in the “business demands => technology implements” mindset that I mentioned earlier. This was how things were made in the past, without any need for discovery, because “business people are the ones interacting with customers so they always know what is best for the customers”.

However, most frequently this aversion to the discovery process is motivated by the business person’s past experiences where the discovery process was too long. The business person needs the solution to his problems implemented as quickly as possible, so she can benefit from the results that this demand may generate. The business person can’t afford lengthy discovery processes.

It’s very difficult, but not impossible to change this mindset. It requires patience and repetition:

  • Ask why: by asking why the business person is demanding the implementation of a certain feature, we have the opportunity to show this person a very simple discovery tactic that helps both the product manager and the business person to find other solutions hypotheses to the problem. We change to a discovery mode without using the word discovery. After a few times applying this tactic, we can mention to the person that understanding the why of a certain demand, generating solution hypotheses, and testing these solution hypotheses is the process of discovery and it’s based on the product manager and the product development team needs to find the easiest and quick to implement the solution.
  • Learn about the business: sometimes the business person believes that she knows more about the business than the product manager. This normally happens when a new product manager joins a company and still doesn’t know much about its business. To solve this perception from the business person, the product manager needs to find ways to learn about the business as quickly as possible. Talk to business people, talk to customers, read about the business, attend short-term courses about the business, and go to conferences about the business topic. Product managers need to understand the business in order to discuss business issues with the business person.
  • Shorten the discovery process: sometimes discoveries take quite long. A few weeks, one month, more than one month. Meanwhile, the business person has a problem that needs a solution as quickly as possible so she can benefit from the expected outcome that the solution of the problem may generate. This happens especially when the discovery process is focused only on the problem discovery. If the product manager is able to cycle fast between problem discovery and solution discovery, the business person may see the product development team working sooner rather than later on a solution hypothesis for the problem and may have her expectations for a solution calmed down.

MVD – Minimal Viable Discovery

Unfortunately, this third reason, the lengthy discovery process, happens quite often and this is our fault, especially when we aim to understand everything about a problem prior to testing solutions.

As I mentioned earlier, the discovery process has two sides, problem discovery, and solution discovery. We don’t need to know everything about a problem prior to testing, i.e., discovering solutions. The solution discovery is a powerful tool for us to understand more about the problem. For this reason, we need to cycle as quickly as possible between problem discovery and solution discovery. The faster we do so, the faster we understand the problem and the faster we discover a solution for the problem.

Also, if we do a complete problem discovery to understand everything about the problem, we may end up with so many sub-problems that will make the solution discovery process also very lengthy and the delivery will take a lot of time to be completed.

The product development community talks a lot about MVP, the minimal viable product, but we cannot forget this is not only about fast delivery of a minimal product, but also a lean discovery process. It’s time to adopt an MVD – Minimal Viable Discovery mindset, i.e., what’s the minimal problem discovery we need to make in order to test the minimal solution hypotheses and deliver the one that works and actually solves the problem?

Lopes’ broker app

A good example to illustrate this is the Lopes’ broker app. Lopes is the biggest real estate company in Brazil, where I’m leading the digital transformation efforts. When I joined the company the team was working on an “MVP” of this app. I put in quotes because it was under development for 5 months and there were still 2 to 3 months to go. When I dig a bit deeper into the process and why it was taking so long, I’ve learned a few things:

  • The discovery process took anywhere between 7 to 10 months!
  • The discovery process was focused only on the problem discovery.
  • The discovery process was internal, i.e., demand gathering from business areas and benchmarking with other broker apps available in the market.
  • The “MVP” was scoped as having 58 requirements/features and there were already 90 requirements/features scoped for future releases.
  • The main pain point was based on a hypothesis that, if the broker received the lead, i.e., a potential customer interested in a property, the faster she received this lead and interacted with the customer, the greater the chances of closing a deal.
  • Then, the team analyzed the broker journey and realized that when a lead arrives, the broker needs to search Lopes potential customers database to check if the potential customer is already in our database and if it is not, register the user data in our database.
  • And then, from this broker journey analysis they realized that, if the broker was able to send a few other property options to the potential customer, it would potentially increase the chances of closing a deal.
  • This created the scope to be implemented that took 7 to 10 months of discovery plus 7 to 8 months of delivery to build the app “MVP”.

There are a few points to highlight from the process above:

  • The discovery process was too long, which created a huge list of problems to be solved.
  • The solution discovery phase was not performed. The team went from problem discovery directly to delivery, without any opportunity to test some solution hypotheses.
  • The huge list of problems to be solved impacted directly the delivery process making it very long too.
  • If the solution discovery was used as soon as the main problem was discovered, the hypothesis that the faster she received this lead and interacted with the customer, the greater the chances of closing a deal, probably the team would be able to devise a simpler solution, that probably would take days, not months to be implemented.

Regarding this last point, after a few discussions, we thought about an app with only a push notification for each lead and the broker could continue the tasks as she already did them. And it could be even simpler to test the solution hypotheses by not to even building an app, but by sending an SMS or a WhatsApp message to the broker. An A/B test could be made to compare the closing rates of the brokers who received SMS notifications versus the closing rates of brokers that didn’t receive them.

We actually ended up implementing the SMS notification, it took us 10 days to implement, and right after that, we were able to test the hypothesis that the faster a broker received a lead and interacted with the customer, the greater the chances of closing a deal.

The best discovery method is called delivery

I already mentioned that one of the reasons to deliver early and often is that the moment of truth for your product is when a product is in front of its users, being used in the context where it is supposed to be used. It doesn’t matter how much research, interviews, and prototypes you do, the moment of truth, that is, the moment when you will know if your product is, in fact, the solution to a problem of a group of people, is when the product is in your customers’ hands, in the context where they need the product.

So the best way to discover if a solution hypothesis works is actually implementing it and presenting it to potential users that may have the problem that you discovered during the problem discovery.

For many solution hypotheses, we don’t need to build a complete product to test. Today there are many low-code and no-code tools that allow us to build simple solutions. And some of these tools exist for quite a while, like presentations and forms. At Gympass we tested some solution hypotheses that we had to solve the problem we discovered of bringing new options to people that didn’t want to go to the gym but wanted to pursue a healthier lifestyle.

The solution hypothesis was to partner with wellness apps and provide this app to our users for a monthly subscription fee. This new idea had two main hypotheses that we needed to test:

  • Application providers willingness to partner. Application providers, like gyms, are used to the recurring monthly revenue model. Would they accept to be paid per day of use?
  • Our user base willingness to pay. Is our user base interested in paying a monthly fee to access the applications?

To test our first hypothesis, we built a deck with the value proposition that we planned to deliver to the partners and talked to some potential partners. We presented the opportunity to 8 potential partners, of whom 6 showed interest and 4 decided to join our proof of concept. NEOU, a workout app, 8fit, a workout and nutrition app, Tecnonutri, a nutrition app, and ZenApp a meditation app.

Okay, our first hypothesis was validated with just a simple slide deck. No product was built. Now we needed to validate the second hypothesis, the willingness to subscribe. Is our user willing to pay to access these applications through Gympass?

To test our second hypothesis, we built a simple form, where we described the product and asked for the user’s name, email, and company. After the user provided this information, he was directed to a Paypal subscription page, where he had to provide his credit card details to subscribe to the service. The user would receive an email with the activation link for each application. There was no real product, no logged-in area, just a form to test interest and an email with links to the applications.

The first version of Gympass Wellness

So use the no-code or low-code tools options available to build your solution hypothesis to make it easier and faster to go through the solution discovery. As a side-effect, business people will start to understand, appreciate and even want to participate in your next discoveries.

Summing up

  • Business people dislike discoveries because of 3 main reasons. (1) They believe they know more about the business, the clients, and what they need. (2) They may have had past experiences where the discovery took too long. (3) They are used to a “business demands => technology implements” model.
  • Changing this mindset requires patience and repetition. Three things a product manager should do continuously to help change this mindset. (1) Ask why the person is asking to implement the demanded feature. (2) Learn about the business. (3) Shorten the discovery process.
  • In order to shorten the discovery process, we should think in terms of an MVD mindset, i.e., minimal viable discovery, where we discover enough about the problem in order to generate and test the solution hypothesis as fast as possible.
  • The best discovery method is called delivery. The moment of truth of any solution hypothesis is when we are able to present it to the potential user in her own context where she faces the problem we want to solve. Today we have many low-code and no-code solutions that help us build our solution hypothesis to make it easier and faster to go through the solution discovery.
  • As a side-effect, business people will start to understand, appreciate and even want to participate in your next discoveries.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

You can also acquire the books individually, by clicking on their titles above.

Mentoring and advice on digital product development

I’ve been helping several companies extract more value and results from their digital products. Check here how I can help you and your company.

Porque as pessoas de negócios odeiam discovery

Existem basicamente três razões, duas delas tem a ver com a mentalidade e a outra tem a ver com o processo de descoberta.

A que tem a ver com mentalidade fica clara quando ouvimos frases como “Por que você quer fazer uma descoberta? Eu sou a pessoa de negócios, então sou a pessoa que mais entende sobre nossos problemas/necessidades de negócios e como resolvê-los. Você apenas tem que implementar o que eu digo”.

Outras vezes, essa aversão está enraizada na mentalidade de “exigências de negócios => implementos de tecnologia” que mencionei anteriormente. Era assim que as coisas eram feitas no passado, sem necessidade de descoberta, pois “são os empresários que interagem com o cliente para que sempre saibam o que é melhor para os clientes”.

Contudo, na maioria das vezes, essa aversão pelo processo de descoberta é motivada pelas experiências passadas do empresário em que o processo de descoberta foi muito longo. O empresário precisa que a solução de seus problemas seja implementada o mais rápido possível, para que possa se beneficiar dos resultados que essa demanda pode gerar. A pessoa de negócios não pode arcar com longos processos de descoberta.

É muito difícil, mas não impossível, mudar essa mentalidade. Requer paciência e repetição:

  • Pergunte por quê: perguntando por que a pessoa de negócios está exigindo a implementação de uma determinada funcionalidade, temos a oportunidade de mostrar a essa pessoa uma tática de descoberta muito simples que ajuda tanto o gerente de produto quanto a pessoa de negócios a encontrar outras hipóteses de soluções para o problema. Mudamos para um modo de discovery sem usar a palavra discovery. Depois de algumas vezes aplicando essa tática, podemos dizer à pessoa que entender o porquê de uma demanda, gerar hipóteses de solução e testar essas hipóteses de solução é o processo de discovery e é baseado na necessidade do gerente de produto e da equipe de desenvolvimento de produto encontrarem a solução mais fácil e rápida de implementar.
  • Aprenda sobre o negócio: às vezes a pessoa de negócio acredita que sabe mais sobre o negócio do que o gerente de produto. Isso normalmente acontece quando um novo gerente de produto ingressa em uma empresa e ainda não sabe muito sobre o negócios. Para resolver essa percepção da pessoa de negócio, o gerente de produto precisa encontrar maneiras de conhecer o negócio o mais rápido possível. Converse com pessoas de negócio, converse com clientes, leia sobre o negócio, participe de cursos de curta duração sobre o negócio, vá a conferências sobre o tema de negócios. Os gerentes de produto precisam entender sobre o negócio para discutir questões de negócios com a pessoa de negócios.
  • Encurte o processo de discovery: às vezes os discoveries demoram bastante. Algumas semanas, um mês, mais de um mês. Enquanto isso, a pessoa de negócio tem um problema que precisa de solução o mais rápido possível para que possa se beneficiar do resultado esperado que a solução do problema pode gerar. Isso acontece principalmente quando o processo de descoberta é focado apenas na descoberta do problema. Se o gerente de produto for capaz de alternar rapidamente entre a descoberta do problema e a descoberta da solução, a pessoa de negócios poderá ver a equipe de desenvolvimento de produto trabalhando mais cedo nas hiopóteses de solução para o problema e pode ter suas expectativas por uma solução acalmadas.

MVD – Descoberta Mínima Viável

Infelizmente, esse terceiro motivo, o processo de descoberta lento, acontece com bastante frequência e a culpa é nossa como gestores de produto, principalmente quando buscamos entender tudo sobre um problema antes de testar as soluções.

Como mencionei anteriormente, o processo de descoberta tem dois lados, a descoberta do problema e a descoberta da solução. Não precisamos saber tudo sobre um problema antes de testar hipóteses de solução, ou seja, descobrir soluções. A descoberta de solução é uma ferramenta poderosa para entendermos mais sobre o problema. Por esse motivo, precisamos alternar o mais rápido possível entre a descoberta do problema e a descoberta da solução. Quanto mais rápido fizermos isso, mais rápido entenderemos o problema e mais rápido descobriremos uma solução para o problema.

Além disso, se fizermos uma descoberta completa do problema para entender tudo sobre esse problema, podemos acabar com tantos subproblemas que tornarão o processo de descoberta da solução também muito demorado e o delivery levará muito tempo para ser concluído.

A comunidade de desenvolvimento de produtos fala muito sobre MVP, o produto mínimo viável, mas não podemos esquecer que não se trata apenas de um delivery rápido de um produto mínimo, mas também de um processo de discovery enxuto. É hora de adotar uma mentalidade MVD – Minimal Viable Discovery ou Descoberta Mínima Viável, ou seja, qual é a descoberta mínima sobre o problema que preciso fazer para testar hipóteses de solução mínimas e entregar aquela que funciona e realmente resolve o problema?

App para corretores Lopes

Um bom exemplo para ilustrar isso é o app para corretores Lopes. A Lopes é a maior imobiliária do Brasil, onde lidero os esforços de transformação digital. Quando entrei na empresa, a equipe estava trabalhando em um “MVP” deste aplicativo. Coloquei aspas porque estava em desenvolvimento há 5 meses e ainda faltavam 2 ou 3 meses. Quando me aprofundei um pouco mais sobre o processo e porque estava demorando tanto, aprendi algumas coisas:

  • O processo de descoberta durou de 7 a 10 meses!
  • O processo de descoberta foi focado apenas na descoberta do problema.
  • O processo de descoberta foi interno, ou seja, levantamento de demanda das áreas de negócios e benchmarking com outros aplicativos para corretores disponíveis no mercado.
  • O “MVP” foi definido com 58 requisitos/funcionalidades e já havia mais 90 requisitos/funcionalidades com escopo definido para lançamentos futuros.
  • O principal problema a ser resolvido foi baseado na hipótese de que, se a corretora recebeu um lead, ou seja, um potencial cliente interessado em um imóvel, quanto mais rápido ela receber esse lead e interagir com o cliente, maiores serão as chances de fechar um negócio.
  • Em seguida, a equipe analisou a jornada da corretora e percebeu que, quando um lead chega, a corretora precisa pesquisar o banco de dados de potenciais clientes da Lopes para verificar se o potencial cliente do lead já está em nosso banco de dados e, caso não esteja, cadastrar seus dados nosso sistema.
  • E então, a partir dessa análise da jornada da corretora, o time percebeu que, se a corretora pudesse enviar algumas outras opções de imóveis para o cliente em potencial, isso aumentaria as chances de fechar um negócio.
  • Esse processo criou o escopo a ser implementado que levou de 7 a 10 meses de discovery mais 7 a 8 meses de entrega para construir o aplicativo “MVP”.

Há alguns pontos a destacar do processo acima:

  • O processo de descoberta foi muito longo, o que gerou uma enorme lista de problemas da corretora a serem resolvidos.
  • A fase de descoberta da solução não foi executada. A equipe passou da descoberta do problema diretamente para a entrega, sem qualquer oportunidade de testar hipóteses de solução.
  • A enorme lista de problemas a serem resolvidos impactava diretamente no processo de entrega tornando-o muito longo também.
  • Se a descoberta da solução fosse utilizada assim que o problema principal fosse descoberto, ou seja, a hipótese de que quanto mais rápido ela recebesse esse lead e interagisse com o cliente, maiores as chances de fechar um negócio, provavelmente a equipe conseguiria conceber uma solução mais simples, que levaria dias e não meses para ser implementada.

Em relação a este último ponto, após algumas discussões, pensamos em um aplicativo com apenas uma notificação push para cada lead recebido e a corretora poderia continuar as outras tarefas como já fazia. E para ser ainda mais simples de testar a hipótese da solução pensamos em nem construir um aplicativo, mas enviar um SMS ou uma mensagem de WhatsApp para a corretora. Um teste A/B pode ser feito para comparar as taxas de fechamento de negócios dos corretores que receberam notificação por SMS versus as taxas de fechamento dos corretores que não receberam.

Na verdade, acabamos implementando a notificação por SMS. Demoramos 10 dias para implementar e logo em seguida conseguimos testar a hipótese de que quanto mais rápido um corretor receber um lead e interagir com o cliente, maiores as chances de fechar um negócio.

O melhor método de discovery chama-se delivery

Já mencionei que uma das razões para entregar cedo e frequentemente é que o momento da verdade para o seu produto acontece quando um produto está na frente de seus usuários, sendo usado no contexto em que deve ser usado. Não importa quantas pesquisas, entrevistas e protótipos você faça, o momento da verdade, ou seja, o momento em que você saberá se o seu produto é, de fato, a solução para um problema de um grupo de pessoas, é quando o produto está nas mãos de seus clientes, no contexto em que eles precisam do produto.

Portanto, a melhor maneira de descobrir se uma hipótese de solução funciona é realmente implementá-la e apresentá-la a usuários em potencial que podem ter o problema que você descobriu durante a descoberta do problema.

Para muitas hipóteses de solução, não precisamos construir um produto completo para testar. Hoje existem muitas ferramentas low-code e no-code que nos permitem construir soluções simples. E algumas dessas ferramentas existem há bastante tempo, como apresentações e formulários. No Gympass testamos algumas hipóteses de solução que tínhamos para resolver o problema que descobrimos de trazer novas opções para pessoas que não queriam ir à academia, mas queriam seguir um estilo de vida mais saudável.

A hipótese de solução foi fazer parceria com aplicativos de bem-estar e fornecer esses aplicativos aos nossos usuários por uma taxa de assinatura mensal. Essa nova ideia tinha duas hipóteses principais que precisávamos testar:

  • Disposição dos provedores de aplicativos para fazer parceria. Provedores de aplicativos, assim como academias, estão acostumados com o modelo de receita mensal recorrente. Eles aceitariam ser pagos por dia de uso?
  • Nossa disposição de base de usuários para pagar. Nossa base de usuários está interessada em pagar uma taxa mensal para acessar os aplicativos?

Para testar nossa primeira hipótese, construímos um deck com a proposta de valor que planejamos entregar aos parceiros e conversamos com alguns potenciais parceiros. Apresentamos a oportunidade a 8 potenciais parceiros, dos quais 6 demonstraram interesse e 4 decidiram aderir à nossa prova de conceito. NEOU, um aplicativo de atividade física, 8fit, um aplicativo de atividade física e nutrição, Tecnonutri, um aplicativo de nutrição e ZenApp, um aplicativo de meditação.

Ok, nossa primeira hipótese foi validada apenas com um deck de slides. Nenhum produto foi criado. Agora precisávamos validar a segunda hipótese, a vontade de assinar. Nosso usuário está disposto a pagar para acessar esses aplicativos através do Gympass?

Para testar nossa segunda hipótese, construímos um formulário simples, onde descrevíamos o produto e pedíamos nome, e-mail e empresa. Após o usuário fornecer essas informações, ele era direcionado para uma página de assinatura do Paypal, onde precisava fornecer os dados do cartão de crédito para assinar o serviço. O usuário receberia um e-mail com o link de ativação para cada aplicativo. Não havia produto real, nenhuma área logada, apenas um formulário para testar o interesse e um e-mail com links para os aplicativos.

Primeira versão do Gympass Wellness

Ou seja, devemos utilizar as opções de ferramentas no-code ou low-code disponíveis para criar sua hipótese de solução para facilitar e agilizar a descoberta da solução. Como efeito colateral, as pessoas de negócios começarão a entender, apreciar e até querer participar de seus próximos discoveries.

Resumindo

  • Pessoas de negócios não gostam de discoveries por causa de 3 razões principais. (1) Acreditam saber mais sobre o negócio, os clientes e o que esse clientes precisam. (2) Eles podem ter tido experiências passadas em que a descoberta levou muito tempo. (3) Eles estão acostumados a um modelo de “negócios demanda => tecnologia implementa”.
  • Mudar essa mentalidade requer paciência e repetição. Três coisas que uma gerente de produto deve fazer continuamente para ajudar a mudar essa mentalidade. (1) Pergunte por que a pessoa está pedindo para implementar a funcionalidade pedida. (2) Procure conhecer mais sobre o negócio. (3) Encurte o processo de discovery.
  • Para encurtar o processo de discovery, devemos pensar em termos de uma mentalidade MVD, ou seja, Minimal Viable Discovery ou Descoberta Mínima Viável, onde descobrimos o suficiente sobre o problema para gerar e testar hipóteses de solução o mais rápido possível.
  • O melhor método de discovery chama-se delivery. O momento da verdade de qualquer hipótese de solução é quando somos capazes de apresentá-la ao potencial usuário em seu próprio contexto onde ele enfrenta o problema que queremos resolver. Hoje temos muitas soluções low-code e no-code que nos ajudam a construir nossa hipótese de solução para tornar mais fácil e rápido trabalhar na descoberta da solução.
  • Como efeito colateral, as pessoa de negócio começarão a entender, apreciar e até querer participar de suas próximas descobertas.

Gestão de produtos digitais

Você trabalha com produtos digitais? Quer saber mais sobre como gerenciar um produto digital para aumentar suas chances de sucesso, resolver os problemas do usuário e atingir os objetivos da empresa? Confira meu pacote de gerenciamento de produto digital com meus 3 livros, onde compartilho o que aprendi durante meus mais de 30 anos de experiência na criação e gerenciamento de produtos digitais. Se preferir, pode comprar os livros individualmente:

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.

Porque “negócios demanda => tecnologia implementa” não funciona

Trabalho há algum tempo em empresas em transformação digital ou que possuem pessoas, inclusive C-level, não familiarizadas com métodos de desenvolvimento de produtos digitais.

Um dos maiores desafios dessas empresas é passar de uma mentalidade de “negócios demanda => tecnologia implementa” para uma mentalidade de “negócio traz problemas/necessidades => tecnologia trabalha na compreensão desses problemas/necessidades com o usuário, testando hipóteses de solução e implementando uma hipótese de solução validada”.

Normalmente, as pessoas de negócios tendem a pensar e dizer coisas como “Eu sou a pessoa de negócios, então sou a pessoa que mais entende sobre nossos problemas/necessidades de negócios e como resolvê-los. Você apenas tem que implementar o que eu digo”. Essa pessoa de negócios está pensando na equipe de tecnologia como uma equipe de implementadores de soluções, não uma equipe de solução de problemas ou, como Marty Cagan coloca, como um feature team, não um product team empoderado.

Então, por que o modelo “demandas de negócios => tecnologia implementa” não funciona?

Em vez de dar apenas um motivo, vou listar 5 motivos:

  • Empresas de tecnologia de sucesso como Apple, Amazon, Google, Netflix não usam o modelo “negócios demanda => tecnologia implementa” para construir seus produtos de sucesso. Eles preferem e usam o modelo de desenvolvimento de produto “negócio traz problemas/necessidades => a tecnologia trabalha na compreensão desses problemas/necessidades com o usuário, testando hipóteses de solução e implementando uma hipótese de solução validada”, pois sabem que esse modelo traz os melhores resultados.
  • O modelo “negócios demanda => tecnologia implementa” gera uma posição de adversário entre negócios e tecnologia e, consequentemente, o comprometimento e engajamento da equipe de tecnologia diminui, o que causa alta rotatividade de pessoal e aumenta da frustração das pessoas de negócios, o que acaba gerando um círculo vicioso.
  • As pessoas de tecnologia não se sentem responsáveis ​​pelo resultado do que constroem, pois a área de negócios definiu o que fazer.
  • A área de negócios pode exigir desenvolvimentos que sejam bons para os interesses individuais de cada área de negócios, mas não necessariamente bons para a empresa.
  • A área de negócios pode pedir coisas complexas que causarão longos ciclos de desenvolvimento que, quanto mais longos, maior a frustração gerada e maiores as chances da entrega não satisfazer as necessidades e não gerar os resultados esperados.

O outro modelo realmente gera melhores resultados?

O fato de que o modelo de trabalho “negócios demanda => tecnologia implementa” ter muitos problemas, não significa necessariamente que o outro modelo realmente gera melhores resultados. Para responder a esta pergunta, ou seja, se o “negócio traz problemas/necessidades => a tecnologia trabalha na compreensão desses problemas/necessidades com o usuário, testando hipóteses de solução e implementando uma hipótese de solução validada” entregar melhores resultados, compartilharei um case interessante.

Ingressei na Lopes, maior empresa de consultoria imobiliária do Brasil, no final de agosto/2020 como CDO (Chief Digital Officer) com a missão de liderar sua transformação digital. Após minha integração, implementamos o OKR, executamos o 4T2020 com a ferramenta OKR e definimos os objetivos estratégicos para 2021. Naquela época, mais de 50% do time era de empresas terceirizadas de consultoria de TI. Um de nossos objetivos estratégicos para 2021 era tirar gradualmente nosso envolvimento com essas empresas de consultoria de TI e contratar engenheiros, designers de produto e gerentes de produto para construir nossas equipes internas de desenvolvimento de produtos. Iniciamos a desativação das consultorias em janeiro/2021 e terminamos em julho/2021. Ao mesmo tempo, contratamos e integramos muitos engenheiros, designers de produtos e gerentes de produtos para substituir a capacidade de desenvolvimento de produtos que tínhamos com as empresas de consultoria de TI que estavam saindo.

A maioria das empresas de consultoria de TI opera sob o modelo “negócios demanda => tecnologia implementa” onde são medidos por suas entregas, sem nenhuma preocupação se essas entregas realmente trazem resultados para o negócio.

O principal objetivo da nossa equipa digital é, e foi desde a sua criação, trazer mais leads, ou seja, potenciais clientes interessados ​​em comprar um imóvel, a partir de fontes digitais. O gráfico acima mostra que quando as empresas de consultoria de TI, medidas pelas funcionalidades entregues, estiveram na Lopes não conseguimos cumprir esse objetivo. Assim que começamos a descontinuar as empresas de consultoria de TI em fev/2021 e contratamos e integramos engenheiros, designers de produtos e gerentes de produto para construir nossa equipe interna de desenvolvimento de produtos que foi medida pela geração ou potencialização de leads por meio do digital, começamos ver um aumento no número de leads em maio/2021.

Resumindo

  • Um dos maiores desafios das empresas em transformação digital é passar de uma mentalidade de “negócios demanda => tecnologia implementa” para uma mentalidade de “negócios traz problemas/necessidades => a tecnologia trabalha na compreensão desses problemas/necessidades com o usuário, testando hipóteses de solução e implementando uma hipótese de solução validada”.
  • Existem 5 razões pelas quais o modelo “negócios demanda => tecnologia implementa” não funciona. As melhores empresas de tecnologia não o usam esse modelo. Gera comportamento de adversários entre as equipes de negócios e tecnologia, as equipes de tecnologia não se sentem responsáveis pelos resultados, as pessoas de negócios podem exigir desenvolvimentos não alinhados com os objetivos da empresa e as pessoas de negócios podem exigir desenvolvimentos muito complexos e que demoram muito para trazer resultados.
  • Os benefícios da transição de um modelo de “negócios demanda => tecnologia implementa” para um modelo de “negócios traz problemas/necessidades => tecnologia trabalha na compreensão desses problemas/necessidades com o usuário, testando hipóteses de solução e implementando uma hipótese de solução validada” podem ser vistos quando passamos da medição do desempenho pelo número de entregas para a medição do desempenho pelos resultados alcançados.

Gestão de produtos digitais

Você trabalha com produtos digitais? Quer saber mais sobre como gerenciar um produto digital para aumentar suas chances de sucesso, resolver os problemas do usuário e atingir os objetivos da empresa? Confira meu pacote de gerenciamento de produto digital com meus 3 livros, onde compartilho o que aprendi durante meus mais de 30 anos de experiência na criação e gerenciamento de produtos digitais. Se preferir, pode comprar os livros individualmente:

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.

Why “business demands => technology implements” doesn’t work

I’ve been working for quite some time in companies undergoing a digital transformation or which have people, including C-level, not familiar with digital product development methods.

One of the biggest challenges in these companies is moving from a “business demands => technology implements” mindset into a “business brings problems/needs => technology works on understanding these problems/needs with the user, testing solution hypothesis, and implementing a validated solution hypothesis” mindset.

Normally business people tend to think and say things like “I’m the business person so I’m the person that understands the most about our business problems/needs and how to solve them. You just have to implement what I say”. This business person is thinking about the technology team as a solution implementer team, not a problem solver team or, as Marty

Cagan puts it, as a feature team, not an empowered product team.

So, why “business demands => technology implements” model doesn’t work?

Instead of giving you just one reason, I’ll list 5 reasons:

  • Successful tech companies like Apple, Amazon, Google, Netflix do not use the “business demands => technology implements” model to build their successful products. They prefer and use the “business brings problems/needs => technology works on understanding these problems/needs with the user, testing solution hypothesis, and implementing a validated solution hypothesis” model of product development since they know this model brings the best results.
  • The “business demands => technology implements” model generates an adversarial position between business and technology and, consequently, the commitment and engagement of the technology team decreases, which causes high staff turnover and increased frustration of business people, which ends up generating a vicious circle.
  • Technology people do not feel responsible for the result of what they build, since the business area has defined what to do.
  • The business area may demand developments that are good for the individual interests of each business area, but not necessarily good for the company.
  • The business area can ask for complex things that will cause long development cycles that, the longer they are, the greater the frustration generated and the greater the chances of the delivery not satisfying the needs and not generating the expected results.

Does the other model actually generate better results?

The fact that the “business demands => technology implements” has many issues, it doesn’t necessarily mean that the other model actually generates better results. In order to answer this question, i.e., if the “business brings problems/needs => technology works on understanding these problems/needs with the user, testing solution hypothesis, and implementing a validated solution hypothesis” deliver better results I’ll share an interesting case.

I joined Lopes, the biggest Real Estate consultancy company in Brasil, in late Aug/2020 as CDO (Chief Digital Officer) with the mission to lead their digital transformation. After my onboarding, we implemented OKR, run the 4Q2020 with the OKR tool, and defined strategic objectives for 2021. Back then, more than 50% of the team was from 3rd-party IT consultancy companies. One of our strategic objectives for 2021 was to phase out our engagement with these IT consultancy companies and hire engineers, product designers, and product managers to build our in-house product development teams. We started the phase-out in Jan/2021 and ended in Jul/2021. During the same time, we hired and onboarded many engineers, product designers, and product managers to replace the product development capability that we had with the parting IT consultancy companies.

The majority of IT consultancy companies run under the “business demands => technology implements” model where they are measured by their deliverables, without any concern if these deliverables actually bring business results.

The main objective of our digital team is and was since its inception to bring more leads, i.e., potential customers interested in buying a property, from digital sources. The chart above shows that when IT consultancy companies, measured by features delivered, were at Lopes we were unable to fulfill this objective. As soon as we started to phase out the IT consultancy companies in Feb/2021 and hire and onboarded engineers, product designers, and product managers to build our in-house product development team which was measured by generating or potentializing leads through digital, we start to see an increase on the numbers of leads in May/2021.

Summing up

  • One of the biggest challenges in companies undergoing digital transformation is moving from a “business demands => technology implements” mindset into a “business brings problems/needs => technology works on understanding these problems/needs with the user, testing solution hypothesis, and implementing a validated solution hypothesis” mindset.
  • There are 5 reasons why “business demands => technology implements” model doesn’t work. Best tech companies don’t use it. Generates adversarial behavior between business and tech teams, tech teams don’t feel responsible for the results, business people may demand developments not aligned with company goals, and business people may demand developments that are too complex and that take too long to bring results.
  • The benefits of transitioning from a “business demands => technology implements” model into a “business brings problems/needs => technology works on understanding these problems/needs with the user, testing solution hypothesis, and implementing a validated solution hypothesis” model can be seen when we move from measuring performance by the number of deliverables to measuring performance by results achieved.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

You can also acquire the books individually, by clicking on their titles above.

Mentoring and advice on digital product development

I’ve been helping several companies extract more value and results from their digital products. Check here how I can help you and your company.

Growth: be a “data geek”

Take a close look at the data that your product generates! Aside from talking to your users and hearing their feedback, a mandatory way of knowing your product and how your users interact with it is through data. To take advantage of these data you must become a data geek, a person who knows in depth the data generated by the application and their meaning.

In God we trust. All others bring data. — W. E. Deming

William Edwards Deming is an American engineer, statistician, and professor known for his work in Japan right after World War II when he taught about statistic management of quality and helped the Japanese to become the second larger economy in the world in only 10 years. It’s all about collecting and trusting valuable customer data.

Which data is important?

Every data is important, but depending on your goal, some are more important than others. Knowing your data is a continuous task because at each new information you acquire, new questions appear that are going to need more data to understand it.

One of the first pieces of information that you will want to know is how many visits you get to your product’s website. To know these numbers, you can use some statistic reports that your hosting provider offers. Another very common option is Google Analytics.

With a report like that in hand, you get some important information, such as the number of visits, amount of unique visitors, amount of page views, among others. Depending on the statistical system you are using, you will also check:

  • what is the first and the last page visited during the access to your website;
  • where (which country and city) your visitors come from;
  • if they accessed your website due to a Google AdWords or Facebook campaign;
  • or some other online campaign that you are running;
  • or if they found your website organically, that is, typing the address directly;
  • or searching for something in some search system.

It is good to remember that it is important to hold these reports not only for your website but also for your entire software product.

Be careful. Many of the visiting report systems show a great amount of information, and it is easy to get lost in this sea of data.

Along with the number of visits and access that your website holds, other important data you must know about your web product is:

  • Amount of people who discover your product: it is possible to differentiate the way people discover your product by dividing them into two categories, paid and free. The paid ones are those which you have to invest some money, such as on Google AdWords, Facebook ads, ads on content websites (preferably those linked to the theme of your product), and ads on magazines (also preferably linked to the theme of your product). The free ones are those in which you invest time and work to get to be known, such as creating relevant content on the theme of your website, interacting on blogs related to the theme of your product, making it easier for people to recommend your product to others, etc. The return in this case comes slower but holds the advantage of not having any financial cost, only time and work.
  • Amount of clicks generated by ads or other sources: this is information a little more difficult to obtain because depending on the strategy to attract people to your website, it will not be available. The online ad systems such as Google AdWords, Facebook ads, and ads on content sites usually have that information available, and the price they will charge usually will be set on a price per click.
  • Amount of unique visitors: they are the new visitors that your website gets. It is different from the number of visits: one single person can visit your site more than once until he/she decides to buy anything.
  • Amount of visitors who become users: from these unique visitors, some will register to become a user of your system. If you offer a free trial period or a free version with no expiration date, this number can be reasonably big.
  • Amount of users who become clients: by the end of the trial period, some of your users will want to become a client, that is, will want to pay to use your service. If you are offering a free version of your product, with no expiration date, you must have a paid version that pushes your users to leave the free version and pay for using your product.

Conversion funnel

Napoleon Bonaparte, a French political leader and military officer known for the Napoleonic Wars — through which he was responsible for establishing the French supremacy over the major part of Europe at the beginning of the 19th century –, had a great defeat in 1812, in the Russian Campaign. This campaign was a huge military operation designed by the French and their allies that had a great impact on the Napoleonic Wars, setting the beginning of the decay of the First French Empire. In this campaign, Napoleon brought 580,000 soldiers, but only 22,000 survived, and the rest perished in the way from France to Moscow due to the difficulties found on the way (cold, rain, rivers, etc.).

Russia’s campaign

This image resembles very much a conversion funnel of a website, which can be built with the data we discussed previously. The conversion funnel shows us how many potential clients we are losing on the way of attracting people to the site until the point someone pays to become your client:

Conversion funnel

The funnel displays several opportunities for you to better understand how your users interact with your product. Each part of the funnel has its specific characteristics and can be expanded in different ways. Focus on one piece at a time and test it. In the worst-case scenario, if the test goes bad, you can always come back to the previous situation. For a data geek, the funnel must be the very first data focus to be collected and analyzed.

In the next chapter, we will see two other metrics that are the natural consequence of the conversion funnel: engagement, which shows how the user utilizes your product; and churn, which shows how many users are not using it anymore, helping to identify why this happens.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

You can also acquire the books individually, by clicking on their titles above.

Mentoring and advice on digital product development

I’ve been helping several companies extract more value and results from their digital products. Check here how I can help you and your company.

Crescimento: Seja um “Data Geek”

Dê uma olhada nos dados que o seu produto gera! Além de conversar com seus usuários e obter feedback deles, uma maneira obrigatória de conhecer o seu produto e como os usuários interagem com ele é por meio de dados. Para poder tirar proveito desses dados, você deverá se transformar em um data geek, uma pessoa que conhece profundamente os dados gerados pela sua aplicação e seus significados.

Em Deus nós acreditamos. Todos os outros devem trazer dados.
W. E. Deming

William Edwards Deming é um engenheiro, estatístico e professor americano bastante conhecido pelo seu trabalho no Japão, logo após a II Guerra Mundial, onde ele ensinou sobre gestão estatística da qualidade, e ajudou os japoneses a se transformarem em 10 anos na segunda maior economia do mundo em apenas 10 anos. Tudo se resume a coletar e confiar nos valiosos dados do cliente.

Quais Dados são Importantes?

Todos os dados são importantes, mas, dependendo do que você está querendo entender, uns são mais importantes do que outros. Conhecer seus dados é uma tarefa contínua, pois a cada novo conhecimento que você adquire, aparecem novas questões, que vão precisar de mais dados para serem respondidas.

Uma das primeiras informações que você vai querer conhecer é quantas visitas você recebe no site de seu produto. Para conhecer esses números, você pode usar algum relatório de estatísticas que o provedor de hospedagem oferece. Outra opção muita usada é o Google Analytics.

Com um relatório como esse, você consegue algumas informações importantes, tais como: quantidade de visitas, quantidade de visitantes únicos, quantidade páginas vistas (pageviews) e várias outras. Dependendo do sistema de estatísticas que você estiver usando, você também conseguirá ver:

  • qual a primeira e a última página visitadas durante um acesso ao seu site;
  • de onde (que país e cidade) vêm seus visitantes;
  • se eles acessaram seu site partindo de uma campanha de Google AdWords, do Facebook;
  • ou de alguma outra campanha online que você está fazendo;
  • ou se acharam seu site de forma orgânica, digitando diretamente o endereço;
  • ou buscando por algo em algum sistema de busca.

Vale lembrar que é importante ter esses relatórios de acesso não só para o seu site como também para seu produto software.

Cuidado, pois esses sistemas de relatório de visitas normalmente dão uma quantidade muito grande de informação, e é fácil se perder nesse mar de dados.

Junto com a quantidade de visitas e acessos que seu site tem, outros dados importantes que você precisa conhecer de seu produto web são:

  • Quantidade de pessoas que ficam sabendo que seu produto existe: é possível diferenciar as formas como as pessoas ficam sabendo que seu produto existe classificando-as em duas categorias, as pagas e as gratuitas. As pagas são aquelas em que você tem de investir algum dinheiro, como Google AdWords, anúncios no Facebook, anúncio em sites de conteúdo (preferencialmente ligados ao tema de seu produto) e anúncios em revistas (também preferencialmente ligados ao tema de seu produto). Já as gratuitas são aquelas em que você investe tempo e trabalho para ficar conhecido como, por exemplo, criar conteúdo relevante sobre o tema do seu site, interagir em blogs sobre o tema do seu produto, facilitar que as pessoas recomendem seu produto para seus conhecidos etc. O retorno nesse caso é mais lento, mas tem a vantagem de não ter custo financeiro, só de tempo e trabalho.
  • Quantidade de cliques gerados pelos seus anúncios ou por outros meios: essa é uma informação um pouco mais difícil de obter, pois, dependendo de sua estratégia para atrair pessoas para o seu site, essa informação não estará disponível. Os sistemas de anúncio online como Google AdWords, Facebook e anúncios em sites de conteúdo normalmente têm essa informação disponível, e o preço que cobrarão normalmente será baseado em um preço por clique.
  • Quantidade de visitantes únicos: são os novos visitantes que seu site recebe. É diferente da quantidade de visitas, pois uma mesma pessoa pode visitar seu site mais de uma vez até decidir comprar.
  • Quantidade de visitantes que se tornaram usuários: desses visitantes únicos, alguns vão se cadastrar para se tornar um usuário do seu sistema. Se você oferecer um período de experiência gratuito ou uma versão grátis sem prazo de expiração, esse número pode ser razoavelmente grande.
  • Quantidade de usuários que se tornaram clientes: findo o período de experiência, alguns de seus usuários vão querer se tornar um cliente, ou seja, vão querer pagar para usar o seu serviço. Se você estiver oferecendo uma versão gratuita de seu produto, sem prazo de expiração, você deverá ter uma versão paga que motive seus usuários a saírem da versão gratuita e a pagarem pelo uso de seu produto.

Funil de Conversão

Napoleão Bonaparte, líder político e militar francês conhecido pelas Guerras Napoleônicas – por meio das quais foi responsável por estabelecer a hegemonia francesa sobre a maior parte da Europa no início do século XIX –, teve uma grande derrota em 1812, na Campanha da Rússia. Essa campanha foi uma gigantesca operação militar intentada pelos franceses e seus aliados, que teve grande impacto sobre o desenrolar das Guerras Napoleônicas, marcando o início do declínio do Primeiro Império Francês. Nessa campanha, Napoleão usou 580.000 combatentes. Desses, sobreviveram apenas 22.000 combatentes, o restante pereceu no caminho da França até Moscou devido às dificuldades encontradas nesse caminho (frio, chuva, rios etc.).

Campanha da Rússia

Essa imagem lembra muito um funil de conversão de um site, que pode ser feito com os dados que discutimos anteriormente. O funil de conversão nos mostra quantos potenciais clientes estamos perdendo no caminho entre atrair pessoas para o site até o ponto em que uma pessoa paga para se tornar seu cliente:

Funil de conversão

O funil apresenta várias oportunidades para você entender melhor como seus usuários interagem com seu produto. Cada pedaço do funil tem suas características específicas e pode ser alargado de diferentes formas. Concentre-se em um pedaço por vez e faça seus testes. Na pior das hipóteses, se o teste for ruim, você sempre pode voltar para a situação anterior. Para um data geek, o funil deve ser o primeiro foco de dados a se obter e analisar.

No próximo capítulo, vamos ver mais duas métricas que são a consequência natural do funil de conversão: o engajamento, que mostra como seu usuário utiliza seu produto; e o churn, que mostra quantos usuários deixam de usá-lo, ajudando a identificar por que isso acontece.

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:

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.

Growth: how to prioritize the roadmap?

This is a frequent question from every product manager. Whether is a new product that’s is being created now, or a fully operating product full of suggestions from clients and users, how to prioritize, that is, how to decide what to do first?

There is a great number of techniques. I’ll talk about a few here and, in the end, I’ll tell which one is the best. I only ask you not to jump to the end of this chapter so you won’t ruin the surprise… 😛

Value versus effort

One of the simpler ways of prioritizing a roadmap is making an analysis of all items, seeking for estimating: the value (benefit) of each one for the business and for the users, and the cost of implementing each item. With these data in your hands, it is possible to even build a graph with two axes and put each and every one of the items in it based on the value and on the cost. The idea is to always prioritize what has the bigger value and lower cost, for the benefit will be obtained more quickly.

Value versus cost chart

Kano Model Analysis

Kano Model was created by professor Noriaki Kano, from Tokyo University, to classify the items of a product based also on two dimensions, the need of an item and the excitement that it provides to clients. With this, it is possible to classify the items into three types: basic; satisfies, and delighters.

Kano Model Chart

For instance, in a car, the wheel is a basic item, for there is no car without wheels. The sunroof is a satisfier item if your client does not consider it valuable. Being very silent is an item that delights a client that appreciates it. The recommendation is to have all basic items, some satisfiers, but do not leave some delighters out if you want to positively impress your client.

RICE

When I arrived at ContaAzul, I came across another prioritization method adopted by the product team, RICE. RICE stands for Reach, Impact, Confidence, and Effort. The first three items of the matrix are scored and, in the end, divided by the last.

Reach refers to how many people that task will reach over a given period of time, which should be the same for all features being compared. Impact estimates how many people will be impacted (use 3 for a massive impact, 2 for a large impact, 1 for a medium impact, 0.5 for a small impact, and 0.25 for a minimal impact). Confidence addresses how confident you are about your estimates (choose from 100% for high confidence, 80% for medium, and 50% for low). In Effort, enter how many person-months the task will take to complete with a minimum of 0.5, ie one person per half month.

The mathematical calculation is very simple:

RICE = (Reach x Impact x Confidence) / Effort

Feature Sequencer

Feature Sequencer was created by Paulo Caroli, from ThoughtWorks, to plan a product based on deliverables and its features. The sequencer rules, such as three cards per line, foster the prioritization conversation.

According to the Lean Inception: How to Align People and Build the Right Product book, the Feature Sequencer helps you organize and visualize the features and their relation to the deliverables. The sequencer organizes and plans the product releases beyond the first deliverable. Typically, teams using the feature sequencer will dazzle the product evolution via a clear understanding of the features contained by each deliverable, and the release order.

Sample feature sequencer

The previous image has a sample feature sequencer; each feature is represented by an index card. The post-its on the right-hand side represent the deliverables.

Product tree

The idea is kind of like the Kano analysis: classifying items of the roadmap according to the parts of a tree. Roots are the infrastructure; the stalk provides support; the branches are the different paths in which you can put your product in; the leaves are the features themselves, and the flowers and the fruits are the features that are going to delight the customer. Every product has to have roots, stalk, and some branches with their respective leaves, but it’s important to always add on some flowers and fruits in order to make your product delightful.

Example of product tree

Buy your features

In this technique, you make everyone play a game. You show all the items in your roadmap and set a value for each one based on how much is going to cost to build it. Then, invite some clients and tell them they have X to spend. This X must be substantially less than the sum of the value of all your items.

With this X, each client has to buy the most important features and, as the money is limited, everyone is forced to make choices such as “Do I take these two features or trade them for this more expensive one?”. It is a very interesting exercise and provides good knowledge of client behavior.

UserVoice

UserVoice is a suggestion system that you can put in your product. With this, your user will be able to make suggestions about it, and will also be able to vote for suggestions from other users. You can still limit the number of votes, forcing them to make choices, like in the previous method.

Example of suggestion in UserVoice

The one you remember first

Jason Fried, the founder of 37signals, now renamed as Basecamp, said in his book Getting Real[ that in his company the option was to prioritize based on remembrance. They receive several suggestions every day and simply decided not to write them down so they won’t spend time counting and classifying them.

As suggestions come up every day, they hear them every day. From time to time, they get together and discuss the suggestions they remember, and these are the ones that are approached and eventually prioritized in the product’s roadmap.

The best prioritization technique

As you can see, there are many ways of prioritizing a roadmap, all very useful. In other words, what we can conclude is that if there are so many ways of prioritizing a roadmap and if all prioritizing ways can be useful, it means that prioritizing a roadmap is not an exact science.

We are eager to find a prioritization method that justifies our choices. However, every time this method fails in a certain item that we are sure it is best to do it before (or after) then the method tells us to do, we end up tempted to follow our certainty, ignoring and not following the method.

However, there are several roadmap prioritization techniques and methods, and the best method is common sense. That is, the ability the product managers have of analyzing the available options and, by using their empathy, they prioritize these options taking into account the company’s goals and the users’ needs.

What to do with special requests?

During the lifecycle of your product, you will certainly meet requests of new features coming from clients (or the commercial team) that, explicitly or not, come with a threat that if you don’t build this feature you will lose them. On the other hand, if you meet this demand to the detriment of all roadmap planning already made, you are risking to delay the delivery of important features to the rest of the clients and to the strategic goals of the software product owner.

What to do?

The answer to this question depends a lot on your product and your client base. I’ll explain this answer with an example.

At Locaweb, we have two e-mail marketing products. One of them is called ** Locaweb’s E-mail Marketing** (very original name, hum?), and the other one is the All-In Mail. To understand the dimension of each product and the type of client that each one of them attends, here are some figures.

Comparative table of different e-mail marketing product offers from Locaweb

In this table, we can see that although the E-mail Marketing from Locaweb has 75 times more clients than the All In Mail, it sends only 16,7% of the total messages sent with All In Mail. In other words, Locaweb’s E-mail Marketing holds much more clients than All In Mail, but they are small clients that use the product very little compared to All In Mail’s clients.

For that reason, the product manager of Locaweb’s E-mail Marketing cannot afford to attend to special requests. The manager cannot favor the request of one single client to the detriment of the other 29,999. The product manager in this case must be concerned with implementing features that attend to as many clients as possible. And the product manager of All In Mail not only can but must pay full attention to special requests. There are a few clients, but all of them are special and demand customized attention.

The problem of saying yes to everything

When we talk about prioritizing a roadmap, one thing that happens is that we end up answering to every request, from everyone. That is, everything is important because everything is added to the roadmap, and then the less important things are postponed. The person who requested has the confidence that “it’s in the roadmap”, although it was pushed upfront on the line, and has good chances of being pushed even further if some more important item comes up.

Why does this happen?

The product manager ends up saying yes to requests he/she gets for several reasons:

  • Needs to please everyone: this is a very common problem of product managers, the need of pleasing everyone. When product managers see that the answer “I’ll put it in the backlog” calms down people who are requesting something, they start to use this answer indiscriminately. Then, the roadmap will become huge and very complex to manage. In addition to that, when people realize that being in the backlog doesn’t guarantee that it will be done soon, they won’t be happy… :-/
  • The data show that we must do: more and more I see companies focused on making decisions exclusively based on data. Therefore, soon we can be replaced by algorithms that will make all decisions, since it is enough to make them all based on data. It happens that data are not always correct. They can be insufficient, or even wrong. Another problem of decisions based in data is the risk of falling in a great place. The suggestion is to use data as one of the inputs to make a decision, but not forgetting the qualitative data, your intuition and your judgment.
  • But it is such a small feature: every feature, as small as it is, will imply in more code and more interaction. More code means code complexity; as the code gets more complex, it is more difficult to maintain it. More interaction means more complexity for its user to work with, that is, more chances of offering a bad experience to the user. No feature is so small for not bringing code and interaction complexity, so think carefully if this additional complexity will bring benefits for your user and for the software owner.
  • The client requested and, if we don’t build it, he’ll leave: this is the moment of making tough decisions. If you want to please all your clients, you’ll end up pleasing none of them. You have to choose to whom you are building your product. A product cannot have more than two or three primary personas. By the way, the recommendation is to have only one primary persona; having two or three will be quite difficult to manage. If the client’s request does not attend your primary persona, you have to have the courage to say no.
  • We can always turn this new feature into one more option in the configuration: one more time, we are creating pointless complexity. As we said, every feature implies in code and interaction complexity. Putting all new features as options to be configured in a set up screen will turn this screen into something very difficult to its user.
Set up screen of a software
  • Our competitors already have it: this is a very common mistake, to base yourself on competition and not on your client/user. Remember: a product manager has to worry about making the software meet the goals of the company that owns it, at the same time he/she solves a problem or fulfil a need of the clients. It is important to know what the competitor is doing, but if it has nothing to do with your company’s goals, nor the problems or needs of your client, then you don’t have to do the same.
  • The boss wants: there are bosses and bosses. If your boss is extremely up to date regarding the clients, it is important to listen. But if your boss wants a certain feature just because he/she saw it in some competitor, or someone told him/her to do so, you should remind him/her of the company’s goals and the problems and needs of your clients that you are trying to meet with your software product.

Learning how to say NO!

In spite of all the reasons we saw here, in order to say yes to each and every feature request, a product manager has to learn how to say NO.

Saying NO seems difficult, but not if you have your product goals very clear, that is, which company goals your product must reach, who is your main client and what is the problem of this client you are trying to solve, you’ll have the necessary arguments to say NO to certain demands.

Be kind to the person who is bringing the demand and say something like:

How to say no

Your suggestion is interesting and I can see why you are giving them. However, let me show you what we have already planned in our roadmap, and which are the goals of each item in it. For this reason, we will not be able to pay due attention to your request right now. Remind me in the future so we can talk about this again, ok?

Pass on the responsibility for remembering the conversation again in the future for the person who is requesting the new feature. If he/she does not remember, it is because his/her request was not that important. If he/she remembers, evaluate the request again and, if necessary, say NO again.

Dealing with B2B customers’ special requests

I mentioned earlier that if you have a B2B product focused on bigger customers, the product manager “must pay full attention to special requests. There are few customers, but all of them are special and demand customized attention. The product manager must be careful and not implement features that will be used by only one customer. However, requests from one customer, especially the bigger ones, will always be a priority in this scenario.”

How to manage these special requests

So this means that the product manager should do everything that big customers demand?

The short answer is *NO! You are still managing a product, so two important aspects of product management still apply:

  • Demand normally comes in the shape of solutions, and big customers can be quite incisive describing the solution they want. It’s the product manager’s job to understand what’s the underlying problem that made the customer request that specific solution. Quick tip: ask why the customer needs that solution and what she will do as soon as she gets that solution. This will give you lots of insights on the customer’s problem.
  • You are managing a product, not a tailor-made software. If you implement each and every feature request from customers, you’ll be building a tailor-made software for each customer or, what’s even worse, a “frankenstein software” product.

The longer answer is no, but you’ll still have to manage the special requests. There are some techniques that can help you deal with these special requests:

  • Modularization: if you are able to build your product as modules that work together in different combinations to deliver different types of solutions, this will enable your sales team to mix and match the modules to fit the needs of your customers. And whenever a new feature request comes, and you figure out the underlying problem and decide to build a solution for that problem, you can build it as a separate module. You can even charge this customer for the development of this new module. Charging a customer for the development of a new solution, even considering that this new solution can be offered to other customers, is a good way to test the real need of this customer. If he is willing to pay you to deliver this solution, he really needs this solution and trust you to build it. SAP is a good example of modular solutions.
  • Advanced configuration: another way to customize your product without making look like a “frankenstein software” product is through advanced configuration. For instance, for a certain customer, feature X can be delivered as the sequence of step A, step B and step C. For another customer, that doesn’t want feature X, but needs feature Y, it can be delivered by the sequence of step C, then step E, and you turn off feature X for this customer. Depending on the complexity, it is possible also to deliver this advanced configuration through programming languages. Some examples are, again SAP, with its ABAP (Advanced Business Application Programming) and Salesforce with Apex, which enables developers to add business logic to most Salesforce system events, including button clicks, related record updates, and Visualforce pages.
  • Integration: another common need from big companies is to have your product integrated with other products they already use. For instance, let’s imagine your company provides ecommerce solutions. Your customer hired your ecommerce product and they will have all of their product catalog, and also data on customers and their purchases in your ecommerce product. This big customer will certainly ask you to integrate your ecommerce solution into their ERP, so they can invoice customers and manage their inventory. This integration can be done in many ways, completely manual through re-typing of data, through file exchange or using an API integration. The best solution is through API, since it provides an error-free and real-time solution for the data integration between systems. For this reason, it is very important that your product has APIs with the endpoints needed to connect with other systems.

Technical Sales (or Sales Engineering)

New special requests come up during the sales process. Each of these special requests will take time from the product manager as well as the product development team. The team needs to understand the special request, the underlying problem and design solution options that can be used with other customers. This will take time from the product manager and the team.

At a certain point, the team will use the above-described techniques to cope with the special requests in a scalable way. As soon as the team starts using these techniques, the need to interact with customers for each request will probably persist or even increase. The sales team will ask the product manager to have meetings with the customer and help them show the customer what are the technical options available in order to address the request.

The first step is to train the sales team. However, this won’t be enough. The product manager will continue to be asked to join meetings to answer technical questions. To help with this issue, we should create a new role, the technical sales, also known as a sales engineer or pre-sales, someone with a technical background who will engage in technical discussions with the customer during the sales process.

Sometimes this role, since it has the sales word in it, is placed under the sales leadership. It’s a possibility but can lead to misalignment of incentives. Under sales leadership, the incentive is the number of sales. So, if a tech seller is taking too long to design the solution, and other requests get delayed, a new tech seller is hired, increasing headcount and, consequently, the cost of selling. An alternative is to place this position under product management leadership so the focus is on sales enablement, i.e., to provide the sales team with the needed tools to conduct sales without the need for a tech seller.

Professional Services

Supposing everything goes well with the negotiation and the customer decides to buy your product, if there are customizations to be made, additional work is required, no matter if it will be through modules, through advanced configuration, and/or through integration. This work may end up falling into the product development team backlog, which is not ideal since this work is specific to address a certain customer request, while the product development team should be working on things that could be used by the majority of customers.

To help with this issue, we should create a second role, called professional services. A person with this role works on this type of project, setting up a new customer using the customization techniques from the product (modules, advanced configuration, and/or integration). They should be people with technical skills able to do the customization work needed to set up the new company. Professional services can be done by a team within the company that offers the product and/or by third parties. For instance, to implement SAP, Salesforce, or Zendesk, you can choose to use professional services from them or from certified third parties that have knowledge and experience in implementing and customizing their software in many customers. This work is normally billed as a setup fee.

Summing up

We saw many techniques to prioritize a roadmap. Prioritizing a roadmap is not an exact science and we learned that the best way to prioritize a roadmap is pure and simple common sense, i.e., building a roadmap that aligns the company’s goals and objectives while solving a problem or fulfilling a need of clients and users. We also learned how to say no to prioritization requests and what is and how to deal with special requests.

Dealing with special requests may be a need of your market, especially if you are in the B2B space with bigger customers. It is possible to build a product that fits these special requests without building a “frankenstein software” product. In order to do that, the product manager and product development team should use one or more of the known techniques to deal with special requests, modularization, advanced configuration, and integration. Having these techniques in place won’t probably be enough, since the sales team will still need help in order to present the options to the customer and, after the sale, to implement them. Then two new roles come up, that should be close to product management: technical sales – or sales engineer – and professional services, which could be internal, could be done by third parties or both.

Next topic: Data!

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

You can also acquire the books individually, by clicking on their titles above.

Mentoring and advice on digital product development

I’ve been helping several companies extract more value and results from their digital products. Check here how I can help you and your company.

Crescimento: como priorizar o roadmap?

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.

Gráfico valor versus custo

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.

Diagrama de Kano

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.

Sequenciador de features

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.

Exemplo de árvore de produto

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.

Exemplo de sugestão no UserVoice

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.

Tabela comparativa das diferentes ofertas de produto de e-mail marketing da Locaweb

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.
Tela de configuração de um software
  • 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:

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.

Growth: what is roadmap and OKR?

The roadmap is a very useful tool for product managers. It enables us to plan and communicate the view of the future that you have for your product.

Check out some roadmap examples:

Example of a software roadmap
Another example of a software roadmap
Windows Server Roadmap

The first two examples are short-term roadmaps, that is, they display a few months and the features that are going to be in each version of the software. On the other hand, in the Windows Server roadmap, we see a broader view, without major details but a long-term roadmap, holding almost a decade.

By setting up a roadmap for your product, you must adequate it to your audience. In other words, you must add more or less details, depending on to whom you will present this roadmap.

How frequently should I update the roadmap?

If you are part of a team that uses good practices in software engineering, you are going to be doing frequent deliveries and, by frequently delivering, you will have plenty of feedback from your users about the software and the features you are delivering. This will probably change your roadmap, because when users start to use a new feature, they will make suggestions for your software. However, even if you don’t get any suggestion, just seeing them using it will give you new ideas for your product.

If you are a product manager for hardware — such as a server, a notebook, a smartphone, a tablet, a smartwatch or even the operational system for these devices — your roadmap will be much less flexible. Many decisions will be taken months before your product is ready for the users.

Fortunately, continuous delivery in digital products allows much more flexibility. It is important to have a roadmap for a digital product of at least 12 months. However, this roadmap will frequently change, according to what you and your team will learn with your product’s users and with the way the market reacts to your novelties. Therefore, at each change of course you should update your roadmap and communicate it to everyone involved.

12-month rolling roadmaps

During my time at ContaAzul and now at Gympass my teams and I have been using a roadmap structure that has been very helpful for us to achieve the two main goals of product roadmaps, planning what are the next steps of the product and aligning the view of the product future with the entire organization.

Example of a 12-month rolling roadmap

We call this roadmap structure the 12-month rolling roadmap. I know that some people will comment that having a 12-month roadmap will prevent us from being agile, that we should have no more than 3 months planned ahead, ideally we should have no roadmap and we should only use OKRs. I tend to agree with all these comments. However, my experience has showed me that the need for roadmaps depends a lot on the product development culture maturity of the company. Probably companies like Google and Facebook have such maturity of product development culture that roadmaps are not needed and the product is developed only based on OKRs. This is also the case when we are managing mature products.

However, if you are working on a product in its innovation or growth phase, and your company does not have yet a mature product development culture, roadmaps in general and the 12-month rolling roadmap that I will present here can be very helpful.

The motivation

When a product manager presents to stakeholders a 3-month roadmap, it is not unusual that the product manager gets asked questions like “what about feature X?” or “when will we put more energy on objective Y?”. The answer is normally something in the lines of “it’s planned for future quarters but I believe that what we have planned for the coming quarter are the most important things to work on, do you agree?”. This answer will probably generate some frustration.

If a product manager decides not to use roadmaps and only use OKRs to present her plans for her product to stakeholders, the questions she will get will be in the lines of “how do you intend to reach objective Z?” or “why don’t you do W to get to your objective faster?”

For this reason, we created the 12-month rolling roadmap. It helps product managers communicate the view of the future of their product and, consequently, this will elevate the discussion to a more strategic level. Here’s an example of a 12-month rolling roadmap for a team that takes care of invoice issuance in an ERP product for SMBs.

Elements and how to use the 12-month rolling roadmap

The basic elements that should be in a 12-month rolling roadmap are:

  • Objectives and metrics: it is placed at the top of the slide because this is the most important thing of the roadmap, what you are planning to achieve by doing the things you plan to do and how do you measure that you achieved. From these, you create your OKRs.
  • Deliveries: here we have what is planned to be delivered by each team to achieve the objectives. It’s important to note down when a new team will be hired and onboarded. Normally it takes some time to hire people and have them onboarded with enough knowledge in order to deliver something. The deliveries are boxes of one or more months. That does not mean that delivery will happen only once per month. Teams should be deploying in production every week, every day, every hour if possible. This means that these deliveries are high-level deliveries, composed of many smaller deliveries that are one level down of details from what is shown in the 12-month rolling roadmaps. For those familiar with agile methodologies, think in terms of themes, epics, and stories. In the 12-month rolling roadmap we are at the level of themes and epics, we don’t go to the level of detail of stories. Note that deliveries for the upcoming quarter are in darker green while the others are in lighter green. This is by design, to show that we are more certain of the things that are closer. It is the job of the product manager presenting this roadmap to maintain the upcoming quarter the focus of the discussion. If your stakeholders want to discuss deliveries later in the roadmap, the only discussion that is important is if that delivery should happen in the upcoming quarter and, if so, what should be postponed.
  • Discoveries: the same way you present your deliveries in a timeline, you can present the required discoveries you need to do prior to the deliveries. Again, the result of discovery should not be presented only after one or more months. The discovery team (product manager, product designer and someone from engineering) will be making discoveries and sharing them with stakeholders on a weekly or even daily basis, but a better full picture of the discovery may need more time to be put together. This element is optional.
  • Constraints: if you have any relevant constraint, it is important to be placed here. In this example, the government was rolling out a new invoice layout that should be used since April 2018. For this reason, our invoicing system should be prepared to issue invoices in this new format by then. This element is also optional.

You can add other elements if it makes sense to you, your team, and your stakeholders. At Gympass we are building an integration layer that is enabling us to easily integrate our systems with gym booking and ERP systems as well as with payroll systems. As we build the building blocks of these integration layers, we are getting ready to offer specific types of professional services. For this reason, we created in our 12-month rolling roadmap an element called Professional Services readiness, to show stakeholders when we will be able to do certain types of integrations with our professional services team.

Note that with the 12-month rolling roadmap, when you get questions like “what about feature X?” or “when will we put more energy on objective Y?” or “how do you intend to reach objective Z?” or “why don’t you do W to get to your objective faster?”, it is easier to answer because you have a big picture of what’s coming next.

We named it “rolling roadmap” for a reason. It has to be reviewed regularly. If nothing changes, it should be reviewed at least quarterly, to guarantee it is aligned with the product vision and strategy. If there are changes in the external environment (new regulation, new competitors, etc) or in the internal environment (people leaving the team, change in company strategy, etc.) and these changes need to be dealt immediately, the 12-month rolling roadmap is the perfect tool to help everyone understand the impact of the changes in the objectives and deliveries of the team.

Should I keep a secret about my roadmap?

Many companies publish their roadmaps to users and to the market, while others rather keep them locked away fearing that competitors will copy their steps. I believe that the short-term roadmap (1 to 3 months) must be known by its users, so they can even present some feedback on it.

Regarding the market, you can respond reactively, that is, when asked, you can answer if it is or it is not on your short-term roadmap. The medium and long-term ones (three or more months) are not to be unveiled, not only for keeping them away from competitors, but because there are big chances of changing and, if it’s disclosed publicly, these changes will end up frustrating its users.

Cone of uncertainty

The cone of uncertainty is a concept used in project management that describes the amount of uncertainty through a given project’s lifecycle.

Cone of Uncertainty

In the beginning, very little is known and the uncertainty is high. As we move forward in the project, we learn more and the uncertainty diminishes.

Software researchers concluded that before starting a software development project, the uncertainty might vary from 0 to 4 times of the initially estimated regarding the time and the cost of developing the software.

How to build a roadmap?

After understanding what a roadmap is, the question remaining is: how to build a roadmap? That is, how to define which items are going to be in it and their order? The answer has three elements: the company, the users, and the possibilities.

What are the company’s goals?

The first element a product manager should know in order to build the roadmap is the company’s goals. The main goal of a company is not revenue or profit margin. Revenue and profit are its financial health indexes that can even show if its goals are being reached.

However, sometimes revenue and profit are not necessarily linked to goals. Moreover, these goals can change over time. For instance, in the beginning of any social network, the goal is not revenue but the number of users and the certainty that they will come back. Only after having a considerable base of active users that is reasonable to think of how to profit, whether with users or companies interested in communicating with them. That is why it is important that the product manager knows what the company’s goal is and, from time to time, check if it is still the same.

What do users want?

Knowing what are the company’s goals, the product manager should think of new products or evolve the existing ones in order to reach these goals. To do that, the product manager needs to know:

  • The users: it is necessary to know the users or possible users of your product, and which problems or needs they have that can be solved by your product. There are innumerous tools and methods to get to know your client. Some examples are surveys, interviews, access data analysis, A/B test, prototypes, usability test etc.
  • Context: the context in which your users are in and, specifically, when they use the product. Context is the set of physical conditions and events that surround your user. For instance, your user accessing your product from a desktop or from a smartphone is part of the context.
  • Market and competitors: either direct or indirect competitors. The direct ones are those that deliver the same or a similar product. The indirect competitors are the ones that somehow replace your product. For instance, suppose that you built a tool for managing orders of service for small service providers. One of the main competitors is e-mail, because these small providers can use it instead of using your tool. Or, yet, they can use the phone, paper and pen!

Can we do it?

So, you already know your company’s goals, understood your user and now you defined how your product is going to be, or that new feature that will, at the same time, meet the company’s goals and be useful to your user. Now you need to know if it’s feasible and what would be the cost. It may seem possible of building it, but if it takes too many months and too much money, it may not be worth it. Then you have the conversation with the team that will build the new product or feature; the people from UX and development. They will tell the cost, time-wise or money-wise, and if it’s not acceptable you’ll have to discuss in order to seek alternatives.

Putting everything into one image

After reading what to take into consideration while doing a roadmap, it is possible to translate product management into one image, that we saw in the chapter What is software product management?

Digital product management

In order to build your roadmap, you need to know the company’s goals, users, their needs and problems, and what can be done. With that in hand, you can build your roadmap. However, do not forget that the company’s goals may change, as well as the users’ problems and needs, and what can be done. Therefore, it is essential to make periodic reviews in your roadmap in order to keep it lined up with these three elements.

Roadmap = motivation + metrics

It is common to see roadmaps as a list of features, as depicted in the previous examples. This type of roadmap works well when you have to present it to an audience outside your company, that is, to users and the market.

Having the roadmap as a simple feature list is incomplete. Following are two very important elements to explain why these features are in the roadmap in this priority order.

What’s the motivation?

As previously stated, we should take into account three aspects while building a roadmap:

  • Company’s strategic goals;
  • Problems and needs of the client;
  • Available technology.

These are the inputs that the product manager has to take into consideration while building a roadmap, that is, to define which features to add up to it and in what order. For that reason, for the roadmap that is going to be used internally, in addition to the features themselves, it is important to state the motivation that lead the product manager to put it there. More clients? More revenue? Fewer client requirements asking for support? Increasing engagement? Etc.

Having the feature motivation in the roadmap will help the product manager to set the context for the team that will work on creating these features.

How to measure the result?

Aside from the motivation, the roadmap must also have an indication of how to measure if what motivates the features is being reached. If the motivation is to increase the number of clients, how to measure it? If it is to get more revenue, how to measure it? If it is fewer support requirements, how to measure it? If it is increasing engagement, how to measure it?

It is important to define how to measure if a given feature has accomplished its motivation and effectively measure it. It is very likely that the way of measuring it must be considered while developing the feature. Most likely, it requires adding specific programming code to allow this measurement.

An example

To illustrate the use of motivation plus metrics while building a roadmap, I’ll use an example from Locaweb: an e-mail marketing product for sending e-mails.

If you use e-mail marketing, you know that is necessary to follow some good practices in order to reach a good delivery ratio. First, it is necessary the agreement of the recipients to send them e-mails. After that, it is fundamental to hold a frequency of e-mails. If you send a message once and never again, you are not going to create a relationship with the recipient. Besides, it is important to keep your recipient address list clean, that is, remove an e-mail address that triggers error messages or spam complaints.

Those who don’t follow these simple rules will end up having a low e-mail delivery ratio, will get disappointed with the product, and eventually will no longer use e-mail marketing for thinking that it is ineffective.

Thinking about this, we decided at Locaweb to create the concept of reputation, translated into a percentage that aims to inform the clients how well they are doing while following these good practices. With that, we can educate them regarding the good practices of using e-mail marketing.

Therefore, the feature reputation from Locaweb’s e-mail marketing had:

  • Motivation: to educate clients on good practices of using e-mail marketing so they would reach a higher success rate in their campaigns and, consequently, would not cancel the service;
  • Metrics: the result of this feature is being measured in two ways: amount of deliveries (inbox delivery, opened message ratio, spam complaint ratio) and decrease of cancelling.

OKRs, the future of product roadmaps

Since 2012, we review Locaweb’s product roadmaps every quarter. At the beginning of each quarter, we look back on what was done in the previous quarter, which items were delivered, which weren’t, and what were the reasons for success or failure. Then we plan what to do in the following quarter.

In the middle of 2014, I wrote an article on writing roadmaps including the motivation behind each item in the roadmap and metrics that showed that the motivation was being fulfilled. It was the result of several conversations we had at Locaweb about having the roadmap as a list of items to make every quarter, but not always having clear why we were doing each of those planned items. Since that time we started to make our roadmaps with each item composed of three sub-items: what to do, why it had to be done, and what metric we expected to move when we do that item. However, while we try to make clear the motivation and the metric of each roadmap item, the discussions ended up mainly around the “what to do”.

In the first half of 2015, we heard about a framework called OKR, which means Objectives and Key Results. This framework has been used by Google since its early days and was brought there by John Doerr, an Intel employee, where this framework was created. John Doerr, after leaving Intel, became an investor in technology businesses such as Google, Amazon, Intuit, and Zynga and brought this framework to these companies. Several technology companies today use OKRs. A few more examples are LinkedIn, GoPro, Flipboard, Yahoo!, Amazon, Adobe, Baidu, Dropbox, Facebook, Netflix, and Spotify.

OKR is a framework derived from a management technique called Management by Objectives, a term coined by Peter Drucker in his book The Practice of Management, 1954. Management by Objectives is a process that requires the identification and accurate description of goals to achieve and deadlines for completion and monitoring. This process requires that those involved agree with what you want to achieve and that all of them play their roles for the achievement of the objectives.

How does OKRs work?

There are several articles and videos that explain in detail how OKRs work, so I will make my explanation very brief. OKRs are composed of two parts, a goal (objective) and 2 to 5 key outcomes (key results) indicating that the goal was achieved. For example:

Objective: To have satisfied customers to the point of recommending our services to their friends.

Key Result 1: To maintain 80% of satisfaction survey notes above 8 on a scale from 0 to 10.

Key Result 2: At least 50% of new sales should come from recommendations of existing customers.

The goal does not necessarily need to have numbers. However, key results must always have numbers, i.e., there must be some metric and must say where we are and where we want to be with regards to the metric, that is, the goal we want to achieve with that metric.

It is recommended to have at least two key results. When there is only one key result, we can suffer from what is called the “perverse effect”. For example, suppose the goal is to raise the productivity of the telephone service team. Let’s say we define only one key result, the AHT (average handle time) which is now in 8 minutes and we want it to drop to 2 minutes. One way to achieve this key result is for the attendant to hang up the phone when close to 2 minutes. Of course, this would be bad for the quality of service, but the key result and the goal would be achieved. In this case, to balance the “perverse effect”, another key result is recommended to ensure that customer satisfaction is maintained.

Implementing OKRs at Locaweb

After studying OKR for some time, we realized that it was very similar to what we always wanted to do, focusing more on the motivations and metrics than on the “what to do” itself. The big difference is that in OKRs the “what to do” simply does not exist. It can be discussed when defining each goal and its key results, but “what to do” is not documented and, therefore, it is not committed and can be changed. What matters is the goal and key results that indicate that the goal has been reached.

To help us in this change, we brought Felipe Castro from Lean Performance, a company that specialized in OKR implementation. We brought him in June 2015 and started implementation in the 3rd quarter of 2015 with a series of internal training on OKR, goal setting, metrics, and objectives. In August we made our first training planning session to set OKRs for the month of September. It was a test for us to understand a little better the mechanics of the OKR setting process. In late September we made our first planning session of a full quarter, where we defined the product development and marketing OKRs for the 4th quarter of 2015. In parallel, we continued with the quarterly product planning roadmap based on a list of items to do.

Each team updated their OKRs weekly. Furthermore, we followed the evolution of the roadmap monthly. We have seen throughout these follow-ups that the roadmap items were the tasks that enabled the achievement of the objectives and key results, i.e., there were monitoring tools — OKRs and Roadmaps — for the same job. Throughout these monitoring sessions, we had an epiphany: what if we abandon the traditional roadmap, the list of tasks to do, and focus only on defining and tracking OKRs?

From ToDoers to pointer managers

That’s what we did in the 1st quarter of 2016. The planning was done completely based on goals and metrics that we wanted to move, i.e., the pointers we wanted to manage. We ceased being mere ToDoers, mere executors of tasks, to become pointer managers. Given a goal and a metric that indicates that this objective is being achieved, we decided what to do. In the OKRs review meeting for the 1st quarter of 2016 and planning for the 2nd quarter, no one missed the old roadmap list of tasks to do. Obviously, during the retrospective, each team commented a bit about what they did to move the pointers, but the “what to do” was just a means to achieve a goal, and not the goal itself. And of course, in each OKR planning session, the teams already have a sense of “what they will do” to achieve their goals, but they have the autonomy to decide “what to do” as they please.

OKRs or Roadmaps?

In August 2016, after 11 years leading product development and management at Locaweb, I decided to move to ContaAzul, a SaaS ERP startup at Joinville, a city in the south of Brazil, to help them scale their product development team. When I arrived at ContaAzul, I noticed that they also used OKRs for the entire company, including the product development team. However, besides using OKR, they also used roadmaps and it didn’t seem it would be possible to stop using roadmaps and manage all product development efforts only using OKRs. That made me ponder if OKR can really substitute roadmaps or if there are circumstances where both tools can be used together. And if the latter is true, what are those circumstances.

When discussing this topic with people from the software industry, it became clear to me that the use of a roadmap or OKR depends on the stage of the product in its lifecycle. I discussed the 4 stages of a product lifecycle in the Lifecycle of a software product chapter.

As described in that article, the software product lifecycle has 4 stages:

  • Innovation: from all 4 lifecycle stages of a software product, Innovation is the one that holds the biggest amount of doubts. It is also the stage that holds the biggest number of books. Any book on innovation and startups is helpful when your product is in this stage. The main objective is to create a product that addresses problems and needs of a group of customers. For this reason, during this phase there’s only one Objective, to find product-market fit, and to measure this Objective we can use various Key Results that demonstrate customer engagement and satisfaction. In the Innovation stage we should use neither OKR nor roadmaps. We should use the MVP (Minimum Viable Product) framework of build-measure-learn to reach the Objective of finding product-market fit.
  • Growth: In the growth stage, when the product has been developed and launched, we should worry about how to manage the product during its growth. Since during the innovation phase we built an MVP to reach our Objective of finding product-market fit, our product is quite incomplete, so we should have a roadmap describing which features we will build plus the motivation to build each feature and the metrics that will show us that we are fulfilling the motivation to build each feature, as I described in my article about roadmap. Motivation is another word for Objective and Metrics is the same as Key Results. In the Growth stage we should use Roadmaps together with OKR, since in the Innovation phase we launched an MVP lacking many features that would make the product more complete, and now we need to implement those features.
  • Maturity: After growth, comes maturity. In this phase, our product reached its potential market and consequently doesn’t grow as fast as it grew in the Growth phase. When a product reaches this stage, it has all needed features and there’s no need for a roadmap anymore. In the Maturity stage we should use only OKRs to manage the product development since in this phase we will be optimizing the product to fulfill its Objectives.
  • End of life: After maturity, or when the product is developed but it does not find product-market fit, comes the stage known as the end of life, or sunset, of a software product. In this phase, like in the Maturity phase, a roadmap is not needed since it doesn’t make sense to build any additional features. If your product reached the End of life phase after the Maturity phase, it already has all the features it needs to have. If your product reached the End of life phase right after the Innovation phase because it didn’t find the product-market fit, you should not invest any effort in building any additional features. In the End of life stage we should use only OKRs to manage the product development since in this phase our only Objective is to stop serving the product.

For this reason, it is clear that OKRs substitute Roadmaps in all stages of the product lifecycle except for the Growth stage, where Roadmaps are very helpful to understand where your product is heading, i.e., to understand the future of your product. In the Growth stage, we should use Roadmaps and OKRs in conjunction to manage the product development.

Detailing versus audience

As mentioned at the beginning of this chapter, the roadmap of your software product is your tool to communicate the vision of the future for your product. We know there are different types of targets that will demand different levels of detailing in your roadmap. In which level of detailing should we stand for each type of target?

Detailing versus audience in a roadmap

The picture points out a suggestion of detailing level according to each audience. The first aspect you have to consider is whether the target is internal or external. As previously said, to external targets you will usually talk about features. To internal audiences, your focus will be more on results and metrics than on the feature itself.

The second aspect to consider is the level of detailing you to have to display.

  • General target: in this case, detailing does not have to be high. The ideal is to talk in terms of features and you should disclose the features closer to being delivered.
  • Close clients: for the closest clients, it is possible to show more details, giving a medium-term vision. It is very important to create a good relationship with your close clients. You can guide the vision of your product based on the problems they have, and that your product is willing to solve.
  • Partners: to them it is worth to get into details, especially those who help the product to reach your clients. For instance, the final clients of the Locaweb hosting platform are the companies that host their websites there. However, you have to consider the partners, that is, the developers and agencies that develop these sites. In this case, you should continue to depict the roadmap as a list of features.
  • CEOs, vice-presidents and directors: at this point, we move to internal audience. This target group might be interested in the feature list, but they really want to know the motivation for these functionalities on the roadmap.
  • Sales and marketing: for the sales and marketing teams, it is necessary to get into a little more details. For sales, details are important because they may have already identified the market’s demand, and for marketing the need of more details comes from the publicity work they will do.
  • Product marketing: this group is practically the fourth element of that core team I mentioned in the chapter What is software product management? They must participate very closely of the product’s development, and must know the whole motivation and the metrics of the features in roadmap.
  • Costumer service: this group does not have to know a lot about the motivation of the features as many of the internal groups, but it is the one that needs to know more details of these future features, for it communicates with their clients on a daily basis.
  • Engineering and UX: they are part of the product’s core team. They need all the details, motivations and metrics in order to do their job.

Roadmap or backlog?

A question that I frequently hear is: what is the difference between roadmap and backlog? The roadmap is your map or guide, that is, the things you have to do; backlog is the term used in agile methodologies for your “record of things to do”. So, these terms are equivalent and can be used interchangeably.

In the next chapter, we’ll approach roadmap prioritizing techniques.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

You can also acquire the books individually, by clicking on their titles above.

Mentoring and advice on digital product development

I’ve been helping several companies extract more value and results from their digital products. Check here how I can help you and your company.

Crescimento: O que é roadmap e OKR?

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:

Exemplo de roadmap de software
Outro exemplo de roadmap de software
Roadmap do Windows Server

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.

Exemplo de um roadmap contínuo de 12 meses

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.

Cone da incerteza

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?:

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?

Detalhamento vs. audiência de um roadmap

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:

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.