Product management in a crisis

There are several types of crisis. It can be a crisis in the company, a crisis in the economy, or a crisis in health, like the COVID-19 crisis. Crises shake the company, its customers, and the products the company offers to its customers. In this chapter, we will see the role of the product manager in a crisis.

COVID-19 crisis

In 2020 we faced the COVID-19 crisis. Another crisis like many others, but this one with a huge impact on people’s daily lives. To help remember, here’s Wikipedia’s list of economic crises and a list of health crises, including the Spanish Flu that happened more than 100 years ago with 500 million people infected – about a quarter of the world’s population at the time.

Crises have a big impact on business. In a crisis, people and companies spend less, demand for certain types of products and services plummets, and, depending on the crisis, some companies may even have to cease operations altogether.

That’s what’s happening now, people have to stay at their homes due to social distancing and many businesses need to stop or change the way they operate. Some can’t remain open like barbershops, gyms, dance houses, and others that require close contact, while others can operate only by delivery, like markets and restaurants.

Product management in a crisis

Product management “is the function responsible for making the connection between the company strategy and the problems and needs of clients using the digital product. It must be, at the same time, helping the company to accomplish its strategic goals, and solving the problems and needs of clients.”

In a crisis, what is the company strategy? What are its strategic goals? First thing is to preserve cash. As people say, “cash is king”. Good times or bad times, a company needs cash to pay wages to workers for the labor, pay suppliers for the supply and pay its tax debts.

In order to continue to receive more cash, the company needs to be solving a problem or addressing a need of its clients. In a crisis, the client’s problems and needs will probably change considerably. The company needs to identify and adapt to these changes as fast as possible.

When the COVID-19 crisis hit the market, companies started to look into these two perspectives:

  • preserve cash;
  • identify and adapt to changes in customer problems and needs.

For the first measure, to preserve cash, all the usual suspects apply to many companies. Preserve or even advance revenue streams while looking into all costs with a magnifying glass.

On the revenue side, some companies, like travel agencies, offered to exchange existing travel bookings for future bookings with an increased value. For instance, if you have a trip scheduled for March or April, some companies are offering that you can rebook it late for the same amount, or even for a bigger amount, say 120% of the amount you paid. Some companies are offering special discounts if you pay in advance, like a barbershop that are offering discounted prices if you book a dye hair session for July.

On the cost side, some companies are realizing some costs while keeping their offices closed, but that may not be enough. Unfortunately, that may not be enough and some companies may have to lay off part of their employees. Very sad situation but many times it’s unavailable.

The role of the product manager

The interesting side comes when the company focuses on identifying and adapting to changes in customer problems and needs. That’s the main role of the product manager.

With COVID-19, customer problems and needs changed really fast, and the product manager and the entire product development team (product managers, UX, and engineers) have to be even faster in order to adapt the product to these new needs.

I heard about an interesting offline example. A pizza house added to its product portfolio a new type of pizza, the do-it-yourself pizza. They send the pizza disk pre-baked plus the sauce and all ingredients separately to your home, so you enjoy the pleasure of building and baking the pizza yourself.

Street stores had to adapt themselves to e-commerce way faster than they were planning since now all buyers are at home and don’t visit stores.

Schools and art event coordinators now are adapting to e-learning and event live streaming.

Real-life example

Here at Gympass we have 3 different customers and all of them are deeply impacted by COVID-19:

  • gyms in many cities were closed to help in physical distancing measures applied in many cities to avoid the spread of COVID-19 and consequently are losing recurring revenues from users who are not visiting the gym;
  • users, the employees of our clients, cannot go to gyms anymore and have to stay at home, but also have to somehow stay active, but their first reaction is to cancel or pause their Gympass membership since they won’t have access to gyms for a while;
  • corporate clients, whose employees are at home and don’t go anymore to gyms, while HRs are concerned about how to keep these employees engaged and productive.

So all 3 of our customers, gyms, user and corporate clients, had huge changes in their problems and needs and we had to be very fast to adapt to those changes.

At the end of 2019, after some product discovery work, we decided to explore the idea of offering our users wellness services beyond access to gyms and studios.

Our first challenge was to find partners who were willing to test this new concept with us. We were able to partner with NEOU, 8fit, tech.fit, and Zen App. Thank you, partners! \o/

We built a pilot to be launched in early March to a very limited audience to test real user interest in this offer. The pilot was a very simple order form, where we presented the value proposition of Gympass Wellness, the name we gave to this new service, and a place for the user to register and put their credit card info.

We had just launched the pilot internally (eat your dog food!) when the COVID-19 crisis arrived. We were able to adapt in record time our pilot to be offered to our entire user base so they can not only remain active but also take care of their nutrition and their minds during these very challenging times.

With Gympass Wellness we were able to address both users’ and our corporate clients’ changing problems and needs during the crisis.

What about the gyms? By being closed, they are losing revenue. Their customers are not visiting them anymore so the regular gym users are prone to cancel their subscription while those who used to visit gyms using Gympass won’t visit the gym during the crisis which will cause a loss of revenue for the gyms as well. To help our partner gyms we decided and implemented in record time 2 solutions:

  • Provide gyms a white label app they could offer to all their members so they can deliver value to their clients helping them stay active while at home;
  • Provide a platform for gyms to schedule and stream live classes to all Gympass users so they can keep their instructors employed while providing Gympass users with exclusive content.

As I mentioned, all these solutions were implemented in record time, which was needed to provide solutions as fast as possible.

Perfect is the enemy of good

As mentioned earlier, when a crisis hit the market, companies need to look into these two perspectives:

  • preserve cash;
  • identify and adapt to changes in customer problems and needs.

Even though product managers and product development teams have an important role in the former, their main role is in the latter.

In order to identify and adapt to these changes in customer problems and needs, the product development team needs to change its behavior with the rule in mind that “perfect is the enemy of good”. In all moments of product development, this rule is valid. The most important thing is to have your product in front of real users in their own context so the product development team can deliver value to their users as fast as possible and can learn from real users using their product.

However, in a crisis, this rule is even more critical and key. We need to deliver solutions to our users’ changing problems super fast. It doesn’t matter if we didn’t do the best discovery process, that the solution is a very simple web form that we will have tons of manual work afterward, or that the solution will generate many technical debts. The main thing is that we are able to deliver a solution to the new problems and needs that our users are facing in a crisis.

That’s the role of the product manager and the product development team in a crisis.

Product leadership advisor

I’ve been helping several product leaders (CPOs, heads of product, CTOs, CEOs, tech founders, and heads of digital transformation) extract more value and results from their digital products. Check here how I can help you and your company.

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.

Como Gerenciar Produtos Durante Crises

Existem vários tipos de crise. Pode ser uma crise na empresa, uma crise na economia, como a que estamos vivendo agora, ou uma crise na saúde, como a crise do COVID-19. As crises abalam a empresa, seus clientes e os produtos que empresa oferece para seus clientes. Vamos ver nesse capítulo qual o papel do gestor de produtos em uma crise.

Crise COVID-19

Em 2020 enfrentamos a crise do COVID-19, com um enorme impacto no dia a dia das pessoas. Para lembrar, aqui está a lista de crises econômicas da Wikipedia (https://en.wikipedia.org/wiki/List_of_economic_crises) e uma lista de crises na saúde (https://en.wikipedia.org/wiki/Health_crisis), incluindo a gripe espanhola que aconteceu há mais de 100 anos com 500 milhões de pessoas infectadas – cerca de um quarto da população mundial na época.

As crises têm um grande impacto nos negócios. Em uma crise, as pessoas e as empresas gastam menos, a demanda por certos tipos de produtos e serviços despenca e, dependendo da crise, algumas empresas podem até precisar interromper suas operações por completo.

É isso que aconteceu durante a crise do COVID-19, as pessoas precisaram ficar em suas casas devido ao distanciamento social e muitas empresas precisaram parar ou mudar a maneira como operam. Algumas não podem permanecer abertas, como barbearias, academias, casas de dança e outros que exigem contato próximo, enquanto outros poderam operar apenas por entrega, como mercados e restaurantes.

Gerenciamento de Produtos em uma Crise

No capítulo O que é gestão de produtos de software? expliquei que o gerenciamento de produtos “é a função responsável por fazer a conexão entre a estratégia da empresa e os problemas e necessidades dos clientes que usam o produto digital. Este deve, ao mesmo tempo, ajudar a empresa a atingir seus objetivos estratégicos, e solucionar os problemas e as necessidades dos clientes.”

Em uma crise, qual é a estratégia da empresa? Quais são seus objetivos estratégicos? A primeira coisa é economizar dinheiro. Como as pessoas dizem, “o caixa é rei”. Bons ou maus momentos, uma empresa precisa de dinheiro para pagar salários aos trabalhadores pelo trabalho, pagar fornecedores pelo suprimento e pagar suas dívidas fiscais.

Para continuar recebendo mais dinheiro, a empresa precisa resolver um problema ou atender às necessidades de seus clientes. Em uma crise, os problemas e necessidades do cliente provavelmente mudarão consideravelmente. A empresa precisa identificar e se adaptar a essas mudanças o mais rápido possível.

Quando a crise do COVID-19 chegou ao mercado, as empresas começaram a analisar essas duas perspectivas:

  • preservar o caixa;
  • identificar e adaptar-se às mudanças nos problemas e necessidades dos clientes.

Para a primeira medida, para economizar dinheiro, todos os suspeitos comuns se aplicam a muitas empresas. Preserve ou até avance os fluxos de receita enquanto analisa todos os custos com uma lupa.

No lado da receita, algumas empresas, como agências de viagens, ofereceram a troca de reservas de viagens existentes por reservas futuras com um valor maior. Por exemplo, se você tem uma viagem agendada para março ou abril, algumas empresas estão oferecendo que você pode agendá-la com atraso pelo mesmo valor, ou mesmo por um valor maior, digamos 120% do valor pago. Algumas empresas oferecem descontos especiais se você pagar antecipadamente, como uma barbearia que oferece preços com desconto se você reservar uma sessão de tintura de cabelo para julho.

No lado dos custos, algumas empresas podem ter algumas economias enquanto mantêm os escritórios fechados, mas isso pode não ser suficiente e algumas empresas podem ter que demitir parte de seus funcionários. Situação muito triste, mas muitas vezes inevitável.

O Papel do Gerente de Produto

O lado interessante vem quando a empresa se concentra na identificação e adaptação às mudanças nos problemas e necessidades dos clientes. Essa é a principal função do gerente de produto.

Com o COVID-19, os problemas e as necessidades dos clientes mudaram muito rapidamente, e o gerente de produtos e toda a equipe de desenvolvimento de produtos (gerentes de produto, engenheiros de produção e engenheiros) precisam ser ainda mais rápidos para adaptar o produto a essas novas necessidades.

Durante a pandemia ouvi sobre um exemplo offline interessante. Uma pizzaria adicionou ao seu portfólio de produtos um novo tipo de pizza, a pizza faça você mesmo. Eles enviam o disco da pizza pré-cozido, além do molho e todos os ingredientes separadamente para sua casa, para que você desfrute do prazer de construir e assar a pizza sozinho.

As lojas de rua estão tendo que se adaptar ao comércio eletrônico muito mais rápido do que planejavam, pois agora todos os compradores estão em casa e não visitam as lojas. Escolas e coordenadores de eventos de arte agora estão se adaptando ao e- learning e à transmissão ao vivo de eventos.

Exemplo da Vida Real

No Gympass são 3 clientes diferentes e todos profundamente impactados pelo COVID-19:

  • academias de ginástica em muitas cidades foram fechadas para ajudar nas medidas de distanciamento físico aplicadas em muitas cidades para evitar a disseminação do COVID- 19 e, consequentemente, estão perdendo receitas recorrentes de usuários que não visitam a academia;
  • os usuários, funcionários de nossos clientes, não podem mais frequentar academias e precisam ficar em casa, mas também precisam permanecer ativos, mas a primeira reação é cancelar ou pausar a associação ao Gympass, pois não terão acesso a academias por um tempo;
  • clientes corporativos, cujos funcionários estão em casa e não frequentam mais academias, enquanto os RHs preocupam-se em como manter esses funcionários engajados e produtivos.

Portanto, todos os três de nossos clientes, academias, usuários e clientes corporativos, tiveram grandes mudanças em seus problemas e necessidades e tivemos que ser muito rápidos para nos adaptarmos a essas mudanças.

No final de 2019, depois de algum trabalho de descoberta de produto, decidimos explorar a ideia de oferecer aos nossos usuários serviços de bem-estar além do acesso a academias e estúdios.

Nosso primeiro desafio foi encontrar parceiros dispostos a testar esse novo conceito conosco. Conseguimos parceria com NEOU, 8fit, tech.fit e Zen App. Obrigado, parceiros! Criamos um piloto a ser lançado no início de março para um público muito limitado para testar o interesse real do usuário nessa oferta. O piloto era um formulário de pedido muito simples, onde apresentamos a proposta de valor do Gympass Wellness, o nome que atribuímos a esse novo serviço e um local para o usuário se registrar e colocar suas informações de cartão de crédito.

Tínhamos acabado de lançar o piloto internamente (eat our own dog food!) Quando a crise do COVID-19 chegou. Conseguimos adaptar em tempo recorde nosso piloto para ser oferecido a toda a nossa base de usuários, para que eles não apenas permaneçam ativos, mas também cuidem de sua nutrição e mente durante esses momentos muito difíceis. Com o Gympass Wellness, conseguimos abordar os problemas e as necessidades dos usuários e de nossos clientes corporativos durante a crise.

E as academias? Ao serem fechados, eles estão perdendo receita. Seus clientes não os visitam mais, portanto os usuários regulares de academias tendem a cancelar sua assinatura, enquanto aqueles que costumavam visitar academias usando Gympass não visitam a academia durante a crise, o que causará uma perda de receita para as academias também. Para ajudar nossos ginásios parceiros, decidimos e implementamos em tempo recorde 2 soluções:

  • Fornecer às academias um app white-label para eles colocarem sua marca e que pudessem oferecer a todos os seus clientes, ajudando-os a permanecerem ativos em casa;
  • Fornecer uma plataforma para as academias agendarem e transmitirem aulas ao vivo para todos os usuários do Gympass, para que eles possam manter seus instrutores empregados enquanto fornecem aos usuários do Gympass conteúdo exclusivo.

Como mencionei, todas essas soluções foram implementadas em tempo recorde, o que era necessário para fornecer soluções o mais rápido possível.

Perfeito é Inimigo do Bom

Como mencionado anteriormente, quando uma crise atinge o mercado, as empresas precisam olhar para essas duas perspectivas:

  • preservar caixa;
  • identificar e adaptar-se às mudanças nos problemas e necessidades dos clientes.

Embora os gerentes de produto e as equipes de desenvolvimento de produtos tenham um papel importante no primeiro, o principal deles é no segundo.

Para identificar e se adaptar a essas mudanças nos problemas e necessidades dos clientes, a equipe de desenvolvimento de produtos precisa mudar seu comportamento com a regra em mente de que “perfeito é inimigo do bem”. Em todos os momentos do desenvolvimento do produto, essa regra é válida. O mais importante é ter seu produto na frente de usuários reais em seu próprio contexto, para que a equipe de desenvolvimento do produto possa entregar valor a seus usuários o mais rápido possível e aprender com usuários reais usando seu produto.

No entanto, em uma crise, essa regra é ainda mais crítica e fundamental. Precisamos fornecer soluções para os problemas de mudança de nossos usuários super-rápido. Não importa se não fizemos o melhor processo de descoberta, ou se a solução é um formulário da Web muito simples, teremos toneladas de trabalho manual posteriormente ou se a solução gerará muitas dívidas técnicas. O principal é que somos capazes de fornecer uma solução para os novos problemas e necessidades que nossos usuários enfrentam em uma crise.

Esse é o papel do gerente de produto e da equipe de desenvolvimento de produto em uma crise.

Mentoria de líderes de produto

Tenho ajudado líderes de produto (CPOs, heads de produtos, CTOs, CEOs, tech founders, heads de transformação digital) a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.

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:

Putting it all together – vision, strategy, roadmap and OKRs

In the previous chapter about the growth phase of the product lifecycle, I described a set of 4 tools that will be of great support for your digital product management work when used together:

  • Vision: is the reason why the product exists. It’s what guides all decisions regarding the product. It gives the context for the product development team to make decisions about what to prioritize.
  • Strategy: is the detailing of the steps you will take to get your product closer to the vision. Both product vision and strategy are long-term tools, i.e., help you set, communicate and align the direction of your product for the next 2 or more years.
  • Roadmap: enables you and your team to plan and communicate the view of the future that you have for your product for the next 12 months. It is important to have 12-month roadmaps in order to give additional details of what’s coming. You’ll probably be able to provide more details of the next 3 to 6 months, but that’s okay. The purpose of the 12-month planning is to give a chance to check if things left to be done later should be brought to be done earlier and to give some sense about when to discuss what is not being discussed for the next quarter.
  • OKR: objectives and key results, or motivation and metrics, i.e., what do we want to accomplish and how we will know that we accomplished it? OKRs are composed of two parts, a goal (objective) and 2 to 5 key outcomes (key results) indicating that the goal was achieved. OKRs are normally short-term, during a quarter. It is possible to have 12 or 6-month OKRs, but since you already have the 12-month roadmap as a mid-term tool, it’s better to use OKR with a quarterly frequency. For some time I advocated replacing roadmaps, but now it’s clear that these two tools together yield better results. OKRs provide short-term planning and alignment. Roadmaps provide mid-term planning and alignment.

Putting it all together in one image, here are the product management 4 tools:

Putting it all together

Final thoughts

With this chapter, we concluded the growth phase of the software product lifecycle. We understand how to handle customer feedback, what it is, and how to prioritize a roadmap. We also looked at the most varied types of metrics, including conversion funnel, engagement, churn, global and individual financial metrics, revenue and negative churn, NPS, loyalty metrics, and some considerations about metrics. We saw what it is and how to build the product vision and strategy, useful tools for making decisions about what will be the future of your product and how to get there. And in this chapter, we saw how these 4 tools (vision, strategy, roadmap, and OKR) work together to help us manage our product with long, mid, and short-term views.

Product leadership advisor

I’ve been helping several product leaders (CPOs, heads of product, CTOs, CEOs, tech founders, and heads of digital transformation) extract more value and results from their digital products. Check here how I can help you and your company.

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.

Juntando Tudo – Visão, Estratégia, Roadmap e OKRs

No capítulo anterior, sobre a fase de crescimento do ciclo de vida do produto, descrevi um conjunto de 4 ferramentas que serão de grande ajuda para o trabalho de gestão de produtos de software quando usadas em conjunto:

  • Visão: é a razão pela qual o produto existe. É o que guia todas as decisões sobre o produto. Ela fornece o contexto para a equipe de desenvolvimento de produtos tomar decisões sobre o que priorizar.
  • Estratégia: é o detalhamento das etapas a serem seguidas para aproximar seu produto da visão. A visão e a estratégia do produto são ferramentas de longo prazo, ou seja, ajudam a definir, comunicar e alinhar o caminho do seu produto pelos próximos 2 ou mais anos.
  • Roadmap: permite que você e sua equipe planejem e comuniquem a visão do futuro que você tem para o seu produto pelos próximos 12 meses. É importante ter roadmaps de 12 meses para fornecer detalhes adicionais do que está por vir. Você provavelmente poderá fornecer maiores detalhes dos próximos 3 a 6 meses, mas tudo bem. O objetivo do planejamento de 12 meses é ter a chance de verificar se as coisas a serem feitas posteriormente devem ser feitas mais cedo, e dar algum sentido sobre quando discutir o que não está sendo discutido para o próximo trimestre.
  • OKR: objetivos e principais resultados, ou motivação e métricas, ou seja, o que queremos alcançar e como saberemos que conseguimos? Os OKRs são compostos por duas partes, uma meta (objetivo) e 2 a 5 desfechos (principais resultados), indicando que o objetivo foi alcançado. Os OKRs são normalmente de curto prazo, ao longo de um trimestre. É possível ter
    OKRs de 12 ou 6 meses, mas como você já tem o roadmap de 12 meses como ferramenta de médio prazo, é melhor usar o OKR com uma frequência trimestral. Por algum tempo eu defendi a substituição de roadmaps, mas agora ficou claro que essas duas ferramentas juntas produzem melhores resultados. OKRs que fornecem planejamento e alinhamento a curto prazo. Roadmaps que fornecem planejamento e alinhamento a médio prazo.

Juntando tudo em uma imagem, aqui estão as 4 ferramentas de gestão de produtos:

Juntando tudo

Pensamentos Finais

Com este capítulo, concluímos a fase de crescimento do ciclo de vida de um produto de software. Entendemos como lidar com o feedback do cliente, o que é e como priorizar um roadmap. Também analisamos os mais variados tipos de métricas, incluindo funil de conversão, engajamento, churn, métricas financeiras globais e individuais, receita e churn negativo, NPS, métricas de lealdade, algumas considerações sobre métricas. Vimos o que é e como construir a visão e a estratégia do produto, ferramentas úteis para tomar decisões sobre o que será o futuro do seu produto e como chegar lá. E neste capítulo, vimos como essas quatro ferramentas (visão, estratégia, roadmap, e OKR) funcionam juntas para nos ajudar a gerir nosso produto com visões de longo, médio e curto prazo.

Mentoria de líderes de produto

Tenho ajudado líderes de produto (CPOs, heads de produtos, CTOs, CEOs, tech founders, heads de transformação digital) a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.

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:

Delivery date is another source of conflict between business and tech

In the same that discovery seems to be a source of conflict between business people and product development teams, as I explained in the article Why business people hate discovery, the term delivery date also seems to generate some conflicts. On one side, business people are constantly asking for a delivery date for a product or a feature. On the other side, the product development team has many difficulties setting a delivery date due to many reasons. Let’s better understand both sides:

Why we need a delivery date

There are a number of reasons that makes having a defined delivery date important:

  • Some events don’t change and if the product or feature we are working on is supposed to be used prior to this event, it is very important it is up and running by then. For instance, if we are working on some new features that will improve user e-commerce shopping experience, it is important that it is available a few weeks prior to the Christmas shopping season and, ideally, prior to Black Friday shopping season.
  • There are some regulatory dates that also don’t change. Some examples are IRS tax filing deadline, new invoice layout determined by the government, etc.
  • Company events. For instance, suppose your company has an annual conference for its customers every October which is a perfect date for announcing new releases and new features. Ideally, the product development team should work to deliver the product or feature prior to this date.
  • Marketing campaigns also have set dates to start. If this is a campaign to announce a product or a feature, we definitely need this product or feature ready prior to the campaign launch date.

Certainly there are more reasons why a product or a feature needs to be delivered by a certain date. In all of these cases above it is clear that there are fixed dates that can not be changed and we need to figure out a way to deliver something prior to the fixed date.

Why it is so difficult to set a delivery date

The same way as there are a number of reasons that makes having a defined delivery date important, there are also many reasons why it’s difficult to set a delivery date:

  • The product development team is new or has new members so the product development capacity is still unclear. The team needs to work together for some time in order to better understand its pace. It’s the Tuckman’s stages of team evolution that I mentioned in the article on team structure. And there can be changes in the team also, like people leaving to join other teams or people changing functions. This can also impact the ability to set a delivery date, since the team does not know its product development capacity, and this capacity will change over time as people on the team get know each other and how to work together.
  • The bigger the product or feature to be delivered, the more difficult it is to estimate a delivery date. The team may be able to break down the feature or product into many small chunks that can be easier to estimate a delivery date, which could be a few days or weeks. The smaller the thing that needs to be developed, the easier it is to be more accurate in estimating its delivery date. The issue here is that by breaking down the product or feature into smaller chunks we can better predict what’s closer to be delivered, but things that are more distant are harder to predict a delivery date.
  • Changes of scope are another source of delay and uncertainty on delivery dates. If the scope is increased or, even worse, unrelated work get higher priority, the original delivery will need to be changed.
  • Technical debt can be another source of delays, specially if its unknown or undocumented technical debt. When we encounter a technical debt that prevent us to deliver a feature or a product, we may need to spend extra time to fix that specific technical debt, which will certainly generate delays in the delivery date.

The examples above make it clear that there are a number of factors that can negatively impact the delivery date of a product or feature. Again, this is not an exhaustive list. I’m pretty sure you can list more reasons that impact our capacity to set delivery dates.

There’s a very good article from the team at Apptio with a diagram that maps many things that impact positively (green, like focused work), negatively (red, like multi-tasking) or positively to some extent (yellow, like technical debt).

What impacts development speed? Source: Apptio Blog

Product development speed is a complex matter, that’s why it’s so difficult to estimate delivery dates.

So, what should we do?

On one side, business people are constantly asking for a delivery date for a product or a feature and there are very good reasons to need a delivery date defined. On the other side, the product development is a very complex matter and the team has many reasons why setting a delivery date is so difficult. So what should we do?

The first step is to understand that business people and product development team are parts of the same team and, as such, must have the same objectives, achieving the company goals while solving a problem for its users. For this reason, they should work together to achieve these objetctives.

The second step is to understand that behind every product or feature there’s a result expectation. So, when we discuss about a product or feature delivery date, we are actually thinking about when we will benefit from the expected results that this product or feature is set to generate.

The thing is that more often than not we end up talking so much about the new product or feature and its delivery date that the expected result becomes less discussed and, consequently, forgotten.

I already mentioned that product and features are means to an end, and not the final objective. They are vehicles to achieve the goal of delivering value, and results, for customers and for the company.

So, instead of discussing about product and feature delivery dates, we should be discussing about results delivery dates and how we can get to these results by this date. Sometimes there’s a simpler product or feature to be built that will enable us to achieve that result faster. Sometimes there’s no need to build a product or feature, but a change in a process can yield the expected results.

Looking through the results delivery date perspective, there are two possible situations:

1) if there is any fixed date (Christmas, Black Friday, company event, regulatory date, etc.), the date is already given. And the expected result too. Christmas, Black Friday the expected result is more sales. Company event, normally the expected result is engagement, cross-sell and/or upsell. regulatory date, the expected result is compliance. With this information in hand, we should ask ourselves what can we deliver before the given date to achieve the expected result?

