#1 Cultura de Produto: Product Discovery na prática!

As startups e fintechs são provavelmente as empresas que mais investem tempo tentando entender as necessidades dos seus usuários e as oportunidades de mercado uma vez que boa parte delas ainda não conseguiu encontrar o tão sonhado market fit, e estão testando e pivotando ideias a todo momento em busca de algo que realmente funcione.

O empreendedor e professor Steve Blank desenvolveu uma metodologia chamada Customer Development, que inclusive está sendo utilizada nas aulas de algumas das melhores universidades do mundo, como Harvard, Stanford, Berkeley e Columbia.

O framework se divide em 4 etapas que passam por validar a necessidade que foi supostamente identificada, construir o produto certo para atender as necessidades identificadas, testar modelos e métodos para escalar o produto (aquisição de clientes) e implementar ferramentas e recursos adequados para manter e melhorar o produto. Esse é um framework amplamente utilizado nas startups e fintechs durante todo o ciclo de criação de produto.

Desde a época da faculdade eu nunca gostei de fazer trabalhos gigantescos e principalmente o famoso Trabalho de conclusão de curso (TCC). Entretanto, não gostar de fazer não era um bom argumento para convencer o professor, certo?

Passados anos fui fazer MBA (no Brasil) e me deparei com o então rebatizado - Plano de Negócios. Estávamos já em 2015, eu já tinha alguns anos de experiência profissional e dezenas de startups surgiam a cada momento com ideias inovadoras, trabalhando de formas nunca vistas antes, resolvendo problemas que nem nós mesmos sabíamos que tínhamos e causando um alvoroço danado nas "Blue Chips" do mercado.

Entediado, fui num evento de Startups em SP, no Cubo Itaú, e com aproximadamente 15 co-fundadores de startups no palco tive a oportunidade de fazer uma pergunta: "Como vocês começaram? Vocês transformaram a ideia num plano de negócios? Como foi esse processo?" Todos deram risada e a resposta unanime foi: Um Powerpoint e uma planilha Excel.

Enfim, o objetivo não é criticar as práticas tradicionais, quero só fazer a correlação de que nós levamos para dentro das empresas o aprendizado que tivemos ao longo da vida. A resposta dos co-fundadores foi sensacional, no fundo o que eles disseram é: Meu amigo, a gente está o tempo todo validando ideias e pensando em novas (Customer Development), não temos bola de cristal para determinar qual vai ser o faturamento da empresa daqui 5 anos se ainda nem sabemos se ela vai existir. Traduzindo, o recado que eu entendi é de que a todo momento eles estavam fazendo discovery para validar hipóteses ou buscar por problemas desconhecidos.

Além disso as startups são também conhecidas por usarem ferramentas mais recentes, clima mais descontraído, a vestimenta dos colaboradores não descrimina poder e conhecimento e, consequentemente formas diferente de resolver e abordar problemas.

E é aqui que eu queria chegar, a definição que eu mais gosto é que Discovery é uma abordagem para resolver de maneira efetiva um problema. Uma abordagem errada que percebo acontecer com frequência é os times utilizarem do argumento de que estão fazendo Product Discovery mas no fundo estão validando suas próprias ideias. Eu tive um gestor que repetia sempre uma frase emblemática "Não importa a opinião de ninguém aqui nessa sala, o que importa é o que os clientes acham".

Levando isso em consideração, vou compartilhar experiências reais que todos podem utilizar nos diferentes tipos de ambientes, sejam eles super regulamentados ou não.

Na prática

Eu gostaria de registrar que o Product Discovery é eminentemente um trabalho do Product Manager e do Product Designer. Não existem restrições sobre os Tech Leads não participarem mas não os envolveria em muito mais do que 10–20% do tempo deles, afinal, muitas coisas nesse processo não evoluem para além de uma conversa.

Enfim, procurei pensar em ferramentas e metodologias que ja utilizei com exemplos de aplicação.

