O ciclo de vida do produto: jornada de um recurso do produto

Este é o quarto post de uma série de cinco partes que estou escrevendo com o objetivo de ajudar um aspirante a produto a entrar no mundo do Gerenciamento de Produto.

No meu último post , dividi a disciplina de Product Management em quatro partes com o objetivo de ajudar os aspirantes a Product Management a entender sua trajetória de carreira dentro de uma empresa ou em geral. Neste post, falarei sobre a jornada de vida de um recurso de produto, da idealização ao abandono, para ajudar um aspirante a Gerenciamento de Produto a ter uma perspectiva de 360 ​​graus sobre o que envolve o papel de um Gerente de Produto.

T - 30 dias

Diz-se que a necessidade é a mãe da invenção. Esse é literalmente o caso em que o nascimento de um recurso do produto está envolvido. Tudo começa com algum nível de desconforto.
Algum funcionário da empresa sente desconforto em realizar uma de suas tarefas diárias – talvez a base de usuários tenha aumentado e ele não consiga gerenciá-la com os processos antigos. Algum executivo da empresa olha para uma planilha do Excel e acha que a empresa está perdendo muito dinheiro por causa, digamos, do alto número de cancelamentos de produtos. Ou talvez um concorrente tenha lançado um recurso de produto que está fazendo com que os clientes deixem o produto da referida empresa. Alguém olhando para o funil de conversão de marketing notou altas desistências em um determinado estágio e sentiu que otimizar isso poderia ajudá-lo a atingir sua meta trimestral. Ou podem ser 100 motivos diferentes, desde um alto número de reclamações de clientes por um problema comum até um novo recurso sendo exigido pela maioria dos usuários pesquisados ​​na semana anterior. O ponto é – tudo começa com algum nível de desconforto.

Agora, esse desconforto é levado ao conhecimento do Gerente de Produto; ou talvez o Gerente de Produto seja o primeiro a perceber. Este é o ponto que inicia uma cadeia de eventos que pode levar ao nascimento de um novo recurso.

T - 25 dias

É hora do Gerente de Produto refletir sobre a declaração do problema. Ele vai e conversa com clientes ou stakeholders internos que relataram o desconforto e depois com aqueles que realmente o estão vivenciando; tudo com um único objetivo – certificar-se de que ele identificou a declaração do problema 'raiz'. Se esta etapa for tomada de ânimo leve ou o Gerente de Produto não dedicar tempo suficiente a isso, as características do produto nascidas são frágeis, distorcidas e chegam ao fim rapidamente.
Uma vez que o Gerente de Produto tenha identificado a declaração do problema central, ele decide se vale a pena resolvê-lo. O desconforto é realmente grande ou é meio exagerado ou pior, apenas inventado? Resolver isso realmente agregaria valor significativo ao cliente e/ou à empresa? A solução não imporia uma penalidade significativa ao cliente e/ou empresa? Existe uma maneira de resolver esse problema com um pequeno ajuste nos processos ou por meio de qualquer atividade que não exija alterações no produto - por exemplo, mudar de fornecedor, negociar melhor preço de um fornecedor existente, obter um software de terceiros para resolver o problema, contratar um funcionário extra, alterações no conteúdo, gráficos, botão de call-to-action, etc?

Basicamente, se houver uma maneira de obter uma agregação de valor semelhante a partir de um método que não envolva mudanças no produto, então iríamos mudar qualquer coisa no produto – quer isso signifique adicionar ou remover. Uma vez que o Gerente de Produto esteja convencido de que resolver a declaração do problema fornecerá um valor significativo e uma mudança no nível do produto dará muito mais ROI (considerando tempo, dinheiro e esforço versus valor) do que uma mudança no nível do produto, as sementes de um novo característica do produto são plantadas.

T - 15 dias

Se o Gerente de Produto tiver alguma experiência anterior, ele poderá propor uma solução com base nessa experiência. No entanto, essa pode não ser a melhor solução em todos os casos.
Se a declaração do problema exigir uma solução altamente técnica, o Gerente de Produto discute o mesmo com desenvolvedores e gerentes de engenharia e recebe seus conselhos sobre a melhor maneira de fazê-lo. Se a solução exigir alterações no nível de design, o líder de UX pode ser consultado. Pode ser que o Gerente de Produto e a pessoa de UX organizem um sprint de design e escolham a solução que é bem recebida pelos usuários reais desse recurso. Às vezes, o problema está totalmente relacionado aos negócios e, portanto, exige a adesão da alta administração.
Portanto, pode haver várias maneiras pelas quais uma solução pode ser finalizada. Mas uma vez que é, o Gerente de Produto é responsável por converter essa solução teórica em um recurso ativo do produto.

T = 0 (também conhecido como nascimento do recurso do produto)

Quando uma solução específica é identificada, o Gerente de Produto, em colaboração com a equipe relevante, traça um esboço básico da solução. Pode ou não incluir um protótipo da solução. Às vezes, é apenas uma planilha básica do Excel com condições 'se-então' escritas para quando mostrar um CTA específico para um usuário, etc.
O Gerente de Produto coloca a solução em palavras no PRD (Documento de Requisitos do Produto) relevante. Se o recurso for pequeno, pode ser apenas um parágrafo em um PRD existente para um recurso maior. Às vezes, o recurso é tão grande que requer um PRD completo apenas para detalhá-lo corretamente. O PRD é executado pelas equipes relevantes e o Gerente de Produto garante que exista um amplo consenso em relação ao recurso.

T + 15 dias

Pequenos recursos podem levar menos de um dia para serem congelados. Grandes recursos, às vezes, levam mais de 30 dias para obter a aprovação de todos.
Vamos levar em média 15 dias para dizer que este é o momento em que o recurso recém-nascido é apresentado aos desenvolvedores. Um design adequado e entrega de PRD ocorrem onde os desenvolvedores que estão trabalhando no projeto são informados sobre os 5Ws (O que, Por que, Quando, Onde, Quem) e os casos de teste (como o recurso deve se comportar ou não após ser lançado) .
Juntamente com o gerente de engenharia, um cronograma de lançamento adequado é decidido para o recurso com prazos para quando o desenvolvimento terminará, quando os testes começarão, quando os bugs relatados serão corrigidos e a data final de lançamento. Em seguida, toda a linha do tempo é dividida em sprints mensuráveis ​​(geralmente 15 dias). Uma vez que os desenvolvedores estão satisfeitos, o desenvolvimento começa.

T + 30 dias

O Sprint 1 termina. Uma parte do recurso do produto é lançada. Pode não ser voltado para o cliente ainda, mas a maioria das equipes segue as metodologias ágeis hoje para desenvolvimento de software – o que significa que construímos de forma incremental e iterativa. Então, em vez de construir um grande recurso em 6 meses e lançar tudo de uma vez, dividimos tudo em partes independentes que podem funcionar por conta própria (um monte de histórias de usuário) e estão rapidamente prontas para serem revisadas e iteradas.
O Gerente de Produto garante que o cronograma de lançamento esteja no caminho certo por meio de reuniões diárias de Scrum e discussões com o gerente de engenharia relevante que trabalha no projeto. Caso haja um atraso, os cronogramas são ajustados de acordo ou pequenas partes dos recursos são descartadas para garantir que o lançamento seja pontual. Após cada sprint, o progresso realizado é apresentado ao Gerente de Produto e aos stakeholders relevantes em uma reunião, e após a aprovação é divulgado.
Um ano do programa de gerenciamento de produtos da UpGrad

T + x dias

Após 'n' número de sprints, o desenvolvimento está completo e todo o recurso está fora. Não é necessário que os clientes usem o recurso apenas quando liberado completamente. Eles podem estar usando-o desde o lançamento no final do próprio sprint 1. Cada versão subsequente do ciclo de sprint apenas torna o recurso mais robusto e o aproxima do que deveria ser.
Lançar um recurso em si é uma arte e envolve muitas etapas que vamos pular e apenas assumir que, depois de muita bateria e pancadas no peito, foi declarado ao mundo que um recurso foi lançado. Isso pode ser tão complexo quanto um comunicado à imprensa completo com o próprio CEO falando sobre o novo lançamento, ou pode ser apenas algo em que um e-mail é enviado para um departamento específico que usará o recurso e provavelmente o solicitou em o primeiro lugar. Então, agora que o recurso está disponível, vamos dar um nome a esse recurso – Sr. Recurso.

T + y dias

Mesmo após o lançamento final, as coisas às vezes dão errado. Mr. Feature, que já foi todo brilhante e valioso, pode não ser mais o mesmo e pode haver várias razões para isso. Esta fase no ciclo de um produto é sobre o suporte ao produto. Um belo dia, outro lançamento foi feito que fez com que o Mr. Feature funcionasse de maneiras não intencionais (também conhecido como buggy) ou talvez outro recurso tenha sido removido que tinha algumas dependências do Mr. Feature e isso causou o comportamento de buggy. Também pode ser que, quando o recurso foi criado, subestimamos o número de usuários que o usarão ou não planejamos todos os casos de uso e agora o recurso não pode ser dimensionado para esses muitos usuários ou casos de uso.

Isso é relatado pela equipe de teste em sua revisão periódica ou é relatado por algum membro da equipe que acabou de descobrir enquanto usava o próprio recurso. No caso de recursos voltados para o cliente, essas reclamações podem vir dos clientes reais do produto e ser comunicadas ao Gerente de Produto por meio da equipe de Experiência do Cliente.

O Gerente de Produto tenta entender a causa raiz do bug e, de acordo com a prioridade, agenda a correção para o próximo ciclo de lançamento – ela pode ser adicionada no sprint atual se for de alta prioridade ou até sprints subsequentes. Depois que o bug é corrigido e lançado, o Mr. Feature vive para ver outro dia, embora em uma forma reformada – Mr. Feature 2.0 – graças ao Gerente de Produto e à equipe de engenharia. Parabéns!

T + z dias

Diz-se que todas as coisas boas devem chegar ao fim. Infelizmente, esse também é o caso do Mr. Feature, não importa qual seja sua versão – talvez o Mr. Feature 9.263.75! Isso significa que o Sr. Feature viveu uma vida longa e feliz, mas agora o fim da estrada está aqui.
Pode ser por vários motivos. Surgiu um novo recurso que tornou a necessidade do Mr. Feature totalmente redundante. Pode ser algo extremo também – como se a empresa decidisse que, embora o recurso estivesse agregando valor aos seus usuários, não fazia mais sentido econômico para eles.

Não importa qual seja o motivo, é comunicado ao Gerente de Produto (ou é ele quem inicia a discussão) que os serviços do Sr. Feature não serão mais necessários. Agora, por mais doloroso que seja, o Gerente de Produto tem o dever de deixar o Sr. Feature para descansar. Embora, antes disso, ele precise se certificar de algumas coisas, como informar aos usuários que estavam usando o Mr. Feature que ele não estará disponível a partir de uma determinada data, o novo recurso está funcionando bem antes de remover o Mr. Feature, nenhum outro o fluxo é afetado quando o Sr. Recurso desaparece e assim por diante.

Então, é hora de dizer RIP ao Sr. Feature. Em sua carreira de gerenciamento de produtos, você terá que fazer isso várias vezes. Mas lembre-se, o fim de um recurso é o início de outro e o ciclo continua. Essa é a vida de gerenciamento de produtos!

Estude cursos de gerenciamento de produtos online das melhores universidades do mundo. Ganhe Masters, Executive PGP ou Advanced Certificate Programs para acelerar sua carreira.

Programa em destaque para você: Programa de certificação em Design Thinking da Duke CE