2) if it’s something new, with no specific date, again the conversation revolves around the expected result. What result is expected of this something new? Is there any expected date for us to obtain this expected result? Or the sooner the better? With the answers to these questions above in hand, we should ask ourselves what can we do to achieve this result in this period?

Summing up

  • Delivery date is another source of conflict between business people and the product development team. On one side, business people are constantly asking for a delivery date for a product or a feature and there are very good reasons to need a delivery date defined. On the other side, the product development is a very complex matter and the team has many reasons why setting a delivery date is so difficult.
  • To address this conflict, the first step is to understand that business people and product development team are parts of the same team and, as such, must have the same objectives, achieving the company goals while solving a problem for its users. For this reason, they should work together to achieve these objetctives.
  • The second step is to understand that behind every product or feature there’s a result expectation. So, when we discuss about a product or feature delivery date, we are actually thinking about when we will benefit from the expected results that this product or feature is set to generate.

Product development advisor

I’ve been helping several product leaders (CPOs, heads of product, CTOs, CEOs, and tech founders) extract more value and results from their digital products. Check here how I can help you and your company.

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.

Data de entrega é outra fonte de conflito entre negócios e tecnologia

Assim como discovery parece ser uma fonte de conflito entre os pessoas de negócios e as equipes de desenvolvimento de produtos, como expliquei no artigo Porque as pessoas de negócios odeiam discovery, o termo data de entrega também parece gerar alguns conflitos. Por um lado, as pessoas de negócios estão constantemente pedindo uma data de entrega para um produto ou uma funcionalidade. Por outro lado, a equipe de desenvolvimento de produtos tem muitas dificuldades em definir uma data de entrega por vários motivos. Vamos entender melhor os dois lados:

Por que precisamos de uma data de entrega

Há uma série de razões para a necessidade de ter uma data de entrega definida:

  • Alguns eventos não mudam e se o produto ou funcionalidade em que estamos trabalhando deve ser usado antes deste evento, é muito importante que esteja funcionando antes do evento. Por exemplo, se estivermos trabalhando em algumas novas funcionalidades que melhorarão a experiência de compra do usuário no comércio eletrônico, é importante que essas funcionalidades estejam disponíveis algumas semanas antes da época de compras de Natal e, idealmente, antes da época de compras da Black Friday.
  • Existem algumas datas regulatórias que também não mudam. Alguns exemplos são o prazo de declaração do imposto de renda, o novo layout de Nota Fiscal definido pelo governo, etc.
  • Eventos da empresa. Por exemplo, suponha que sua empresa tenha uma conferência anual para seus clientes todo mês de outubro, uma data perfeita para anunciar novos lançamentos e novos funcionalidades. Idealmente, a equipe de desenvolvimento do produto deve trabalhar para entregar o produto ou recurso antes dessa data.
  • As campanhas de marketing também têm datas definidas para começar. Se esta for uma campanha para anunciar um produto ou funcionalidade, definitivamente precisamos desse produto ou funcionalidade pronto antes da data de lançamento da campanha.

Certamente há mais razões pelas quais um produto ou funcionalidade precisa ser entregue em uma determinada data. Em todos esses casos acima fica claro que existem datas fixas que não podem ser alteradas e precisamos descobrir uma forma de entregar algo antes dessa data fixa.

Por que é tão difícil definir uma data de entrega

Da mesma forma que existem vários motivos que tornam importante ter uma data de entrega definida, também existem muitas razões pelas quais é difícil definir uma data de entrega:

  • A equipe de desenvolvimento de produto é nova ou tem novos membros, então a capacidade de desenvolvimento de produtos ainda não está clara. A equipe precisa trabalhar em conjunto por algum tempo para entender melhor seu ritmo. São os estágios de evolução de time do Tuckman que mencionei no artigo sobre estrutura de time. E também pode haver mudanças na equipe, como pessoas saindo para se juntar a outras equipes ou pessoas mudando de função. Isso também pode afetar a capacidade de definir uma data de entrega, uma vez que a equipe não conhece sua capacidade de desenvolvimento de produtos, e essa capacidade mudará com o tempo à medida que as pessoas da equipe se conhecem e conhecem como trabalhar juntas.
  • Quanto maior o produto ou funcionalidade a ser entregue, mais difícil é estimar uma data de entrega. A equipe pode ser capaz de dividir a funcionalidade ou produto em vários pequenos pedaços o que pode facilitar a estimativa de data de entrega, que pode ser de alguns dias ou semanas. Quanto menor for o que precisa ser desenvolvido, mais fácil será de conseguir maior precisão na estimativa de sua data de entrega. A questão aqui é que, ao dividir o produto ou funcionalidade em pedaços menores, podemos prever melhor o que está mais próximo de ser entregue, mas as coisas que estão mais distantes são mais difíceis de prever uma data de entrega.
  • Mudanças de escopo são outra fonte de atraso e incerteza nas datas de entrega. Se o escopo for aumentado ou, pior ainda, trabalhos não relacionados receberem maior prioridade, a entrega original precisará ser alterada.
  • A dívida técnica pode ser outra fonte de atrasos, especialmente se for uma dívida técnica desconhecida ou não documentada. Quando nos deparamos com uma dívida técnica que nos impeça de entregar uma funcionalidade ou um produto, talvez precisemos gastar um tempo extra para corrigir essa dívida técnica específica, o que certamente gerará atrasos na data de entrega.

Os exemplos acima deixam claro que há uma série de fatores que podem impactar negativamente a data de entrega de um produto ou funcionalidade. Novamente, esta não é uma lista exaustiva. Tenho certeza de que você pode listar mais motivos que afetam nossa capacidade de definir datas de entrega.

Há um artigo muito bom da equipe da Apptio com um diagrama que mapeia muitas coisas que impactam positivamente (verde, como trabalho focado), negativamente (vermelho, como multitarefa) ou positivamente até certo ponto (amarelo, como dívida técnica).

O que afeta a velocidade de desenvolvimento? Fonte: Apptio Blog

A velocidade de desenvolvimento de produtos é um assunto complexo, por isso é tão difícil estimar datas de entrega.

Então o que deveríamos fazer?

Por um lado, as pessoas de negócio estão constantemente pedindo uma data de entrega para um produto ou uma funcionalidade e há boas razões para precisar de uma data de entrega definida. Por outro lado, desenvolvimento do produto é um assunto muito complexo e a equipe tem muitas razões pelas quais definir uma data de entrega é tão difícil. Então o que deveríamos fazer?

O primeiro passo é entender que pessoas de negócios e equipe de desenvolvimento de produtos fazem parte de uma mesma equipe e, como tal, devem ter os mesmos objetivos, focando sempre em atingir os objetivos da empresa e resolvendo um problema para seus usuários. Por esta razão, eles devem trabalhar juntos para alcançar esses objetivos.

O segundo passo é entender que por trás de cada produto ou recurso existe uma expectativa de resultado. Então, quando discutimos sobre a data de entrega de um produto ou funcionalidade, estamos realmente pensando em quando nos beneficiaremos dos resultados esperados que esse produto ou funcionalidade poderá gerar.

O fato é que na maioria das vezes acabamos falando tanto sobre o novo produto ou funcionalidade e sua data de entrega que o resultado esperado passa a ser menos discutido e, consequentemente, acaba sendo esquecido.

Já mencionei que produto e funcionalidades são meios para um fim, e não o objetivo final. São veículos para atingir o objetivo de entregar valor e resultados para os clientes e para a empresa.

Então, em vez de discutir sobre datas de entrega de produtos e funcionalidades, deveríamos discutir sobre datas de entrega de resultados e como podemos chegar a esses resultados até essa data. Às vezes, há um produto ou funcionalidade mais simples de ser construído que nos permitirá alcançar esse resultado mais rapidamente. Às vezes, pode não haver necessidade de construir um produto ou funcionalidade, mas uma mudança em um processo pode gerar os resultados esperados.

Olhando pela perspectiva de data de entrega de resultados, existem duas situações possíveis:

1) se houver alguma data fixa (Natal, Black Friday, evento da empresa, data regulatória, etc.), a data já está dada. E o resultado esperado também. Natal, Black Friday o resultado esperado é mais vendas. Evento da empresa, normalmente o resultado esperado é engajamento, cross sell e/ou up sell. Data regulatória, o resultado esperado é compliance. Com essas informações em mãos devemos nos perguntar o que conseguimos entregar antes da data dada para atingir o resultado esperado?

2) se for algo novo, sem nenhuma data específica, de novo a conversa gira em torno do resultado esperado. Que resultado se espera desse algo novo? Existe alguma expectativa de data para obtermos esse resultado esperado? Ou quanto antes melhor? Com as respostas a essas perguntas acima em mãos devemos nos perguntar o que podemos fazer para atingir esse resultado nesse prazo?

Resumindo

  • A data de entrega é outra fonte de conflito entre os empresários e a equipe de desenvolvimento do produto. Por um lado, os empresários estão constantemente pedindo uma data de entrega para um produto ou um funcionalidade e há boas razões para precisar de uma data de entrega definida. Por outro lado, o desenvolvimento do produto é um assunto muito complexo e a equipe tem muitas razões pelas quais definir uma data de entrega é tão difícil.
  • Para lidar com esse conflito, o primeiro passo é entender que pessoas de negócios e equipe de desenvolvimento de produtos fazem parte de uma mesma equipe e, como tal, devem ter os mesmos objetivos, focando em atingir os objetivos da empresa e resolvendo um problema para seus usuários. Por esta razão, eles devem trabalhar juntos para alcançar esses objetivos.
  • O segundo passo é entender que por trás de cada produto ou recurso existe uma expectativa de resultado. Então, quando discutimos sobre a data de entrega de um produto ou recurso, estamos realmente pensando em quando nos beneficiaremos dos resultados esperados que esse produto ou recurso está definido para gerar.

Coaching em liderança de produtos digitais

Tenho ajudado várias pessoas líderes de produto (heads de produto, tech founders, heads de engenharia) e suas empresas a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.

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:

What is and how to create the product vision and strategy?

At some point during the growth phase of your product, it may be helpful to create its vision and strategy. These tools will greatly help you in the decisions about what the future of your product will be. For this reason, I will explain in this chapter what is product vision and strategy and how to create them.

What is a product vision and why do we need it?

The same way your kids wants to be something (doctors, lawyers, engineers, etc.) when they grow up, the product vision is what you want your product to be when it grows up. Product vision is how you envision your product in the future. It is the reason why the product exists. It is what should guide all decisions regarding this product. It gives the context for the product development team to make decisions about what to prioritize in relation to the product.

