Outros cases

História de Produto veja minhas decisões

Cada case aqui conta uma decisão pontual: o contexto, o que eu fiz, o resultado e o que aprendi.

01 · Varejo · app de vendas

Um app em 1 mês para quem tinha perdido a confiança

Assumi o app dos vendedores de uma varejista de moda depois que a versão web falhou e entreguei um app novo em 1 mês. Em 3 meses ele estava nas 52 lojas próprias, e a adoção foi de 60% para 92%.

Contexto: Os vendedores falam com os clientes pelo WhatsApp. A versão web que substituiu o app antigo abria uma página extra antes do WhatsApp, era lenta e fazia as pessoas perderem link e senha. O produto não era meu: eu trabalhava perto do time porque os dois apps compartilhavam microsserviços, e tinha recomendado app nativo desde o início.
O que eu fiz: Levantei o problema de novo e me ofereci para entregar uma versão mínima em 1 mês. Meu trabalho foi decidir o que ficava de fora. Reaproveitamos a maior parte da API, e limitei a versão 1 a três frentes: o fluxo principal (clientes, campanhas e meta), a autenticação, que era a maior dor, e a distribuição de clientes, que dependia de uma API lenta de fornecedor, onde conduzi os testes junto com o time do fornecedor.
Resultado: Lançamos no prazo, com nota máxima de satisfação no 1º mês. Começamos por São Paulo e, em 3 meses, estávamos nas 52 lojas próprias. A adoção foi de 60% para 92%.
O que aprendi: A versão web falhou pelo atrito do dia a dia: uma página a mais, lentidão, senha perdida. Hoje, quando assumo um produto rejeitado, a v1 ataca só o que trava a rotina e fica em poucas frentes; o resto espera a confiança voltar.

02 · E-commerce · dados

O funil que ninguém tinha

Quando o app próprio entrou no ar, ninguém sabia onde o cliente desistia. Estruturei o funil do zero, e ele passou a guiar as decisões que levaram a conversão de menos de 1% para 5%.

Contexto: Com o app no ar, não existia estrutura de funil: só usuários ativos, cliques, número de compras e faturamento. E os eventos não estavam mapeados corretamente, então os números não eram confiáveis.
O que eu fiz: Assumi a frente de dados, que não tinha dono. Mapeei os eventos com a engenharia, estruturei o funil, defini as métricas e montei o painel de clientes com o time de dados.
Resultado: O funil virou a base das decisões seguintes: a reconstrução da página de coleção e da PDP, o teste na home e o checkout novo. Ao fim desse programa, a conversão tinha saído de menos de 1% para 5%.
O que aprendi: Antes de confiar num número, confiro o evento: ele dispara uma vez, no gatilho certo, nas duas plataformas? Bate com outra fonte? O que mudou recentemente?

03 · E-commerce · experimentação

O teste inconclusivo que virou vitória

Um teste A/B da home estava inconclusivo e apontava contra a variante. Em vez de encerrar, levantei hipóteses, iteramos, e a variante acabou ganhando.

Contexto: Planejei e acompanhei o teste A/B da home, controle contra variante, de fevereiro a maio. Compra era a métrica principal e adição ao carrinho a secundária, com iOS e Android lidos separadamente.
O que eu fiz: No primeiro ciclo, a variante perdia nas duas plataformas, mas sem significância. Em vez de encerrar o teste ou lançar por gosto, localizei onde a perda acontecia: no meio do funil. Levantei hipóteses sobre a hierarquia de conteúdo e a clareza do CTA e especifiquei uma nova versão, com o valor mais claro e um CTA mais evidente.
Resultado: As hipóteses se confirmaram: a nova versão virou o jogo, e a variante ganhou.
O que aprendi: No primeiro ciclo a perda estava no meio do funil, não na home inteira. Hoje, antes de encerrar um teste inconclusivo, localizo em que etapa a variante perde e escrevo a próxima hipótese para essa etapa.

04 · E-commerce · IA generativa

Provador virtual com IA, validado em etapas

Defini como validar um provador virtual com IA antes de colocá-lo na frente do cliente. Lançamos em 2 etapas, e foi a abertura ao público que mostrou os casos que nenhum teste interno tinha pegado.

Contexto: A marca queria um provador virtual com IA generativa. Uma imagem ruim na frente do cliente prejudicaria a marca, então qualidade era o maior risco. A engenharia construiu a feature; as decisões de produto eram minhas.
O que eu fiz: Defini as métricas, os guardrails e os critérios de sucesso das imagens e conduzi testes com vários tipos de imagem. Desenhei o rollout em 2 etapas: primeiro interno (funcionários, família e amigos), depois clientes, só em coleções específicas.
Resultado: Os testes internos pegaram muita coisa, mas só a abertura ao público mostrou cenários que ninguém tinha imaginado. A feature foi para produção e o engajamento com o app subiu.
O que aprendi: O beta interno pegou muito, mas só clientes reais mostraram os casos que ninguém imaginou. Hoje toda feature de IA generativa sai com guardrails definidos antes e passa por um grupo restrito de usuários reais antes da abertura geral.

05 · Plataforma · decisão técnica

CMS: migrar agora ou não

Quando o Contentful cortou o plano gratuito que usávamos, o time quis migrar para o Strapi. Fiz um estudo de custo e escala e propus ficar mais tempo no Contentful, mantendo a engenharia focada no produto.

Contexto: Para gerenciar o conteúdo de um dos produtos, escolhemos o Contentful porque era mais rápido de integrar e o plano gratuito atendia a demanda estimada. Depois da implementação, o Contentful limitou várias funcionalidades do plano gratuito, e o time passou a considerar migrar para o Strapi, que é open source.
O que eu fiz: Fiz um estudo de custo e de como o nosso uso escalaria no Contentful ao longo do tempo, comparei com o esforço de migrar e levei a proposta para a engenharia.
Resultado: Ficamos mais tempo no Contentful, com a migração planejada para quando os números justificassem. O tempo da engenharia continuou no produto.
O que aprendi: Ficar no Contentful tinha um custo previsível; migrar tirava tempo de engenharia do produto. Hoje levo para a engenharia o custo projetado no tempo e o número que dispara a migração, para a troca acontecer quando o número mandar.

06 · SaaS B2B · discovery

Parar em vez de defender o trabalho

O discovery confirmou o problema, mas mostrou que o nosso produto não era a resposta certa. A direção tinha sido minha, e mesmo assim defendi parar. Refizemos o produto em 6 semanas.

Contexto: Uma plataforma B2B SaaS de Customer Revenue Intelligence. A direção da primeira estrutura do produto era minha. Construímos um protótipo funcional e conduzi mais de 10 sessões de discovery com potenciais clientes.
O que eu fiz: Os clientes confirmavam o problema, mas viam a solução como algo que já faziam ou poderiam construir, e se perdiam num menu de 12 opções. Separei a evidência sobre o problema da evidência sobre a solução, reduzi a navegação de 12 áreas para 5 fluxos e troquei o dashboard inicial por uma tela "Hoje", que mostra o que fazer agora e quais ações geram receita. Também construí o protótipo e o front-end.
Resultado: Refizemos o produto em 6 semanas, e hoje ele está com empresas na fase beta.
O que aprendi: Os clientes confirmavam o problema e mesmo assim se perdiam num menu de 12 opções. Hoje separo a evidência sobre o problema da evidência sobre a solução e testo se o usuário sabe o que fazer na primeira tela antes de tratar demanda como sinal para escalar.

07 · Pet care · precificação

Um preço que o cliente entendesse antes de agendar

O preço de cada serviço dependia do peso do pet e de várias outras variáveis. Transformei isso num valor claro no app, antes do agendamento, e foi isso que permitiu tirar o agendamento do atendimento manual.

Contexto: O preço de cada serviço dependia de muitas variáveis ao mesmo tempo e mudava conforme o peso do pet. Era o maior desafio do produto: o app só tiraria o agendamento do atendimento manual se o cliente conseguisse ver quanto ia pagar.
O que eu fiz: Desenhei a composição de preço para transformar todas essas variáveis em um valor claro dentro do app, antes do agendamento, e tratei a transparência de preço como parte do funil de conversão.
Resultado: Com o preço visível no app, o agendamento deixou de depender do atendimento, e os pedidos digitais foram de 20% (pelo site) para 80% (pelo app) no primeiro mês.
O que aprendi: O agendamento só saiu do WhatsApp quando o cliente passou a ver o preço antes de agendar. Hoje trato a regra de preço como uma etapa do funil e testo se ela é entendida antes de desenhar o resto do fluxo.