O seu produto de software pode ter chegado aqui por três caminhos diferentes:
Independente do caminho seguido – maturidade não programada, não cruzar o abismo ou maturidade programada –, você eventualmente chegou ao que é conhecido como o fim de vida do produto. Em inglês, usa-se um termo mais elegante, o sunset do produto.
Assim como todas as fases anteriores, essa também terá de ser gerenciada. Engana-se o gestor de produtos que acredita que, quando um produto chega ao fim de vida, termina-se o trabalho de gestão de produtos. Ao contrário, essa fase requer tanta atenção quanto as anteriores.
O primeiro passo é reconhecer que chegou ao fim de vida, e um ótimo indicador é avaliar se o custo de manter o produto é maior que o retorno que ele dá. Se isso acontecer, existe um forte indicativo de que ele está entrando nessa fase.
A decisão pelo fim de vida de um produto não é científica. Os números ajudam bastante nessa decisão; porém, como explicado no capítulo Considerações sobre métricas, além das métricas, é preciso usar outras informações como a experiência, a intuição, o julgamento e as informações qualitativas para se tomar a decisão de fim de vida do produto.
Cada um dos três possíveis caminhos que seu produto pode ter feito para chegar ao fim de vida vai trazer consigo fatos e considerações específicas para essa tomada de decisão. Normalmente, ela feita em comitê, com as pessoas que trabalham com o produto e os executivos da empresa.
Caso seu produto tenha de fato entrado no fim de vida, o gestor de produtos precisará gerenciar essa fase. A decisão e seu gerenciamento dependem do caminho seguido por ele para chegar a ela, e é isso que vamos ver nas próximas seções.
Esse é o pior dos casos pois, além de não planejado – como é o caso do fim de vida após a maturidade programada –, é uma situação difícil de identificar. Antes de decretar que é o fim de vida do produto, é preciso ter certeza de que isso não é só temporário. O mais comum nesses casos é deixar o produto dormente por um tempo.
O que significa dormente? Significa não investir em seu desenvolvimento e marketing, e observar como ele se comporta. Ele parou de crescer? Ou ele cresce muito devagar? Faz sentido parar de vendê-lo? Ou pode-se deixar o produto sendo comercializado por mais algum tempo? Após algum tempo dormente, deve-se reavaliar se vale investir novamente nele.
Esse foi o caso do produto PABX Virtual da Locaweb, que decidimos deixar dormente por uns 3 anos, sem nenhum investimento de marketing e de desenvolvimento, para podermos investir em outros produtos. Mesmo sem nenhum investimento, a quantidade de clientes não diminuiu. Inclusive, em certos momentos, houve até um crescimento. Esse crescimento, quando acontecia, era bem pequeno, mas não deixava de ser um crescimento. Por esse motivo, decidimos voltar a investir no produto.
Outro exemplo, já comentado no capítulo anterior, foi o caso do produto Hospedagem de Sites da Locaweb que, por nos focarmos demais em métricas e desconsiderarmos nosso conhecimento empírico, acabou entrando em uma situação de não crescimento que, felizmente, pôde ser corrigido. Não era o fim da vida útil da hospedagem na web. Foi uma desaceleração do crescimento que causamos ao produto.
Por isso quero dizer novamente para se ter muito cuidado para não tomar uma decisão precipitada, pois o fim de vida por maturidade não programada é extremamente difícil de ser identificada.
Se você realmente tiver certeza de que seu produto chegou mesmo ao fim de vida, você precisará gerenciar essa fase. A primeira decisão que você deverá tomar, junto com o comitê que mencionei – composto por pessoas que trabalham com o produto e executivos da empresa –, é se você vai descontinuar o produto ou deixá-lo dormente. Essa decisão será baseada no retorno que ele estiver dando para a empresa e no custo de mantê-lo.
Se o produto ainda der um retorno considerável, é provável que vocês decidam por mantê-lo e façam esforços para reduzir o custo de manutenção. O gestor de produtos será o responsável por coordenar os esforços de redução de custo de manutenção, e por avaliar se esses custos estão menores do que o retorno que o produto dá.
Por outro lado, se o retorno desse produto for pequeno, ou seus custos operacionais forem muito grandes e não passíveis de redução, é provável que vocês optem por descontinuá-lo. Nesse caso, o gestor deverá coordenar todos os passos necessários para descontinuar o produto, que incluem:
Se seu produto entrar no fim de vida por não cruzar o abismo, apesar de essa não ser uma situação desejada pelo time de desenvolvimento, é uma situação importante que precisa ser identificada rapidamente, e o gestor de produtos tem papel fundamental para detectar isso.
Essa situação é mais fácil de ser detectada, pois o produto não cresce. Ele conquista alguns poucos clientes, os early adopters, e depois para de crescer. Nesse ponto, você deve avaliar junto com o gestor de marketing se a estratégia de comunicação do produto está sendo eficiente e se está atingindo as pessoas que têm o problema que o seu produto se propõe a resolver.
É importante também entender com os possíveis clientes se o produto não só resolve o problema como também como eles estão dispostos a lhe remunerar por esse produto. Sempre é possível fazer ajustes no produto e no seu modelo de comercialização para adequá-lo aos seus clientes.
Contudo, se mesmo após avaliar essas questões e tentar fazer ajustes no produto e/ou no seu modelo de comercialização, você não estiver conseguindo fazê-lo crescer, é hora de decretar seu fim de vida. Quanto antes você chegar a essa decisão, melhor, para não perder tempo e investimento em um produto que não vai vingar.
Nesse caso, como o produto tem uma base pequena de clientes, as opções de mantê-lo dormente por ter uma receita considerável não faz sentido. Sendo assim, a única decisão viável é descontinuar o produto. Como no caso do fim de vida por maturidade não programada, aqui também o gestor de produtos deverá coordenar todos os passos necessários para descontinuá-lo, que são os mesmos descritos anteriormente na seção Fim de vida por maturidade não programada.
Essa é a melhor das três opções para o dono do software, mas é a que dará mais trabalho para o gestor do produto. No caso de software instalado, isso acontece quando novas versões são lançadas. Para software online, isso ocorre quando o time de desenvolvimento opta por reescrever o produto por algum motivo, e decide lançar uma nova versão. Essa decisão por reescrever um produto online deve ser muito bem pensada, pois o tempo gasto em reescrever seu produto é tempo não utilizado em sua evolução do ponto de vista de quem o usa.
Pode acontecer que seu produto não tenha sido devidamente planejado do ponto de vista técnico e agora você esteja em um ponto em que: ou reescreve, ou o produto não poderá mais evoluir. Entretanto, cair em uma situação como essa deveria ser exceção, e não parte normal do ciclo de vida de um produto online.
Resumindo: Para software instalado, o fim de vida por maturidade programada é intrínseco ao modelo de negócios, enquanto para software online, o fim de vida por maturidade programada deve ser sempre exceção.
Como esse tipo de fim de vida pode ser programado, o gestor de produtos deve, em conjunto com UX e engenharia de produtos, desenhar como será essa fase, sempre visando ao mínimo de impacto para os clientes. Na Locaweb, no nosso produto de e-mail marketing, chegamos a um ponto em que tivemos de mudar o banco de dados. Usávamos MongoDB que, por problemas de projeto, não estava sendo capaz de aguentar o crescimento do produto; por isso, decidimos por mudar a base de dados para PostgreSQL.
Desenhamos essa reescrita do produto de tal forma para que o cliente não fosse impactado negativamente quando a nova versão com o PostgreSQL fosse implementada. Nada mudou na forma dos clientes usarem o produto. O único impacto percebido por eles foi que o produto estava com performance melhor, o que era esperado por nós.
Este é o ponto mais importante a ser pensado em relação ao fim de vida programado: o que vai acontecer com os clientes que estão na versão atual, que passará a ser a versão “velha”, quando lançarmos a nova? Isso tem de ser pensado com muito cuidado, e o foco tem de ser sempre em um impacto mínimo para o cliente.
É lógico que, quando a nova versão tem interface e interação diferentes da versão antiga, o cliente será impactado. É muito importante fazer testes com alguns deles para medir o impacto antes de forçar a mudança para toda a base de clientes. Em algumas situações, você pode até decidir por manter a versão antiga por algum tempo, dada a dificuldade de trazer os clientes para a versão nova. Mas, não se esqueça, o foco é sempre fazer seu cliente sofrer o mínimo possível.
Vimos em detalhes nos capítulos anteriores todo o ciclo de vida de um produto de software, passando por todas as suas fases: a inovação, o crescimento, a maturidade – que pode ser programada ou não –, e o fim de vida – que pode vir após a maturidade ou quando o produto não cruza o abismo que separa a fase da inovação da fase do crescimento.
Para concluir esse tema sobre ciclo de vida, vamos falar agora sobre a diferença entre startup e gestão de produtos de software; diferença esta, que tem muito a ver com o ciclo de vida de um produto de software.
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.
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: