Não sei você, mas por muito tempo quando eu ouvia o termo storytelling eu pensava em histórias encantadoras, imaginativas, que mexessem com os sentimentos das pessoas e fizesse as cabeças balançarem, em sincronia, dizendo “sim, sim, aceito, ótima ideia”.
A experiência, porém, me ensinou que não era nada daquilo.
Uma história sem um racional transparente e uma linha argumentativa sólida geralmente não serve para muita coisa. Você pode até encantar o seu público uma vez e convencê-lo de algo, mas se aquilo não tem base racional, seu público logo poderá ser convencido de outra ideia, antagônica, apenas porque a história era mais bonita.
Para quem já assistiu minha aula no curso de product manager da PM3 sobre gerenciamento de stakeholders, este artigo vai ser um bom complemento.
O único jeito seguro de engajar stakeholders e confiar que eles não vão mudar de ideia toda hora é entregar uma narrativa que faça sentido, que seja clara a respeito do que se sabe e do que não se sabe.
Até aí, nada de novo: separar o que se sabe do que não se sabe é fundamental na construção e evolução de produto (e até na vida, né?).
Mas como, exatamente, fazer isso?
Narrativa central
Imagine que você descobriu que um dos principais fluxos de uso do seu produto tem uma conversão de 15% e, segundo seus estudos, o ideal seria que ela ficasse em 40%. O fluxo é a ativação de uma ou mais configurações necessárias para a operação do cliente.
Investigando os problemas relacionados à baixa conversão, você chegou ao seguinte:
- 30% dos usuários que não convertem não entendem que o termo “salvar”. Não ativa o uso da ferramenta, mesmo tendo o botão “salvar e ativar” logo ao lado.
- 30% têm medo de clicar em “salvar e ativar” porque não sabem exatamente o que vai acontecer.
- 25% quer que a tarefa criada execute para sempre, porém “data limite” é um campo obrigatório (e entre os que completam o fluxo, cerca de 40% configura o limite para 10 ou mais anos, o que pode representar “para sempre”).
- 25% não entende o que acontecerá depois da “data limite”.
Obviamente, há usuários em mais de um grupo.
Mas até o momento, você ainda tem dúvidas:
- Unir “salvar” e “ativar” em uma coisa só vai aumentar a quantidade de pessoas que se sentem inseguras de ativar imediatamente?
- Remover a “data limite” aumenta o risco das pessoas esquecerem muitas configurações ativas e elas começarem a conflitar entre si. Não está claro como evitar isso.
Neste momento, talvez o ponto central da sua história seja:
A maioria dos usuários não completa o fluxo porque tem dificuldade com a diferença entre “salvar” e “ativar”, e porque a “data limite” gera confusão ou é desnecessária.
Eu geralmente começo por aí. Sintetizar em um parágrafo curto o centro do meu argumento.
Depois, gosto de desdobrar para uma sequência lógica.
Então, uma maneira de contar essa história com precisão seria:
- Considerando o direcionador estratégico X, entendemos que um número saudável para a conversão do fluxo “A” é 40%.
- Atualmente, esse número está em 15%. Esta é a tendência dele nos últimos X meses.
- Para entender os problemas atuais, investigamos da seguinte maneira: (explicar o racional da investigação).
- Descobrimos que os principais motivos são o “salvar” x “ativar” e a data de expiração, nestas proporções: (gráfico na tela!).
- Alguns exemplos mais práticos – screenshots, quotes reais de clientes etc.
- O que a gente ainda não sabe. Que dúvidas ficaram a ser resolvidas, e como pretendo endereçá-las. Ou, se não pretendo, por que. Afinal, há dúvidas cuja resposta é simplesmente viver com elas.
- Pedido claro de engajamento para o que eu quero – que pode ser aprofundar a pesquisa, refazer o fluxo inteiro, conduzir experimentos etc. Idealmente, se estou contando a história para alguém, estou contando porque preciso que essas pessoas engajem de alguma maneira – aprovando, apenas concordando ou participando da execução.
- Argumentos que quebrem as principais objeções, que terei levantado previamente refletindo sobre ou sondando com algumas pessoas de confiança.
Com pequenas variações, essa é a sequência que eu gosto de usar para contar uma história de produto.
Parece óbvio, mas se você não fizer esse tipo de exercício prévio, a chance de dar errado é enorme. Faça isso em texto. Esqueça slide. Esqueça Excel. Esqueça modelos (templates). Texto!
Se você não souber escrever a linha central de um argumento que faça algum sentido, torne isso sua prioridade em sua formação como Product Manager.
Alguns estilos de narrativa
A partir disso, você vai encontrar o seu estilo de narrativa, sempre adaptando ao contexto da reunião – por que as pessoas estão ali, quem são essas pessoas, o que você espera delas.
1. Comédia
Eu tenho um estilo peculiar de humor, mas evito usar de improviso porque sei que a chance de eu exagerar é grande. Então, prefiro pensar antecipadamente em alguma gracinha para descontrair a apresentação na hora certa. Ainda assim, pensando que as pessoas podem interpretar como palhaçada fora de hora e isso se virar contra mim.
O ponto é que se você vai usar humor, você não pode fazer isso com a expectativa das pessoas darem risada. Tem que estar pronto para, caso ninguém embarque na piada, seguir como se nada tivesse acontecido.
2. Drama
Estilos mais emotivos, que tendem a pegar um cliente (real ou fictício) como arquétipo e contar uma história individualizada desse cliente:
O cliente X (trate pelo nome, claro) tentou criar uma configuração e se deparou com esta tela (print da tela!), sem saber o que aconteceria se ele clicasse no “salvar e ativar”. (Traz aqui uma citação do cliente.) E por aí vai…
Eu gosto, mas não sei fazer muito bem, então evito essa abordagem. Mal feita, ela parece artificial demais. Se você for por essa linha, cuide para que a narrativa tenha naturalidade.
Aliás, vale o reforço: naturalidade é essencial. Se você tem dificuldade com exposições em público, como eu, a melhor maneira de adquirir naturalidade é dominar o assunto. Fez um bom estudo? Entendeu bem o que foi descoberto e construiu uma linha argumentativa coerente (usando a prática que sugeri acima)? Então, vai ser muito mais fácil apresentar com naturalidade.
Um erro que já cometi bastante, principalmente em registros que fazia para mim mesmo, é abandonar a precisão em nome do estilo. Em outras palavras: para deixar a história mais bonita e mais poética, encher de aumentativos, superlativos e advérbios de intensidade.
O texto fica enfático, mas desastrosamente impreciso.
Se o seu objetivo é apresentar seu estudo, fique no que é concreto. Expresse corretamente o que você sabe, o que você supõe, o que você acredita que seja verdade… a vida como ela é!
3. Analítico
Por último, existe a possibilidade de uma narrativa racional, sem comédia nem drama. É a mais segura, mas você precisa tomar muito cuidado para não ficar entediante.
Quando vou por esse caminho, gosto de fazer “checagens” com o meu público.
Considerando o exemplo acima, logo depois do item 5 (“alguns exemplos mais práticos – screenshots, quotes reais de clientes etc.”), eu faria um resumo do que foi falado até ali:
Então, temos uma conversão de 15%, tendo que chegar a 40% conforme tal direcionamento estratégico da empresa, mas esbarrando nos problemas de “salvar e ativar” e “data limite”. Vamos em frente?
Reparem que estou condensando em uma frase o que levei alguns minutos para apresentar e comprovar. É importante que o público me acompanhe, então essa recapitulação serve para garantir que, de tudo que foi falado, o mais importante a ser gravado é esse resumo.
O que nos leva ao próximo ponto:
Dica final: expandir e sintetizar
Se você desenhou bem o ponto central do seu argumento, contar a história é “apenas” uma questão de quanto tempo você tem.
Tomo aqui de exemplo um dos meus filmes favoritos: 300.
Se eu tivesse que resumir suas duas horas de história em até 150 palavras:
“Diante da ameaça do exército persa, que propõe a submissão de Esparta como maneira de evitar conflito, Leônidas tenta conseguir aprovação do Conselho e dos sábios para entrar em guerra durante o período sagrado em que guerras eram proibidas. Como não consegue, ele reúne 300 de seus melhores soldados e vai em direção ao exército persa, tentando adiar sua chegada a Esparta. Sua aposta é em ganhar tempo enquanto Esparta aprova a ida à guerra. Utilizando seu conhecimento da geografia local, leva a batalha a um lugar onde a superioridade numérica do exército persa é quase irrelevante. Ele é traído por um espartano que havia tentado se juntar ao exército mas fora recusado. Morre junto de seu exército, logo após enviar um emissário de volta a Esparta para contar sua história e chamar toda a cidade para a guerra.“
Em até 100 palavras:
“O exército persa avança e pede a rendição de Esparta. Leônidas recusa e busca aprovação do Conselho e dos sábios para ir a guerra, mas eles recusam, por ser um período de importância religiosa. Leônidas reúne 300 soldados para conter o avanço do exército persa em uma região geográfica que torna inútil a superioridade numérica dos persas. Traído por um espartano que fora recusado em seu exército, Leônidas e seu exército vão para a batalha final, onde certamente morrerão, mas antes envia um emissário para contar sua história e chamar Esparta para a guerra.“
Em 50 palavras:
“Sem aceitar render-se aos persas e diante da recusa do Conselho em ir à guerra, Leônidas reúne 300 soldados para conter o avanço inimigo, até que os espartanos fossem convencidos a guerrear. Antes de sua última batalha, envia um emissário para contar sua história e chamar Esparta à guerra.“
A essa altura, você já entendeu meu ponto.
E se você se propuser a exercitar essa prática acima, em pouco tempo estará criando histórias mais precisas e consistentes.
Storytelling é literalmente contar uma história. Em Produto, essa história (também) é sua. Mesmo com o squad trabalhando junto, você liderou esse negócio! Você pesquisou, você descobriu, você aprendeu, você testou.
Contar a história para seus stakeholders é só exteriorizar aquilo que você já deve ter feito dezenas de vezes internamente: contar a história para si mesmo.
Você está apenas dando um formato agradável, dentro de um limite de tempo, para um racional que você construiu e explorou – porque é exatamente esse o seu trabalho como Product Manager.
Então, nesse momento, seu dever é narrar com precisão.
Se você não tiver clareza da história, volte para o início do tabuleiro.
Bônus track
Esta era a linha central deste artigo:
Para criar uma narrativa que engaje seus stakeholders, você precisa ter muita segurança do conteúdo (o que você sabe / estudou / refletiu), para então dar uma forma agradável, com algum estilo, conforme o contexto. Se você domina o conteúdo, pode contá-lo de formas diferentes e de acordo com o tempo disponível para apresentá-lo.
E esta era a sequência planejada:
- Storytelling não é “contar histórias bonitinhas”. O foco é engajar e convencer.
- Em produto, isso só funciona se tiver conteúdo. Narrativa bonita sem conteúdo não adianta nada, porque logo os stakeholders serão convencidos de outra coisa.
- Dar um exemplo de como construir um argumento central.
- Dar exemplo de como construir uma sequência / um roteiro lógico da narrativa.
- Estilos possíveis para dar a “roupa” ao conteúdo apresentado. (Mas não cair no erro de priorizar estilo ao conteúdo.)
- Treinar a capacidade de contar a mesma história em diferentes formatos e tamanhos.
- Reforçar que storytelling para stakeholders é uma consequência natural do storytelling para si mesmo, construído durante o estudo, não depois.
Mais conteúdos para te ajudar a ser um(a) PM melhor:
