In praise of the incomplete leader

It’s very difficult, if not impossible, to be a complete leader. And that’s ok!!!

Just to be clear, by complete I mean good at everything that a team needs a leader to be good at.

That’s not to say that a leader shouldn’t always strive to be a better leader, but being a better leader doesn’t mean being good at everything. Means understanding weaknesses and having a clear plan to address the weaknesses. This plan can be either some skill development plan or having someone in the team that can address the weakness or, my preferred option, a mix of both.

When I joined Lopes, the biggest real estate company in Brazil that I joined to lead the digital transformation process, one of my first focuses was team structure design. During this process we envisioned a team focused on franchises and brokers. I had a few options as Group Product Manager for this team. I could bring someone from outside of the company, with product management leadership experience. I could bring someone from the product development team, that already know the company and the systems. I could bring someone from the business side.

I decided to go with one of the least obvious options. There was one Lopes leader who was at the company for more than 12 years and had worked in sales operations, was a partner of one of Lopes franchises for a few years, and was now working in franchise management. He was also working on some of the digital initiatives, very hands-on, together with the digital team. He had business experience, leadership experience, Lopes experience, and a lot of interest in digital initiatives, to the point that he worked on these initiatives in addition to his day-to-day job. For this reason, I decided to offer him the opportunity to become the Franchise and Broker Trybe Group Product Manager even though he did not have any formal product management experience. He sort of had some informal experience in the digital initiatives he participated but I could certainly find in the market more experienced product managers leaders. However, this person had the business experience and company experience that would be very beneficial for his role. He then took training on product management and we hired product managers and product designers with experience in product development to join his team. And this was clear to everyone, including the experienced product people joining the team, that they were joining a team where the GPM was very experienced in the business and the company, but not so much on product management, and that we were counting on the more experienced product people to level up the overall team product experience.

Common CTO blindspots

CTO, Chief Technology Officer, and all similar heads of technology and engineering positions are very well-known positions in the tech market. Normally people occupying this position came not only from a technical background but from being a hands-on developer. In tech startups, it is common that the tech founder who wrote the first lines of code of the product becomes the CTO. This person normally knows a lot about technology and writing code but, more often than not, this person has little to no experience in other important areas of leadership that may be needed as the team and the company scale:

  • business: connecting the technology to the business, its objectives, and its customers. A tech leader needs to be able not only to understand this connection but also to explain this connection to the product development team and use this connection as the context for every new step that the team will give. I common way to overcome this is to bring a head of product to the organization that could report to the CTO or be a pair to the CTO reporting to the CEO.
  • people: leadership is all about people. Understanding people, what motivates each person in your team, what are her weaknesses and strengths, and how you can help her improve even more in her strengths while getting better in her weaknesses.
  • process: another common blindspot of CTOs and heads of engineering is process, i.e., the ability to define and track a set of metrics to measure the product development process and then define what needs to be improved. Are we delivering better software? Are we delivering software faster? Are we delivering software aligned with business results? Are we improving in these metrics?

When I joined Gympass there were already 2 very good heads of engineering. We still needed to hire another 2 heads of engineering for our team, so we were actively hiring. When I discussed the candidates’ profiles with the 2 existing heads of engineering, the common feedback I heard was that the candidates were not technical enough. Then I asked them, “but aren’t you quite technical?” They agreed they were quite technical and could provide the needed tech leadership. We then discussed that maybe we should look for other leadership qualities, like people and process leadership to add to our team of leaders. That’s when we started to analyze candidates through this perspective and brought a very good tech people leader and a very good process leader to join our leadership team.

My weak spot

I’ve had the opportunity to lead amazing product development teams. From my own startup back in the 1990s to Locaweb, Conta Azul, Gympass, and, most recently, Lopes digital transformation. Even though I have some technical background and used to write code at the beginning of my career, the more I entered into leadership and product management the more distant I got from the technical details of the products built by the teams I led, and that’s my weak spot. I cannot help much when conversations go too technical. Fortunately, I always had very good technical people in my teams taking care of the technical aspects and I could focus my energy where I’m a bit better, such as helping people evolve, setting and communicating vision and strategy, organizing team structure, and defining processes.

It is very important that a leader and her team know what are her weak spots and her strengths so she can build a team with people that can help her and the entire team in all aspects of product development including the ones that are her weak spots. Weak spots should not be hidden. They must be known by everyone in the team so they can properly deal with them.