As I mentioned earlier when defining product management as the function responsible for building the connection between the company’s strategic goals and the problems and needs of clients, a product must at the same time meet the strategic objectives that the product owner has for this product while it solves problems and needs of its users. There you have the two elements needed to make your product vision.

Creating the Product Vision

The vision of the product will be created by bringing together these two elements, understanding the objectives of the product owner and the problems and needs of the user of the product. So the first step in creating your product vision is to be clear about what the product owner’s goals are.

For example, a bank creating an internet banking system may have the objective to reduce the need for in-person, face-to-face interactions. A clinical lab that creates an app for users to view their clinical exam results may have as its objective to lower the operational costs of handling and sending results.

Then you need to understand the problems and needs that this product will solve for your users, in which context these problems and needs happen and what motivates these users have to see their problem or need to be solved.

A nice tool to understand the user is the empathy map.

Empathy map

This map helps to focus on the different perceptions that the user may have:

  • See? – What does your user see? How is the environment where it uses the product? What does the market offer?
  • Listen? – What does your user listen to? What do your friends tell you about your product? What does his boss say? What do the influencers say?
  • What do you say and do? – What does your user say and do in relation to your product? What does he talk about with friends and on social networks? What can he do with your product?
  • Think and Feel? – What does your user think and feel when using your product?
  • Pain? – What are the main pains, fears, frustrations, and obstacles that your user encounters?
  • Gain – What are the key winnings, desires, and needs that your user expects to have when using your product?

Another useful tool is the persona, which represents a group of users with similar patterns of behavior, attitudes, and motivations in terms of purchasing decisions, use of technologies or products, lifestyle, etc.
The personas are used to:

  • Know and understand customers and users of products and services;
  • Bring the user to the project focus;
    Make design decisions more human and less abstract.

The following figure shows how to build a persona:

What is needed to create a Persona

The first step is to define a name and some characteristics of that persona. This helps in conversations about the product. In the name, it’s nice to already give a hint of the main characteristic. For example, Maria, the cool girl, or Michelle, the busy one.

If you are making a product for Michelle, the busy, and want to insert a new feature, one question that comes to mind is: “Will Michelle, the busy one, be able to use this feature? Will she find it useful enough to find time to learn how to use it?”

Beyond the name and basic characteristics, it is also important to describe your behaviors and your problems. The following examples will make the concept of persona clearer.

Mary, the cool girl
Michelle, the busy one

Maria, the cool girl is one of the personas that we used at Locaweb. Given the different products that we have in our portfolio, we ended up building eight personas. However, for each product in our portfolio, we had no more than 4 personas, being one of them the primary persona for that product, i.e, for whom all decisions about the product were taken.

As part of understanding the problem or need that your user expects to be solved by your product, it is very important that you map out the alternatives that exist today for her to have that problem or need to be solved. In the case of commercial products, they are the competitors. In the case of products that are systems without clear revenue objectives, such as internet banking or the clinical lab system for result visualization, the alternatives are going in person to the bank or the lab, calling the bank by phone, and receiving results by mail, etc.

This alternative mapping is very important to understand how your user deals with her problem or need without your product. How these alternatives are better and in which ones they are worse than the product you manage.

Empathy map, persona, and alternative mapping can and should be created in conjunction with UX, engineering, and product marketing people.

Okay, you already have all the elements to create the vision of your product:

  • The objectives of the owner of the product you manage;
  • Who the users are and what problems and needs these users expect to solve with your product. Useful tools for this are empathy map, persona, and alternative map.

Remember that to get these elements, the product manager will have to use a lot of empathy to talk to the owner of the product she manages and understand their goals, and to talk to the product users and understand them.

With these elements in hand, you are ready to create your vision, which is nothing more than to make clear these elements. Simple, right? It would be something like this:

(name of software owner) has decided to have this software for (objectives of the software owner to have such software). This software is used by (description of the people who will use the software) that, when using this software, expects to solve (problem or need that the user expects to solve) in a better way than (existing alternatives).

(Include more information about the problem or need, including context and motivation to have it solved).

Please do not copy + paste this text! Create your own product vision, which does not have to be text. It can be a presentation or a video, remembering that the vision of the product is the reason why the product exists. It is what should guide all decisions in relation to it.

As you get your product vision clearer, it is important to circulate it within your company to get input, feedback, and questions. By doing this, you’ll have a chance to complete the product vision as well as get the alignment and buy-in from all stakeholders.

Product Vision examples

Internet banking

Here’s an example of a bank where the owner decided to create an internet banking app so they could decrease the cost of building, staffing, and maintaining physical bank branches:

XYZ Bank has decided to have an internet banking app to reduce the operating costs of bank branches.

This software is used by bank account holders who, when using this software, expect to solve their banking needs (see account balance and report, pay bills, make investments, etc.) in a better way than when they visit the bank’s agencies.

Locaweb’s Email product

During my time at Locaweb we put together the following product vision for Locaweb’s Email product:

Locaweb’s Email product will be the most complete and flexible email solution of the Brazilian market.

Conta Azul’s product vision

We built Conta Azul’s product vision as an image because with the image it was easier to explain all the elements of what we saw as the future of Conta Azul product.

Conta Azul product vision

Gympass Product Vision

Again, we preferred an image instead of words. The saying a picture is worth a thousand words has a reason to exist.

Gympass product vision

Product Strategy

Once you have defined the product vision, you’ll be probably thinking something along the lines of: “Hum, I think my product is still far from this vision.” Then comes the question “how do I get my product closer to this vision?”. This is where the product strategy comes in, i.e., what steps will be taken to bring the product closer to the vision.

A good tool to help build product strategy is the SWOT analysis, to help you and your team analyze Strengths, Weaknesses, Opportunities, and Threats to your product.

SWOT

Strengths and weaknesses are internal items (from your product development team, or your company) that you, your team, or your company have some control over, that help or hinder your product from reaching your vision.

Opportunities and threats are external elements to the organization over which the organization has no or minimum control, and which can influence positively or negatively the attainment of the vision of the product.

Filling the SWOT should also be a team effort. The product manager must have one or more sessions together with UX, engineering, and marketing people to build your product SWOT. It is likely that your organization has also done a SWOT analysis for the organization as a whole, which can be a great input for your product SWOT.

SWOT analysis can be tricky, especially in the weaknesses quadrant. It tends to be a big list of items your product doesn’t have yet. My suggestion is to limit all quadrants to 3 items. Having this discipline, you’ll be able to prioritize what are the 3 more important items in each quadrant. Since we have 4 quadrants, you will have a list of 12 items to take care of.

In order to build a more comprehensive SWOT analysis, it is very important to have a good market analysis available. This market analysis should include:

  • Competitors: a good view of your product competitors is very important to help you build your product SWOT. Don’t forget to think also about indirect competitors. For instance, an email product has the telephone as an indirect competitor.
  • Potential and addressable market: ultimately your product could have the total global population as users or the total number of companies worldwide in a B2B product. However, you most likely designed your product for a subset of these users – or companies. For instance, you designed a delivery product for people who sell things and since it is a delivery product, it is limited to a certain region. This is the potential market. The addressable market is the size of this market that you believe you can reach.
  • Market growth: as important as it is to know the size of the market is to know the growth of this market. For instance, the number of landline telephones is close to 1 billion, but this is a shrinking market since there’s a clear movement toward mobile telephones.
  • Disruptors: as important as it is to know your competitors is to know what can disrupt your product. For instance, at Locaweb we were seeing a decline in email usage, possibly due to the migration of a part of the communication, which was normally carried out through email, being made by other means such as WhatsApp and Slack. Anyone managing a riding or a delivery product such as Uber, Rappi, and others should be already discussing the impact of autonomous vehicles on their product and business.

Having the SWOT filled up, it’s time to draw the strategy of your product. Product strategy is nothing more than a short, medium, and long-term roadmap.

Long term?

You are certainly thinking that as you use agile methodologies in the product development team, it makes no sense to have a long-term roadmap, not even a medium-term roadmap makes that much sense. In fact, it does, but not in the classic sense of roadmap as a list of features, but instead using the roadmap as a priority list, a list of focus points that must be tackled in a specific order to make the product gets closer to the product vision.

With your product SWOT analysis completed, you should look at each of the items in each of the quadrants, along with the team (UX, engineering and product marketing), and evaluate what impact each item has on the product vision you have created. Are there strengths to be strengthened? If so, which ones should be strengthened first? Are there weaknesses to be tackled? If so, which ones should be tackled first? Are there opportunities to be taken advantage of? If so, which ones should be looked into first? Are there threats to be fought? If so, which ones should be tackled first?

This analysis will help you define the motivations and goals, i.e., the macro themes of your roadmap. Remembering that roadmap = motivation + metrics, which is being popularized with the acronym OKR (Objectives and Key Results). This analysis will help you define what to focus on now and what to leave for later, always aiming ultimately to get closer to your product vision. And that’s the product strategy, the path that you and the product development team will go through to get to the product vision.

Your product evolves, and your vision and strategy too!

An important point is that your product evolves as the team works on it. A lot is learned about the users of the product, their problems, and their needs. New alternatives may appear to help your user solve their problems and needs. The software owner can also revisit their strategic objectives and, consequently, revisit the defined goals for the digital product.

