Quem atua com produtos digitais, seja como Product Owner ou Product Manager, sabe que há infinitos cursos sobre Product Management com foco em estratégica, tática, frameworks, métricas, etc. Eu mesma já cursei vários cursos de produto e continuo cursando na minha jornada lifelong learning.
Mas há aprendizados que só a vivência traz, ou melhor, que somente as dificuldades enfrentadas na prática (ou seja, os incêndios, “BOs”) – muito além da teoria – proporcionam. Nesses momentos, “criamos casca” e ficamos mais preparados para encarar um desafio semelhante no futuro. Algo que nem sempre acontece ao aprender teoria por cursos, pois nem sempre vivenciamos a teoria estudada ao mesmo tempo dos fatos de nosso cotidiano.
O objetivo deste artigo é compartilhar algumas práticas que vivi que podem lhe ajudar no seu momento atual, ou ainda lhe trazer memórias (talvez não tão boas) caso você se identifique com as mesmas dificuldades. Let’s go!
Feature Flags: chave liga/desliga de funcionalidades
Feature flag ou feature toogle (conforme martinfowler.com) é o termo em inglês para chave liga/desliga de funcionalidade. Sem mesmo aprender sobre isso na teoria, percebi que há situações de maior criticidade ao lançar uma nova funcionalidade que exigem agir rápido caso o efeito em ambiente de produção não seja o esperado, e que nem sempre rollback será rápido e que haverá alguém de tecnologia disponível e capaz para fazê-lo em algum cenário de urgência.
Ter uma flag on/off significa dar autonomia para o PO/PM e/ou área de negócio-cliente ativar ou desativar uma funcionalidade de maneira rápida e fácil, sem dependência de um desenvolvedor, sem depender do time de engenharia.
Além disso, já atuei em plataforma de e-commerce que ter uma funcionalidade com chave liga/desliga me permitiu realizar teste A/B para essa feature, pois para determinada % do tráfego (controle) a plataforma considerava o default de chave desligada, e outra % do tráfego veria a versão variante com a chave ativa, ou seja: expor a nova funcionalidade de maneira controlada para baixa quantidade de usuários e posterior crescimento gradativo, conforme resultado do experimento elaborado a partir da feature flag.
A tríade de PROJETOS: prazo, escopo e custo
Embora o foco aqui é falar sobre gerenciamento de produtos digitais, sabemos que há MUITO de projeto envolvido no dia a dia de Product Managers quando envolve o lançamento de um novo produto, entrega de uma grande funcionalidade, ou ainda qualquer adequação que envolve prazos pré-determinados (como adequação a alguma legislação, ou ainda para algum grande evento, como Black Friday).
Entregas must have e nice to have
O trabalho em produtos digitais e projetos envolve muito alinhamento (ou gestão) de expectativas, ou seja: stakeholders (área de negócio-cliente) têm expectativas sobre as entregas que serão feitas conforme prometido, especialmente sobre funcionalidades e prazos.
Por isso, é essencial ter alguns combinados pré-definidos para evitar expectativas frustradas que podem comprometer a área cliente e prejudicar seu desempenho e capacidade de liderança.
Antes de prometer entregas completas dentro de um prazo pré-definido:
- Defina o que é essencial para o produto digital funcionar. O mínimo necessário. Essas funcionalidades essenciais são o “must have” do produto. Sem elas, o produto não funciona. O golive (ou seja, o dia do lançamento) é apenas o dia da virada, da migração, de ativar em produção com todas as entregas must have garantidas.
- Defina o que pode ser feito após a entrega do projeto: pós-golive e backlog, sendo pós-golive o que realmente precisa ter foco a e ser feito assim que o lançamento em produção acontecer. Chamo de “nice to have” no sentido de, se der tempo de fazer e entregar para o golive, ótimo! Será um plus, overdelivery, expectativas superadas. Mas se não for possível e ficarem para após o lançamento, sem problemas, pois são entregas que não foram prometidas para esse grande dia.
- E backlog é o que será feito no futuro se, passada as entregas “nice to have“, as demandas desse backlog ainda fizerem sentido, ainda solucionar dores (afinal, as prioridades já poderão ter mudado, e tudo bem por ser um contexto ágil).
Com as entregas definidas entre must have, nice to have e backlog, comunique os stakeholders, os times interessados no produto digital em construção. Se alguém quiser cobrar por algo já no lançamento que não seja must have, é fundamental argumentar que essa entrega poderá ser feita depois, evitando atrasos para o golive que irão afetar muito mais pessoas interessadas no produto.
Exemplo: o que seria must have para um e-commerce? O mínimo necessário é conseguir comprar. Para isso, envolve cadastrar produtos, ter uma homepage, páginas de categoria (PLP), páginas de produto (PDP), carrinho e checkout funcional. Isso é o mínimo pra colocar uma loja virtual no ar.
Busca interna, carrosséis de recomendação, avaliação de produtos (review), criar cupons promocionais e até mesmo uma área logada com status da entrega podem ser feitos depois. Como nice to have nesse exemplo, busca interna, criar cupons de desconto e ter alguma maneira de comunicar status da entrega (por e-mail, área do cliente) seriam importantes como próximas entregas pós-golive, pois são recursos bem triviais de e-commerce. Se forem entregues no dia do golive, perfeito! Mas lembre-se: para ter status de entrega do pedido… precisa ter pedido. Por isso que ser possível comprar é must have enquanto status da compra pode ser nice to have.
E backlog? Ainda no foco em e-commerce, comunicar status da entrega por WhatsApp seria muito interessante para o futuro, por exemplo. Assim como lista de favoritos, entre outros recursos que ajudam em fidelização…. depois do cliente já ser capaz de comprar.
Funcionalidades que não existem no produto vigente enquanto um novo é construído também valem ser analisadas como backlog. Se não existem hoje, por que seriam essenciais na migração para um novo produto?
Mas nem sempre foi assim pra mim…
O relato acima pode parecer simples e óbvio, mas nem sempre foi óbvio pra mim como é hoje.
Mais de 5 anos atrás, participei como business owner na construção de um novo site em que era escopo totalmente completo e fechado (sem definição entre must have, nice to have e backlog) com prazo literalmente “cravado na pedra” e orçamento apertado, o que me faz acreditar hoje, olhando pra trás, que esse custo menor pode ter ocasionado time enxuto (ou com pouca experiência) para atuar num grande escopo em prazo “desafiador” para tudo que era necessário entregar.
O que aconteceu? Não deu tempo de entregar tudo no prazo, stakeholders irredutíveis em ampliar o prazo, testes pendentes. Lançamento feito com entregas não concluídas e negociadas para serem entregues em até 2 meses depois. Se você também tiver senso de dono e comprometimento, não recomendo cenário como esse, porque serão dias muito tensos (sendo que poderiam ser dias de comemoração se houvesse maior planejamento conforme dicas deste artigo).
Defina apenas 1 dono do projeto/produto (owner)
Há 2 situações que podem ocorrer quando não há um dono que irá conduzir, liderar cronograma e áreas envolvidas para garantir expectativas atendidas e sem frustrações.
- Sabe aquele ditado que diz “cachorro de 2 donos morre de fome”? Exatamente isso que pode ocorrer – atrasos porque uma pessoa pode confiar que outra está conduzindo, garantindo as entregas… e vice-versa. No final, ninguém está acompanhando nada de perto, e agendas de follow-up perdem a credibilidade, deixam de ser priorizadas pelos times por falta de status concreto. O que ocorre no final? Correria perto do limite de prazo para entregar “o que der”, horrível.
- Porém o inverso, com “vários donos” participativos, também pode se tornar um problema de atraso para cumprir o cronograma. O que é must have? O que é prioridade? Nem todo mundo entende sobre o que é essencial a fazer para o lançamento, conforme explicado sobre entregas must have. Pedidos e solicitações surgem de diferentes times porque cada um só enxerga as suas próprias prioridades para o “grande dia” do novo produto em produção. Mesmo que sejam entregas zero importantes para esse dia, e que podem ser feitas posteriormente, principalmente quando são funcionalidades que nem sequer existem hoje na rotina ou no produto vigente (!). O resultado? Tempo passando, demora para lançar o produto ao mercado = demora para começar a colher os frutos financeiros depois de tanto trabalho.
Product Delivery: fatiamento de entregas incrementais
Conforme a própria metodologia ágil prega, é fundamental exercitar fatiamento de funcionalidades em entregas incrementais.
Parece simples na teoria, mas a prática exige uma visão mais holística do produto para conseguir quebrar grandes entregas em versões menores, e ganhar tração com a área de negócio para começar a coletar feedback do cliente o mais rápido possível.
Essa capacidade de enxergar como dividir entregas menores melhora com o tempo: é a bagagem da experiência que aperfeiçoa – só o tempo e uma boa relação com o time de engenharia e líder técnico para conseguir enxergar oportunidades de entregas incrementais com mais clareza.
É muito mais simples e fácil pensar na entrega completa de uma funcionalidade, levantar todas as dores e começar a desenvolver, afinal, a gente quer atender todas as necessidades dos clientes, surpreender stakeholders. Porém, quanto tempo isso vai levar? Quanto esforço vai precisar? O cliente irá conviver com essa dor por quanto tempo até a solução ficar pronta?
Com o tempo, as áreas de negócio e stakeholders começam a se acostumar com entregas incrementais, e não lançar tudo de uma vez deixa de ser um problema interno. A razão para isso é que essas áreas clientes começam a ver resultados e ações de maneira mais rápida, além de ter certeza de que há um time trabalhando para atender as dores da empresa, as dores dos clientes.
Quick-Win! Entregas rápidas, feedback rápido
Há um termo em inglês comum na área de produtos que é “quick-win“, “vitória rápida” em tradução literal. Em resumo: o que conseguimos fazer com menor esforço e em menor tempo para já começarmos a tratar determinada dor? Mesmo que seja algo paliativo, até que construções incrementais sejam desenvolvidas, mas para que determinadas métricas comecem a ser alimentadas com dados de uso e retroalimentem as hipóteses de solução.
A cada entrega incremental, mais a gente entende o que tem funcionando e o que não tem, até mesmo para definir entregas em sequência. Inclusive, algumas entregas fatiadas para serem feitas no futuro podem cair de prioridade e não serem mais necessárias. Com isso, não se perde tempo construindo algo gigante sem a certeza de que realmente tudo será necessário para resolver determinados problemas.
Conclusão…TL;DR
Espero que as dicas deste artigo sejam úteis para evitar atrasos, requisitos prejudicados e expectativas frustradas. Resumo em tópicos:
- Para funcionalidades de maior impacto, acrescente na especificação ao time de engenharia a inclusão de uma feature flag/toogle, uma chave liga/desliga de fácil acesso pelo negócio;
- Se você tiver prazo para alguma grande entrega, defina quais entregas serão must have (obrigatórias para o lançamento) e quais entregas serão nice to have (não requer estarem prontas para o lançamento, mas a serem desenvolvidas após golive). Apresente essa divisão aos stakeholders e alinhe expectativas;
- Defina apenas um único dono (ou seja você essa pessoa) responsável para liderar e conduzir uma grande entrega: cobrar os envolvidos e comunicar andamento no decorrer do prazo, sem surpresas negativas para nenhum time durante o cronograma;
- Por fim, como entregar algo mais rápido, de baixo esforço e que já começa a tratar a dor do cliente? Mesmo que seja um paliativo até a construção completa da solução final. Lembre-se: melhor um paliativo temporário do que nada. E quem sabe você descobre que o paliativo já soluciona e se torna uma solução permanente, sobrando tempo para outras demandas.
Espero que no decorrer de sua trajetória, você não se depare com a ilustração ao alto deste artigo: preocupação sem saber o que fazer enquanto os dias vão se aproximando cada vez mais do grande dia de lançamento. Mas pelo contrário, que sua liderança na condução de uma grande entrega seja sucesso com expectativas atendidas! Não deixe de conferir também o artigo Soft-Skills no Gerenciamento de Produtos Digitais.
Esse artigo foi 100% escrito por (minha) inteligência humana.