Summary

  • It’s very difficult, if not impossible, to be a complete leader. And that’s ok!!! Just to be clear, by complete I mean good at everything that a team needs a leader to be good at.
  • A leader should always strive to be a better leader, but being a better leader doesn’t mean being good at everything. Means understanding weaknesses and having a clear plan to address the weaknesses. This plan can be either some skill development plan or having someone in the team that can address the weakness or, my preferred option, a mix of both.
  • Heads of engineering normally came from a strong technical background and may lack some other important leadership skills such as business, people, and process. It’s important to map these possible blindspots and design plans to address them.
  • I’ve had the opportunity to lead amazing product development teams. My own startup, Locaweb, Conta Azul, Gympass, and Lopes. Even though I have some technical background and used to write code at the beginning of my career, the more I entered into leadership and product management the more distant I got from the technical details of the products built by the teams I led, and that’s my weak spot.
  • It is very important that a leader and her team know what are her weak spots and her strengths so she can build a team with people that can help her and the entire team in all aspects of product development including the ones that are her weak spots. Weak spots should not be hidden. They must be known by everyone in the team so they can properly deal with them.

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.

Elogio ao líder incompleto

É muito difícil, se não impossível, ser um líder completo. E tudo bem!!!

Só para ficar claro, por completo quero dizer bom em tudo que uma equipe precisa que um líder seja bom.

Isso não quer dizer que um líder não deva sempre se esforçar para ser um líder melhor, mas ser um líder melhor não significa ser bom em tudo. Significa entender seus pontos fracos e ter um plano claro para lidar com esses pontos fracos. Esse plano pode ser algum plano de desenvolvimento de habilidades, pode ser ter alguém na equipe que seja bom nesses pontos fracos ou, minha opção preferida, uma mistura de ambos.

Quando entrei na Lopes, a maior imobiliária do Brasil, onde entrei para liderar o processo de transformação digital, um dos meus primeiros focos foi o desenho da estrutura de equipes. Durante esse processo enxergamos a oportunidade de criar uma equipe focada em franquias e corretores. Eu tinha algumas opções como Group Product Manager para esse time. Eu poderia trazer alguém de fora da empresa, com experiência em liderança de PMs. Poderia trazer alguém da equipe de desenvolvimento de produtos, que já conhecesse a empresa e os sistemas. Eu poderia trazer alguém da área de negócios da empresa.

Eu decidi por uma das opções menos óbvias. Havia um líder na Lopes que estava na empresa há mais de 12 anos e que trabalhou com operações de vendas, foi sócio de uma das franquias da Lopes por alguns anos e agora trabalhava no time que fazia a gestão de franquias. Ele também estava trabalhando em algumas das iniciativas digitais, muito hands-on, junto com a equipe digital. Ele tinha experiência em negócios, experiência em liderança, experiência em Lopes e muito interesse em iniciativas digitais, a ponto de trabalhar nessas iniciativas além do seu trabalho do dia-a-dia. Por esse motivo, decidi oferecer a ele a oportunidade de se tornar o Group Product Manager do time de Franquias e Corretores, mesmo que ele não tivesse nenhuma experiência formal em gestão de produtos. Ele tinha alguma experiência informal nas iniciativas digitais que participou, mas eu certamente poderia encontrar no mercado líderes de gestão de produto mais experientes. No entanto, essa pessoa tinha a experiência de negócios e a experiência da empresa que seriam muito úteis para sua função. Ele então fez treinamento em gestão de produtos e contratamos gestores de produtos e designers de produtos com experiência em desenvolvimento de produtos para se juntarem à sua equipe. E isso ficou claro para todos, inclusive para o pessoal de produto experiente que se juntou ao time, que eles estavam se juntando a um time onde o GPM era muito experiente no negócio e na empresa, mas não tanto em gestão de produto, e que estávamos contando com as pessoas de produto mais experientes para aumentar a experiência geral em desenvolvimento e gestão de produto da equipe.

Pontos cegos comuns do CTO

CTO, diretor de tecnologia e todos os cargos semelhantes de liderança de tecnologia e engenharia são cargos muito conhecidos no mercado de tecnologia. Normalmente, as pessoas que ocupam essa posição não vêm apenas de uma formação técnica, mas também de terem sido desenvolvedores. Em startups de tecnologia, é comum que o fundador de tecnologia que escreveu as primeiras linhas de código do produto se torne o CTO. Essa pessoa normalmente sabe muito sobre tecnologia e código, mas, na maioria das vezes, essa pessoa tem pouca ou nenhuma experiência em outras áreas importantes de liderança que podem ser necessárias à medida que a equipe e a empresa escalam:

  • negócio: conectar a tecnologia ao negócio, seus objetivos e seus clientes. Um líder de tecnologia precisa ser capaz não apenas de entender essa conexão, mas também de explicar essa conexão para a equipe de desenvolvimento do produto e usar essa conexão como contexto para cada nova etapa que a equipe entrará. Uma maneira comum de suprir essa necessidade é trazer uma pessoa head de produto que pode se reportar ao CTO ou ser um par do CTO reportando-se ao CEO.
  • pessoas: liderança tem tudo a ver com pessoas. Compreender as pessoas, o que motiva cada pessoa em sua equipe, quais são suas fraquezas e pontos fortes, e como você pode ajudá-la a melhorar ainda mais em seus pontos fortes enquanto melhora em suas fraquezas.
  • processo: outro ponto cego comum dos CTOs e chefes de engenharia é o processo, ou seja, a capacidade de definir e acompanhar um conjunto de métricas para medir o processo de desenvolvimento do produto e então definir o que precisa ser melhorado. Estamos entregando um software melhor? Estamos entregando software mais rápido? Estamos entregando software alinhado com os resultados do negócio? Estamos melhorando nessas métricas?