In addition, strengths and weaknesses may change over time, and opportunities and threats may appear or disappear. So, it’s important to understand that neither the vision nor the strategy of the product is written in stone. They can and should be revisited periodically.

My suggestion is that they be revisited annually, or when a relevant event happens, such as when there is a change in the strategic objectives of the company, or when there’s an alternative that solves the problem or need of the user in a different way from the one of its product.

Summing up

With this chapter, we are almost closing the theme of the growth phase of the software product lifecycle. In the next chapter, we will put it all together. Vision, strategy, roadmap, and OKRs.

Product leadership coaching

I’ve been helping several product leaders (CPOs, heads of product, CTOs, CEOs, and tech founders) extract more value and results from their digital products. Check here how I can help you and your company.

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.

O que é e como criar a visão e a estratégia do produto?

Em algum momento durante a fase de crescimento do seu produto, pode ser útil criar a visão e a estratégia do produto. Essas ferramentas ajudarão muito nas decisões sobre qual será o futuro do seu produto. Por este motivo, vou explicar neste capítulo o que é e para que serve sua visão e sua estratégia.

O que é e para que serve a visão do produto?

Visão do produto é a razão de existir do produto. É o que deve nortear todas as decisões em relação a esse produto. O que dá o contexto para o time de desenvolvimento do produto tomar decisões sobre o que priorizar em relação ao produto. Vale lembrar de que, quando falo “produto”, estou me referindo a qualquer software que tenha usuários.

Lembrando da definição de gestão de produtos, um produto deve ao mesmo tempo atender aos objetivos estratégicos que o dono do produto tem para esse produto enquanto ele resolve problemas e necessidades de seus usuários. Pronto, esses dois elementos são o que você precisa para fazer a sua visão do produto.

Criando a visão do produto

A visão do produto será criada juntando esses dois elementos, o entendimento dos objetivos do dono do produto e os problemas e necessidades do usuário do produto. Sendo assim, o primeiro passo para criar a sua visão do produto é ter bem claro quais os objetivos que o dono do produto tem para ele.

Por exemplo, um banco pode querer, com um sistema de Internet Banking, reduzir a necessidade de atendimento em agências. Um laboratório de análises clínicas e de imagem, com um sistema de consulta de resultados, pode querer diminuir os custos operacionais de manuseio e envio de resultados.

Em seguida, é preciso entender quais são os problemas e necessidades que esse produto vai resolver a partie de seus usuários, qual o contexto onde esses problemas e necessidades acontecem e qual a motivação que esses usuários têm para querer ter esse problema ou necessidade resolvido.

Uma ferramenta bacana para entender o usuário é o mapa de empatia.

Mapa de empatia

Esse mapa ajuda a dar foco nas diferentes percepções que o usuário pode ter:

  • Vê? – O que seu usuário vê? Como é o ambiente onde ele usa o produto? O que o mercado oferece?
  • Ouve? – O que o seu usuário ouve? O que seus amigos dizem para ele sobre o seu produto? O que o chefe dele diz? O que os influenciadores dizem?
  • Diz e faz? – O que o seu usuário diz e faz em relação ao seu produto? O que ele comenta com amigos e em redes sociais? O que ele consegue fazer graças ao seu produto?
  • Pensa e sente? – O que seu usuário pensa e sente quando usa o seu produto?
  • Dores? – Quais são as principais dores, medos, frustrações e obstáculos que o seu usuário encontra?
  • Ganhos? – Quais os principais ganhos, desejos e necessidades resolvidas que seu usuário espera ter ao usar seu produto?

Outra ferramenta muito útil é a persona, que representa um grupo de usuários com padrões de comportamento, atitudes e motivações similares em termos de decisão de compra, de uso de tecnologias ou produtos, de estilo de vida etc.

As personas são usadas para:

  • Conhecer e entender clientes e usuários de produtos e serviços;
  • Trazer o usuário para o foco do projeto;
  • Tornar as decisões de design mais humanas e menos abstratas.

A figura a seguir mostra como construir uma persona:

O que é necessário para criar uma persona

O primeiro passo é definir um nome e algumas características dessa persona. Isso ajuda nas conversas sobre o produto. No nome, é bacana já dar uma dica da característica principal. Por exemplo, Maria, a descolada ou Michelle, a ocupada.

Se você estiver fazendo um produto para Michelle, a ocupada e quiser inserir uma nova funcionalidade, vale a pergunta: “Será que Michelle, a ocupada vai conseguir usar essa funcionalidade? Ela a achará útil o suficiente para achar tempo para aprender a usá-la?”.

Além do nome e características básicas, é importante também descrever seus comportamentos e seus problemas. Os exemplos a seguir deixarão mais claro o conceito de persona.

Maria, a descolada
Michelle, a ocupada

Maria, a descolada é uma das personas que usávamos na Locaweb. Dados os diferentes produtos que temos em nosso portfólio, acabamos construindo oito personas. Contudo, para cada produto de nosso portfólio, tínhamos uns 3 ou, no máximo, 4 personas, sendo que uma destas era a persona primária do produto, ou seja, para quem todas as suas decisões de seu produto de software são tomadas.

Como parte do entendimento do problema ou necessidade que seu usuário espera ver resolvido pelo seu produto, é muito importante você mapear quais as alternativas que existem hoje para ele ter esse problema ou necessidade resolvido. No caso de produtos comerciais, são os concorrentes. No caso de produtos que são sistemas sem objetivos diretos de receita, como o internet banking ou o sistema de consulta de resultado de exames, são as alternativas existentes como ir ao banco ou ao laboratório, acesso ao banco por telefone, envio de resultados por correio etc.

Esse mapeamento de alternativas é muito importante para você entender como seu usuário se vira sem o seu produto como no que essas alternativas são melhores e no que elas são piores do que o produto que você cuida.

Tanto o mapa de empatia, a persona quanto o mapeamento de alternativas podem e devem ser criados em conjunto com pessoas de UX, de engenharia e de marketing de produtos.

Pronto, você já tem todos os elementos para criar a visão do seu produto:

  • Os objetivos do dono do produto;
  • Quem são os usuários e quais os problemas e necessidades esses usuários esperam resolver com seu produto. Ferramentas úteis para isso são o mapa de empatia, a persona e o mapa de alternativas.

Vale lembrar de que, para obter esses elementos, o gestor de produtos terá de usar muita empatia para conversar com os donos do produto e entender seus objetivos, e para conversar e entender o seu cliente.

Com esses elementos em mãos, você está pronto para criar a sua visão, que nada mais é do que deixar claro esses elementos. Simples, né? Seria algo mais ou menos assim:

O (nome do dono do software) decidiu ter esse software para (objetivos do dono do software em ter esse software). Esse software é usado por (descrição das pessoas que usarão o software) que, ao usar esse software, espera resolver (problema ou necessidade que o usuário espera resolver) de uma forma melhor do que (alternativas existentes).

(Incluir mais informações sobre o problema ou necessidade, incluindo contexto e motivação para ver resolvido).

Por favor, não dê copiar + colar nesse texto! Crie sua própria visão do produto, que não precisa ser um texto. Pode ser uma apresentação ou um vídeo. Lembrando de que a visão do produto é a razão de existir do produto. É o que deve nortear todas as decisões em relação a ele.

À medida que você obtém sua visão do produto mais clara, é importante circulá-la dentro de sua empresa para obter informações, feedback e perguntas. Ao fazer isso, você terá a chance de concluir a visão do produto, além de obter o alinhamento e a adesão de todas as partes interessadas.

Exemplos de visão do produto

INTERNET BANKING

Aqui está um exemplo de banco em que o proprietário decidiu criar um aplicativo de internet banking para diminuir o custo de construção, contratação de pessoal e manutenção de agências bancárias físicas:

O XYZ Bank decidiu ter um aplicativo de internet banking para reduzir os custos operacionais das agências bancárias.

Este software é utilizado por correntistas que, ao utilizarem este software, esperam resolver suas necessidades bancárias (ver saldo e relatório da conta, pagar contas, fazer investimentos, etc.) de uma forma melhor do que quando visitam as agências do banco.

PRODUTO DE E-MAIL DA LOCAWEB

Durante meu tempo na Locaweb, montamos a seguinte visão de produto para o produto Email da Locaweb:

O produto Email da Locaweb será a solução de email mais completa e flexível do mercado brasileiro.

VISÃO DE PRODUTO DA CONTA AZUL

Construímos a visão do produto Conta Azul como uma imagem porque com a imagem era mais fácil explicar todos os elementos do que víamos como o futuro do produto Conta Azul.

Visão do produto Conta Azul

VISÃO DO PRODUTO GYMPASS

Mais uma vez, preferimos uma imagem em vez de palavras. O ditado que uma imagem vale mais que mil palavras tem uma razão de existir.

Visão do produto Gympass

Estratégia do produto

Uma vez que você tem em mãos a visão do produto, provavelmente vem um pensamento a mente, algo na linha de: “hum, acho que meu produto ainda está distante da visão”. E a pergunta subsequente é: “como fazer com que meu produto chegue mais perto da visão?”. É aí que entra a estratégia do produto, ou seja, que passos serão dados para aproximar o produto da visão.

