Quando a ativação cai, todo mundo corre pro topo do funil, mexe na landing, no cadastro, no tráfego...
Inclusive essa era basicamente a primeira pergunta que eu fazia pras startups no Google Accelerator.
"Como tá sua jornada de usuário hoje?"
Se o founder ou o time de produto não sabia responder, eu já sabia que tinha um problema, quando sabia, ficava fácil achar onde ele estava.
Vou deixar um método simples pra achar furos no balde, é basicamente mapear toda a jornada do usuário até o recebimento de valor. Funciona assim:
⭢ #1: Define o que é "valor" no teu produto
Valor é o primeiro momento em que o usuário tira o resultado que você prometeu na LP, muita gente costuma confundir com "completou o cadastro" ou "terminou o tour", e aí mede a coisa errada.
Esse momento tem que ser uma ação que você consegue ver no teu dado e seja mensurável.
No RepareCar esse momento é a ordem de serviço.
Inclusive é uma métrica de sucesso, oficina com baixo número de OS significa pouco uso do produto, todo o resto é secundário.
Se meu usuário não cria OS, ou ele não tá usando a ferramenta, ou não tá entrando carro na oficina, as duas coisas são ruins.
Se você não consegue apontar a ação exata que gera valor no teu produto, para aqui e anota pra descobrir isso HOJE.
⭢ #2: Lista cada passo entre o cadastro e esse valor
Cada tela, cada clique, cada espera, cada campo.
TUDO!
Conectar integração, importar dado, convidar o time, configurar preferência, tudo que fica entre a porta e o primeiro resultado.
O primeiro aprendizado vem daqui, quase sempre são muito mais passos do que você lembrava.
⭢ #3: Mede quantos usuários caem em cada passo
Instrumenta e monta o funil: Clarity, PostHog, o que preferir, precisa medir quantos chegam no passo 2 contra o passo 1, no 3 contra o 2, e assim até o valor.
Você não tá procurando média, tá procurando o passo com a queda mais brusca, o ponto onde o número despenca de uma tela pra outra.
Idealmente deveria ser uma linha suave com alguma queda entre cada passo.
⭢ #4: Conserta o maior tombo primeiro
O instinto é mexer no primeiro degrau, lá no começo, a grana tá no de maior queda, onde você perde mais gente de uma vez só.
Parece contraintuitivo, mas o topo raramente é o problema, o vazamento costuma ficar no meio, no passo onde o esforço já é alto e o usuário ainda não viu nada que prove que vale.
⭢ #5: Diagnostica por que aquele passo tomba
Três causas possíveis:
Atrito: tá difícil demais ali, campo demais, passo demais. Conserto, cortar.
Confusão: o usuário não entende o que fazer naquela tela. Conserto, direcionar a atenção pra ação certa.
Ordenação: você pede trabalho antes de mostrar que compensa. Conserto, inverter a ordem, entregar um valor antes de pedir o esforço.
Conserta e mede, a menos que seja óbvio demais.
Conta quantos passos vêm antes do primeiro valor, cada um é uma chance de desistir, ativação alta mora no menor caminho até o primeiro resultado, não no produto mais completo antes dele.
Quase todo founder tem esse mapa na cabeça e nunca no papel, e o que tá na cabeça sempre parece mais curto do que é de verdade.
@fernandovife 1. Não é argumento, é info
2. O iFood perde dinheiro como qualquer empresa, a diferença é q eles recebem em dolar (vem d fora) e investem em real (100k dolar = 500k real)
3. É difícil de concorrer com o iFood apesar de ter 300 concorrentes, pois eles estão em tudo que é canto
Infelizmente esse tipo de decisão veio de fora, não é do iFood, é de quem comprou!
Tem uma ciência por trás disso, e por incrível que pareça, deu certo!
Como eu sei? Não interessa, apenas sei....
Fui tentar comprar no iFood pra um dev que mora no Brasil, 15 minutos depois desisti.
- Roleta, cupom que inútil e banner em todo lado
- Ordenar por avaliação não adianta
- Super Restaurante não muda nada
- Foto feita por IA
- Qdo não apresentação de centavos
agente matou um monolito que respondia em 10ms pra subir uns 20 microsserviço.
agora a request leva 800ms só passeando pela rede. a aws cobra o triplo e o log é um labirinto.
mas o diagrama da arquitetura ficou lindo no slide do tech lead. valeu a pena.
É esse o nível de confiança que uma esteira de testes robusta te dá.
Reescrever um runtime inteiro em 8 dias e mergear, sem quebrar tudo.
É pra aplaudir de pé.
E tem gente que acha teste automatizado inútil
@HamiltonSan É melhor desistir mesmo. Quem começou a estudar em 2015 e não conseguiu emprego em 2021-22, é preferível nem entrar na área.
Pelo bem do software no mundo.
Tenho um cliente que vende produto digital de low ticket em Portugal.
Faturamento maior que muitos SaaS da bolha dev brasileira.
Maior gargalo? Suporte.
Quando avisei que low ticket gera até 3x mais volume de suporte que ticket convencional, ele achou exagero e quis testar.
Testou. Confirmou.
Isso acontece por 3 razões:
1. Perfil de comprador diferente
Quem paga R$49 tem compromisso diferente de quem paga R$499, menos paciência para resolver sozinho, menor familiaridade com produto digital e mais expectativa de atendimento humano.
2. Decisão de compra impulsiva
Ticket baixo = fricção baixa = compra por impulso.
Usuário entra sem entender o que comprou, primeira reação?
Buscar suporte.
3. Custo de oportunidade invertido
Para cliente de ticket, o tempo dele vale mais que esperar suporte. Ele resolve sozinho.
Para cliente de ticket baixo, pedir suporte é mais fácil que procurar resposta.
E no caso de SaaS?
O que parece problema de suporte geralmente é problema de design.
Você reduz volume de suporte durante o próprio onboarding. FAQ contextual dentro do produto, interface que responde dúvidas antes de serem feitas.
Existe um case antigo com a McAfee onde foi reduzido 90% do volume de suporte implementando FAQ, na época sem nenhum tipo de chatbot, texto mesmo.
Automatizar suporte resolve esse sintoma, mas redesenhar a jornada resolve a causa e pode impactar também no churn.
Meu cliente está fazendo os dois, mas se tivesse feito o segundo antes, talvez não precisasse do primeiro.
Quem não se emocionou vendo isso daqui, já está morto por dentro!
Só quem acompanhou o professor dormindo no chão pra realizar o sonho dele, e conquistar, e hj, ser referencia pra muita gente aqui no br e lá fora, sabe o que é ser brasileiro e sempre lutar contra o mundo
Três planos. Free. Pro e Enterprise.
90% dos SaaS brasileiros.
Problema: você está deixando a decisão para o usuário.
Usuário com opções iguais demora a decidir, posterga.
Quem posterga não converte.
Efeito Chamariz: Quando você adiciona uma opção pior, a opção alvo parece melhor.
Não inventei isso, no o The Economist vendeu 3X mais assinaturas print + digital quando adicionou a opção "só impressa" pelo mesmo preço.
Ninguém comprou só impressa.
Mas todo mundo comparou e concluiu : "Impresso + digital é obviamente melhor"
Seu pricing:
Free: 0
Pro: 99
Enterprise: sob consulta
O usuário compara o Free com Pro, lógico que o Pro vai parecer claro.
Pricing com chamariz:
Starter: R$79 (com limitações irritantes)
Pro: R$99 (sem limitações)
Enterprise: Sob consulta
O usuário compara starter com Pro, e aí o Pro parece óbvio por R$20 a mais.
Conversão sobe de 10-20% em testes documentados, não porque você mudou o produto, mas porque você mudou a moldura de comparação.
Pq eu arranquei o Free?
Ancoragem: O primeiro número que a pessoa vê define o referencial. Seu pricing mostra Free primeiro, ancora o zero.
Tudo parece caro comparado a zero.
Pricing que converte mostra o preço maior primeiro, um preço anterior, um plano enterprise...
Pro a R$99 parece barato.
Mesmo preço, percepção diferente, conversão diferente, você está competindo contra seu próprio plano free.
E perdendo.
os dev discutindo arquitetura hexagonal por 2 horas na daily
o banco de prod tem 4 usuario
um deles é o pm fazendo teste
agente só queria jogar um go no cloud run e ir dormir mas o ego do tech lead precisa de uns pattern q nem o claudinho entende
vou contratar um dev jr p me ajudar na https://t.co/gYokZKDItY
o processo:
1. take home usando IA
2. 2-3 dias de trabalho pago direto na codebase
3. referencia & oferta
chama na DM se tiver interesse
@acgfbr Por esses e tantos outros motivos q eu evito de usar métodos de pagamento pequenos
Quando c trata do dinheiro necessário para manter o meu SaaS no ar, ñ posso esperar a boa vontade da empresa de me pagar
Kiwify/hotmart sempre! Pago os 10% de comissão rindo mas ñ me incomodo