Quando entrei no Gympass já havia 2 heads de engenharia muito bons. Ainda precisávamos contratar mais 2 heads de engenharia para nossa equipe, estávamos contratando ativamente. Quando discuti os perfis dos candidatos com os 2 heads de engenharia existentes, o feedback comum que ouvi foi que os candidatos não eram técnicos o suficiente. Então eu perguntei a eles, “mas vocês já não são muito técnicos?” Eles concordaram que eram bastante técnicos e poderiam fornecer a liderança técnica necessária. Discutimos então que talvez devêssemos buscar outras qualidades de liderança, como liderança de pessoas e processos, para agregar à nossa equipe de líderes. Foi quando começamos a analisar os candidatos por essa perspectiva e trouxemos um líder de pessoas de tecnologia muito bom e um líder de processo muito bom para se juntar à nossa equipe de liderança.

Meu ponto fraco

Tive a oportunidade de liderar equipes incríveis de desenvolvimento de produtos. Desde minha própria startup nos anos 1990 à Locaweb, Conta Azul, Gympass e, mais recentemente, a transformação digital da Lopes. Apesar de ter alguma formação técnica e de escrever código no início da minha carreira, quanto mais eu ingressava na liderança e gestão de produtos mais distante ficava dos detalhes técnicos dos produtos construídos pelas equipes que liderei, e esse é o meu ponto fraco. Não posso ajudar muito quando as conversas ficam muito técnicas. Felizmente, sempre tive líderes técnicos muito bons em minhas equipes cuidando dos aspectos técnicos e pude concentrar minha energia onde sou um pouco melhor, como ajudar as pessoas a evoluir, definir e comunicar visão e estratégia, organizar a estrutura de equipe e definição de processos.

É muito importante que uma líder e sua equipe saibam quais são seus pontos fracos e seus pontos fortes para que ela possa construir uma equipe com pessoas que possam ajudá-la e a toda a equipe em todos os aspectos do desenvolvimento de produtos, incluindo aqueles que são seus pontos fracos. Os pontos fracos não devem ser escondidos. Eles devem ser conhecidos por todos na equipe para que possam lidar adequadamente com eles.

Resumindo

  • É muito difícil, se não impossível, ser um líder completo. E tudo bem!!! Só para ficar claro, por completo quero dizer bom em tudo que uma equipe precisa que um líder seja bom.
  • Um líder deve sempre se esforçar para ser um líder melhor, mas ser um líder melhor não significa ser bom em tudo. Significa entender os pontos fracos e ter um plano claro para lidar com os pontos fracos. Esse plano pode ser algum plano de desenvolvimento de habilidades ou ter alguém na equipe que possa endereçar os pontos fracos ou, minha opção preferida, uma mistura de ambos.
  • Os heads de engenharia normalmente vêm de uma sólida formação técnica e podem não ter outras habilidades importantes de liderança, como negócios, pessoas e processos. É importante mapear esses possíveis pontos cegos e desenhar planos para endereçá-los.
  • Tive a oportunidade de liderar equipes incríveis de desenvolvimento de produtos. Minha própria startup, Locaweb, Conta Azul, Gympass e Lopes. Apesar de ter alguma formação técnica e de escrever código no início da minha carreira, quanto mais eu ingressava na liderança e gestão de produtos mais distante ficava dos detalhes técnicos dos produtos construídos pelas equipes que liderei, e esse é o meu ponto fraco.
  • É muito importante que um líder e sua equipe saibam quais são seus pontos fracos e seus pontos fortes para que ela possa construir uma equipe com pessoas que possam ajudá-la e a toda a equipe em todos os aspectos do desenvolvimento de produtos, incluindo aqueles que são seus pontos fracos. Os pontos fracos não devem ser escondidos. Eles devem ser conhecidos por todos na equipe para que possam lidar adequadamente com eles.

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

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:

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: