Porque você deve ler esse artigo?    Mostro aqui de um dos maiores aprendizados da minha vida profissional (e ainda penso isso 4 anos depois), onde todo o squad do time passou a atender clientes e tivemos incríveis ganhos em consciência de cliente, senso de dono, e correções rápidas.

Já parou para pensar em quanto tempo se perde para que uma reclamação ou sugestão de um cliente consiga chegar até você no desenvolvimento de um produto?

Você investe finalmente investe em pesquisa de usuários e enquanto está recebendo opiniões enviesadas seus clientes estão gerando reclamações valiosas para seu produto.

É uma abordagem tão simples e natural que fico pensando como não adotamos em larga escala, e por mais que eu gostaria de falar que fui o responsável, ela aconteceu por uma feliz soma de fatores: Um time engajado, proximidade física dos clientes e uma combinação especial de pessoas.

Eis o cenário atual:

1. Times de research inchados e custosos
2. Insights importantes que se perdem no fluxo de pesquisa
3. Entrevistas altamente scriptadas
4. Feedbacks enviesados
5. Distância de onde o feedback é coletado até o time de produto e dev

Normalmente em startups, principalmente nas de maior porte, o consumidor está longe não só fisicamente, mas o próprio organograma joga contra, fazendo com que as pessoas que possuem relacionamento direto com o cliente não possam compartilhar seus aprendizados diretamente com o design e desenvolvimento do produto.

Não é só isso, muitas vezes toda essa linha de frente é setorizada entre comercial, suporte e pós venda, contribuindo ainda mais para fragmentar e perder valiosas informações que poderiam ser cruciais para o produto.

E por fim essas pessoas estão mais preocupadas em vender, conduzir ao uso do produto ou serviço, ou resolver rapidamente seus próprios problemas. Elas têm uma meta de vendas, de quantidade de pessoas atendidas e até de tempo de atendimento para se preocupar; dificilmente irão anotar cada reclamação ou ideia que um cliente possa dizer durante um atendimento.

O time e o problema a ser resolvido

Cheguei nas primeiras semanas do primeiro time que estava se organizando como um squad, ou seja, vários profissionais de habilidades complementares organizados para atacar um único produto, neste caso o empréstimo consignado do banco.

O time era quase inteiramente novo, gabaritamos toda a cartilha de software ágil. Realizando todas as cerimônias, como as daily scrum, sprint planning, e depois começamos a renomear cada uma delas conforme fazia mais sentido por nós. 

A retrospectiva da sprint que acontecia nas sexta-feiras por exemplo virou o "dia de lavar roupa suja".

O produto era o empréstimo consignado, uma modalidade de empréstimo onde basicamente você paga por descontos na folha de pagamentos; exatamente por isso gera um risco menor para o banco que por sua vez oferece menos juros, uma modalidade comum para aposentados, pensionistas e servidores públicos.

Desse público, boa parte são aposentados, fazendo que um dos maiores desafios fosse o de desenvolver uma solução moderna, mas acessível para pessoas da terceira idade, muitas delas tinham pela primeira vez um smartphone  e pouco ou nenhum contato com produtos digitais.

Após uma etapa de pesquisa mais aprofundada, iniciamos nosso mínimo produto viável (MVP), uma primeira versão de software focado no usuário mobile que sintetizava todo o conjunto de hipóteses a serem validadas, com a menor quantidade de funcionalidades que entregam valor ao cliente.

A primeira versão desse MVP era esteticamente excelente, digno de portifólio no Dribbble (comunidade para designers), mas logo no primeiro teste com clientes, percebemos ser apenas bonito. Falamos com um, dois e no terceiro cliente veio uma ideia diferente, onde aumentaríamos todas as fontes, reduziríamos tudo a ponto de existir uma única ação por tela com o objetivo de gerar telas sem scroll.

Fazia sentido, já que 10 entre 10 clientes poderiam até não usar o Facebook (isso era 2018), mas usava o WhatsApp, onde o scroll era automático. O resultado veio rápido, e percebemos ter muito mais a aprendermos; cada vez mais próximo de nosso público.

Conversas diárias, de um jeito ou de outro

Em um dado momento, nosso MVP ganhou um pequeno botão de “ajuda” e lá os usuários podiam escolher utilizar o WhatsApp ou fazer uma ligação telefônica cujas ligações iam parar em nossa sala, foi aí que as coisas começaram a ficar divertidas, visto que o cliente começou a vir até nós.

O ramal ficava bem no meio da mesa principal, a vista de todos, e quando tocava sabíamos que provavelmente era um cliente do banco.

Nenhum cliente sabia que éramos desenvolvedores, designers e profissionais de tecnologia, e quase sempre já iniciavam a conversa com alguma dúvida ou reclamação, mas todas às vezes uma oportunidade única de aprendermos algo sobre nosso produto se ouvíssemos com a atenção devida.

O produto que estávamos era disponível apenas para parte da base de clientes do banco, e isso garantia suficientes ligações para gerar bons feedbacks, mas não a ponto de precisarmos de alguém dedicado para isso. 

O Product Owner (PO) do time era uma figura sem igual, que na época tinha pouca experiência de tecnologia, entretanto, possuía mais de uma década nos processos do banco e empatia com as pessoas. Ele sempre dizia detestar o termo “usuário” que usávamos e isso não fazia nenhum sentido para ele, talvez por isso quando atendeu a primeira ligação que tocou naquele telefone, disse:

ParanáBanco, bom dia! Setor de experiência do cliente…

A partir daquele momento sempre que falávamos com os clientes pretendíamos ser um tipo especial de call center, mesmo sem saber exatamente o que fazer em alguns casos, e isso também foi crucial e falarei a seguir.

Foi também neste exato momento que percebi que estávamos fazendo algo diferente...

Resolvi documentar o máximo que podia, inclusive comparando que estávamos fazendo com o de pesquisas tradicionais, e cheguei na seguinte tabela:

Dois ou três dias depois da primeira ligação eu atendia as ligações, e é óbvio que ainda não tinha conhecimento de todos os processos do banco e pedia auxílio para resolver problemas, mas já conseguia identificá-los e classificá-los.

Isso muda toda a dinâmica de feedback, não apenas na quantidade que pode aumentar muito, mas na qualidade, que pode gerar resultados em áreas até onde você não estiver procurando.

Certa vez, durante uma dessas conversas, descobrimos uma falha que atingia somente usuários do navegador “Internet” que geralmente só telefones Samsung possuem como padrão, um navegador que nem conhecíamos e claramente não foi testado até aquele momento.

“Minha internet não funciona.” — Disse a senhora.

O bug descoberto nem precisou se tornar uma história de desenvolvimento, foi resolvido em poucas horas e no dia seguinte já tivemos mudança instantânea na quantidade de pessoas que passavam através do chamado “funil de conversão”.

Algo que também surgiu naturalmente foi o processo de pedir permissão para o cliente para atendê-lo em viva voz, a ideia era tornar todo o time ciente de um determinado problema, e assim aumentar a empatia geral, puxando a responsabilidade para todo mundo ali.

Ownership que fala né?

Essas ligações quase sempre geravam algum tipo de discussão depois, afinal, queríamos relacionar aquele porque com algum dado maior, saber quantas pessoas estavam vivenciando aquilo.

Os problemas poderiam ser classificados em:

1. Bugs a serem resolvidos
2. Ajustes de usabilidade
3. Insights de produto
4. Novas funcionalidades.

O fluxo de cada coisa

1. Bugs a serem resolvido

Todas as falhas que pudéssemos resolver rapidamente não entravam necessariamente na sprint, isso se fossem muito críticas ou muito rápidas para serem resolvidos, já se o esforço fosse maior ela seria mapeada na sprint semanal de acordo com sua criticidade.

Ajustes de usabilidade

O restante era registrado em post-its e apresentadas ao time semanalmente como “Design Insights” antes da sprint planning, reunião em que alinhamos as demandas da próxima sprint.

Os ajustes de usabilidade por exemplo eram parecidos com os bugs, podendo ir de coisas pequenas (como descrições), ou maiores (como a mudança de um elemento completo) — e quase sempre se tornavam tarefa da próxima sprint.

Insights de produto

Sabe quando alguém te diz algo que te oferece uma luz diferente? É quase isso. Os insights eram basicamente novas formas de fazer algo: podia ser um fluxo mais curto, uma forma de comunicar algo conforme a própria descrição do cliente. Aqui tudo dependia muito da nossa percepção de ganho com o insight gerado, se fosse a mudança de um texto ou botão logicamente poderia acontecer no mesmo dia, já no caso de um fluxo poderia entrar no backlog de produto.

⠀

Nova funcionalidade

Esse era provavelmente o cenário mais raro, mas não necessariamente o menos importante, até porque já tínhamos muita coisa mapeada no backlog, e aqui com toda certeza iria passar por uma etapa mais longa de discussão e até de ideação onde por algumas usamos a dinâmica Crazy 8 que retirei do Design Sprint.

Aliás não apenas ela, mas várias ferramentas do Design Sprint podem ser tranquilamente adaptadas para a realidade do desenvolvimento de software ágil, mas talvez esse ponto específico seja papo para outro livro.

Conclusão

As conversas diárias geradas por essa mudança conseguiam mudar toda a percepção do time, isso nos tornou mais atentos ao que diferentes públicos tinham como necessidades e desejos, além da quantidade de feedback gerada pelo cliente que possibilita maior velocidade na melhoria de produto

Já a abordagem como SAC garantiu feedbacks mais reais, afinal, foi se tornando cada vez mais claro que as pessoas suavizam falhas quando conversávamos como uma pesquisa, e tinham completamente outra postura enquanto SAC.

Porém o maior de todos os ganhos em minha opinião foi na forma como todo o time encarou tanto o problema, os clientes, com muito mais empatia e responsabilidade no valor gerado de cada funcionalidade, de cada elemento de design e cada linha de código implementada.

Você passa a se importar muito mais se sabe que tem gente dependendo daquilo, enxerga essas pessoas, ouve essas pessoas e sabe que a vida delas podem depender de você, isso muda sua percepção do que faz.

E você já tentou algo parecido na sua empresa? Me conta por aqui. 

Aproveita e me segue no Instagram, onde eu compartilho um pouco sobre design e teoria comportamental.