Para que serve uma persona de verdade
Persona não é ficha de personagem de RPG. É uma representação sintetizada de um grupo real de clientes ou usuários, baseada em dados coletados, e usada como referência compartilhada por produto, marketing e vendas. A técnica de criação de personas no universo das startups a técnica de criação de personas é frequentemente confundida com exercício criativo, e essa confusão custa dinheiro. Começa assim: você entrevistar dez pessoas, agrupar padrões, nomear os perfis e transformar o resultado em decisões de produto.
no universo das startups a técnica de criação de personas
A forma como eu tenho feito isso nas últimas rodadas é direta. Primeiro, defino o recorte. Startup não tem público "todos os jovens que usam celular". Recorto por comportamento e contexto de uso, não por faixa etária isolada. Depois, rodo entrevistas semiestruturadas. Dezoito a vinte entrevistas costumam ser suficientes para estabilizar os padrões principais em mercados B2B mais estreitos. Para B2C amplo, preciso de trinta a quarenta, ou dados secundários robustos de analytics. Coloco as citações brutas em um painel. Destaco frases que se repetem, comportamentos observados e objeções reais. Agrupo por similaridade funcional: quem faz a mesma coisa, sob as mesmas condições, com o mesmo motivo. Nomeio os grupos. Acho o nome útil apenas se ele for operacional. "Marcos, 34 anos, gerente de operações" é rótulo. "Carlos, que resolve relatórios manuais antes do fim do expediente porque o sistema atual trava na exportação" é persona.
Aqui vai um detalhe que pouca gente aplica na prática. Eu nunca construo menos de duas personas primárias para um produto novo. Uma terceira só entra quando o comportamento do usuário se divide de forma clara. O erro comum é criar cinco perfis e terminar com ninguém lembrando qual deles decide a compra. Dois perfis fortes geram mais clareza do que cinco perfis rasos. Se o produto atende segmentos diferentes, trate como linhas de produto distintas, não como expansão de personas.
Como eu monto a persona, passo a passo
O processo que eu aplico leva de cinco a sete dias úteis, dependendo da disponibilidade dos entrevistados e da qualidade dos dados existentes.
Passo um: recorte e hipótese
Defino o problema central do produto. Anoto a hipótese de quem sente essa dor com mais intensidade. Esse recorte inicial evita entrevistas aleatórias. Eu já chego sabendo quem procura. Em produtos B2B, o recorte costuma vir por função e maturidade tecnológica. Em B2C, vem por contexto de uso e frequência.
Passo dois: entrevista com foco em comportamento
Eu pergunto ação, não opinião. "O que você faz hoje quando precisa resolver X" rende mais que "você gostaria de uma solução para X". Gravo as sessões e transcrevo só as partes relevantes. Levo cerca de quinze minutos por entrevista para gerar anotações estruturadas. O importante é capturar o workflow atual, os gatilhos e os pontos de atrito.
Passo três: análise e agrupamento
Coloco tudo num quadro. Destaco padrões repetidos. Agrupo por comportamento, não por demografia. Demografia entra como dado complementar, não como base. Eu costumo usar códigos curtos nas citações: C1 para cliente novo, R1 para cliente recorrente, P1 para produto concorrente. Isso agiliza a leitura posterior.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Passo quatro: perfil nominal
Crio fichas objetivas. Nome fictício. Idade aproximada. Contexto profissional ou de vida. Objetivo principal. Principais dores. Limitações atuais. Cenário de uso típico. Tomo cuidado para não inventar dados. Se não sei, registro como lacuna. Persona com lacuna declarada é melhor que persona com suposição mascarada.
Passo cinco: validação rápida
Levo o rascunho para três a cinco pessoas do público-alvo. Pergunto se aquilo soa verdadeiro. Aplico duasrodadas rápidas. Ajusto o que estiver distante. Isso consome cerca de uma hora do meu tempo e evita gastar semanas em um desenho equivocado.
Um caso específico que moste onde a coisa trava
Em um projeto recente de fintech B2B, eu identifiquei duas personas claras. A primeira era o gestor financeiro que precisava de conformidade e rastreabilidade. A segunda era o analista operacional que precisava de velocidade na rotina. O problema surgiu quando vendas e produto passaram a usar a mesma ficha para decisões opostas. O gestor pedia integrações pesadas. O analista pedia interface enxuta. O produto ficou morno nos dois lados. A solução que funcionou foi separar as personas por etapa do funil e por nível de autorização. Criei uma persona para decisão e outra para execução. Defini claramente quem aprova, quem usa e quem conserta. Aí sim, as reuniões de produto ganharam critério. Se você tiver mais de um tomador de decisão no cliente, trate cada um como persona própria. Não mistura papel de comprador com papel de usuário final.
O que eu faço diferente do manual genérico
Eu transformo a persona em critérios de decisão. Não deixo ela apenas decorada num PDF. Adiciono uma seção chamada "o que isso descarta". Uma persona bem escrita já elimina propostas que não fazem sentido para aquele perfil. Isso economiza tempo em review de features. Na prática, reduz o tempo de triagem de ideias de uma média de duas horas por semana para quinze minutos, quando o time já domina as fichas. Também anoto fontes de dados. Cada afirmação importante recebe referência: número de entrevistas, trecho transcrito, métrica de analytics quando disponível. Isso impede que persona vire doutrina intocável. Se o dado muda, a persona muda. Revisão semestral é o mínimo para produtos com ciclo de atualização rápido. Produtos B2B mais lentos aguentam revisão trimestral.
Pegadinhas que eu vejo todo dia
A primeira é usar dados de pesquisa de mercado genéricos para construir persona de produto específico. Dados de indústria servem como pano de fundo. Eles não substituem entrevistas com o usuário real do seu fluxo. A segunda é persona baseado em feedback espontâneo de redes sociais. Comentários públicos tendem a representar os mais insatisfeitos e os mais entusiastas. Você perde a maioria silenciosa. A terceira pegada é persona como documento estático. Quando eu vejo ficha que não é consultada nos sprints, ela já morreu. Eu coloco as fichas no kanban do produto, linkadas às histórias de usuário relevantes. A persona deve aparecer em requisitos, em testes de usabilidade e em revisões de priorização. Senão vira enfeite.
Limitações honestas
Persona não funciona bem quando o produto é altamente personalizado ou quando cada cliente tem um fluxo distinto. Em contratos B2B customizados, persona vira generalização perigosa. Nesses casos, eu uso perfis de conta e jornadas porVertical em vez de personas tradicionais. Também tenho problemas com personas para públicos muito novos, sem histórico de uso. Aí a melhor aposta é pesquisa etnográfica pontual e protótipos rápidos até estabilizar os padrões. Outro ponto: persona não substitui métricas de retenção e conversão. Ela direciona a atenção. Ela não garante que o produto vá bem. Se a sua taxa de ativação está ruim, ajustar a descrição da persona não resolve. Resolve entender o que o usuário efetivamente faz após o onboarding.
Um adendo prático sobre distribuição
Eu costumo exportar as fichas em formato simples, com campos padronizados. Nome, papel, objetivo, dores, contexto, fontes, o que descarta e links para registros de entrevistas. Mantenho tudo em um repositório acessível. Atualizo quando há mudança relevante. Se o time não consegue encontrar a persona em dois cliques, o documento está mal organizado, não o conceito. Em resumo, a técnica funciona quando ela gera clareza operacional. Funciona menos quando vira exercício de escrita. Comece pequeno, valide rápido, atualize com frequência. Se precisar de um template básico, eu monto uma ficha única com os campos citados acima e distribuo para o time de produto. Levanta dúvidas específicas, posso detalhar o passo de análise ou a parte de validação conforme o seu contexto.