• Design Sprint: Utilizamos essa metodologia em um dos maiores adquirentes do Brasil para descobrir os principais problemas que os nossos usuários encontravam ao utilizar nossos canais digitais para gerenciar suas vendas e recebimentos. Durante a semana que ocorreu a Design Sprint, fizermos sessões com clientes, diversas áreas internas da empresa, fornecedores, benchmarkings e protótipos. Como fruto desse trabalho reestruturamos todo o App e Site dessa empresa e obtivemos resultados impressionantes.
• Focus Group: Apesar de existir divergência sobre a efetividade do Focus Group por ser realizado em um ambiente não realista, continuo achando que tem bastante valor. Em casos extremos como um app que um motoboy utiliza na chuva, no sol e com capa de proteção sem dúvidas vale um teste em "vida real" também. Participei de dezenas de Focus Groups e destaco um em especial que rodamos em Nova York para validar problemas previamente identificados em outras dinâmicas, encontrar novos problemas e principalmente diferenças de necessidades entre geografias. Essa dinâmica nos mostrou a importância de levar em consideração diferentes perfis de uso dos seus consumidores, principalmente quando você é um produto global.
• Análise de comportamento: Uma forma simples de observar seu usuário usando o produto num ambiente normal é a utilização de ferramentas como o Smartlook, que te permite determinar variáveis que gravam usuários navegando pelo seu site ou app. Fizemos mudanças significativas no nosso produto assistindo como nossos usuários utilizavam, desde simples alterações em literais até mudanças de fluxos inteiros. Aproveite para utilizar o mapa de calor, você pode identificar áreas que são altamente acessadas e que podem estar sendo sub-utilizadas.
• Análise de feedbacks: Ouvir o seu usuário nunca é demais. Para aqueles que o produto se manifesta em forma de um App os reviews das lojas de aplicativos são uma fonte de informação extremamente valiosa. Ainda assim, podem utilizar ferramentas como Appbot e App Annie para facilitar as análises. Além disso, tenho percebido uma crescente utilização da metodologia de NPS no mundo digital, que pode ser facilmente implementada para colher a nota do produto como um todo, ou especificamente de algum pedaço dele/jornada. Em uma das minhas experiências o NPS da empresa era muito bom mas os clientes reclamavam bastante sobre o uso do produto em si. Utilizamos NPS para medir a satisfação dos usuários ao utilizarem o produto, tirando da cabeça deles o conceito do produto e chamando atenção para o uso efetivamente. O resultado foi drasticamente diferente e nos ajudou muito durante a priorização do nosso backlog.
• Análises quantitativas: Esse é um dever básico do nosso dia a dia mas que infelizmente nem todos os times utilizam. Conheci vários times que apesar de terem os dados disponíveis e com fácil acesso, simplesmente o ignoram e perdem a oportunidade de tirar proveito de uma das maiores fontes de informação disponível. Estou falando tanto de dados de navegação (também conhecido como digital analytics) como dados transacionais. O exemplo que eu tenho compartilhado ultimamente sobre esse tema aconteceu em um dia que ficamos sabendo que uma funcionalidade chave do produto estava fora do ar pelos próprios clientes e stakeholders da empresa. Um dashboard com a quantidade média de acessos e um alarme teria evitado isso, parece simples mas acontece mais do que imaginamos. Outro exemplo veio de uma análise que fizemos para entender oportunidades de conversão e churn. Percebemos que se não conseguíssemos converter os usuários em até 3 meses (de uma determinada etapa/momento), o esforço financeiro para fazê-lo depois era inviável, beirava uma conversão média próxima de 2%, contra mais de 60% inicialmente.
• Teste de guerrilha: Acho que esse nome tem sido bastante veiculado mas caso não conheça é tão simples quanto sair do ar condicionado confortável do escritório, abordar clientes ou não clientes na rua, por whatsapp, e fazer pequenas validações. Acho pouco aconselhável propor testes mais ligados a usabilidade pela falta de interações e dedicação devida.
• Testes de usabilidade: Normalmente quando você parte para um teste de usabilidade você já identificou os problemas e nesse momento você vai diminuir o risco do cliente não conseguir utilizar seu produto, um dos 4 riscos mencionados pelo Marty Cagan (usability risk). Já vi times fazerem testes de usabilidade usando sala espelho com uma baita estrutura mas também ja fizemos de maneira remota, usando plataformas como Upwork, por exemplo.
• Stakeholders: É natural que áreas de Sales, Ops, CX tenham conhecimentos importantes sobre problemas, dores e bottlenecks dos clientes. Entrevistar pessoas dessas áreas é uma prática que eu sempre tenho feito e além disso, analisar dados como: Quantidade de interações (chat, email, telefone), principais motivos de contato, segmentação desses dados por região, faixa etária, classe social ou seja la qual for o segmento que faz sentido para o produto em questão - podem revelar informações de extrema valia.
• Shadow: Como parte de um plano de discovery acompanhamos usuários indo treinar em academias em NY. Encontramos com eles desde o momento em que se preparavam para sair de suas casas até terminarem a atividade. Nosso papel foi não atrapalhar, só observar a rotina para ver como o produto é usado "na prática", que tipo de ações os usuários faziam em outros aplicativos ou sites para complementar suas necessidades etc.
• Benchmarking (direto e análogo): Muito comum e amplamente utilizado, não vou me estender muito mas acho valido compartilhar um aprendizado que eu tive: Benchmarking não significa copiar, por mais que seja o mesmo produto, você não sabe se seus usuários vão usar só porque o concorrente tem, e no fundo talvez você nem saiba se os usuários usam no concorrente.
• The Opportunity Solution Tree: A criadora dessa ferramenta é a Teresa Torres e ela descreve como uma representação visual de como alcançar o resultado desejado mapeando nossas oportunidades e gerando ideias para alcança-las. Para acessar o artigo completo clique aqui.

We don’t examine our ideas before investing in them” or “our solutions don’t connect to an opportunity or our desired outcome at all” .

Existem outras dezenas de formas e ferramentas de descoberta mas vale ressaltar também que Discovery não significa necessariamente que você vai ficar 10 ou 20 dias executando um plano com uma série de atividades. O Discovery tem que se tornar um processo para quando você se deparar com os desafios do dia a dia, você tenha condição de abrir o seu toolkit e aplicar um teste de guerrilha, por exemplo, em 2 horas para validar ou descobrir algo que gere valor para o seu produto.

Importante ressaltar que idealmente Product Managers deveriam investir a maior parte do tempo em descoberta, e tornar a descoberta de maneira geral uma atividade contínua, sem fim. Afinal, acredito que essa é uma das principais dinâmicas que nos diferencia de uma área de projetos.