Uma boa ferramenta para ajudar a construir a estratégia do produto é a análise SWOT, sigla em inglês para Strengths, Weaknesses, Opportunities and Threats, ou pontos fortes, fracos, oportunidades e ameaças.

SWOT

Os pontos fortes e os pontos fracos são itens internos (ou seja, do seu time de desenvolvimento de produto, ou da sua empresa) sobre as quais você, seu time ou sua empresa têm algum controle, que ajudam ou atrapalham o seu produto atingir a sua visão. As oportunidades e ameaças são os elementos externos à organização, ou seja, sobre os quais a organização não tem controle, e que podem influenciar positiva ou negativamente o atingimento da visão do produto.

Preencher o SWOT deve ser também um trabalho de equipe, ou seja, o gestor de produto deve ter uma ou mais sessões junto com pessoas de UX, engenharia e marketing para construir o SWOT do seu produto. É provável que sua organização também tenha feito uma análise SWOT para a organização como um todo. É um ótimo input para o SWOT do seu produto.

Tendo em mãos o SWOT preenchido, é hora de desenhar a estratégia do seu produto. A estratégia do produto nada mais é do que um roadmap de curto, médio e longo prazo. Longo prazo?

Você certamente está pensando que, como vocês adotaram metodologias ágeis no time de desenvolvimento de produto, não faz mais sentido ter um roadmap de longo prazo, nem de médio prazo. Na verdade, faz sim, mas não no sentido clássico de roadmap como lista de funcionalidades, mas sim usando o roadmap como lista de prioridades, lista de pontos de foco que devem ser vistos para fazer com que o produto se aproxime da visão.

Com o SWOT preenchido, você deve olhar para cada um dos itens em cada um dos quadrantes, junto com o time (UX, engenharia, marketing de produto), e avaliar qual o impacto dele na visão de produto que vocês criaram. Existem pontos fortes devem ser reforçados? Se sim, quais devem ser reforçados primeiro? Existem pontos fracos a serem combatidos? Se sim, quais devem ser combatidos primeiro? Existem oportunidades a serem aproveitadas? Se sim, quais devem ser aproveitadas primeiro? Existem ameaças a serem combatidas? Se sim, quais devem ser combatidas primeiro?

Essa análise te ajudará a definir as motivações, os objetivos, ou seja, os macrotemas do seu roadmap. Lembrando de que roadmap = motivação + métrica, o que agora está sendo popularizado com a sigla OKR (Objectives and Key Results), tema de um futuro artigo. Essa análise te ajudará a definir no que se focar agora e o que deixar para depois, sempre tendo por objetivo final chegar mais próximo da sua visão de produto. E isso é a estratégia do produto, o caminho que você e o time de desenvolvimento de produto vão percorrer para chegar na visão do produto.

Seu produto evolui, sua visão e estratégia também!

Um ponto importante é que seu produto evolui à medida que o time trabalha nele. Muito se aprende sobre os usuários do produto, seus problemas e necessidades. Novas alternativas podem aparecer para ajudar seu usuário a resolver seus problemas e necessidades. O dono do software também pode revisitar seus objetivos estratégicos e, consequentemente, revisitar os objetivos definidos para o software.

Além disso, pontos fortes e pontos fracos podem mudar com o tempo, e oportunidades e ameaças podem aparecer ou sumir. Por isso é importante entender que nem a visão nem a estratégia do produto estão escritas em pedra. Elas podem e devem ser revisitadas periodicamente.

Minha sugestão é que elas sejam revisitadas anualmente, ou quando algum evento relevante acontecer, como por exemplo, quando houver uma mudança nos objetivos estratégicos da empresa, ou quando aparecer uma alternativa que resolve o problema ou necessidade do usuário de uma forma diferente da do seu produto.

Concluindo

Com isso, fechamos o tema sobre a fase de crescimento do ciclo de vida de um produto de software. Entendemos como lidar com feedback dos clientes, e o que é e como priorizar um roadmap. Também vimos sobre os mais variados tipos de métricas, incluindo funil de conversão, engajamento, churn, métricas financeiras globais e individuais, churn de receita e o negativo, NPS, a métrica da lealdade, algumas considerações sobre métricas. Vimos aqui o que é e para que serve a visão e a estratégia do produto, ferramentas úteis para as tomadas de decisão sobre qual será o futuro dele.

No próximo capítulo, entenderemos melhor a próxima fase do ciclo de vida de um produto de software: a maturidade.

Mentoria de líderes de produto

Tenho ajudado líderes de produto (CPOs, heads de produtos, CTOs, CEOs, tech founders) a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.

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:

Growth: thoughts on metrics

Measuring is good. Metrics are essential for knowing deeply your product and for making more accurate decisions. But you must be very careful. The excess of metrics can get in your way and overshadow the full knowledge of your product.

Data-driven

Instead of excessively collecting metrics, you should follow a data-driven approach. When you manage a product in a data-driven way, you run experiments that generate data that feed your decisions for the next experiments. It is this simple, and it seems to be an excellent way to manage a product. But there are a few problems with this approach.

  • Easy versus most relevant: There’s a natural tendency to measure what is easy to measure, and that can happen to the detriment of measuring what is most relevant. For instance, what is easier to measure: clicks in a message from an e-mail marketing campaign or the user perception (curiosity, happiness, disdain, etc.) when getting this message from the e-mail marketing campaign? Before taking action over the existent data, it is always good to ask if these are the best data for making the decision.
  • Local optimization: Another concern in relation to decisions based on data is the hazard of sticking to the improvements focused on local optimization. That is, you make incremental improvements in your product focusing on improving a given metric, but you don’t realize that if you make a more radical change you can get a considerable increase in this metric, larger than the largest increase obtained from these incremental improvements.
Local optimization
  • Quality of data: It is necessary to understand the quality of data, that is, how they are obtained and processed before you get them into the analysis. Are the results statistically relevant? You must have heard of A/B tests, right? It is a test in which you build two versions of something. Next, you set apart the traffic in these two versions and start to measure the behavior on the two versions according to a given goal, such as clicks on the Buy button. After running this test for a while, you will know which of the two versions reaches the goal more often. Now try to run an A/A test, that is, an A/B test in which the two versions of the page are identical. After running the test, check out the results. Chances are you will find one of the A versions of your page reaching the goal more times than the other one. How is that possible? Statistical variations, seasonality, and unpredictable effects. Every data can be subject to statistical variations and that is why, in quantitative data, it is always good to understand the size of the sample and how it was collected. The season when the data sample was taken also affects the data quality: time of the day, day of the week, day of the month, period of the year, and so on. Data are photography with a date and time set, and the same datum collected minutes later can give you different information.
  • Quality acknowledgment: Not only from quantitative data lives the product management. Au contraire, the product manager must use different tools to learn more about the user, the problem afflicting this user, the context in which this happens, and what motivates having this problem solved. Many of these tools present qualitative data, that is, exploratory research data, through which it is seeking to understand reasons, motivations, and opinions. This kind of understanding is very difficult, if not impossible, to obtain in quantitative data analysis.

Data-informed

Instead of data-driven, we need to be data-informed, in other words, using data as one more input to decision-making, not the only input. Take the experience, the intuition, the judgment, and the qualitative information into consideration, along with the metrics to increase the quality of decision-making.

One of the best examples I can quote has to do with the website hosting product from Locaweb. Through the years, in a reasonably informed way, but always counting on a lot of intuition, we altered our hosting plans in order to have more space on disk, data transfer, and the number of sites that could be hosted in each plan sold. In 2011 we noticed that more than 90% of our clients were choosing the basic plan because it attended to the needs of most people who needed a website.

We wanted that the largest plans would play a bigger role in sales, but with the limits we had, there was no motivation for the clients to buy them. We thought of changing the plans for new subscriptions, decreasing the limits to incentive clients to get bigger plans. However, as this was a significant and very sensible change, we brought in a consulting expert in pricing that helped us collect and analyze several data, to suggest which was the best chance to be done.

We implemented the changes suggested in 2012. There was a little variation in the distribution of plans, but the number of plans contracted per month didn’t change. Moreover, it even decreased a little, which resulted in no alteration in the amount of monthly revenue. That is, we spent time and money collecting and analyzing data that made us take a decision that didn’t change the company’s result. Maybe if we had defined the changes more intuitively, we would have saved money and would know the result of the decision more quickly.

A little bit on A/B tests

There are two great tools for taking A/B tests — the Visual Website Optimizer and the Optimizely. I used the services from Visual Website Optimizer, that gives you one free month to test some hypotheses about the home of ContaCal:

Original home of ContaCal

In less than 30 minutes, I was able to create 4 versions and began to run the test. I decided to test two things. One was for the color of the create account button if it was going to make a difference in the number of people who would click on it:

Version with a green button
Version with a red button

The second test: if changing the explanatory video for a photo would increase or decrease the number of people who would click on create account button:

Version with a photo of a thin woman
Version with a photo of a family cooking a healthy meal

The result was:

A/B test result for ContaCal’s home

After seeing this result, I got the impression that if I put the green button with the healthy family picture, I was going to increase the conversion even more. So, I decided to run this test and the result was:

A/B test result for ContaCal with the photo of a healthy family and changing button color

Therefore, take care, appearances can be deceiving! Make experiments before taking conclusions!

Analysis paralysis

Lastly, aside these precautions, it is necessary to take care with the analysis paralysis effect, that is, analyzing data all the time and not taking any action. As seen in the picture from xkcd.com (2014), analysis paralysis can cost you a lot:

Efficiency, by Randall Munroe, https://xkcd.com/1445

Final thoughts

The metrics are not the reason for the existence of your product. The users, their problems, and the strategic goals of the business are the reasons for its existence. In other words, metrics are a mean and not the end, the results, and the goal. Therefore, use them more like one of the tools to help you to drive your product in the right direction.

With this, we close the theme on the growth stage of a software product life cycle. We understood how to deal with client feedback, what it is, and how to prioritize a roadmap. We also saw several types of metrics, including the conversion funnel, engagement, churn, global and individual financial metrics, revenue and negative churn, NPS, the loyalty metrics, and we also approached some considerations on metrics.

In the next chapter, we will better understand the next stage of a software product life cycle: maturity.

Product leadership coaching

I’ve been helping several product leaders (CPOs, heads of product, CTOs, CEOs, and tech founders) extract more value and results from their digital products. Check here how I can help you and your company.

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.

Crescimento: considerações sobre métricas

Ter métrica é bom. Métricas são essenciais para conhecer mais a fundo seu produto e para poder tomar decisões mais acertadas. Mas é preciso tomar cuidado. Métrica em excesso pode atrapalhar, pode ofuscar o seu conhecimento pleno do seu produto.

Em inglês, existem dois termos que podem explicar bem essa minha preocupação. O primeiro termo é data-driven. Quando se gerencia um produto de forma data-driven, você roda experimentos que geram dados que alimentam suas decisões sobre próximos experimentos. É simples assim, e parece ser uma excelente forma de se gerir um produto. Só que existem alguns problemas nessa abordagem:

  • Medição de dados: Existe uma tendência natural a medir o que é fácil de ser medido, e isso pode acontecer em detrimento de medir o que é mais relevante. Por exemplo, o que é mais fácil de medir: cliques em uma mensagem de uma campanha de e-mail marketing, ou percepção do usuário (curiosidade, alegria, desdém etc.) ao receber essa mensagem de uma campanha de e-mail marketing? Antes de sair tomando ações em cima dos dados existentes, é sempre bom perguntar se estes são os melhores dados para poder tomar a decisão.
  • Ótimo local: Outro ponto de preocupação em relação às decisões baseadas em dados é o perigo de se ater às melhorias focadas em ótimos locais. Ou seja, você faz melhorias incrementais em seu produto, focando em melhorar determinada métrica, mas não percebe que, se você fizer uma mudança mais radical, pode obter um aumento considerável nessa métrica, maior do que o maior aumento obtido com essas melhorias incrementais.
Local optmium
  • Qualidade dos dados: Mesmo tendo dados, é preciso entender a qualidade dos dados, isto é, como eles são obtidos e processados antes de você recebê-los para analisar. Os resultados têm relevância estatística? Você já deve ter ouvido falar em teste A/B, não? É um teste no qual você monta duas de uma determinada página de um site. Em seguida, você divide o tráfego que vai para essas duas versões e começa a medir o comportamento das duas páginas em relação a um determinado objetivo como, por exemplo, cliques no botão “comprar”. Após rodar esse teste por algum tempo, você vai saber qual das duas versões atinge mais o objetivo. Experimente agora fazer um teste A/A, ou seja, faça um teste A/B em que as duas variações da sua página são idênticas. Depois de rodar esse teste, veja os resultados. Existem grandes chances de você encontrar uma das versões A de sua página atingindo o objetivo mais vezes do que a outra versão A. Como isso é possível? Variações estatísticas, sazonalidade e efeitos imprevisíveis. Todo dado pode estar sujeito a variações estatísticas e, por isso, em dados quantitativos é sempre bom entender o tamanho da amostra e como ela foi coletada. A época em que a amostra de dados foi coletada também impacta na qualidade dos dados: hora do dia, dia da semana, dia do mês, período do ano, e assim por diante. Dados são uma foto com data e hora marcada, o mesmo dado coletado minutos depois pode dar informações diferentes. Por fim, os efeitos imprevisíveis que podem afetar seus dados. A campanha presidencial de 2014 foi completamente mudada com a morte de um dos candidatos, o Eduardo Campos. Esse foi um evento imprevisível que mudou completamente a qualidade dos dados de pesquisa eleitoral.
  • Conhecimento qualitativo: Nem só de dados quantitativos vive a gestão de produtos. Ao contrário, o gestor de produtos deve (como visto no capítulo Inovação: foco no problema) usar diferentes ferramentas para aprender mais sobre seu usuário, o problema que o aflige, o contexto em que isso acontece e o que o motiva a ter esse problema resolvido. Muitas dessas ferramentas apresentam dados qualitativos, ou seja, dados de pesquisa exploratória, por meio da qual se está buscando entender razões, motivações e opiniões. Esse tipo de entendimento é muito difícil, senão impossível, de se obter em análise de dados quantitativos.

Em função disso, em vez de data-driven, está cada vez mais claro que precisamos ser data-informed; em outras palavras, usar os dados como mais um insumo para as tomadas de decisão, e não como o único insumo. A experiência, a intuição, o julgamento e as informações qualitativas devem também ser levados em consideração, junto com as métricas, para aumentar a qualidade da tomada de decisão.

Acredito que um dos melhores exemplos que posso citar tem a ver com o produto de hospedagem de sites da Locaweb. Ao longo dos anos, de forma razoavelmente informada, mas contando sempre com bastante intuição, alteramos nossos planos de hospedagem para ter mais espaço em disco, transferência e quantidade de sites que poderiam ser hospedados em cada plano vendido. Em 2011, notamos que mais de 90% de nossos clientes escolhiam o plano mais básico, pois ele atendia a necessidade da maioria das pessoas que precisavam de um site.

Queríamos que os planos maiores tivessem uma participação maior nas vendas, mas, com os limites dos planos que tínhamos, não havia nenhuma motivação para os clientes os comprarem. Pensamos em mudar os planos para novas contratações, diminuindo os limites para incentivar os clientes a adquirirem planos maiores. Entretanto, como era uma mudança significativa e bastante sensível, trouxemos uma consultoria especializada em precificação, que nos ajudou a coletar e analisar vários dados, para sugerir qual a melhor mudança a ser feita.

Implementamos as mudanças sugeridas em 2012. Houve uma pequena variação na distribuição dos planos, mas a quantidade de planos contratados por mês não mudou. Aliás, chegou a cair um pouco, o que resultou em nenhuma alteração na quantidade de nova receita por mês. Ou seja, gastamos tempo e dinheiro coletando e analisando dados que nos fizeram tomar uma decisão que em nada mudou o resultado da empresa. Talvez se tivéssemos definido as mudanças de forma mais intuitiva, teríamos economizado dinheiro e saberíamos o resultado da decisão mais rapidamente.

Um pouco sobre testes A/B

Existem duas ótimas ferramentas para fazer testes A/B, o Visual Website Optimizer (http://visualwebsiteoptimizer.com) e o Optimizely (http://optimizely.com). Usei o serviço Visual Website Optimizer, que oferece um mês grátis, para testar algumas hipóteses sobre a home do ContaCal:

Home original do ContaCal

Em menos de 30 minutos, consegui criar 4 variações e comecei a rodar o teste. Resolvi testar duas coisas. Uma era se a cor do botão “criar conta” faz diferença na quantidade de pessoas que clicam nele:

Variação com botão verde
Variação com botão vermnelho

E a outra era se, mudando o vídeo explicativo para uma foto ilustrativa, aumentava ou diminuía a quantidade de pessoas que clicam no botão “criar conta”:

Variação com foto de mulher magra
ariação com foto de família preparando refeição saudável

O resultado foi:

Resultado do teste A/B na home do ContaCal

Ao ver esse resultado, fiquei com a impressão de que, se eu colocasse botão verde com a imagem da família saudável, eu iria aumentar mais ainda a conversão. Resolvi, então, fazer esse teste e o resultado foi:

Resultado do teste A/B na home do ContaCal com foto de família saudável

Por isso, tome cuidado, as aparências enganam! Faça experiências antes de tirar conclusões!

Analysis paralysis

Por fim, além desses cuidados, é preciso tomar cuidado com o efeito analysis paralysis, ou seja, ficar o tempo todo analisando dados e não tomar nenhuma ação. Como bem ilustrado pela figura do xkcd.com (2014), a analysis paralysis pode custar bem caro:

Fonte: Efficiency, por Randall Munroe, em https://xkcd.com/1445

Concluindo

As métricas não são a razão da existência de seu produto. Os usuários de seu produto, os problemas que ele resolve para esses usuários e os objetivos estratégicos da empresa que é dona do software são as razões de sua existência. Ou seja, métricas são um meio, e não o fim, o resultado e o objetivo. Por isso, use-as como mais uma das ferramentas que você tem à sua disposição para ajudá-lo a guiar seu produto na direção certa.

No próximo capítulo vou falar sobre o que é e para que serve a visão e a estratégia do produto, ferramentas úteis para as tomadas de decisão sobre qual será o futuro do seu produto.

Mentoria de líderes de produto

Tenho ajudado líderes de produto (CPOs, heads de produtos, CTOs, CEOs, tech founders) a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.

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: